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