style guide compliance in older docs page

Author: iamfortune

modules/deploy/pages/setting-up-dr-cluster.adoc

@@ -36,7 +36,7 @@ include::ROOT:partial$_show_page_header_block.adoc[]
 == Introduction
 
 {server-xdcr--xref} (XDCR) replicates data between two or more autonomous Couchbase Server clusters.
-It serves an important role in supporting Disaster Recovery (DR) and Data Migration, even where Sync Gateway is the normal replicator of choice for mobile data.
+It plays an important role in supporting Disaster Recovery (DR) and Data Migration, even where Sync Gateway is the normal replicator of choice for mobile data.
 
 
 == Recommended Deployment Models
@@ -47,7 +47,7 @@ It serves an important role in supporting Disaster Recovery (DR) and Data Migrat
 
 This model provides true zero-downtime disaster recovery using bi-directional XDCR between two active mobile clusters.
 Both clusters remain operational, with seamless fail-over through load balancer switching.
-`shared_bucket_access=true` is required when loading a database in SGW 4.0+, and you must configure both clusters with `import_docs=true`.
+`shared_bucket_access=true` becomes required when loading a database in SGW 4.0+, and you must configure both clusters with `import_docs=true`.
 
 .Set Up
 To set up zero-downtime disaster recovery:
@@ -72,21 +72,21 @@ To activate disaster recovery:
 This process requires no Sync Gateway service interruption.
 . Verify disaster recovery cluster is handling traffic properly.
 . Maintain bi-directional replication for recovery preparedness. +
-The original primary becomes new DR cluster automatically and no manual XDCR reconfiguration required.
+The original primary becomes the new DR cluster automatically and requires no manual XDCR reconfiguration.
 
 // end::zero-downtime-active-active[]
 
 === Clusters in Same Region
 // tag::clusters-in-same-region[]
 
 This model caters for situations where the Active and Disaster Recovery clusters are in the same region or datacenter -- see: <<fig-dr-same-regn>>.
-It includes an optional optimization step, which verifies that there is no downtime during the activation stage.
+It includes an optional optimization step, which confirms that there is no downtime during the activation stage.
 
 .Set Up
 To set up and maintain a disaster recovery cluster:
 
 . [*Optional step -- for optimization*] Start Sync Gateway with `offline: true` in the Disaster Recovery cluster to asynchronously create indexes.
-Having everything reindexed lowers switching costs. +
+Creating all indexes beforehand reduces switching costs. +
 If you skip this test, you'll incur latency when Sync Gateway switches to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes.
 . Connect Sync Gateway to your Primary cluster.
 . Start the *unidirectional* XDCR from the Primary cluster to the Disaster Recovery cluster.
@@ -99,10 +99,10 @@ image::ROOT:{image-sgw-xdcr-dr-same-regn-setup}[,{std-image-size}]
 When you're ready to switch to Disaster Recovery operations:
 
 . Stop the replication (XDCR) from the Primary cluster to Disaster Recovery cluster.
-. *When XDCR is stopped:* Switch the Load Balancer to point to the Sync Gateway on the Disaster Recovery cluster.
-This maintains the deployment of Sync Gateway at only one end of the XDCR replication.
+. *After you stop XDCR:* Switch the Load Balancer to point to the Sync Gateway on the Disaster Recovery cluster.
+This approach keeps the deployment of Sync Gateway at only 1 end of the XDCR replication.
 . Promote the Disaster Recovery cluster to Primary and the *old* Primary to Disaster Recovery.
-. Flush all replicated buckets in the Primary cluster as a precaution against any spurious writes that came into the Primary cluster and were not replicated when XDCR stops.
+. Flush all replicated buckets in the Primary cluster as a precaution against any spurious writes that enter the Primary cluster and XDCR fails to replicate when you stop it.
 . Reverse the XDCR to replicate from the newly promoted Primary to the old Primary to set up a new Backup.
 
 [#fig-dr-same-regn-in-recovery]
@@ -115,15 +115,15 @@ image::ROOT:{image-sgw-xdcr-dr-same-regn-in-recovery}[,{std-image-size}]
 // tag::clusters-in-diff-region[]
 
 This model caters for situations where the Active and Disaster Recovery clusters are in different regions or data centers.
-Although the model has a separate Sync Gateway cluster attached to the Disaster Recovery cluster, it maintains the deployment of Sync Gateway at only one end of the XDCR replication.
-The optional optimization step verifies that there is no downtime during the activation stage.
+Although the model has a separate Sync Gateway cluster attached to the Disaster Recovery cluster, this approach keeps the deployment of Sync Gateway at only 1 end of the XDCR replication.
+The optional optimization step confirms that there is no downtime during the activation stage.
 
 
 .Set Up
 To set up and maintain a disaster recovery cluster - see: <<fig-dr-diff-regn-setup>>:
 
 . [*Optional step -- for optimization*] Start Sync Gateway with `offline: true` in the Disaster Recovery cluster to asynchronously create indexes.
-If you skip this test, you'll incur latency when Sync Gateway is switched to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes.
+If you skip this test, you'll incur latency when you switch Sync Gateway to the Disaster Recovery cluster and Sync Gateway rebuilds its indexes.
 . [*Critical step*] Turn off *all* the Sync Gateways in the Disaster Recovery cluster.
 . Start the *unidirectional* XDCR from the Primary cluster to the Disaster Recovery cluster.
 
@@ -140,7 +140,7 @@ When you're ready to switch to Disaster Recovery operations -- see: <<fig-dr-dif
 . Verify that any and all Load Balancer updates to direct all traffic to the new Sync Gateway clusters.
 . Turn on the Sync Gateway cluster in the Disaster Recovery cluster.
 . Assign the Disaster Recovery cluster to be the *new* Primary cluster, and make the *old* Primary cluster the *new* Disaster Recovery cluster.
-. Flush all replicated buckets in the Primary cluster; as a precaution against any spurious writes coming into the Primary cluster that had not been replicated when XDCR was stopped.
+. Flush all replicated buckets in the Primary cluster as a precaution against any spurious writes coming into the Primary cluster that XDCR did not replicate when you stopped it.
 . Reverse the original XDCR to replicate from the newly promoted Primary to the old Primary, to set up a new Backup.
 
 [#fig-dr-diff-regn-in-recovery]

modules/server-compatibility/pages/server-compatibility-xdcr.adoc

@@ -44,18 +44,18 @@ Here we provide details on how XDCR feature relates to the {cbm} ecosystem.
 
 
 If you need to sync mobile clusters, you should use Inter-Sync Gateway replication -- see: {sync-inter-syncgateway-overview--xref}.
-It was designed to keep mobile clusters in different data centers in sync.
+It's designed to keep mobile clusters in different data centers in sync.
 The ideal use-case being the need to replicate edge clusters containing active Sync{nbsp}Gateway nodes between geographically separate cloud-based Sync Gateway deployments.
-A typical architecture for this use case is shown in <<icr-active-mobile>>.
+<<icr-active-mobile>> shows a typical architecture for this use case.
 
-Inter-Sync Gateway replication provides bi-directional read/write replications that ensure:
+Inter-Sync Gateway replication provides bi-directional read/write replications that make sure:
 
-* Cluster specific security is observed; by invoking the appropriate Sync Function.
-* The integrity of security history is maintained.
-Historical access rules are held and maintained in the Sync Gateway metadata.
+* Sync Gateway observes cluster-specific security by invoking the appropriate Sync Function.
+* Sync Gateway maintains the integrity of security history.
+Sync Gateway holds and maintains historical access rules in its metadata.
 This history is necessary to consistently handle the revocation of access grants.
-* A consistent Revision Id is used across all clusters, allowing clients to identify a revision regardless of the cluster it is on.
-* Cluster-specific _sync documents are not replicated to other mobile clusters
+* All clusters use a consistent Revision Id, allowing clients to identify a revision regardless of which cluster it's on.
+* Cluster-specific `_sync` documents are not replicated to other mobile clusters
 
 [[icr-active-mobile]]
 .Active-to-active mobile synchronization
@@ -71,7 +71,8 @@ XDCR replicates all of Sync Gateway’s metadata (_sync xattr) along with associ
 
 Your default preference for the replication of {cbm} changes should always be to use inter-Sync{nbsp}Gateway replication.
 
-XDCR can be useful though in use-cases where the entire dataset from a source bucket is replicated to a target bucket. This could include categories such as active standby, disaster recovery, data migration and _lift-and-shift_ cases in hybrid cloud.
+XDCR proves useful in use-cases where you replicate the entire dataset from a source bucket to a target bucket.
+These categories include active standby, disaster recovery, data migration and _lift-and-shift_ cases in hybrid cloud.
 
 
 === Unidirectional XDCR
@@ -83,8 +84,8 @@ In all these categories you should run XDCR in unidirectional mode, deploying Sy
 ====
 In this example XDCR deployment:
 
-* XDCR is run unidirectionally.
-It pushes data from the primary data center to the secondary data centers, where it is pulled by Sync Gateway for downstream clients.
+* XDCR runs unidirectionally.
+It pushes data from the primary datacenter to the secondary datacenter, where it's pulled by Sync Gateway for downstream clients.
 * Sync Gateway, although deployed at both ends of the XDCR replication, crucially is in *read-only* mode at the target end.
 
 .XDCR Replication