public inbox for [email protected]  

help / color / mirror / Atom feed
From: Mahesh Sathe <[email protected]>
To: Raj <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: Major upgrade in patroni cluster
Date: Mon, 6 Jul 2026 16:06:13 +0530
Message-ID: <CAG6Sa9Uz9_WTq7u2Zm6VJaJDvYh-vVbqbwstvARj6CJ7f3EGew@mail.gmail.com> (raw)
In-Reply-To: <CAJk5Atax1egLDrB3YUb1+q5kGfyFpMsN0H5djSacL309k5C28Q@mail.gmail.com>
References: <CAJk5Atax1egLDrB3YUb1+q5kGfyFpMsN0H5djSacL309k5C28Q@mail.gmail.com>

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]> 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]
  Subject: Re: Major upgrade in patroni cluster
  In-Reply-To: <CAG6Sa9Uz9_WTq7u2Zm6VJaJDvYh-vVbqbwstvARj6CJ7f3EGew@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