Skip site navigation (1) Skip section navigation (2)

Re: streaming replication

From: senthilnathan <senthilnathan(dot)t(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: streaming replication
Date: 2011-11-29 12:08:32
Message-ID: 1322568512313-5032131.post@n5.nabble.com (view raw or flat)
Thread:
Lists: pgsql-admin
Just check the following thread for more details:
http://postgresql.1045698.n5.nabble.com/Timeline-Conflict-td4657611.html

> 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?
... [show rest of quote]

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.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 


--
View this message in context: http://postgresql.1045698.n5.nabble.com/streaming-replication-tp4954954p5032131.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

In response to

pgsql-admin by date

Next:From: David SchnurDate: 2011-11-29 15:28:33
Subject: Re: Repeatable crash in pg_dump (with -d2 info)
Previous:From: Scott MarloweDate: 2011-11-29 04:51:07
Subject: Re: Database is in recovery mode.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group