EnterpriseDB · djw-m · Jun 9, 2025 · Apr 22, 2025 · Mar 31, 2025 · Apr 1, 2025
@@ -6,7 +6,7 @@ redirects:
   - /biganimal/latest/using_cluster/pgd_cli_ba/ #generated for BigAnimal URL path removal branch
 ---
 
-When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. 
+When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/reference/cli/) to manage cluster operations.
 Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
 
 ## Installing the PGD CLI
@@ -31,11 +31,11 @@ sudo yum install edb-pgd5-cli
 
 To connect to your distributed high-availability Cloud Service cluster using the PGD CLI, you need to [discover the database connection string](/pgd/latest/cli/discover_connections/). From your Console:
 
-1.  Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view.
-2.  To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**.
-3.  Select your cluster.
-4.  In the view of your cluster, select the **Connect** tab.
-5.  Copy the read/write URI from the connection info. This is your connection string.
+1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view.
+2. To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**.
+3. Select your cluster.
+4. In the view of your cluster, select the **Connect** tab.
+5. Copy the read/write URI from the connection info. This is your connection string.
 
 ### Using the PGD CLI with your database connection string
 

@@ -11,15 +11,15 @@ This configuration provides a true active-active solution as each data group is
 
 Distributed high-availability clusters support both EDB Postgres Advanced Server and EDB Postgres Extended Server database distributions. 
 
-Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/commit-scopes/commit-scopes/). 
+Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes/). 
 
 [PGD Proxy](/pgd/latest/routing/proxy) routes all application traffic to the leader node, which acts as the principal write target to reduce the potential for data conflicts. PGD Proxy leverages a distributed consensus model to determine availability of the data nodes in the cluster. On failure or unavailability of the leader, PGD Proxy elects a new leader and redirects application traffic. Together with the core capabilities of EDB Postgres Distributed, this mechanism of routing application traffic to the leader node enables fast failover and switchover.
 
 The witness node/witness group doesn't host data but exists for management purposes. It supports operations that require a consensus, for example, in case of an availability zone failure. 
 
 !!!Note
 
-   Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations.
+   Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/reference/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations.
 
 ## Single data location
 

@@ -67,11 +67,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik
 
 EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments.
 
-The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
+The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/5.7/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
 
-Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
+Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
 
-PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
+PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
 
 Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications.
 

@@ -73,11 +73,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik
 
 EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments.
 
-The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
+The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/5.7/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with third party change data capture (CDC) functionality. This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
 
-Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
+Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
 
-PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
+PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
 
 Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications.
 

@@ -103,7 +103,7 @@ To enable pglogical metadata fetch instead of PGD, set `logical_replication_mode
 Using replication sets in PGD, you can configure specific tables to include in the PGD replication. You can also specify the nodes to receive data from these tables by configuring the node to subscribe to the replication
 set the table belongs to. This setting allows for different architectures such as PGD sharding and the use of PGD witness nodes.
 
-A PGD witness is a regular PGD node that doesn't replicate any DML from other nodes. The purpose of the witness is to provide quorum in Raft Consensus voting. (For details on the PGD witness node, see [Witness nodes](/pgd/latest/nodes/witness_nodes/) in the PGD documentation.) Replication set configuration determines whether the witness replicates DDLs. This means that there are two types of PGD witnesses:
+A PGD witness is a regular PGD node that doesn't replicate any DML from other nodes. The purpose of the witness is to provide quorum in Raft Consensus voting. (For details on the PGD witness node, see [Witness nodes](/pgd/latest/reference/nodes/witness_nodes/) in the PGD documentation.) Replication set configuration determines whether the witness replicates DDLs. This means that there are two types of PGD witnesses:
 
 -   A completely empty node, without any data nor tables
 -   A node that replicates DDL from other nodes, so it has empty tables

@@ -103,7 +103,7 @@ To enable pglogical metadata fetch instead of PGD, set `logical_replication_mode
 Using replication sets in PGD, you can configure specific tables to include in the PGD replication. You can also specify the nodes to receive data from these tables by configuring the node to subscribe to the replication
 set the table belongs to. This setting allows for different architectures such as PGD sharding and the use of PGD witness nodes.
 
-A PGD witness is a regular PGD node that doesn't replicate any DML from other nodes. The purpose of the witness is to provide quorum in Raft Consensus voting. (For details on the PGD witness node, see [Witness nodes](/pgd/latest/nodes/witness_nodes/) in the PGD documentation.) Replication set configuration determines whether the witness replicates DDLs. This means that there are two types of PGD witnesses:
+A PGD witness is a regular PGD node that doesn't replicate any DML from other nodes. The purpose of the witness is to provide quorum in Raft Consensus voting. (For details on the PGD witness node, see [Witness nodes](/pgd/latest/reference/nodes/witness_nodes/) in the PGD documentation.) Replication set configuration determines whether the witness replicates DDLs. This means that there are two types of PGD witnesses:
 
 -   A completely empty node, without any data nor tables
 -   A node that replicates DDL from other nodes, so it has empty tables

@@ -24,7 +24,7 @@ Two different Postgres distributions can be used:
 - [EDB Postgres Extended Server](/pge/latest) - PostgreSQL compatible and optimized for replication
 
 What Postgres distribution and version is right for you depends on the features you need.
-See the feature matrix in [Choosing a Postgres distribution](/pgd/latest/planning/choosing_server/) for detailed comparison.
+See the feature matrix in [Choosing a Postgres distribution](/pgd/5.7/planning/choosing_server/) for detailed comparison.
 
 
 ## BDR

@@ -8,7 +8,7 @@ possible for a client connected to multiple PGD nodes or switching
 between them to read stale data.
 
 A [queue wait
-function](/pgd/latest/reference/functions/#bdrwait_for_apply_queue) is provided
+function](/pgd/5.6/reference/functions/#bdrwait_for_apply_queue) is provided
 for clients or proxies to prevent such stale reads.
 
 The synchronous replication features of Postgres are available to PGD as well.

@@ -233,7 +233,7 @@ of a single PGD node, optionally plus WAL archives:
 
 To clean up leftover PGD metadata:
 
-1.  Drop the PGD node using [`bdr.drop_node`](/pgd/latest/reference/functions-internal#bdrdrop_node).
+1.  Drop the PGD node using [`bdr.drop_node`](/pgd/5.6/reference/functions-internal#bdrdrop_node).
 2.  Fully stop and restart PostgreSQL (important!).
 
 #### Cleanup of replication origins

@@ -2,7 +2,7 @@
 title: "Installing PGD CLI"
 navTitle: "Installing PGD CLI"
 redirects:
-  - /pgd/latest/cli/installing_cli
+  - /pgd/5.6/cli/installing_cli
 deepToC: true
 indexCards: simple
 description: Installing the PGD CLI on various systems.