Re: Understanding streaming replication
От | Philippe Amelant |
---|---|
Тема | Re: Understanding streaming replication |
Дата | |
Msg-id | 50A24BA6.7090302@companeo.com обсуждение исходный текст |
Ответ на | Re: Understanding streaming replication ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Understanding streaming replication
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: