Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
c5b282b4
Commit
c5b282b4
authored
Dec 20, 2017
by
James Ramsay
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Reduce step complexity and make DNS optional
parent
85d4de0e
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
33 additions
and
44 deletions
+33
-44
doc/gitlab-geo/disaster-recovery.md
doc/gitlab-geo/disaster-recovery.md
+33
-44
No files found.
doc/gitlab-geo/disaster-recovery.md
View file @
c5b282b4
...
...
@@ -19,15 +19,20 @@ but you can do it manually if you have `root` access to the machine.
1.
Take down your
**primary**
node.
If you have SSH access to the primary node, SSH into your **primary**
node, and stop GitLab.
SSH into your primary node and stop GitLab.
```
sudo gitlab-ctl stop
```
Make sure the primary node will not come up while promoting the secondary
node to primary else you may lose data.
If you do not have SSH access to your primary node take the machine
offline. Depending on the nature of your primary node this may mean
physically disconnecting the machine, stopping a virtual server,
reconfiguring load balancers, or changing DNS records (see next step).
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.
1.
SSH in to your
**secondary**
node and login as root:
...
...
@@ -35,68 +40,52 @@ but you can do it manually if you have `root` access to the machine.
sudo -i
```
1.
Optional. Update the DNS records and the
`external_url`
.
Updating the DNS records for the primary domain to point to the secondary
node will prevent the need to update all references to the primary domain
to the secondary domain, like changing Git remotes and API URLs.
After updating the DNS records, edit `/etc/gitlab/gitlab.rb` to reflect the
new URL:
```
# Change the existing external_url configuration
external_url 'https://gitlab.example.com'
```
1.
Edit
`/etc/gitlab/gitlab.rb`
to reflect its new status as primary node.
Remove the following line:
```
##
DELETE THIS LINE, or update the value to false
##
REMOVE THIS LINE
geo_secondary_role['enable'] = true
```
Add the following lines, replacing the IP addresses with addresses
appropriate to your network configuration:
Add the following line:
```
## ADD THIS LINE
geo_primary_role['enable'] = true
##
## Primary address
## - replace '1.2.3.4' with the primary private address
##
postgresql['listen_address'] = '1.2.3.4'
postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','1.2.3.4/32']
##
## Disable automatic database migrations temporarily
## (until PostgreSQL is restarted and listening on the private address).
##
gitlab_rails['auto_migrate'] = false
```
A new secondary is not added at this time. You should add a new secondary
after you have completed the entire process of promoting the secondary to
the primary node.
Refer to [Geo Replication database documention](
database.html#step-1-configure-the-primary-server) for more details.
A new secondary should not be added at this time. If you want to add a new
secondary, do this after you have completed the entire process of promoting
the secondary node to the primary node.
1.
Promote the secondary geo node to primary node. Execute:
```
sudo
gitlab-ctl promote-to-primary-node
gitlab-ctl promote-to-primary-node
```
1.
Verify you can connect to the newly promoted primary using the URL used
previously for the secondary.
1.
Update the DNS records for the primary to reflect the public address of the
newly promoted primary.
1.
After the DNS changes have propagated, edit
`/etc/gitlab/gitlab.rb`
to
reflect it's new URL:
```
# Change the existing external_url configuration
external_url 'https://gitlab.example.com'
```
Reconfigure GitLab to apply the change:
```
gitlab-ctl reconfigure
```
1.
Success! The secondary node has now been promoted to primary node.
1.
Success! The secondary node has now been promoted to primary node and is
accessible from the URL of the previous primary
.
If you updated the DNS records for the primary domain, these changes may
not have yet propogated depending on the previous DNS records TTL
.
To bring your old primary node back into use as a working secondary, you need to
run
`gitlab-ctl reconfigure`
against the node and then follow the
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment