From: | Pedro Sam <pesam(at)rim(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | senthilnathan <senthilnathan(dot)t(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Timeline Conflict |
Date: | 2011-08-02 19:17:58 |
Message-ID: | 077B647C27DECA4F915A81CA368C84C303179EB02A@XCH119CNC.rim.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've been trying to use repmgr for just that purpose. Looks like it simply creates/modifies a recovery.conf pointing primary_conninfo to the new master, and then restart. It does not seem to have the ability to resolve any timeline conflicts at all.
Am I using repmgr incorrectly?
-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Simon Riggs
Sent: Tuesday, August 02, 2011 12:07 PM
To: Merlin Moncure
Cc: senthilnathan; pgsql-general
Subject: Re: [GENERAL] Timeline Conflict
On Tue, Aug 2, 2011 at 2:55 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Aug 2, 2011 at 12:59 AM, senthilnathan
> <senthilnathan(dot)t(at)gmail(dot)com> wrote:
>> We have system(Cluster) with Master replicating to 2 stand by servers.
>>
>> i.e
>>
>> M |-------> S1
>>
>> |-------> S2
>>
>> If master failed, we do a trigger file at S1 to take over as master. Now
>> we
>> need to re-point the standby S2 as slave for the new master (i.e S1)
>>
>> While trying to start standby S2,there is a conflict in timelines, since
>> on
>> recovery it generates a new line.
>>
>> Is there any way to solve this issue?
>
> AFAIK, the only solution is to follow the initial standby setup
> process to bring the standby up to sync with the new master. One
> small comfort is that since the standby is mostly in the state it
> needs to be, an rsync based process might happen fairly quickly. This
> of course means that if you lose the new master before the standby is
> up to speed you are facing data loss. I'm really curious if anyone
> has figured out a potential solution to this problem.
http://projects.2ndquadrant.com/repmgr
solves the problem
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
From | Date | Subject | |
---|---|---|---|
Next Message | bubba postgres | 2011-08-02 19:35:45 | Re: pg_largeobject vs pg_toast_XXXX |
Previous Message | Rory Campbell-Lange | 2011-08-02 19:05:48 | Problem with selecting arrays in set-returning plpgsql function |