Because of the additional complexity involved in setting up this configuration
for PostgreSQL and Redis, it is not covered by this Geo HA documentation.
For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
[PostgreSQL](../../high_availability/database.md) and
...
...
@@ -37,10 +44,17 @@ For more information about setting up a highly available PostgreSQL cluster and
NOTE: **Note:**
It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document.
## Prerequisites: A working GitLab HA cluster
## Prerequisites: Two working GitLab HA clusters
One cluster will serve as the **primary** node. Use the
[GitLab HA documentation](../../high_availability/README.md) to set this up. If
you already have a working GitLab instance that is in-use, it can be used as a
**primary**.
This cluster will serve as the **primary** node. Use the
The second cluster will serve as the **secondary** node. Again, use the
[GitLab HA documentation](../../high_availability/README.md) to set this up.
It's a good idea to log in and test it, however, note that its data will be
wiped out as part of the process of replicating from the **primary**.
## Configure the GitLab cluster to be the **primary** node
...
...
@@ -99,7 +113,11 @@ major differences:
various resources.
Therefore, we will set up the HA components one-by-one, and include deviations
from the normal HA setup.
from the normal HA setup. However, we highly recommend first configuring a
brand-new cluster as if it were not part of a Geo setup so that it can be
tested and verified as a working cluster. And only then should it be modified
for use as a Geo **secondary**. This helps to separate problems that are related
and are not related to Geo setup.
### Step 1: Configure the Redis and Gitaly services on the **secondary** node
...
...
@@ -118,7 +136,8 @@ recommended.
### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node
NOTE: **Note:** The following documentation assumes the database will be run on
a single node only, rather than as a PostgreSQL cluster.
a single node only. PostgreSQL HA on **secondary** nodes is
[not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
Configure the [**secondary** database](database.md) as a read-only replica of
the **primary** database. Use the following as a guide.
...
...
@@ -167,6 +186,11 @@ the **primary** database. Use the following as a guide.
## the tracking database IP is in postgresql['md5_auth_cidr_addresses'] above.
##
geo_postgresql['enable']=false
##
## Disable `geo_logcursor` service so Rails doesn't get configured here
##
geo_logcursor['enable']=false
```
After making these changes, [reconfigure GitLab][gitlab-reconfigure] so the changes take effect.
...
...
@@ -335,6 +359,13 @@ On the secondary the following GitLab frontend services will be enabled:
Verify these services by running `sudo gitlab-ctl status` on the frontend
application servers.
You may wish to run backend application services on backend-specific servers.
For example, you can disable the `geo-logcursor` service with
`geo_logcursor['enable'] = false` and run it on application servers not
attached to the load balancer. On those backend application servers, you would
disable Unicorn with `unicorn['enable'] = false`. You might also choose to do
the same thing with the `sidekiq` service.
### Step 5: Set up the LoadBalancer for the **secondary** node
In this topology, a load balancer is required at each geographic location to
@@ -41,8 +41,8 @@ You may also want to enable Sentry's GitLab integration by following the steps i
NOTE: **Note:**
You will need at least Reporter [permissions](../../permissions.md) to view the Error Tracking list.
The Error Tracking list may be found at **Operations > Error Tracking** in your project's sidebar.
Errors can be filtered by title or sorted by Frequency, First Seen or Last Seen. Errors are always sorted in descending order by the field specified.
You can find the Error Tracking list at **Operations > Error Tracking** in your project's sidebar.
Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.
