Re: warm standby and reciprocating failover.
От | james bardin |
---|---|
Тема | Re: warm standby and reciprocating failover. |
Дата | |
Msg-id | a3b675320908240834y49be9617sa2ab1b97d70a067c@mail.gmail.com обсуждение исходный текст |
Ответ на | warm standby and reciprocating failover. (james bardin <jbardin@bu.edu>) |
Список | pgsql-admin |
On Fri, Aug 21, 2009 at 10:46 AM, james bardin<jbardin@bu.edu> wrote: > The first move runs easily as expected- postgres ships the last > partial wal immediately on shutdown, trigger the standby and we're up. > I'm now running into issues bringing the first server back up in > standby mode. After the second server finishes recovery, the major > number of the wal files is incremented (say from 00000001 to > 00000002), and the 00000002.history file is shipped back to the first > server. The first server however is still looking for 00000001x files. > So I've been experimenting with this timeline problem without any success. Is it possible that there are changes made during recovery that aren't logged? I tried recovery_target_timeline='X' on the standby, where X is the new timeline created after recovery on the new master. This fails, with some "unexpected timeline ID" lines and a PANIC: could not locate a valid checkpoint record I also tried using recovery_target_timeline='latest'. This fell back gracefully to an earlier state, but changes were lost. Also, it never waited on pg_standby, and finished recovering immediately. Although it doesn't solve this problem, can pg_standby be used with recovery_target_timeline='latest', or should I file a bug? Thanks -jim
В списке pgsql-admin по дате отправления: