public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: [email protected] <[email protected]>
Subject: Re: Upgrade Failover Cluster
Date: Thu, 4 Dec 2025 08:57:30 -0500
Message-ID: <CANzqJaA7NOamDoVLpc478BuxXMMEjiCAJUvHHdwUY5P63LQPSw@mail.gmail.com> (raw)
In-Reply-To: <DU2PR04MB8631002517CF55E7E48B6FB1E3A6A@DU2PR04MB8631.eurprd04.prod.outlook.com>
References: <DU2PR04MB8631002517CF55E7E48B6FB1E3A6A@DU2PR04MB8631.eurprd04.prod.outlook.com>
On Thu, Dec 4, 2025 at 2:00 AM BUBACZ Martin <[email protected]> wrote:
> Hi All,
>
>
>
> I’m fairly new to postgresql and I have a question concerning upgrading a
> 2 node failover physical replication cluster. I’m automating the cluster
> installation and maintenance by using Puppet. All runs good so far.
>
>
>
> When it comes to an upgrade scenario, let’s say upgrading from rel. 16.x
> to 17.x, I’m unsure if it is required to upgrade primary first and then
> replica or if order doesn’t matter. I’ve read different statements in some
> articles on internet about it. One said it’s possible to upgrade replica
> first by using pg_upgrade or rebuilding replica from primary by
> pg_basebackup and others are telling me primary first.
>
>
>
> What is the recommended/most stable path to upgrade a cluster? I would
> appreciate if you could shed some light on this? Thanks beforehand.
>
One standard low-downtime practice is:to do *logical* replication from the
Primary to the Secondary. Then promote the Secondary to be the New
Primary, and do a pg_basebackup from it back to the Old Primary.
The other low- (but not as low) downtime method is to stop replication, and
pg_upgrade the Primary. (It's fast with the --link option, but there's no
going back once you start the upgraded instance.) Then pg_basebackup to
the Secondary as normal.
Last is to stop replication and then do a normal pg_upgrade. It's still
fast, but copies all data to a new directory, but that "fast" is relative
to how big your data is.
Which you choose depends on how much downtime you can get and (since LR
doesn't replicate DDL and sequences) how often the DDL changes.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
reply
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: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Upgrade Failover Cluster
In-Reply-To: <CANzqJaA7NOamDoVLpc478BuxXMMEjiCAJUvHHdwUY5P63LQPSw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox