On Thu, Jan 11, 2018 at 04:58:02PM +0000, Dylan Luong wrote: > The steps I took were: > > 1. Stop all watchdogs > > 2. Start/stop the old master > > 3. Run 'checkpoint' on new master > > 4. Run the pg_rewind on old master to resync with new master > > 5. Start the old master (as new slave) That's a sane flow to me. > 2018-01-11 23:21:59 ACDT [112235]: [2-1] db=,user= app=,host= FATAL: could not receive data from WAL stre > am: ERROR: requested WAL segment 0000000600000383000000BE has already been removed > > Has anyone experience this before with pg_rewind? When restarting a standby after a rewind has been done to it, note that, in order to recover to a consistent point, it needs to replay WAL from the previous checkpoint checkpoint where WAL has forked during the promotion up to the point where the rewind has finished. Per your logs, I am getting that the previous checkpoint before the timeline jump is located in segment 0000000X00000383000000BE, but this did not get archived. > The earliest wall files in the archive directory was around just after the failover occurred. > > Eg, in the archive directory on the new Master: > $ ls -l > total 15745032 > -rw-------. 1 postgres postgres 16777216 Jan 11 17:52 0000000500000383000000C0.partial > -rw-------. 1 postgres postgres 16777216 Jan 11 17:52 0000000600000383000000C0 > -rw-------. 1 postgres postgres 16777216 Jan 11 17:52 0000000600000383000000C1 > -rw-------. 1 postgres postgres 16777216 Jan 11 17:52 0000000600000383000000C2 Yeah, you are looking for the WAL segment just before the last, partial WAL segment of the previous timeline. Depending on your archiving strategy, I guess that you should have set archive_mode = 'always' so as the server which was the standby before the promotion is also able to store them. -- Michael
Attachment:
signature.asc
Description: PGP signature
