You may also want to edit the `wal_keep_segments` and `max_wal_senders` to
match your database replication requirements. Consult the [PostgreSQL - Replication documentation](https://www.postgresql.org/docs/9.6/static/runtime-config-replication.html)
for more information.
1. Check to make sure your firewall rules are set so that the secondary nodes
can access port 5432 on the primary node.
...
...
@@ -146,11 +146,7 @@ The following guide assumes that:
1. Edit `/etc/gitlab/gitlab.rb` and add the following:
```ruby
postgresql['wal_level'] = "hot_standby"
postgresql['max_wal_senders'] = 10
postgresql['wal_keep_segments'] = 10
postgresql['hot_standby'] = "on"
gitlab_rails['auto_migrate'] = false # prevents migrations to be executed on the secondary server
geo_secondary_role['enable'] = true
```
1.[Reconfigure GitLab][] for the changes to take effect.
...
...
@@ -175,59 +171,15 @@ data before running `pg_basebackup`.
sudo -i
```
1. Save the snippet below in a file, let's say `/tmp/replica.sh`:
@@ -74,7 +74,9 @@ The following guide assumes that:
See the Omnibus notes above for more details of `listen_address`.
Edit the `wal` values as you see fit.
You may also want to edit the `wal_keep_segments` and `max_wal_senders` to
match your database replication requirements. Consult the [PostgreSQL - Replication documentation](https://www.postgresql.org/docs/9.6/static/runtime-config-replication.html)
for more information.
1. Set the access control on the primary to allow TCP connections using the
server's public IP and set the connection from the secondary to require a