Hello,
Thank for all this informations
Le 13/11/2012 09:31, Albe Laurenz a écrit :
> Philippe Amelant wrote:
>> I'm setting up a 3 nodes cluster and after some tests
>> I just discover that the cascading slave does not recover.
> Right, switching timeline over streaming replication
> is not supported yet. There's a patch by Heikki in
> the pipeline for this, so it will probably work in 9.3.
So if I understand it, I need to rebuild the cascading slave if I
promote the first standby.
Is there a way to follow the new master without rebuild ?
>> As far as I can see in the 9.2 documentation it should work after
>> an automatic reconnect to the new master.
> Where did you see that?
I found this
http://www.postgresql.org/docs/9.2/static/warm-standby.html
25.2.6. Cascading Replication
Promoting a cascading standby terminates the immediate downstream
replication connections which it serves. This is because the
timeline becomes different between standbys, and they can no longer
continue replication. The affected standby(s) may reconnect to
reestablish streaming replication.
So i was thinking it was just a reconnect to the sender (and I can see
the standby trying to reconnect in the log)
>> Is there any chance to get this fixed in 9.2.x ?
> No. It is a new feature, and those aren't backpatched.
>
>> In case of disaster on master and on standby, can I just restart the
>> cascading slave
>> after removing recovery.conf ?
> The correct way it to "pg_ctl promote".
>
>> Would it be better to copy all archives log from the master in pg_xlog
>> on the third node
>> and then restart it ?
>> What is the best way to get back this node with minimal loss?
> You can copy the archives, then wait until replication has
> caught up, then promote the standby.
>
Ok thanks, I will work on this.
Regards