PGD 5 docs standardized on Always-on architectures.

Signed-off-by: Dj Walker-Morgan <[email protected]>

product_docs/docs/pgd/5/deploy-config/deploy-biganimal/index.mdx

@@ -6,7 +6,7 @@ redirects:
   - /pgd/latest/admin-biganimal/ #generated for pgd deploy-config-planning reorg 
 ---
 
-EDB BigAnimal is a fully managed database-as-a-service with built-in Oracle compatibility. It runs in your cloud account or BigAnimal's cloud account, where it's operated by our Postgres experts. EDB BigAnimal makes it easy to set up, manage, and scale your databases. The addition of distributed high-availability support powered by EDB Postgres Distributed (PGD) enables single- and multi-region Always On clusters. 
+EDB BigAnimal is a fully managed database-as-a-service with built-in Oracle compatibility. It runs in your cloud account or BigAnimal's cloud account, where it's operated by our Postgres experts. EDB BigAnimal makes it easy to set up, manage, and scale your databases. The addition of distributed high-availability support powered by EDB Postgres Distributed (PGD) enables single- and multi-region Always-on clusters. 
 
 This section covers how to work with EDB Postgres Distributed when deployed on BigAnimal. 
 

product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/index.mdx

@@ -22,7 +22,7 @@ This applies to physical and virtual machines, both self-hosted and in the cloud
 
 !!! Note Get started with TPA and PGD quickly 
 
-    If you want to experiment with a local deployment as quickly as possible, you can [deploy an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-On cluster on Docker.
+    If you want to experiment with a local deployment as quickly as possible, you can [deploy an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker.
 
     If deploying to the cloud is your aim, you can [deploy an EDB Postgres Distributed example cluster on AWS](/pgd/latest/quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account.
 

product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx

@@ -11,7 +11,7 @@ both self-hosted and in the cloud (with AWS EC2).
 
 !!! Note Get started with TPA and PGD quickly 
 
-    If you want to experiment with a local deployment as quickly as possible, you can [deploying an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-On cluster on Docker.
+    If you want to experiment with a local deployment as quickly as possible, you can [deploying an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker.
 
     If deploying to the cloud is your aim, you can [deploying an EDB Postgres Distributed example cluster on AWS](/pgd/latest/quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account.
 

product_docs/docs/pgd/5/planning/architectures.mdx

@@ -8,7 +8,7 @@ redirects:
   - /pgd/latest/architectures/
 ---
 
-Always On architectures reflect EDB’s Trusted Postgres architectures. They
+Always-on architectures reflect EDB’s Trusted Postgres architectures. They
 encapsulate practices and help you to achieve the highest possible service
 availability in multiple configurations. These configurations range from
 single-location architectures to complex distributed systems that protect from
@@ -21,16 +21,16 @@ described here. Use-case-specific variations have been successfully deployed in
 production. However, these variations must undergo rigorous architecture review
 first. 
 
-Always On architectures can be deployed using EDB’s standard deployment tool  
+Always-on architectures can be deployed using EDB’s standard deployment tool  
 Trusted Postgres Architect (TPA) or configured manually.
 
-## Standard EDB Always On architectures
+## Standard EDB Always-on architectures
 
 EDB has identified a set of standardized architectures to support single- or
 multi-location deployments with varying levels of redundancy, depending on your
 recovery point objective (RPO) and recovery time objective (RTO) requirements.
 
-The Always ON architecture uses three database node groups as a basic building block.
+The Always-on architecture uses three database node groups as a basic building block.
 You can also use a five-node group for extra redundancy.
 
 EDB Postgres Distributed consists of the following major building blocks:
@@ -40,7 +40,7 @@ EDB Postgres Distributed consists of the following major building blocks:
 - PGD Proxy — A connection router that makes sure the application is connected
   to the right data nodes.
 
-All Always On architectures protect an increasing range of failure situations.
+All Always-on architectures protect an increasing range of failure situations.
 For example, a single active location with two data nodes protects against local
 hardware failure but doesn't provide protection from location (data
 center or availability zone) failure. Extending that architecture with a backup
@@ -75,19 +75,19 @@ requires an odd number of nodes to make decisions using a [Raft](https://raft.gi
 consensus model. Thus, even the simpler architectures always have three nodes,
 even if not all of them are storing data.
 
-Applications connect to the standard Always On architectures by way of multi-host
+Applications connect to the standard Always-on architectures by way of multi-host
 connection strings, where each PGD Proxy server is a distinct entry in the
 multi-host connection string. You must always have at least two proxy nodes in
 each location to ensure high availability. You can colocate the proxy with the
 database instance, in which case we recommend putting the proxy on every data
 node.
 
 Other connection mechanisms have been successfully deployed in production. However,
-they aren't part of the standard Always On architectures.
+they aren't part of the standard Always-on architectures.
 
-### Always On Single Location
+### Always-on Single Location
 
-![Always On 1 Location, 3 Nodes Diagram](images/always_on_1x3_updated.png)
+![Always-on 1 Location, 3 Nodes Diagram](images/always_on_1x3_updated.png)
 
 * Additional replication between data nodes 1 and 3 isn't shown but occurs as part of the replication mesh
 * Redundant hardware to quickly restore from local failures
@@ -104,9 +104,9 @@ they aren't part of the standard Always On architectures.
 * Postgres Enterprise Manager (PEM) for monitoring (not depicted)
     * Can be shared by multiple PGD clusters
 
-### Always On multi-location
+### Always-on multi-location
 
-![Always On 2 Locations, 3 Nodes Per Location, Active/Active Diagram](images/always_on_2x3_aa_updated.png)
+![Always-on 2 Locations, 3 Nodes Per Location, Active/Active Diagram](images/always_on_2x3_aa_updated.png)
 
 * Application can be Active/Active in each location or can be Active/Passive or Active DR with only one location taking writes.
 * Additional replication between data nodes 1 and 3 isn't shown but occurs as part of the replication mesh.
@@ -133,7 +133,7 @@ All architectures provide the following:
 * Zero downtime upgrades
 * Support for availability zones in public/private cloud
 
-Use these criteria to help you to select the appropriate Always On architecture.
+Use these criteria to help you to select the appropriate Always-on architecture.
 
 |                                                      | Single  Data Location                                    | Two  Data  Locations                                     | Two  Data Locations  + Witness                           | Three or More Data Locations                             |
 |------------------------------------------------------|----------------------------------------------------------|----------------------------------------------------------|----------------------------------------------------------|----------------------------------------------------------|

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

@@ -9,7 +9,7 @@ In a multi-master architecture like PGD, conflicts happen. PGD is built to handl
 
 A conflict can occur when one database node has an update from an application to a row and another node has a different update to the same row. This type of conflict is called a *row-level conflict*. Conflicts aren't errors. Resolving them effectively is core to how Postgres Distributed maintains consistency. 
 
-The best way to handle conflicts is not to have them in the first place! Use PGD's Always-On architecture with proxies to ensure that your applications write to the same server in the cluster. 
+The best way to handle conflicts is not to have them in the first place! Use PGD's Always-on architecture with proxies to ensure that your applications write to the same server in the cluster. 
 
 When conflicts occur, though, it's useful to know how PGD resolves them, how you can control that resolution, and how you can find out that they're happening. Row insertion and row updates are two actions that can cause conflicts. 
 

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

@@ -10,7 +10,7 @@ redirects:
 ---
 
 
-This quick start sets up EDB Postgres Distributed with an Always On Single Location architecture using Amazon EC2.
+This quick start sets up EDB Postgres Distributed with an Always-on Single Location architecture using Amazon EC2.
 
 ## Introducing TPA and PGD
 
@@ -147,7 +147,7 @@ tpaexec configure democluster \
   --hostnames-unsorted
 ```
 
-You specify the PGD-Always-ON architecture (`--architecture PGD-Always-ON`), which sets up the configuration for [PGD 5's Always On architectures](../planning/architectures/). As part of the default architecture, 
+You specify the PGD-Always-ON architecture (`--architecture PGD-Always-ON`), which sets up the configuration for [PGD 5's Always-on architectures](../planning/architectures/). As part of the default architecture, 
 this configures your cluster with three data nodes, cohosting three [PGD Proxy](../routing/proxy/) servers, along with a [Barman](../backup#physical-backup) node for backup.
 
 Specify that you're using AWS (`--platform aws`) and eu-west-1 as the region (`--region eu-west-1`). 

product_docs/docs/pgd/5/terminology.mdx

@@ -137,7 +137,7 @@ Witness nodes primarily serve to help the cluster establish a consensus. An odd
 
 #### Write leader
 
-In an Always-On architecture, a node is selected as the correct connection endpoint for applications. This node is called the write leader. Once selected, proxy nodes route queries and updates to it. With only one node receiving writes, unintended multi-node writes can be avoided. The write leader is selected by consensus of a quorum of data nodes. If the write leader becomes unavailable, the data nodes select another node to become write leader. Nodes that aren't the write leader are referred to as *shadow nodes*.
+In an Always-on architecture, a node is selected as the correct connection endpoint for applications. This node is called the write leader. Once selected, proxy nodes route queries and updates to it. With only one node receiving writes, unintended multi-node writes can be avoided. The write leader is selected by consensus of a quorum of data nodes. If the write leader becomes unavailable, the data nodes select another node to become write leader. Nodes that aren't the write leader are referred to as *shadow nodes*.
 
 #### Writer