Merge pull request #4271 from EnterpriseDB/docs/edits_to_pgd5_release

Edits to PGD 5 release content

product_docs/docs/pgd/5/appusage.mdx

@@ -182,7 +182,7 @@ See [Release notes](/pgd/latest/rel_notes/) for any known incompatibilities.
 
 ## Replicating between nodes with differences
 
-By default, DDL is automatically sent to all nodes. You can control this manually, as described in [DDL Replication](ddl), and you can use it to create differences between database schemas across nodes.
+By default, DDL is automatically sent to all nodes. You can control this manually, as described in [DDL replication](ddl), and you can use it to create differences between database schemas across nodes.
 PGD is designed to allow replication to continue even with minor
 differences between nodes. These features are designed to allow
 application schema migration without downtime or to allow logical
@@ -326,7 +326,7 @@ its different modes.
 ## Application testing
 
 You can test PGD applications using the following programs,
-in addition to other techniques.
+in addition to other techniques:
 
 -   [Trusted Postgres Architect](#trusted-postgres-architect)
 -   [pgbench with CAMO/Failover options](#pgbench-with-camofailover-options)
@@ -391,7 +391,6 @@ this scenario there's no way to find the status of in-flight transactions.
 
 ### isolationtester with multi-node access
 
-
 `isolationtester` was extended to allow users to run tests on multiple
 sessions and on multiple nodes. This tool is used for internal PGD testing,
 although it's also available for use with user application testing.

product_docs/docs/pgd/5/architectures.mdx

@@ -137,7 +137,7 @@ Use these criteria to help you to select the appropriate Always On architecture.
 | Global consensus in case of location failure         | N/A                                                      | No                                                       | Yes                                                      | Yes                                                      |
 | Data restore required after location failure         | Yes                                                      | No                                                       | No                                                       | No                                                       |
 | Immediate failover in case of location failure       | No - requires data restore from backup                   | Yes - alternate Location                                 | Yes - alternate Location                                 | Yes - alternate Location                                 |
-| Cross Location Network Traffic                       | Only if backup is offsite                                | Full replication traffic                                 | Full replication traffic                                 | Full replication traffic                                 |
-| License Cost                                         | 2 or 3 PGD data nodes                                    | 4 or 6  PGD data nodes                                   | 4 or 6 PGD data nodes                                    | 6+ PGD data nodes                                        |
+| Cross-location network traffic                       | Only if backup is offsite                                | Full replication traffic                                 | Full replication traffic                                 | Full replication traffic                                 |
+| License cost                                         | 2 or 3 PGD data nodes                                    | 4 or 6  PGD data nodes                                   | 4 or 6 PGD data nodes                                    | 6+ PGD data nodes                                        |
 
 

product_docs/docs/pgd/5/cli/installing_cli.mdx

@@ -44,6 +44,6 @@ By default, `pgd-cli-config.yml` is located in the `/etc/edb/pgd-cli` directory.
 
 If you rename the file or move it to another location, specify the new name and location using the optional `-f` or `--config-file` flag when entering a command. See the [sample use case](/pgd/latest/cli/#passing-a-database-connection-string).
 
-!!! Note Avoiding Stale data
-The PGD CLI can return stale data on the state of the cluster if it is still connecting to nodes that have previously been parted from the cluster. Edit the `pgd-cli-config.yml` file or change your `--dsn` settings to ensure only active nodes in the cluster are listed for connection.
+!!! Note Avoiding stale data
+The PGD CLI can return stale data on the state of the cluster if it's still connecting to nodes that were previously parted from the cluster. Edit the `pgd-cli-config.yml` file, or change your `--dsn` settings to ensure only active nodes in the cluster are listed for connection.
 !!!

product_docs/docs/pgd/5/quickstart/connecting_applications.mdx

@@ -5,7 +5,7 @@ description: >
   Connect to your quick started PGD cluster with psql and client applications
 ---
 
-Connecting your application or remotely connecting to your new Postgres Distributed cluster involves:
+Connecting your application or remotely connecting to your new EDB Postgres Distributed cluster involves:
 
 * Getting credentials and optionally creating a `.pgpass` file
 * Establishing the IP address of any PGD Proxy hosts you want to connect to

product_docs/docs/pgd/5/quickstart/further_explore_failover.mdx

@@ -399,7 +399,7 @@ sudo systemctl start pgd-proxy.service
 ```
 
 !!!Tip Exiting Tmux
-You can quickly exit Tmux and all the associated sessions. First terminate any running processes, as they will otherwise continue running after the session is killed. Press **Control-b** and then enter `:kill-session`. This approach is simpler than quitting each pane's session one at a time using **Control-D** or `exit`. 
+You can quickly exit Tmux and all the associated sessions. First terminate any running processes, as they otherwise continue running after the session is killed. Press **Control-B** and then enter `:kill-session`. This approach is simpler than quitting each pane's session one at a time using **Control-D** or `exit`. 
 !!!
 
 ## Other scenarios
@@ -408,5 +408,5 @@ This example uses the quick-start configuration of three data nodes and one back
 
 ## Further reading
 
-* Read more about the management capabilities of [PGD CLI](../cli/).
+* Read more about the management capabilities of the [PGD CLI](../cli/).
 * Learn more about [monitoring replication using SQL](../monitoring/sql/#monitoring-replication-peers).

product_docs/docs/pgd/5/quickstart/index.mdx

@@ -19,8 +19,8 @@ navigation:
 
 EDB Postgres Distributed (PGD) is a multi-master replicating implementation of Postgres designed for high performance and availability. You can create database clusters made up of many bidirectionally synchronizing database nodes. The clusters can have a number of proxy servers that direct your query traffic to the most available nodes, adding further resilience to your cluster configuration.
 
-!!! Note Fully Managed BigAnimal
-    If you would prefer to have a fully managed EDB Postgres Distributed experience, PGD is now available as the Extreme High Availability option on BigAnimal, EDB's cloud platform for Postgres. Read more about [BigAnimal Extreme High Availability](/biganimal/latest/overview/02_high_availability/#extreme-high-availability-preview).
+!!! Note Fully managed BigAnimal
+    If you prefer to have a fully managed EDB Postgres Distributed experience, PGD is now available as the Extreme High Availability option on BigAnimal, EDB's cloud platform for Postgres. Read more about [BigAnimal Extreme High Availability](/biganimal/latest/overview/02_high_availability/#extreme-high-availability-preview).
 
 PGD is very configurable. To quickly evaluate and deploy PGD, use this quick start. It'll get you up and running with a fully configured PGD cluster using the same tools that you'll use to deploy to production. This quick start includes:
 
@@ -78,6 +78,6 @@ The AWS quick start is more extensive and deploys the PGD cluster onto EC2 nodes
 
 * [Connect applications to your PGD cluster](connecting_applications/)
 * [Find out how a PGD cluster stands up to downtime of data nodes or proxies](further_explore_failover/)
-* [Learn about how Postgres Distributed manages conflicting updates](further_explore_conflicts/)
+* [Learn about how EDB Postgres Distributed manages conflicting updates](further_explore_conflicts/)
 * [Moving beyond the quick starts](next_steps/)
 

product_docs/docs/pgd/5/quickstart/quick_start_aws.mdx

@@ -63,7 +63,7 @@ You can add this to your `.bashrc` script or similar shell profile to ensure it'
 
 ### Configure the repository
 
-All the software needed for this example is available from the Postgres Distributed package repository. The following command downloads and runs a script to configure the Postgres Distributed repository. This repository also contains the TPA packages.
+All the software needed for this example is available from the EDB Postgres Distributed package repository. The following command downloads and runs a script to configure the EDB Postgres Distributed repository. This repository also contains the TPA packages.
 
 ```shell
 curl -1sLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash
@@ -250,7 +250,7 @@ To leave the SQL client, enter `exit`.
 
 ### Using PGD CLI
 
-The `pgd` utility, also known as the PGD CLI, lets you control and manage your Postgres Distributed cluster. It's already installed on the node. 
+The pgd utility, also known as the PGD CLI, lets you control and manage your EDB Postgres Distributed cluster. It's already installed on the node. 
 
 You can use it to check the cluster's health by running `pgd check-health`:
 

product_docs/docs/pgd/5/quickstart/quick_start_docker.mdx

@@ -87,7 +87,7 @@ You can add this to your `.bashrc` script or similar shell profile to ensure it'
 
 ### Configure the repository
 
-All the software needed for this example is available from the Postgres Distributed package repository. The following command downloads and runs a script to configure the Postgres Distributed repository. This repository also contains the TPA packages.
+All the software needed for this example is available from the EDB Postgres Distributed package repository. The following command downloads and runs a script to configure the EDB Postgres Distributed repository. This repository also contains the TPA packages.
 
 ```shell
 curl -1sLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash
@@ -287,7 +287,7 @@ To leave the SQL client, enter `exit`.
 
 ### Using PGD CLI
 
-The `pgd` utility, also known as the PGD CLI, lets you control and manage your Postgres Distributed cluster. It's already installed on the node. 
+The pgd utility, also known as the PGD CLI, lets you control and manage your EDB Postgres Distributed cluster. It's already installed on the node. 
 
 You can use it to check the cluster's health by running `pgd check-health`:
 

product_docs/docs/pgd/5/quickstart/quick_start_linux.mdx

@@ -75,7 +75,7 @@ You can add this to your `.bashrc` script or similar shell profile to ensure it'
 
 ### Configure the repository
 
-All the software needed for this example is available from the Postgres Distributed package repository. Download and run a script to configure the Postgres Distributed repository. This repository also contains the TPA packages.
+All the software needed for this example is available from the EDB Postgres Distributed package repository. Download and run a script to configure the EDB Postgres Distributed repository. This repository also contains the TPA packages.
 
 ```
 curl -1sLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash
@@ -301,7 +301,7 @@ To leave the SQL client, enter `exit`.
 
 ### Using PGD CLI
 
-The `pgd` utility, also known as the PGD CLI, lets you control and manage your Postgres Distributed cluster. It's already installed on the node. 
+The pgd utility, also known as the PGD CLI, lets you control and manage your EDB Postgres Distributed cluster. It's already installed on the node. 
 
 You can use it to check the cluster's health by running `pgd check-health`:
 

product_docs/docs/pgd/5/routing/installing_proxy.mdx

@@ -5,11 +5,11 @@ navTitle: "Installing PGD Proxy"
 
 ## Installing PGD Proxy
 
-You can use two methods to install and configure PGD Proxy to manage a Postgres Distributed cluster. The recommended way to install and configure PGD Proxy is to use the EDB Trusted Postgres Architect (TPA) utility for cluster deployment and management.
+You can use two methods to install and configure PGD Proxy to manage an EDB Postgres Distributed cluster. The recommended way to install and configure PGD Proxy is to use the EDB Trusted Postgres Architect (TPA) utility for cluster deployment and management.
 
 ### Installing through TPA
 
-If the PGD cluster is being deployed through TPA, then TPA installs and configures PGD Proxy automatically as per the recommended architecture. If you want to install PGD Proxy on any other node in a PGD cluster, then you need to attach the `pgd-proxy` role to that instance in the TPA configuration file. Also set the `bdr_child_group` parameter before deploying, as this example shows. See [Trusted Postgres Architect](../tpa) for more information.
+If the PGD cluster is being deployed through TPA, then TPA installs and configures PGD Proxy automatically as per the recommended architecture. If you want to install PGD Proxy on any other node in a PGD cluster, then you need to attach the pgd-proxy role to that instance in the TPA configuration file. Also set the `bdr_child_group` parameter before deploying, as this example shows. See [Trusted Postgres Architect](../tpa) for more information.
 
 ```yaml
 - Name: proxy-a1
@@ -47,7 +47,7 @@ By default, in the cluster created through TPA, `pgd-proxy-config.yml` is locate
 
 If you rename the file or move it to another location, specify the new name and location using the optional `-f` or `--config-file` flag when starting a service. See the [sample service file](#pgd-proxy-service).
 
-You can set the log level for the PGD Proxy service using the top-level config parameter `log-level`, as shown in the sample config. The valid values for `log-level` are `debug`, `info`, `warn` and  `error`.
+You can set the log level for the PGD Proxy service using the top-level config parameter `log-level`, as shown in the sample config. The valid values for `log-level` are `debug`, `info`, `warn`, and  `error`.
 
 `cluster.endpoints` and `cluster.proxy.name` are mandatory fields in the config file. PGD Proxy always tries to connect to the first endpoint in the list. If it fails, it tries the next endpoint, and so on.
 

product_docs/docs/pgd/5/routing/proxy.mdx

@@ -30,7 +30,7 @@ PGD manages write leader election. PGD Proxy interacts with PGD to get write lea
 
 PGD Proxy responds to write leader change events that can be categorized into two modes of operation: *failover* and *switchover*.
 
-Automatic transfer of write leadership from the current write leader node to a new node in the event of Postgres or operating system crash is called failover. PGD elects a new write leader when the current write leader goes down or becomes unresponsive. Once the new write leader is elected by PGD, proxy closes existing client connections to the old write leader and redirects new client connections to the newly elected write leader.
+Automatic transfer of write leadership from the current write leader node to a new node in the event of Postgres or operating system crash is called failover. PGD elects a new write leader when the current write leader goes down or becomes unresponsive. Once the new write leader is elected by PGD, PGD Proxy closes existing client connections to the old write leader and redirects new client connections to the newly elected write leader.
 
 User-controlled, manual transfer of write leadership from the current write leader to a new target leader is called switchover. Switchover is triggered through the [PGD CLI switchover](../cli/command_ref/pgd_switchover) command. The command is submitted to PGD, which attempts to elect the given target node as the new write leader. Similar to failover, PGD Proxy closes existing client connections and redirects new client connections to the newly elected write leader. This is useful during server maintenance, for example, if the current write leader node needs to be stopped for maintenance like a server update or OS patch update.
 
@@ -45,15 +45,15 @@ The main purpose of this option is to allow users to configure the write behavio
 
 Consider a 3-data node group with a proxy on each data node. In this case, if the current write leader gets network partitioned or isolated, then the data nodes present in the majority partition elects a new write leader. If `consensus_grace_period` is set to a non-zero value, say `10s`, then the proxy present on the previous write leader continues to route writes for this duration.
 
-Note that in this case, if the grace period is kept too high, then writes continue to happen on the two write leaders. This condition increases the chances of write conflicts.
+In this case, if the grace period is kept too high, then writes continue to happen on the two write leaders. This condition increases the chances of write conflicts.
 
 Having said that, most of the time, upon loss of the current Raft leader, the new Raft leader gets elected by BDR within a few seconds if more than half of the nodes (quorum) are still up. Hence, if the Raft leader is down but the write leader is still up, then proxy can be configured to allow routing by keeping `consensus_grace_period` to a non-zero, positive value. The proxy waits for the Raft leader to get elected during this period before stopping routing. This might be helpful in some cases where availability is more important.
 
 ### Multi-host connection strings
 
 The PostgreSQL C client library (libpq) allows you to specify multiple host names in a single connection string for simple failover. This is also supported by client libraries (drivers) in some other programming languages. It works well for failing over across PGD Proxy instances that are down or inaccessible. 
 
-However, if the PGD Proxy instance is accessible but does not have access to the write leader or the write leader for given instance does not exist (i.e. because there is no write leader for the given PGD group), the connection will simply fail and no other hosts in the multi-host connection string will be tried. This is consistent with behavior of PostgreSQL client library with other proxies like HAProxy or pgbouncer.
+However, if the PGD Proxy instance is accessible but doesn't have access to the write leader, or the write leader for a given instance doesn't exist (that is, because there's no write leader for the given PGD group), the connection simply fails. No other hosts in the multi-host connection string is tried. This behavior is consistent with the behavior of PostgreSQL client libraries with other proxies like HAProxy or pgbouncer.
 
 ## Managing PGD Proxy
 

product_docs/docs/pgd/5/routing/raft/02_raft_subgroups_and_pgd_cli.mdx

@@ -3,7 +3,7 @@ title: "Working with Raft subgroups and PGD CLI"
 ---
 
 
-You can view the status of your nodes and subgroups with the [pgd](../../cli/) cli command. The examples here assume a cluster as configured by in [Creating Raft subgroups with TPA](01_raft_subgroups_and_tpa).
+You can view the status of your nodes and subgroups with the [pgd](../../cli/) CLI command. The examples here assume a cluster as configured by in [Creating Raft subgroups with TPA](01_raft_subgroups_and_tpa).
 
 
 ## Viewing nodes with pgd
@@ -24,7 +24,7 @@ west3    4162758468 us_west    data ACTIVE        ACTIVE       Up     6
 
 ## Viewing groups (and subgroups) with pgd
 
-To show the groups in a PGD deployment, along with their names and attributes, use the PGD cli command `show-groups.`
+To show the groups in a PGD deployment, along with their names and attributes, use the PGD CLI command `show-groups.`
 
 ```
 $pgd show-groups