From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: tsuraan <tsuraan@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: Streaming replication upgrade sanity check
Date: Thu, 11 Mar 2021 21:37:28 -0500
Message-ID: <20210312023728.GB2999@momjian.us> (raw)
In-Reply-To: <20210312010124.GW20766@tamriel.snowman.net>
References: <CALKcMwLoZajZ8_8OJefNgaCiaXa0MsbDFiiWN-nYyGD-9gAbiA@mail.gmail.com>
<20210312005016.GV20766@tamriel.snowman.net>
<20210312005557.GA2999@momjian.us>
<20210312010124.GW20766@tamriel.snowman.net>
On Thu, Mar 11, 2021 at 08:01:24PM -0500, Stephen Frost wrote:
> > He/she wants to run the standby, I guess in read-only mode, while
> > pg_upgrade is running, which is why I didn't even bother to mention
> > that. I think if downtime is the critical for this person, he/she
> > should be using logical replication for the upgrade. pg_upgrade really
> > wants full control of the primary/standbys during its operation, and if
> > you can't do that, pg_upgrade is not the right tool to use.
>
> What I typically do in that case is just spin up more replicas and let
> those handle the read load while the upgrade happens, and then throw
> them away after the upgrade of the primary plus the other standbys is
> done. I do agree that logical replication could be an alternative but
> that takes a lot longer and puts a number of constraints on what you can
> do while it's going on (DDL changes and such have to be done carefully,
> etc).
Agreed. He/she could use some replicas to take read-only traffic while
the upgrade happens, and use others to do a quick rsync upgrade using
the intructions in the pg_upgrade docs. I agree logical replication is
a lot more complex.
> > > unlogged tables before the pg_upgrade, et al, otherwise you'll end up
> > > rsync'ing those over. Also make sure you haven't got any stray or
> > > forgotten temp files or other things. Again, done properly, the rsync
> > > to upgrade the standbys should only be copying the catalog tables
> > > themselves and it should be quite fast.
> >
> > Yes, good points.
>
> Yeah.. Would really be nice if we had a custom written tool which knew
> how to detect unlogged tables and not try to copy them over and such.
> Might be able to make something that's faster and less error-prone than
> the rsync approach since we know a lot more about the PG data dir than
> rsync does.
True.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: bruce@momjian.us, sfrost@snowman.net, tsuraan@gmail.com
Subject: Re: Streaming replication upgrade sanity check
In-Reply-To: <20210312023728.GB2999@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox