From: | Andre Piwoni <apiwoni(at)webmd(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Promoted slave tries to archive previously archived WAL file |
Date: | 2019-02-19 16:57:18 |
Message-ID: | CAEC-+VGFvVdbaYYvaG_MMpujsej8=2NgO85Wks6SA-T1Fe2k4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)paquier(dot)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
>
--
*Andre Piwoni*
Sr. Software Developer, BI/Database
*Web*MD Health Services
Mobile: 801.541.4722
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Lewis | 2019-02-19 17:11:33 | Re: Postgresql RDS DB Latency Chossing Hash join Plan |
Previous Message | Martín Fernández | 2019-02-19 16:51:12 | Re: PG Upgrade with hardlinks, when to start/stop master and replicas |