Le 13/11/2012 14:57, Albe Laurenz a écrit :
Philippe Amelant wrote:
So i was thinking it was just a reconnect to the sender (and I can see
the standby trying to reconnect in the log)
Hmmm. I think I was too quick when I said no.
If you ship the WAL archives including the "history" file to the
standby, then the standby should be able to recover across the
timeline change from the archives (if you have recovery_target_timeline
set to "latest" in recovery.conf) and then reestablish streaming
replication.
I never tried that though.
(The patch I quoted above would allow the timeline change via
streaming replication.)
Yours,
Laurenz Albe
You're right
I added
recovery_target_timeline='latest'
in the recovery.conf then I promoted the standby.
The replication on the second standby stopped with a message
complaining about timeline.
Then I copied the archived wal from the new master to the (stopped)
standby (in pg_xlog)
The standby restarted on the new timeline and the datas seem to be ok.
I also tried to just copy the last 000000X.history in pg_xlog and it
work too.
I suppose this could fail if max_wal_keep_segment is too low
Thanks you very much for your help.
Could you just point me where you found this information in the doc ?
Regards
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
