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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
