| From: | Michael Banck <mbanck(at)gmx(dot)net> |
|---|---|
| To: | Mahesh Sathe <maheshsathe1(at)gmail(dot)com> |
| Cc: | Raj <rajeshkumar(dot)dba09(at)gmail(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Major upgrade in patroni cluster |
| Date: | 2026-07-06 10:56:19 |
| Message-ID: | 20260706105619.GB6368@p46.dedyn.io;lightning.p46.dedyn.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hi,
On Mon, Jul 06, 2026 at 04:06:13PM +0530, Mahesh Sathe wrote:
> For a 3-node Patroni cluster with PostgreSQL 17.10, here is the
> high-level approach I typically follow for a major version upgrade to
> 18.4 with minimal downtime.
> High-Level Strategy
> 2. *Upgrade Execution (Minimal Downtime)*:
> - *Rolling Upgrade*: Utilize Patroni’s rolling upgrade capability.
> You can upgrade one replica at a time by stopping the Patroni service,
> upgrading the PostgreSQL binaries, and restarting.
I think you issued the wrong prompt here, because the AI answer
describes a rolling minor-version upgrade.
You cannot run a major-version upgrade on a standby.
The proper high-level procedure is to run pg_upgrade on the leader and
to re-build the standbys afterwards, either through re-clone or via
rsync (see my other message).
In terms of Patroni, one also needs to make sure the DCS configuration
is updated, usually by removing it from DCS and letting Patroni recreate
it.
In general, the procedure is quite well described in the Patroni
documentation here:
https://patroni.readthedocs.io/en/latest/existing_data.html#major-upgrade-of-postgresql-version
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Banck | 2026-07-06 16:02:23 | Re: PG version 16.14 upgrade went recovery state |
| Previous Message | Michael Banck | 2026-07-06 10:52:10 | Re: Major upgrade in patroni cluster |