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