Performing a combined minor upgrade v6.5.0

Move both Postgres and PGD to a new minor version at the same time, using one of three approaches: full downtime, a rolling upgrade in place, or a rolling upgrade that replaces nodes. Moving both Postgres and PGD to a new minor version at the same time means upgrading each node in place rather than replacing it: installing the new PGD packages built for your Postgres version also picks up the latest available Postgres minor version for it, so a single package install and restart covers both. No new data directory, pg_upgrade, or node join is needed, since neither a PGD nor a Postgres minor version upgrade changes the on-disk format.

Upgrading with full downtime

Choose this approach when a maintenance window is acceptable and finishing quickly matters more than staying online. See Choosing between a rolling and full-downtime upgrade for the trade-offs against the two rolling approaches described below.

1. Stop Postgres on every node:

   → WrapCopy

   sudo systemctl stop postgres

   You can run this step one node at a time, but you must wait for each node to shut down cleanly before moving to the next. Monitor progress with sudo journalctl -u postgres -f.

2. Install the new combined PGD and Postgres packages for your Postgres version on every node, for example:

   → WrapCopy

   sudo apt install edb-pgd6-expanded-pg<postgres_version>

3. Start Postgres on every node:

   → WrapCopy

   systemctl start postgres

   Both PGD and Postgres upgrade to the new version on start.

4. Confirm the new versions took effect on every node:

   → WrapCopy

   SELECT bdr.bdr_version();
   SHOW server_version;

5. Check pgd nodes list for overall cluster health.

Upgrading with a rolling upgrade, in place

For each node, one at a time:

1. Fence the node, so it can't become the write leader until the upgrade is complete:

   → WrapCopy

   pgd node <node_name> set-option route_fence true

2. Stop Postgres:

   → WrapCopy

   sudo systemctl stop postgres

   Monitor progress with sudo journalctl -u postgres -f.

3. Install the new combined PGD and Postgres packages for your Postgres version, for example:

   → WrapCopy

   sudo apt install edb-pgd6-expanded-pg<postgres_version>

4. Start Postgres. Both PGD and Postgres upgrade to the new version on start:

   → WrapCopy

   systemctl start postgres

5. Unfence the node, then confirm it's healthy before moving to the next one:

   → WrapCopy

   pgd node <node_name> set-option route_fence false

6. Confirm the new versions took effect on the node:

   → WrapCopy

   SELECT bdr.bdr_version();
   SHOW server_version;

Check your monitoring as usual after upgrading a node.

Upgrading with a rolling upgrade, by replacing nodes

Instead of upgrading a node in place, join a new node that already has the new combined PGD and Postgres minor versions installed, then part and drop one of the existing nodes. Use this approach if you're also replacing hardware or a base image at the same time as the minor version bump.

1. Provision a new node with the new combined PGD and Postgres minor version packages already installed.

2. Join the new node to the cluster using a logical join:

   → WrapCopy

   pgd node <node_name> setup --dsn "<new_node_dsn>" --cluster-dsn "<existing_node_dsn>" -D <pg_data>

   Don't use bdr_init_physical, it requires the source and joining node to run the same PGD version, so it can't be used across a version change. See the pgd node setup command reference for the full set of options.

3. Wait for the new node to catch up with the cluster before routing traffic to it, then confirm it's healthy:

   → WrapCopy

   pgd nodes list

4. Update your application's connection configuration to include the new node once it's ready to take traffic.

5. Part one of the existing nodes, then decommission it:

   → WrapCopy

   pgd node <node_name> part

6. Repeat for each remaining node, one at a time, until the whole cluster is on the new version.