I call pg_ctl -D /var/lib/pgsql/10/data promote to upgrade slave to master when failover happens
I repoint slave to the master by stopping it, updating recovery.conf and restarting it. Let me know if I'm doing it wrong.
Thank you for clarifying that contents of WAL files from stream and fetch method should be different. The fact remains that WAL file created during the backup by stream method does not have extension .done and new master repeatedly fails to archive it because previous master archived it. This does not happen in fetch mode where file created during backup has .done extension.
On Sun, Feb 17, 2019 at 5:27 PM Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Feb 15, 2019 at 12:03:39PM -0800, Andre Piwoni wrote: > My slave nodes were created using pg_basebackup with --wal-method=stream. > If I understand right this option streams WAL files generated during backup > and this WAL file was 000000010000000000000002 but its contents were > different from what was on the primary and in WAL archive. When I changed > --wal-method=fetch which collects WAL files generated during the backup at > the end then diff did not detect any changes. When I failover I don't seem > to have the issue with new primary to archive. > > It seems streaming WAL segments created during backup produced corrupt file > based on diff.
Nope, --wal-method=stream and fetch behave as they are designed for. "fetch" would include all the contents of pg_wal/ as part of a BASE_BACKUP command using the replication protocol while "stream" would make the base backup avoid copying all WAL files, copying them in parallel with a secondary process which uses the same facility as pg_receiverwal, in which case the set of files in pg_wal/archive_status/ has little meaning.
I am also curious about the way you use to do failovers. Let me guess: you stop the standby, delete its recovery.conf and then restart the former standby? This would prevent a timeline jump at promotion which would explain the conflicts you are seeing when archiving two times the same segment. -- Michael
