Обсуждение: warm standby and reciprocating failover.

Hello,

I have a working warm standby system, running 8.4 (thanks for urging
me to upgrade from the rehdat provided release).
One of the new requirements is going to be for (a non-DBA) admin to
easily swap services between the two servers for maintenance.

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.

Is there a way to ship back the missing information from the recovery
process, without doing another base backup of data/ ?

Thanks
-jim

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