Thread

1. Upgrade Failover Cluster

   BUBACZ Martin <martin.bubacz@axa.com> — 2025-12-04T06:59:52Z

   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.
   
   Regards,
   
   [http://intranet/pb/site/intranet/get/documents/intraxa/PB7-Datenquelle/Ressorts/Vorstandsvorsitzender/Grafiken-Bilder/KK/allgemein/Signatur/AXA-Logo-E-Mail.png]
   
   Martin BUBACZ
   Database Administrator (Oracle)
   Global Intermediate Products Oracle
   Global Service Operations
   AXA Group Operations
   
   AXA Group Operations
   Colonia-Allee 10-20
   51067 Köln
   Germany
   
   Tel.: +49 221 148 21934
   Fax: +49 221 148 44 21934
   martin.bubacz@axa.com<mailto:martin.bubacz@axa.com>
   
   
   axa.de / axa.be<http://www.axa.de/>
   [http://intranet/pb/site/intranet/get/documents/intraxa/PB7-Datenquelle/Ressorts/Vorstandsvorsitzender/Grafiken-Bilder/KK/allgemein/Signatur/Facebook.png]<https://www.facebook.com/AXA.de> [http://intranet/pb/site/intranet/get/documents/intraxa/PB7-Datenquelle/Ressorts/Vorstandsvorsitzender/Grafiken-Bilder/KK/allgemein/Signatur/Twitter.png] <https://twitter.com/axadeutschland>  [http://intranet/pb/site/intranet/get/documents/intraxa/PB7-Datenquelle/Ressorts/Vorstandsvorsitzender/Grafiken-Bilder/KK/allgemein/Signatur/Xing.png] <https://www.xing.com/companies/axa>  [http://intranet/pb/site/intranet/get/documents/intraxa/PB7-Datenquelle/Ressorts/Vorstandsvorsitzender/Grafiken-Bilder/KK/allgemein/Signatur/Instagram.png] <https://www.instagram.com/axa_deutschland>
   Please consider the environment before printing this e-mail. Thank you.
   
   Scheduled Absence: 22.12.2025-11.01.2026
   
   
   
   Internal
   
   =========================================================================
   AXA Group Operations Germany GmbH
   Sitz der Gesellschaft: Köln
   Handelsregister: Köln HR B Nr. 22372
   Geschäftsführer: Helmut Schmidt
   -------------------------------------------------------------------------
   Der Inhalt dieser E-Mail ist vertraulich und ausschliesslich fuer den
   bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie
   nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein,
   so bitten wir Sie, sich mit dem Absender der E-Mail in Verbindung zu
   setzen. Beachten Sie bitte, dass jede Form der unautorisierten Nutzung,
   Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhaltes dieser
   E-Mail nicht gestattet ist.
   -------------------------------------------------------------------------
   This message contains confidential information and is exclusively for the
   person addressed or their representative. If you are not the intended
   recipient of this message and its contents, please notify the sender
   immediately. Any form of unauthorised use, publication, reproduction,
   copying or disclosure of the content of the e-mail is not permitted.
   =========================================================================
   

2. Re: Upgrade Failover Cluster

   Ron Johnson <ronljohnsonjr@gmail.com> — 2025-12-04T13:57:30Z

   On Thu, Dec 4, 2025 at 2:00 AM BUBACZ Martin <martin.bubacz@axa.com> 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!