From 1020e18069fa468d8e165c90cc07cebe6d830d9b Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 28 May 2025 10:00:09 +0100 Subject: [PATCH 1/7] Edits for DDL replicaction/Mixed version prohibition Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx index 4f0fee4b421..ad93168e815 100644 --- a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx +++ b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx @@ -15,6 +15,8 @@ Doing the same for an EDB Postgres Distributed (PGD) cluster is essentially the The rolling upgrade process allows updating individual cluster nodes to a new major Postgres version while maintaining cluster availability and operational continuity. This approach minimizes downtime and ensures data integrity by allowing the rest of the cluster to remain operational as each node is upgraded sequentially. +While the upgrade process is in progress, the cluster will have mixed Postgres major versions running on different nodes. DDL replication is not supported between different major versions of Postgres, so you must ensure that no DDL changes are made to the cluster while the upgrade is in progress. That includes not running the `ALTER EXTENSION` commands generated by the upgrade processes until all nodes in the cluster are upgraded to the same major version. + The following overview of the general instructions and [worked example](#worked-example) help to provide a smooth and controlled upgrade process. !!!Note @@ -145,12 +147,14 @@ Using the [preliminary order](#prepare-the-upgrade), perform the following steps `sudo systemctl daemon-reload` - * **Restart Postgres** * Proceed to restart the PostgreSQL service: `systemctl start postgres` +* **Update the extensions** + * The upgrade process checks for extension updates and generates a script named `updated_extensions.sql` in the current directory if needed. + This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. As these are DDL commands, if you have to run the script before all nodes are upgraded, you should turn off DDL replication temporarily to avoid issues with mixed major versions. If you can defer running the script until all nodes are upgraded, you can run it on each node after the upgrade of that node is complete. * **Validate the new Postgres version** * Verify that your PostgreSQL instance is now upgraded: @@ -551,6 +555,10 @@ Start the modified Postgres service: sudo systemctl start postgres ``` +### Update the extensions + +After the upgrade, you may need to update the extensions. The upgrade process checks for extension updates and generates a script named `updated_extensions.sql` in the current directory if needed. In this case, no script was generated, so no extensions need updating. + ### Validate the new Postgres version Repeating the first step, check the version of Postgres to confirm that you upgraded kaboom correctly. While still on kaboom, run: From ba4c8f7dd078e50722bc0cf7427d3113230c5baa Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 28 May 2025 10:35:33 +0100 Subject: [PATCH 2/7] Added overview on DDL+mixed versions Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx index efcb90fabd9..af1a8f23ef2 100644 --- a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx @@ -75,3 +75,10 @@ When using the [`bdr.replicate_ddl_command`](/pgd/5.8/reference/functions#bdrrep parameter directly with the third argument, using the specified [`bdr.ddl_locking`](/pgd/5.8/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that function. + +## DDL and mixed PostgreSQL versions + +PGD does not support DDL replication between different major Postgres versions in a cluster. Most of the time, this is not an issue because clusters will be running the same major version of Postgres. This is not the case though when performing a rolling upgrade of a cluster from one major version to another. In this case, DDL replication is not supported until all nodes have been upgraded to the same major version and should not be used. + +Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. See the [Rolling upgrade guide](/pgd/latest/upgrade/rolling-upgrade) for more information on how to perform a rolling upgrade of a PGD cluster. + From 40efef55db419602c64815f966dde9d733c4be25 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Thu, 29 May 2025 10:00:44 +0100 Subject: [PATCH 3/7] Update product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx --- product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx index ad93168e815..01f34fcec80 100644 --- a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx +++ b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx @@ -154,7 +154,7 @@ Using the [preliminary order](#prepare-the-upgrade), perform the following steps * **Update the extensions** * The upgrade process checks for extension updates and generates a script named `updated_extensions.sql` in the current directory if needed. - This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. As these are DDL commands, if you have to run the script before all nodes are upgraded, you should turn off DDL replication temporarily to avoid issues with mixed major versions. If you can defer running the script until all nodes are upgraded, you can run it on each node after the upgrade of that node is complete. + This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. As these are DDL commands, if you have to run the script before all nodes are upgraded, you should [turn off DDL replication temporarily](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrddl_replication) to avoid issues with mixed major versions. If you can defer running the script until all nodes are upgraded, you can run it on each node after the upgrade of that node is complete. * **Validate the new Postgres version** * Verify that your PostgreSQL instance is now upgraded: From 132df59195ac20f16cd3437f53cc6925510e4ec7 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Tue, 10 Jun 2025 11:19:29 +0100 Subject: [PATCH 4/7] Adjust for not latest --- product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx index af1a8f23ef2..2476c47aaec 100644 --- a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx @@ -80,5 +80,5 @@ function. PGD does not support DDL replication between different major Postgres versions in a cluster. Most of the time, this is not an issue because clusters will be running the same major version of Postgres. This is not the case though when performing a rolling upgrade of a cluster from one major version to another. In this case, DDL replication is not supported until all nodes have been upgraded to the same major version and should not be used. -Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. See the [Rolling upgrade guide](/pgd/latest/upgrade/rolling-upgrade) for more information on how to perform a rolling upgrade of a PGD cluster. +Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. See the [Rolling upgrade guide](/pgd/5.8/upgrade/rolling-upgrade) for more information on how to perform a rolling upgrade of a PGD cluster. From 4075c6925f5448e80f13fa73367ddf6c89db6437 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 10 Jun 2025 11:41:02 +0100 Subject: [PATCH 5/7] Fixed and updated 6 with DDL note Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx | 3 +-- product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx | 6 ++++++ product_docs/docs/pgd/6/reference/upgrades.mdx | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx index 2476c47aaec..edfccdcf911 100644 --- a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx @@ -80,5 +80,4 @@ function. PGD does not support DDL replication between different major Postgres versions in a cluster. Most of the time, this is not an issue because clusters will be running the same major version of Postgres. This is not the case though when performing a rolling upgrade of a cluster from one major version to another. In this case, DDL replication is not supported until all nodes have been upgraded to the same major version and should not be used. -Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. See the [Rolling upgrade guide](/pgd/5.8/upgrade/rolling-upgrade) for more information on how to perform a rolling upgrade of a PGD cluster. - +Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. See the [Rolling upgrade guide](/pgd/5.8/upgrades/upgrading_major_rolling) for more information on how to perform a rolling upgrade of a PGD cluster. diff --git a/product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx index 029ef55b658..8a219fcfa68 100644 --- a/product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx @@ -77,3 +77,9 @@ When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/tables-views- parameter directly with the third argument, using the specified [`bdr.ddl_locking`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that function. + +## DDL and mixed PostgreSQL versions + +PGD does not support DDL replication between different major Postgres versions in a cluster. Most of the time, this is not an issue because clusters will be running the same major version of Postgres. This is not the case though when performing a rolling upgrade of a cluster from one major version to another. In this case, DDL replication is not supported until all nodes have been upgraded to the same major version and should not be used. + +Special care should be taken in the upgrade process when updating extensions as the scripts may trigger DDL replication. In this case, if the scripts must be run before upgrading is complete, `bdr.ddl_replication` setting should be set to `off` while running the script. diff --git a/product_docs/docs/pgd/6/reference/upgrades.mdx b/product_docs/docs/pgd/6/reference/upgrades.mdx index 0de30a1ddb9..2e8a2b52e95 100644 --- a/product_docs/docs/pgd/6/reference/upgrades.mdx +++ b/product_docs/docs/pgd/6/reference/upgrades.mdx @@ -8,3 +8,4 @@ redirects: ## Upgrading to EDB Postgres Distributed 6 You can't upgrade to EDB Postgres Distributed 6.0.0 from EDB Postgres Distributed 5.x or earlier. This upgrade will be possible in a future release. + From 496944745bbb7ce83bcb480bcde85b7d17fe68a2 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 10 Jun 2025 11:43:15 +0100 Subject: [PATCH 6/7] format tidy Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx index 01f34fcec80..da47df13287 100644 --- a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx +++ b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx @@ -42,11 +42,11 @@ Then you want to find out which node is the write leader in each subgroup: sudo -u postgres pgd group show --summary ``` -This command shows you information about the pgd group tokened by your `` running in your cluster, including which node is the write leader. -To maintain operational continuity, you need to switch write leaders over to another node in their subgroup before you can upgrade them. -To keep the number of planned switchovers to a minimum, when upgrading a subgroup of nodes, upgrade the writer leaders last. +This command shows you information about the pgd group tokened by your `` running in your cluster, including which node is the write leader. +To maintain operational continuity, you need to switch write leaders over to another node in their subgroup before you can upgrade them. +To keep the number of planned switchovers to a minimum, when upgrading a subgroup of nodes, upgrade the writer leaders last. -Even though you verified which node is the current write leader for planning purposes, the write leader of a subgroup could change to another node at any moment for operational reasons before you upgrade that node. +Even though you verified which node is the current write leader for planning purposes, the write leader of a subgroup could change to another node at any moment for operational reasons before you upgrade that node. Therefore, you still need to verify that a node isn't the write leader just before upgrading that node. You now have enough information to determine your upgrade order, one subgroup at a time, aiming to upgrade the identified write leader node last in each subgroup. @@ -402,6 +402,7 @@ If you didn't initialize Postgres 17 with checksums using the `--data-checksums` ```bash old cluster uses data checksums but the new one does not ``` + !!! ### Execute the Postgres major version upgrade From 63139178c4913a22073dde1209b773938dd171b9 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 10 Jun 2025 12:26:45 +0100 Subject: [PATCH 7/7] Resolved issue regarding scripts and replication Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx index da47df13287..b2485d30173 100644 --- a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx +++ b/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx @@ -154,7 +154,12 @@ Using the [preliminary order](#prepare-the-upgrade), perform the following steps * **Update the extensions** * The upgrade process checks for extension updates and generates a script named `updated_extensions.sql` in the current directory if needed. - This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. As these are DDL commands, if you have to run the script before all nodes are upgraded, you should [turn off DDL replication temporarily](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrddl_replication) to avoid issues with mixed major versions. If you can defer running the script until all nodes are upgraded, you can run it on each node after the upgrade of that node is complete. + This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. + + As the script contains are DDL commands, if you have to run the script before all nodes are upgraded, you should [turn off DDL replication temporarily](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrddl_replication). + You can do this using `SET bdr.ddl_replication = off;` to avoid issues with mixed major versions, but you will have to ensure that the script keeps DDL replication off during the course of its running. Check for any commands in the script that would change database (such as `\c dbname`) and repeat the `SET bdr.ddl_replication = off;` command. + + If you can defer running the script until all nodes are upgraded, it is easier and simpler to run the script on each node after the upgrade of that node is complete. * **Validate the new Postgres version** * Verify that your PostgreSQL instance is now upgraded: