Combine all strong consistency information together

doc/administration/gitaly/index.md

@@ -325,14 +325,23 @@ You can [monitor distribution of reads](#monitor-gitaly-cluster) using Prometheu
 > - From GitLab 13.6, primary-wins voting strategy and the `gitaly_reference_transactions_primary_wins` feature flag was removed.
 > - From GitLab 14.0, [Gitaly Cluster only supports strong consistency](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3575), and the `gitaly_reference_transactions` feature flag was removed.
 
-Gitaly Cluster writes changes synchronously to all healthy, up to date replicas.
-If a replica is outdated or unhealthy at the time of the transaction, the write is asynchronously replicated to it.
+Gitaly Cluster provides strong consistency by writing changes synchronously to all healthy, up-to-date replicas. If a
+replica is outdated or unhealthy at the time of the transaction, the write is asynchronously replicated to it.
 
-In GitLab 13.12 and earlier, if Gitaly Cluster wasn't configured to use strong consistency (or didn't support it yet), Gitaly Cluster guaranteed eventual consistency by replicating all writes to secondary Gitaly nodes after the write to the primary Gitaly node has occurred.
+If strong consistency is unavailable, Gitaly Cluster guarantees eventual consistency. In this case. Gitaly Cluster
+replicates all writes to secondary Gitaly nodes after the write to the primary Gitaly node has occurred.
 
-A subset of operations still use replication jobs (instead of a strong consistency transaction).
-For more information, see the
-[strong consistency epic](https://gitlab.com/groups/gitlab-org/-/epics/1189).
+Strong consistency:
+
+- Is the primary replication method in GitLab 14.0 and later. A subset of operations still use replication jobs
+  (eventual consistency) instead of strong consistency. Refer to the
+  [strong consistency epic](https://gitlab.com/groups/gitlab-org/-/epics/1189) for more information.
+- Must be configured in GitLab versions 13.1 to 13.12. For configuration information, refer to either:
+  - Documentation on your GitLab instance at `/help`.
+  - The [13.12 documentation](https://docs.gitlab.com/13.12/ee/administration/gitaly/praefect.html#strong-consistency).
+- Is unavailable in GitLab 13.0 and earlier.
+
+For more information on monitoring strong consistency, see the Gitaly Cluster [Prometheus metrics documentation](#monitor-gitaly-cluster).
 
 #### Replication factor
 

doc/administration/gitaly/praefect.md

@@ -1105,17 +1105,6 @@ To get started quickly:
 Congratulations! You've configured an observable fault-tolerant Praefect
 cluster.
 
-## Strong consistency
-
-[Strong consistency](index.md#strong-consistency) is the default from GitLab 14.0.
-For configuration information on earlier versions, refer to documentation:
-
-- On your GitLab instance at `/help`.
-- The [13.12 documentation](https://docs.gitlab.com/13.12/ee/administration/gitaly/praefect.html#strong-consistency).
-
-For information on monitoring strong consistency, see the Gitaly Cluster
-[Prometheus metrics documentation](index.md#monitor-gitaly-cluster).
-
 ## Configure replication factor
 
 WARNING:

doc/administration/gitaly/troubleshooting.md

@@ -437,12 +437,12 @@ Praefect does not require a lot of CPU or memory, and can run on small virtual m
 Cloud services may place other limits on the resources that small VMs can use, such as
 disk IO and network traffic.
 
-Praefect nodes generate a lot of network traffic. The following symptoms can be observed
-if their network bandwidth has been throttled by the cloud service.
+Praefect nodes generate a lot of network traffic. The following symptoms can be observed if their network bandwidth has
+been throttled by the cloud service:
 
-- Poor performance of Git operations
-- High network latency
-- High memory use by Praefect
+- Poor performance of Git operations.
+- High network latency.
+- High memory use by Praefect.
 
 Possible solutions: