Re: Timeline Conflict - Mailing list pgsql-general

From Simon Riggs
Subject Re: Timeline Conflict
Date
Msg-id CA+U5nML+T8poWS_TqsrAz=tXd79m+70HPP1Y-vn6bf34R1ci1w@mail.gmail.com
Whole thread Raw
In response to Re: Timeline Conflict  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-general
On Wed, Aug 3, 2011 at 2:38 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 2:59 PM, senthilnathan <senthilnathan.t@gmail.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?
>
> Basically you need to take a fresh backup from new master and restart
> the standby
> using it. But, if S1 and S2 share the archive, S1 is ahead of S2
> (i.e., the replay location
> of S1 is bigger than or equal to that of S2), and
> recovery_target_timeline is set to
> 'latest' in S2's recovery.conf, you can skip taking a fresh backup
> from new master.
> In this case, you can re-point S2 as a standby just by changing
> primary_conninfo in
> S2's recovery.conf and restarting S2. When S2 restarts, S2 reads the
> timeline history
> file which was created by S1 at failover and adjust its timeline ID to
> S1's. So timeline
> conflict doesn't happen.

Though this relies upon a shared archive which gives a single point of failure.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-general by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Timeline Conflict
Next
From: Rory Campbell-Lange
Date:
Subject: Re: Problem with selecting arrays in set-returning plpgsql function