AW: Major upgrade in patroni cluster

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Klaus Darilion <[email protected]>
To: Mahesh Sathe <[email protected]>
To: Raj <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: AW: Major upgrade in patroni cluster
Date: Mon, 6 Jul 2026 10:43:52 +0000
Message-ID: <DBAPR03MB635872C763EDC6BC1DFE7FA4F1F12@DBAPR03MB6358.eurprd03.prod.outlook.com> (raw)
In-Reply-To: <CAG6Sa9Uz9_WTq7u2Zm6VJaJDvYh-vVbqbwstvARj6CJ7f3EGew@mail.gmail.com>
References: <CAJk5Atax1egLDrB3YUb1+q5kGfyFpMsN0H5djSacL309k5C28Q@mail.gmail.com>
	<CAG6Sa9Uz9_WTq7u2Zm6VJaJDvYh-vVbqbwstvARj6CJ7f3EGew@mail.gmail.com>

Hi Mahesh!

Do I understand it right, that during the rolling upgrade you loose High Availability as for short time the Patroni nodes use a different Postgres version and hence the streaming replication will not work?

regards
Klaus

________________________________
Von: Mahesh Sathe <[email protected]>
Gesendet: Montag, 6. Juli 2026 12:36
An: Raj <[email protected]>
Cc: Pgsql-admin <[email protected]>
Betreff: Re: Major upgrade in patroni cluster

Hi Raj,

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

  1.  Preparation & Testing:
     *   Staging Environment: Perform the upgrade on a staging cluster that mirrors your production setup. This is critical for validating application compatibility and performance.
     *   Release Notes: Thoroughly review the release notes for PostgreSQL 18.4 to identify any breaking changes, deprecated features, or specific collation/locale requirements that might impact your data.
     *   Testing: Validate your pgBackRest backups and ensure you can restore from them before proceeding.
  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.
     *   Switchover: Once the replicas are upgraded, perform a controlled switchover to promote an upgraded replica to leader. Finally, upgrade the former leader.
     *   pg_upgrade: In many cases, you may need to use the pg_upgrade utility. If you use it, ensure you run it with the -k (link) option where possible to significantly speed up the process and minimize downtime.
  3.  Key Considerations:
     *   OS/Library Compatibility: Since you are moving to a newer PG version, ensure the underlying OS libraries (especially glibc) are compatible, as this can affect collation.
     *   PgBouncer/HAProxy: Ensure your connection poolers and HA setup are correctly updated to point to the new binary paths if the installation location changes.
     *   Validation: After the upgrade, run your application suite against the cluster to catch any performance regressions.

Let me know if you’d like to discuss specific steps for the pg_upgrade process or how to handle the replication configuration changes.

Best regards,

Mahesh Sathe


Sent from Gmail Mobile

On Sun, 28 Jun 2026 at 9:53 PM, Raj <[email protected]<mailto:[email protected]>> wrote:
Hi All,

I have a three node PATRONI cluster with postgres 17.10 version with PGBACKREST, pgnouncer and haproxy.

We would like to upgrade postgres 18.4 version.

What are the high level steps with minimal downtime? Though I did some research already, would like to understand how it's been followed.

view thread (5+ messages)  latest in thread

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], [email protected], [email protected]
  Subject: Re: AW: Major upgrade in patroni cluster
  In-Reply-To: <DBAPR03MB635872C763EDC6BC1DFE7FA4F1F12@DBAPR03MB6358.eurprd03.prod.outlook.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