Commit 796235ca authored by Stan Hu's avatar Stan Hu

Merge branch '4417-dr-turn-off-primary' into 'master'

Add details on how to disable GitLab to the DR documentation

Closes #4417

See merge request gitlab-org/gitlab-ee!4239
parents 737c506c 44863b22
---
title: Add details on how to disable GitLab to the DR documentation
merge_request: 4239
author:
type: changed
......@@ -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
......
......@@ -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
```
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment