Re: Timeline Conflict

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.

In response to

Responses

Browse pgsql-general by date

  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