public inbox for [email protected]help / color / mirror / Atom feed
Major upgrade in patroni cluster 5+ messages / 4 participants [nested] [flat]
* Major upgrade in patroni cluster @ 2026-06-28 16:23 Raj <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Raj @ 2026-06-28 16:23 UTC (permalink / raw) To: Pgsql-admin <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Major upgrade in patroni cluster @ 2026-07-06 10:36 Mahesh Sathe <[email protected]> parent: Raj <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: Mahesh Sathe @ 2026-07-06 10:36 UTC (permalink / raw) To: Raj <[email protected]>; +Cc: Pgsql-admin <[email protected]> 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. > ^ permalink raw reply [nested|flat] 5+ messages in thread
* AW: Major upgrade in patroni cluster @ 2026-07-06 10:43 Klaus Darilion <[email protected]> parent: Mahesh Sathe <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Klaus Darilion @ 2026-07-06 10:43 UTC (permalink / raw) To: Mahesh Sathe <[email protected]>; Raj <[email protected]>; +Cc: Pgsql-admin <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Major upgrade in patroni cluster @ 2026-07-06 10:52 Michael Banck <[email protected]> parent: Klaus Darilion <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Michael Banck @ 2026-07-06 10:52 UTC (permalink / raw) To: Klaus Darilion <[email protected]>; +Cc: Mahesh Sathe <[email protected]>; Raj <[email protected]>; Pgsql-admin <[email protected]> On Mon, Jul 06, 2026 at 10:43:52AM +0000, Klaus Darilion wrote: > 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? That is correct, and short of using logical replication for zero-downtime upgrade into a separate, new, Patroni cluster, I don't see how to circumvent this. One can make the upgrade window smaller by upgrading the standbys with rsync, but that is quite brittle and should only be done in controlled environments after lots of testing. Also, it only works with the --link pg_upgrade option, not --copy or --clone. Michael ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Major upgrade in patroni cluster @ 2026-07-06 10:56 Michael Banck <[email protected]> parent: Mahesh Sathe <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Michael Banck @ 2026-07-06 10:56 UTC (permalink / raw) To: Mahesh Sathe <[email protected]>; +Cc: Raj <[email protected]>; Pgsql-admin <[email protected]> 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-07-06 10:56 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-28 16:23 Major upgrade in patroni cluster Raj <[email protected]> 2026-07-06 10:36 ` Mahesh Sathe <[email protected]> 2026-07-06 10:43 ` AW: Major upgrade in patroni cluster Klaus Darilion <[email protected]> 2026-07-06 10:52 ` Michael Banck <[email protected]> 2026-07-06 10:56 ` Michael Banck <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox