Standardise style and nomenclature for Geo documentation

doc/administration/geo/disaster_recovery/background_verification.md

@@ -4,18 +4,18 @@ NOTE: **Note:**
 Automatic background verification of repositories and wikis was added in
 GitLab EE 10.6 but is enabled by default only on GitLab EE 11.1. You can
 disable or enable this feature manually by following
-[these instructions][feature-flag].
+[these instructions](#disabling-or-enabling-the-automatic-background-verification).
 
-Automatic backgorund verification ensures that the transferred data matches a
-calculated checksum, proving that the content on the **secondary** matches that
-on the **primary**. Following a planned failover, any corrupted data may be
-**lost**, depending on the extent of the corruption.
+Automatic background verification ensures that the transferred data matches a
+calculated checksum. If the checksum of the data on the **primary** node matches checksum of the
+data on the **secondary** node, the data transferred successfully. Following a planned failover,
+any corrupted data may be **lost**, depending on the extent of the corruption.
 
-If verification fails on the **primary**, this indicates that Geo is
+If verification fails on the **primary** node, this indicates that Geo is
 successfully replicating a corrupted object; restore it from backup or remove it
-it from the primary to resolve the issue.
+it from the **primary** node to resolve the issue.
 
-If verification succeeds on the **primary** but fails on the **secondary**,
+If verification succeeds on the **primary** node but fails on the **secondary** node,
 this indicates that the object was corrupted during the replication process.
 Geo actively try to correct verification failures marking the repository to
 be resynced with a backoff period. If you want to reset the verification for
@@ -65,7 +65,7 @@ in grey, and failures in red.
 ![Verification status](img/verification-status-primary.png)
 
 Navigate to the **Admin Area > Geo** dashboard on the **secondary** node and expand
-the **Verification information** tab for that node to view automatic verifcation
+the **Verification information** tab for that node to view automatic verification
 status for repositories and wikis. As with checksumming, successes are shown in
 green, pending work in grey, and failures in red.
 
@@ -73,7 +73,7 @@ green, pending work in grey, and failures in red.
 
 ## Using checksums to compare Geo nodes
 
-To check the health of Geo secondary nodes, we use a checksum over the list of
+To check the health of Geo **secondary** nodes, we use a checksum over the list of
 Git references and their values. The checksum includes `HEAD`, `heads`, `tags`,
 `notes`, and GitLab-specific references to ensure true consistency. If two nodes
 have the same checksum, then they definitely hold the same references. We compute
@@ -129,33 +129,33 @@ be resynced with a backoff period. If you want to reset them manually, this
 rake task marks projects where verification has failed or the checksum mismatch
 to be resynced without the backoff period:
 
-#### For repositories:
+For repositories:
 
-**Omnibus Installation**
+- Omnibus Installation
 
-```
-sudo gitlab-rake geo:verification:repository:reset
-```
+    ```sh
+    sudo gitlab-rake geo:verification:repository:reset
+    ```
 
-**Source Installation**
+- Source Installation
 
-```bash
-sudo -u git -H bundle exec rake geo:verification:repository:reset RAILS_ENV=production
-```
+    ```sh
+    sudo -u git -H bundle exec rake geo:verification:repository:reset RAILS_ENV=production
+    ```
 
-#### For wikis:
+For wikis:
 
-**Omnibus Installation**
+- Omnibus Installation
 
-```
-sudo gitlab-rake geo:verification:wiki:reset
-```
+    ```sh
+    sudo gitlab-rake geo:verification:wiki:reset
+    ```
 
-**Source Installation**
+- Source Installation
 
-```bash
-sudo -u git -H bundle exec rake geo:verification:wiki:reset RAILS_ENV=production
-```
+    ```sh
+    sudo -u git -H bundle exec rake geo:verification:wiki:reset RAILS_ENV=production
+    ```
 
 ## Current limitations
 
@@ -167,7 +167,6 @@ on both nodes, and comparing the output between them.
 Data in object storage is **not verified**, as the object store is responsible
 for ensuring the integrity of the data.
 
-[feature-flag]: background_verification.md#enabling-or-disabling-the-automatic-background-verification
 [reset-verification]: background_verification.md#reset-verification-for-projects-where-verification-has-failed
 [foreground-verification]: ../../raketasks/check.md
 [ee-5064]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5064

doc/administration/geo/disaster_recovery/bring_primary_back.md

 # Bring a demoted primary node back online
 
-After a failover, it is possible to fail back to the demoted primary to
+After a failover, it is possible to fail back to the demoted **primary** node to
 restore your original configuration. This process consists of two steps:
 
-1. Making the old primary a secondary
-1. Promoting a secondary to a primary
+1. Making the old **primary** node a **secondary** node.
+1. Promoting a **secondary** node to a **primary** node.
 
-> *Warning:* If you have any doubts about the consistency of the data on this node, we recommend to set up it from scratch.
+CAUTION: **Caution:**
+If you have any doubts about the consistency of the data on this node, we recommend setting it up from scratch.
 
-## Configure the former primary to be a secondary
+## Configure the former **primary** node to be a **secondary** node
 
-Since the former primary will be out of sync with the current primary, the first step is
-to bring the former primary up to date. Note, deletion of data stored on disk like
-repositories and uploads will not be replayed when bringing the former primary in back
+Since the former **primary** node will be out of sync with the current **primary** node, the first step is to bring the former **primary** node up to date. Note, deletion of data stored on disk like
+repositories and uploads will not be replayed when bringing the former **primary** node back
 into sync, which may result in increased disk usage.
-Alternatively, you can [set up a new secondary GitLab instance][setup-geo] to avoid this.
+Alternatively, you can [set up a new **secondary** GitLab instance][setup-geo] to avoid this.
 
-To bring the former primary up to date:
+To bring the former **primary** node up to date:
 
-1. SSH into the former primary that has fallen behind
+1. SSH into the former **primary** node that has fallen behind.
 1. Make sure all the services are up:
 
-    ```bash
+    ```sh
     sudo gitlab-ctl start
     ```
 
-    > **Note 1:** If you [disabled primary permanently][disaster-recovery-disable-primary],
+    > **Note 1:** If you [disabled the **primary** node permanently][disaster-recovery-disable-primary],
     > you need to undo those steps now. For Debian/Ubuntu you just need to run
     > `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
-    > the GitLab instance from scratch and set it up as a secondary node by
-    > following [Setup instructions][setup-geo].  In this case you don't need to follow the next step.
+    > the GitLab instance from scratch and set it up as a **secondary** node by
+    > following [Setup instructions][setup-geo]. In this case, you don't need to follow the next step.
     >
     > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domains-dns-record)
     > for this node during disaster recovery procedure you may need to [block
@@ -37,25 +37,25 @@ To bring the former primary up to date:
     > during this procedure.
 
 1. [Setup database replication][database-replication]. Note that in this
-   case, primary refers to the current primary, and secondary refers to the
-   former primary.
+   case, **primary** node refers to the current **primary** node, and **secondary** node refers to the
+   former **primary** node.
 
-If you have lost your original primary, follow the
-[setup instructions][setup-geo] to set up a new secondary.
+If you have lost your original **primary** node, follow the
+[setup instructions][setup-geo] to set up a new **secondary** node.
 
-## Promote the secondary to primary
+## Promote the **secondary** node to **primary** node
 
-When the initial replication is complete and the primary and secondary are
+When the initial replication is complete and the **primary** node and **secondary** node are
 closely in sync, you can do a [planned failover].
 
-## Restore the secondary node
+## Restore the **secondary** node
 
-If your objective is to have two nodes again, you need to bring your secondary
+If your objective is to have two nodes again, you need to bring your **secondary**
 node back online as well by repeating the first step
-([configure the former primary to be a secondary](#configure-the-former-primary-to-be-a-secondary))
-for the secondary node.
+([configure the former **primary** node to be a **secondary** node](#configure-the-former-primary-node-to-be-a-secondary-node))
+for the **secondary** node.
 
 [setup-geo]: ../replication/index.md#setup-instructions
 [database-replication]: ../replication/database.md
-[disaster-recovery-disable-primary]: index.md#step-2-permanently-disable-the-primary
+[disaster-recovery-disable-primary]: index.md#step-2-permanently-disable-the-primary-node
 [planned failover]: planned_failover.md

doc/administration/geo/replication/configuration_source.md

@@ -6,37 +6,38 @@ Please consider [migrating to GitLab Omnibus install](https://docs.gitlab.com/om
 using the Omnibus GitLab packages, follow the
 [**Omnibus Geo nodes configuration**][configuration] guide.
 
-## Configuring a new secondary node
+## Configuring a new **secondary** node
 
 NOTE: **Note:**
-This is the final step in setting up a secondary Geo node. Stages of the setup
+This is the final step in setting up a **secondary** node. Stages of the setup
 process must be completed in the documented order. Before attempting the steps
 in this stage, [complete all prior stages][setup-geo-source].
 
-The basic steps of configuring a secondary node are to replicate required
-configurations between the primary and the secondaries; to configure a tracking
-database on each secondary; and to start GitLab on the secondary node.
+The basic steps of configuring a **secondary** node are to:
+
+- Replicate required configurations between the **primary** and **secondary** nodes.
+- Configure a tracking database on each **secondary** node.
+- Start GitLab on the **secondary** node.
 
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
+NOTE: **Note:**
+**Do not** set up any custom authentication on **secondary** nodes, this will be handled by the **primary** node.
 
-NOTE: **Notes:**
-- **Do not** setup any custom authentication in the secondary nodes, this will be
-  handled by the primary node.
-- **Do not** add anything in the secondaries Geo nodes admin area
-  (**Admin Area > Geo**). This is handled solely by the primary node.
+NOTE: **Note:**
+**Do not** add anything in the **secondary** node's admin area (**Admin Area > Geo**). This is handled solely by the **primary** node.
 
 ### Step 1. Manually replicate secret GitLab values
 
 GitLab stores a number of secret values in the `/home/git/gitlab/config/secrets.yml`
-file which *must* match between the primary and secondary nodes. Until there is
+file which *must* match between the **primary** and **secondary** nodes. Until there is
 a means of automatically replicating these between nodes (see [gitlab-org/gitlab-ee#3789]), they must
-be manually replicated to the secondary.
+be manually replicated to **secondary** nodes.
 
 1. SSH into the **primary** node, and execute the command below:
 
-    ```bash
+    ```sh
     sudo cat /home/git/gitlab/config/secrets.yml
     ```
 
@@ -44,20 +45,20 @@ be manually replicated to the secondary.
 
 1. SSH into the **secondary** node and login as the `git` user:
 
-    ```bash
+    ```sh
     sudo -i -u git
     ```
 
 1. Make a backup of any existing secrets:
 
-    ```bash
+    ```sh
     mv /home/git/gitlab/config/secrets.yml /home/git/gitlab/config/secrets.yml.`date +%F`
     ```
 
-1. Copy `/home/git/gitlab/config/secrets.yml` from the primary to the secondary, or
+1. Copy `/home/git/gitlab/config/secrets.yml` from the **primary** node to the **secondary** node, or
    copy-and-paste the file contents between nodes:
 
-    ```bash
+    ```sh
     sudo editor /home/git/gitlab/config/secrets.yml
 
     # paste the output of the `cat` command you ran on the primary
@@ -66,65 +67,65 @@ be manually replicated to the secondary.
 
 1. Ensure the file permissions are correct:
 
-    ```bash
+    ```sh
     chown git:git /home/git/gitlab/config/secrets.yml
     chmod 0600 /home/git/gitlab/config/secrets.yml
     ```
 
 1. Restart GitLab
 
-    ```bash
+    ```sh
     service gitlab restart
     ```
 
-Once restarted, the secondary will automatically start replicating missing data
-from the primary in a process known as backfill. Meanwhile, the primary node
-will start to notify the secondary of any changes, so that the secondary can
+Once restarted, the **secondary** node will automatically start replicating missing data
+from the **primary** node in a process known as backfill. Meanwhile, the **primary** node
+will start to notify the **secondary** node of any changes, so that the **secondary** node can
 act on those notifications immediately.
 
-Make sure the secondary instance is running and accessible. You can login to
-the secondary node with the same credentials as used in the primary.
+Make sure the **secondary** node is running and accessible. You can login to
+the **secondary** node with the same credentials as used for the **primary** node.
 
-### Step 2. Manually replicate primary SSH host keys
+### Step 2. Manually replicate the **primary** node's SSH host keys
 
-Read [Manually replicate primary SSH host keys][configuration-replicate-ssh]
+Read [Manually replicate the **primary** node's SSH host keys][configuration-replicate-ssh]
 
-### Step 3. Add the secondary GitLab node
+### Step 3. Add the **secondary** GitLab node
 
 1. Navigate to the **primary** node's **Admin Area > Geo**
-   (`/admin/geo_nodes`) in your browser.
-1. Add the secondary node by providing its full URL. **Do NOT** check the box
-   'This is a primary node'.
+   (`/admin/geo/nodes`) in your browser.
+1. Add the **secondary** node by providing its full URL. **Do NOT** check the
+   **This is a primary node** checkbox.
 1. Optionally, choose which namespaces should be replicated by the
-   secondary node. Leave blank to replicate all. Read more in
+   **secondary** node. Leave blank to replicate all. Read more in
    [selective synchronization](#selective-synchronization).
 1. Click the **Add node** button.
 1. SSH into your GitLab **secondary** server and restart the services:
 
-    ```bash
+    ```sh
     service gitlab restart
     ```
 
     Check if there are any common issue with your Geo setup by running:
 
-    ```bash
+    ```sh
     bundle exec rake gitlab:geo:check
     ```
 
 1. SSH into your GitLab **primary** server and login as root to verify the
-   secondary is reachable or there are any common issue with your Geo setup:
+   **secondary** node is reachable or there are any common issue with your Geo setup:
 
-    ```bash
+    ```sh
     bundle exec rake gitlab:geo:check
     ```
 
-Once reconfigured, the secondary will automatically start
-replicating missing data from the primary in a process known as backfill.
-Meanwhile, the primary node will start to notify the secondary of any changes, so
-that the secondary can act on those notifications immediately.
+Once reconfigured, the **secondary** node will automatically start
+replicating missing data from the **primary** node in a process known as backfill.
+Meanwhile, the **primary** node will start to notify the **secondary** node of any changes, so
+that the **secondary** node can act on those notifications immediately.
 
-Make sure the secondary instance is running and accessible.
-You can login to the secondary node with the same credentials as used in the primary.
+Make sure the **secondary** node is running and accessible.
+You can log in to the **secondary** node with the same credentials as used for the **primary** node.
 
 ### Step 4. Enabling Hashed Storage
 
@@ -132,15 +133,15 @@ Read [Enabling Hashed Storage](configuration.md##step-4-enabling-hashed-storage)
 
 ### Step 5. (Optional) Configuring the secondary to trust the primary
 
-You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
+You can safely skip this step if your **primary** node uses a CA-issued HTTPS certificate.
 
-If your primary is using a self-signed certificate for *HTTPS* support, you will
-need to add that certificate to the secondary's trust store. Retrieve the
-certificate from the primary and follow your distribution's instructions for
-adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
+If your **primary** node is using a self-signed certificate for *HTTPS* support, you will
+need to add that certificate to the **secondary** node's trust store. Retrieve the
+certificate from the **primary** node and follow your distribution's instructions for
+adding it to the **secondary** node's trust store. In Debian/Ubuntu, for example, with a
 certificate file of `primary.geo.example.com.crt`, you would follow these steps:
 
-```
+```sh
 sudo -i
 cp primary.geo.example.com.crt /usr/local/share/ca-certificates
 update-ca-certificates
@@ -150,7 +151,7 @@ update-ca-certificates
 
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
 method to be enabled. Navigate to **Admin Area > Settings**
-(`/admin/application_settings`) on the primary node, and set
+(`/admin/application_settings`) on the **primary** node, and set
 `Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
 
 ### Step 7. Verify proper functioning of the secondary node

doc/administration/geo/replication/docker_registry.md

 # Docker Registry for a secondary node
 
 You can set up a [Docker Registry] on your
-secondary Geo node that mirrors the one on the primary Geo node.
+**secondary** Geo node that mirrors the one on the **primary** Geo node.
 
 ## Storage support
 
 CAUTION: **Warning:**
 If you use [local storage][registry-storage]
-for the Container Registry you **cannot** replicate it to the secondary Geo node.
+for the Container Registry you **cannot** replicate it to a **secondary** node.
 
 Docker Registry currently supports a few types of storages. If you choose a
 distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Docker
-Registry on a primary Geo node, you can use the same storage for a secondary
+Registry on the **primary** node, you can use the same storage for a **secondary**
 Docker Registry as well. For more information, read the
 [Load balancing considerations][registry-load-balancing]
 when deploying the Registry, and how to set up the storage driver for GitLab's

doc/administration/geo/replication/faq.md

@@ -7,22 +7,22 @@ The requirements are listed [on the index page](index.md#requirements-for-runnin
 ## Can I use Geo in a disaster recovery situation?
 
 Yes, but there are limitations to what we replicate (see
-[What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
+[What data is replicated to a **secondary** node?](#what-data-is-replicated-to-a-secondary-node)).
 
 Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
 
-## What data is replicated to a secondary node?
+## What data is replicated to a **secondary** node?
 
 We currently replicate project repositories, LFS objects, generated
 attachments / avatars and the whole database. This means user accounts,
 issues, merge requests, groups, project data, etc., will be available for
 query.
 
-## Can I git push to a secondary node?
+## Can I git push to a **secondary** node?
 
 Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
-## How long does it take to have a commit replicated to a secondary node?
+## How long does it take to have a commit replicated to a **secondary** node?
 
 All replication operations are asynchronous and are queued to be dispatched. Therefore, it depends on a lot of
 factors including the amount of traffic, how big your commit is, the
@@ -30,8 +30,8 @@ connectivity between your nodes, your hardware, etc.
 
 ## What if the SSH server runs at a different port?
 
-That's totally fine.  We use HTTP(s) to fetch repository changes from the **primary** node to **secondary** nodes.
+That's totally fine. We use HTTP(s) to fetch repository changes from the **primary** node to all **secondary** nodes.
 
-## Is this possible to set up a Docker Registry for a secondary node that mirrors the one on a primary node?
+## Is this possible to set up a Docker Registry for a **secondary** node that mirrors the one on the **primary** node?
 
-Yes. See [Docker Registry for a secondary Geo node](docker_registry.md).
+Yes. See [Docker Registry for a **secondary** node](docker_registry.md).

doc/administration/geo/replication/high_availability.md

@@ -10,7 +10,7 @@ described, it is possible to adapt these instructions to your needs.
 
 _[diagram source - gitlab employees only][diagram-source]_
 
-The topology above assumes that the primary and secondary Geo clusters
+The topology above assumes that the **primary** and **secondary** Geo clusters
 are located in two separate locations, on their own virtual network
 with private IP addresses. The network is configured such that all machines within
 one geographic location can communicate with each other using their private IP addresses.
@@ -20,14 +20,14 @@ network topology of your deployment.
 The only external way to access the two Geo deployments is by HTTPS at
 `gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
 
-> **Note:** The primary and secondary Geo deployments must be able to
-  communicate to each other over HTTPS.
+NOTE: **Note:**
+The **primary** and **secondary** Geo deployments must be able to communicate to each other over HTTPS.
 
 ## Redis and PostgreSQL High Availability
 
-The primary and secondary Redis and PostgreSQL should be configured
+The **primary** and **secondary** Redis and PostgreSQL should be configured
 for high availability. Because of the additional complexity involved
-in setting up this configuration for PostgreSQL and Redis
+in setting up this configuration for PostgreSQL and Redis,
 it is not covered by this Geo HA documentation.
 
 For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
@@ -35,7 +35,7 @@ For more information about setting up a highly available PostgreSQL cluster and
 [Redis](../../high_availability/redis.md), respectively.
 
 NOTE: **Note:**
-It is possible to use cloud hosted services for PostgreSQL and Redis but this is beyond the scope of this document.
+It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document.
 
 ## Prerequisites: A working GitLab HA cluster
 
@@ -189,7 +189,6 @@ following modifications:
     registry['uid'] = 9002
     registry['gid'] = 9002
     ```
-
 NOTE: **Note:**
 If you had set up PostgreSQL cluster using the omnibus package and you had set
 up `postgresql['sql_user_password'] = 'md5 digest of secret'` setting, keep in

doc/administration/geo/replication/index.md

@@ -30,7 +30,7 @@ Implementing Geo provides the following benefits:
 
 - Reduce from minutes to seconds the time taken for your distributed developers to clone and fetch large repositories and projects.
 - Enable all of your developers to contribute ideas and work in parallel, no matter where they are.
-- Balance the load between your **primary** and **secondary** nodes, or offload your automated tests to the **secondary** node.
+- Balance the load between your **primary** and **secondary** nodes, or offload your automated tests to a **secondary** node.
 
 In addition, it:
 
@@ -42,8 +42,8 @@ In addition, it:
 
 Geo provides:
 
-- Read-only **secondary** nodes: Maintain one **primary** GitLab node while still enabling a read-only **secondary** node for each of your distributed teams.
-- Authentication system hooks: The **secondary** node receives all authentication data (like user accounts and logins) from the **primary** instance.
+- Read-only **secondary** nodes: Maintain one **primary** GitLab node while still enabling read-only **secondary** nodes for each of your distributed teams.
+- Authentication system hooks: **Secondary** nodes receives all authentication data (like user accounts and logins) from the **primary** instance.
 - An intuitive UI: **Secondary** nodes utilize the same web interface your team has grown accustomed to. In addition, there are visual notifications that block write operations and make it clear that a user is on a **secondary** node.
 
 ## How it works
@@ -89,6 +89,7 @@ From the perspective of a user performing Git operations:
 - **Secondary** nodes are read-only but proxy Git push operations to the **primary** node. This makes **secondary** nodes appear to support push operations themselves.
 
 To simplify the diagram, some necessary components are omitted. Note that:
+
 - Git over SSH requires [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) and OpenSSH.
 - Git over HTTPS required [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse).
 
@@ -97,7 +98,7 @@ Note that a **secondary** node needs two different PostgreSQL databases:
 - A read-only database instance that streams data from the main GitLab database.
 - [Another database instance](#geo-tracking-database) used internally by the **secondary** node to record what data has been replicated.
 
-In secondary nodes, there is an additional daemon: [Geo Log Cursor](#geo-log-cursor).
+In **secondary** nodes, there is an additional daemon: [Geo Log Cursor](#geo-log-cursor).
 
 ## Requirements for running Geo
 
@@ -115,8 +116,8 @@ The following are required to run Geo:
 
 The following table lists basic ports that must be open between the **primary** and **secondary** nodes for Geo.
 
-| Primary server | Server secondary | Protocol        |
-| -------------- | ---------------- | --------------- |
+| **Primary** node | **Secondary** node | Protocol     |
+|:-----------------|:-------------------|:-------------|
 | 80               | 80                 | HTTP         |
 | 443              | 443                | TCP or HTTPS |
 | 22               | 22                 | TCP          |
@@ -134,9 +135,12 @@ If you wish to terminate SSL at the GitLab application server instead, use TCP p
 
 ### LDAP
 
-We recommend that if you use LDAP on your **primary** node, you also set up a secondary LDAP server for the **secondary** node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the **secondary** node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.
+We recommend that if you use LDAP on your **primary** node, you also set up secondary LDAP servers on each **secondary** node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the **secondary** node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.
+
+NOTE: **Note:**
+It is possible for all **secondary** nodes to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server will be available in a [disaster recovery](../disaster_recovery/index.md) scenario if a **secondary** node is promoted to be a **primary** node.
 
-Check with your LDAP provider for instructions on how to set up replication. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).
+Check for instructions on how to set up replication in your LDAP service. Instructions will be different depending on the software or service used. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).
 
 ### Geo Tracking Database
 
@@ -153,7 +157,7 @@ The tracking database requires the `postgres_fdw` extension.
 
 This daemon:
 
-- Reads a log of events replicated by the **primary** node to the secondary database instance.
+- Reads a log of events replicated by the **primary** node to the **secondary** database instance.
 - Updates the Geo Tracking Database instance with changes that need to be executed.
 
 When something is marked to be updated in the tracking database instance, asynchronous jobs running on the **secondary** node will execute the required operations and update the state.

doc/administration/geo/replication/object_storage.md

@@ -6,9 +6,9 @@ other compatible object storage).
 ## Configuration
 
 At this time it is required that if object storage is enabled on the
-primary, it must also be enabled on the secondary.
+**primary** node, it must also be enabled on each **secondary** node.
 
-The secondary nodes can use the same storage bucket as the primary, or
+**Secondary** nodes can use the same storage bucket as the **primary** node, or
 they can use a replicated storage bucket. At this time GitLab does not
 take care of content replication in object storage.
 
@@ -22,15 +22,15 @@ For user uploads, there is similar documentation to configure [upload object sto
 
 You should enable and configure object storage on both **primary** and **secondary**
 nodes. Migrating existing data to object storage should be performed on the
-**primary** node only; secondaries will automatically notice that the migrated
+**primary** node only. **Secondary** nodes will automatically notice that the migrated
 files are now in object storage.
 
 ## Replication
 
 When using Amazon S3, you can use
 [CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
-have automatic replication between the bucket used by the primary and
-the bucket used by the secondary.
+have automatic replication between the bucket used by the **primary** node and
+the bucket used by **secondary** nodes.
 
 If you are using Google Cloud Storage, consider using
 [Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional).

doc/administration/geo/replication/tuning.md

@@ -2,14 +2,14 @@
 
 ## Changing the sync capacity values
 
-In the Geo admin page (`/admin/geo_nodes`), there are several variables that
+In the Geo admin page (`/admin/geo/nodes`), there are several variables that
 can be tuned to improve performance of Geo:
 
-* Repository sync capacity
-* File sync capacity
+- Repository sync capacity.
+- File sync capacity.
 
-Increasing these values will increase the number of jobs that are scheduled,
-but this may not lead to a more downloads in parallel unless the number of
+Increasing these values will increase the number of jobs that are scheduled.
+However, this may not lead to more downloads in parallel unless the number of
 available Sidekiq threads is also increased. For example, if repository sync
 capacity is increased from 25 to 50, you may also want to increase the number
 of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency

doc/user/admin_area/geo_nodes.md

@@ -3,7 +3,7 @@
 For more information about setting up GitLab Geo, read the
 [Geo documentation](../../gitlab-geo/README.md).
 
-When you're done, you can navigate to **Admin area > Geo** (`/admin/geo_nodes`).
+When you're done, you can navigate to **Admin area > Geo** (`/admin/geo/nodes`).
 
 ## Common settings