On Fri, Aug 11, 2017 at 8:10 AM, Don Seiler <don@xxxxxxxxx> wrote: > On Thu, Aug 10, 2017 at 1:13 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> Set keep wal segments to something largish (1000 or so) well before >> the upgrade etc. Make sure the volume holding pg_xlog can hold >> 1000*16MB of data. This ensures the streaming replicant can catch up >> if some stuff happens before it's back up. > > > If we have both primary and standby down at the same time, would this really > still be necessary? FWIW right now ours is set to keep 128. It's nice in case the replica hangs or acts up, you won't have to resubscribe it should it run through the first 128 wal segments etc. > Also, going back to my original question. Once both are down, is it best > practice to perform patching/upgrades on the standby first (starting > furthest downstream if cascading)? e.g. patch/upgrade the standby (via > standard CentOS7 yum from the repo), then start the standby DB and verify > nothing has broken, then do the same to the upstream or primary? Lots of ways to do this. One way is to make a replicant, remove it from the cluster and fail it over and then upgrade it and test the crap out of it distinctly from production. Load test, proper behavior testing, and so on. If you're doing minor upgrades, you don't need to bring down the whole cluster, you can take a single replica out and upgrade pg on it, then put it back in the cluster. Again, if you have enough kept wal segments, or you use replication slots, then it will just catch right up. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
