diff options
Diffstat (limited to 'doc/administration')
| -rw-r--r-- | doc/administration/database_load_balancing.md | 18 | ||||
| -rw-r--r-- | doc/administration/geo/replication/high_availability.md | 26 |
2 files changed, 22 insertions, 22 deletions
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md index 7f3be402b84..98404ff2a10 100644 --- a/doc/administration/database_load_balancing.md +++ b/doc/administration/database_load_balancing.md @@ -40,16 +40,16 @@ For example, say you have a primary (`db1.gitlab.com`) and two secondaries, `db2.gitlab.com` and `db3.gitlab.com`. For this setup you will need to have 3 load balancers, one for every host. For example: -* `primary.gitlab.com` forwards to `db1.gitlab.com` -* `secondary1.gitlab.com` forwards to `db2.gitlab.com` -* `secondary2.gitlab.com` forwards to `db3.gitlab.com` +- `primary.gitlab.com` forwards to `db1.gitlab.com` +- `secondary1.gitlab.com` forwards to `db2.gitlab.com` +- `secondary2.gitlab.com` forwards to `db3.gitlab.com` Now let's say that a failover happens and db2 becomes the new primary. This means forwarding should now happen as follows: -* `primary.gitlab.com` forwards to `db2.gitlab.com` -* `secondary1.gitlab.com` forwards to `db1.gitlab.com` -* `secondary2.gitlab.com` forwards to `db3.gitlab.com` +- `primary.gitlab.com` forwards to `db2.gitlab.com` +- `secondary1.gitlab.com` forwards to `db1.gitlab.com` +- `secondary2.gitlab.com` forwards to `db3.gitlab.com` GitLab does not take care of this for you, so you will need to do so yourself. @@ -209,9 +209,9 @@ without it immediately leading to errors being presented to the users. The load balancer logs various messages, such as: -* When a host is marked as offline -* When a host comes back online -* When all secondaries are offline +- When a host is marked as offline +- When a host comes back online +- When all secondaries are offline Each log message contains the tag `[DB-LB]` to make searching/filtering of such log entries easier. For example: diff --git a/doc/administration/geo/replication/high_availability.md b/doc/administration/geo/replication/high_availability.md index 921a3ef1c7a..28ad89c4446 100644 --- a/doc/administration/geo/replication/high_availability.md +++ b/doc/administration/geo/replication/high_availability.md @@ -79,9 +79,9 @@ The **primary** database will require modification later, as part of A **secondary** cluster is similar to any other GitLab HA cluster, with two major differences: -* The main PostgreSQL database is a read-only replica of the **primary** node's +- The main PostgreSQL database is a read-only replica of the **primary** node's PostgreSQL database. -* There is also a single PostgreSQL database for the **secondary** cluster, +- There is also a single PostgreSQL database for the **secondary** cluster, called the "tracking database", which tracks the synchronization state of various resources. @@ -93,9 +93,9 @@ from the normal HA setup. Configure the following services, again using the non-Geo high availability documentation: -* [Configuring Redis for GitLab HA](../../high_availability/redis.md) for high +- [Configuring Redis for GitLab HA](../../high_availability/redis.md) for high availability. -* [NFS](../../high_availability/nfs.md) which will store data that is +- [NFS](../../high_availability/nfs.md) which will store data that is synchronized from the **primary** node. ### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node @@ -270,15 +270,15 @@ After making these changes [Reconfigure GitLab][gitlab-reconfigure] so the chang On the secondary the following GitLab frontend services will be enabled: -* geo-logcursor -* gitlab-pages -* gitlab-workhorse -* logrotate -* nginx -* registry -* remote-syslog -* sidekiq -* unicorn +- geo-logcursor +- gitlab-pages +- gitlab-workhorse +- logrotate +- nginx +- registry +- remote-syslog +- sidekiq +- unicorn Verify these services by running `sudo gitlab-ctl status` on the frontend application servers. |