Add details on how to disable GitLab to the DR documentation

This commit also adds numerous small improvements to spelling and grammar

changelogs/unreleased-ee/4417-dr-turn-off-primary.yml

+---
+title: Add details on how to disable GitLab to the DR documentation
+merge_request: 4239
+author:
+type: changed

doc/gitlab-geo/README.md

@@ -51,6 +51,7 @@ to reading any data available in the GitLab web interface (see [current limitati
 improving speed for distributed teams
 - Helps reducing the loading time for automated tasks,
 custom integrations and internal workflows
+- A Geo secondary can be promoted to become the primary in a [Disaster Recovery](disaster-recovery.md) scenario
 
 ## Architecture
 

doc/gitlab-geo/disaster-recovery.md

@@ -17,28 +17,45 @@ See [current limitations](README.md#current-limitations) for more information.
 We don't currently provide an automated way to promote a geo replica and do a
 fail-over, but you can do it manually if you have `root` access to the machine.
 
-This process promotes a secondary geo replica to a primary in the least steps.
-It does not enable GitLab Geo on the newly promoted primary.
+This process promotes a secondary Geo replica to a primary. To regain
+geographical redundancy as quickly as possible, you should add a new secondary
+immediately after following these instructions.
 
-1. SSH into your **primary** and stop disable GitLab.
+1. SSH into your **primary** to stop and disable GitLab.
 
-    ```
+    ```bash
     sudo gitlab-ctl stop
+    ```
+
+    Prevent GitLab from starting up again if the server unexpectedly reboots:
 
+    ```bash
+    sudo systemctl disable gitlab-runsvdir
     ```
 
-    If you do not have SSH access to your primary take the machine offline.
-    Depending on the nature of your primary this may mean physically
-    disconnecting the machine, stopping a virtual server, reconfiguring load
-    balancers, or changing DNS records (see next step).
+    On some operating systems such as CentOS 6, an easy way to prevent GitLab
+    from being started if the machine reboots isn't available
+    (see [Omnibus issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
+    It may be safest to uninstall the GitLab package completely:
+
+    ```bash
+    yum remove gitlab-ee
+    ```
 
-    Preventing the original primary from coming online during this process is
-    necessary to ensure data isn't added to the original primary that will not
-    be replicated to the newly promoted primary.
+    Preventing the original primary from coming back online during this process
+    is necessary prevent data from being mistakenly added to it. Any data added
+    after the failover process has begun will **not** be be replicated to the
+    newly promoted primary.
+
+    If you do not have SSH access to your primary, take the machine offline and
+    prevent it from rebooting by any means at your disposal. Depending on the
+    nature of your primary, this may mean physically disconnecting the machine,
+    stopping a virtual server, reconfiguring load balancers, or changing DNS
+    records (see next step).
 
 1. SSH in to your **secondary** and login as root:
 
-    ```
+    ```bash
     sudo -i
     ```
 
@@ -46,7 +63,7 @@ It does not enable GitLab Geo on the newly promoted primary.
 
     Remove the following line:
 
-    ```
+    ```ruby
     ## REMOVE THIS LINE
     geo_secondary_role['enable'] = true
     ```
@@ -57,7 +74,7 @@ It does not enable GitLab Geo on the newly promoted primary.
 
 1. Promote the secondary to primary. Execute:
 
-    ```
+    ```bash
     gitlab-ctl promote-to-primary-node
     ```