On 3 August 2018 at 21:59, Michael Paquier <michael@paquier.xyz> wrote:
> On Wed, Aug 01, 2018 at 09:09:30PM +0000, Richard Schmidt wrote:
>> Our procedure that runs on machine A and B is as follows:
>>
>> 1. Build new databases on A and B, and configure A as Primary and B
>> as Standby databases.
>> 2. Make some changes to the A (the primary) and check that they are
>> replicated to the B (the standby)
>> 3. Promote B to be the new primary
>> 4. Switch of the A (the original primary)
>> 5. Add the replication slot to B (the new primary) for A (soon to
>> be standby)
>> 6. Add a recovery.conf to A (soon to be standby). File contains
>> recovery_target_timeline = 'latest' and restore_command = 'cp
>> /ice-dev/wal_archive/%f "%p"
>> 7. Run pg_rewind on A - this appears to work as it returns the
>> message 'source and target cluster are on the same timeline no
>> rewind required';
>> 8. Start up server A (now a slave)
>
> Step 7 is incorrect here, after promotion of B you should see pg_rewind
> actually do its work. The problem is that you are missing a piece in
> your flow in the shape of a checkpoint on the promoted standby to run
> after 3 and before step 7. This makes the promoted standby update its
> timeline number in the on-disk control file, which is used by pg_rewind
> to check if a rewind needs to happen or not.
>
> We see too many reports of such mistakes, I am going to propose a patch
> on the -hackers mailing list to mention that in the documentation...
I think the problem is that writing the online checkpoint is deferred
after promotion, so this is a timing issue that probably doesn't show
in our regression tests.
Sounds like we should write a pending timeline change to the control
file and have pg_rewind check that instead.
I'd call this a timing bug, not a doc issue.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services