Re: Streaming replication upgrade sanity check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > It looks like the most correct approach would be to discard the
> > standby systems and just do a new pg_basebackup, but quite a few of
> > the pairs have a standby on AWS and limited upstream bandwidth, so the
> > basebackup can take several days. I'd like to avoid that if I can.
> >
> > So, my thought is to just upgrade the active side as normal, and once
> > that's done and the master is back in use, stop the standby's
> > postgres, call "pg_start_backup(...)" on the master, rsync the changed
> > files from the running master's data dir to the standby's 10.x data
> > directory, call "pg_stop_backup()", migrate the recovery.conf into a
> > postgresql.auto.conf, touch the standby.signal file, and then start
> > the new postgres 13 on the standby. That seems to work, but I want to
> > be sure I'm not just having good luck due to the relatively low
> > activity on my test systems.
> >
> > I use named replication slots with my streaming replication, so I
> > think that the rsync'd pg_wal directory should have everything I need
> > (or maybe this isn't guaranteed?), and the pg_start/stop_backup will
> > ensure that all the damage done by rsync'ing an active database can be
> > repaired from the pg_wal files that rsync fetches. Are those
> > assumptions right, or am I missing anything else? Is this idea
> > workable at all?
>
> Did you see the pg_upgrade instructions on upgrading standby servers?
> Why are you not using that?

Specifically referring to [0], the part I can't do (and that I
unfortunately left out of my initial email) is right at the beginning,
"Do not start any servers yet". The master needs to get running again
as soon as it's upgraded, and the standby systems can't stop the
master for their upgrades. I believe what I've described is
essentially the documented approach, but with a running master and
then wrapping the rsync command in pg_start_backup/pg_stop_backup
calls, but is it still a correct way to upgrade? From the
pg_start_backup description on the binary replication tutorial [1], it
looks like it should be, but I'd like to know if I'm missing anything.

0 - <https://www.postgresql.org/docs/current/pgupgrade.html#PGUPGRADE-STEP-REPLICAS>
1 - <https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial#Cloning_a_Snapshot_of_the_Master>





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux