Add latest changes from gitlab-org/gitlab@13-9-stable-eev13.9.0-rc42

1 files changed, 10 insertions, 35 deletions

diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 1468c5cd39d..e64d0d4983e 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
 
-# Disaster recovery for planned failover **(PREMIUM ONLY)**
+# Disaster recovery for planned failover **(PREMIUM SELF)**
 
 The primary use-case of Disaster Recovery is to ensure business continuity in
 the event of unplanned outage, but it can be used in conjunction with a planned
@@ -45,6 +45,12 @@ be found in `/var/opt/gitlab/gitlab-rails/shared/pages` if using Omnibus).
 
 ## Preflight checks
 
+NOTE:
+In GitLab 13.7 and earlier, if you have a data type with zero items to sync,
+this command reports `ERROR - Replication is not up-to-date` even if
+replication is actually up-to-date. This bug was fixed in GitLab 13.8 and
+later.
+
 Run this command to list out all preflight checks and automatically check if replication and verification are complete before scheduling a planned failover to ensure the process will go smoothly:
 
 ```shell
@@ -138,41 +144,10 @@ will take to finish syncing. An example message would be:
 
 ## Prevent updates to the **primary** node
 
-Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609) is implemented, updates must be prevented
-from happening manually. Note that your **secondary** node still needs read-only
-access to the **primary** node during the maintenance window.
-
-1. At the scheduled time, using your cloud provider or your node's firewall, block
-   all HTTP, HTTPS and SSH traffic to/from the **primary** node, **except** for your IP and
-   the **secondary** node's IP.
-
-   For instance, you might run the following commands on the server(s) making up your **primary** node:
-
-   ```shell
-   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
-   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
-   sudo iptables -A INPUT --destination-port 22 -j REJECT
-
-   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT
-   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
-   sudo iptables -A INPUT --tcp-dport 80 -j REJECT
-
-   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT
-   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
-   sudo iptables -A INPUT --tcp-dport 443 -j REJECT
-   ```
-
-   From this point, users will be unable to view their data or make changes on the
-   **primary** node. They will also be unable to log in to the **secondary** node.
-   However, existing sessions will work for the remainder of the maintenance period, and
-   public data will be accessible throughout.
-
-1. Verify the **primary** node is blocked to HTTP traffic by visiting it in browser via
-   another IP. The server should refuse connection.
+To ensure that all data is replicated to a secondary site, updates (write requests) need to
+be disabled on the primary site:
 
-1. Verify the **primary** node is blocked to Git over SSH traffic by attempting to pull an
-   existing Git repository with an SSH remote URL. The server should refuse
-   connection.
+1. Enable [maintenance mode](../../maintenance_mode/index.md).
 
 1. Disable non-Geo periodic background jobs on the **primary** node by navigating
    to **Admin Area > Monitoring > Background Jobs > Cron**, pressing `Disable All`,