Re: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster - Mailing list pgsql-admin

From Scott Ribe
Subject Re: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster
Date
Msg-id 866D2812-D9DE-4920-8C6C-0EF1761970F5@elevated-dev.com
Whole thread Raw
In response to Re: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster  (Scott Ribe <scott_ribe@elevated-dev.com>)
Responses AW: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster
List pgsql-admin
> Are you mean do the following step:
>
> 1- upgrade primary node
> 2- take base backup from new  version in primary node and keep wal file for 3 days
> 3- move backup by external hard disk to the replica node
> 4- restore base backup to replica
> 5- start replication to replicate delta from primary node.
>
> Please confirm if this the best approach and it will work without risk.

Yes, that's what I meant. It will work, nothing is completely without risk ;-) Main thing is to make absolutely sure
youdon't lose WAL during that time period. If you could set up WAL archiving to push to the remote site, that would be
greatas then you could configure the remote to pull accumulated WAL locally instead of across the slow network link. 

But, just thought of this:

- pg_upgrade both sides
- with neither side running, rsync the data directories (bonus points for being paranoid and using -c)
- fix up the standby flag on the standby
- fix up the postgresql.conf -- for instance, standby config has been moved out of a separate file into the main one,
sothat you can have common config both sides now, with the only necessary difference being the standby flag 
- bring them up

You could even try to figure out where the catalog tables are stored and only rsync those, since pg_)upgrade doesn't
changethe format of your data files. But personally, I wouldn't. I wouldn't want to introduce the possibility of error
onmy part, and the rsync checksum is a nice check that nothing has gotten corrupted over time from network or disk
glitch.(Excluding disk glitch on the primary...) 

You may be wondering why not just pg_upgrade both sides? Well, pg_upgrade ourput should be deterministic, right? So if
youmake sure that clients are disconnected and standby is completely in sync before starting, why not? Maybe you could.
Butbecause it's not designed nor documented for that use, so although you likely could make it work, that's a dangerous
path.The last thing you want to do is take your server down for this scheduled operation, and wind up at the end with
anunusable standby. 




pgsql-admin by date:

Previous
From: Scott Ribe
Date:
Subject: Re: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster
Next
From: "Dischner, Anton"
Date:
Subject: AW: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster