diff options
Diffstat (limited to 'doc/administration/geo/disaster_recovery/planned_failover.md')
| -rw-r--r-- | doc/administration/geo/disaster_recovery/planned_failover.md | 14 |
1 files changed, 9 insertions, 5 deletions
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md index a7a64701cbd..6312ed669ae 100644 --- a/doc/administration/geo/disaster_recovery/planned_failover.md +++ b/doc/administration/geo/disaster_recovery/planned_failover.md @@ -162,6 +162,9 @@ be disabled on the **primary** site: ## Finish replicating and verifying all data +NOTE: +GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary site statuses will appear to stop updating and become unhealthy. For more information, see [Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](../replication/troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). + 1. If you are manually replicating any data not managed by Geo, trigger the final replication process now. 1. On the **primary** node: @@ -192,12 +195,13 @@ At this point, your **secondary** node contains an up-to-date copy of everything ## Promote the **secondary** node -Finally, follow the [Disaster Recovery docs](index.md) to promote the -**secondary** node to a **primary** node. This process causes a brief outage on the **secondary** node, and users may need to log in again. +After the replication is finished, [promote the **secondary** node to a **primary** node](index.md). This process causes a brief outage on the **secondary** node, and users may need to log in again. If you follow the steps correctly, the old primary Geo site should still be disabled and user traffic should go to the newly-promoted site instead. -Once it is completed, the maintenance window is over! Your new **primary** node, now -begin to diverge from the old one. If problems do arise at this point, failing +When the promotion is completed, the maintenance window is over, and your new **primary** node now +begins to diverge from the old one. If problems do arise at this point, failing back to the old **primary** node [is possible](bring_primary_back.md), but likely to result in the loss of any data uploaded to the new **primary** in the meantime. -Don't forget to remove the broadcast message after failover is complete. +Don't forget to remove the broadcast message after the failover is complete. + +Finally, you can bring the [old site back as a secondary](bring_primary_back.md#configure-the-former-primary-node-to-be-a-secondary-node). |