diff options
Diffstat (limited to 'doc/administration/high_availability')
| -rw-r--r-- | doc/administration/high_availability/consul.md | 2 | ||||
| -rw-r--r-- | doc/administration/high_availability/database.md | 52 | ||||
| -rw-r--r-- | doc/administration/high_availability/gitlab.md | 2 | ||||
| -rw-r--r-- | doc/administration/high_availability/nfs.md | 6 | ||||
| -rw-r--r-- | doc/administration/high_availability/nfs_host_client_setup.md | 12 | ||||
| -rw-r--r-- | doc/administration/high_availability/pgbouncer.md | 6 | ||||
| -rw-r--r-- | doc/administration/high_availability/redis.md | 8 |
7 files changed, 45 insertions, 43 deletions
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md index 71d380dbec7..0ea5e55cc35 100644 --- a/doc/administration/high_availability/consul.md +++ b/doc/administration/high_availability/consul.md @@ -58,7 +58,7 @@ On each Consul node perform the following: Before moving on, make sure Consul is configured correctly. Run the following command to verify all server nodes are communicating: -```sh +```shell /opt/gitlab/embedded/bin/consul members ``` diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md index 8e57b049730..daeb0f9baf5 100644 --- a/doc/administration/high_availability/database.md +++ b/doc/administration/high_availability/database.md @@ -46,7 +46,7 @@ deploy the bundled PostgreSQL. and confirmation. Use the value that is output by this command in the next step as the value of `POSTGRESQL_PASSWORD_HASH`. - ```sh + ```shell sudo gitlab-ctl pg-password-md5 gitlab ``` @@ -202,7 +202,7 @@ When using default setup, minimum configuration requires: - `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME ``` @@ -245,7 +245,7 @@ We will need the following password information for the application's database u - `POSTGRESQL_PASSWORD_HASH`. This is a hash generated out of the username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME ``` @@ -258,7 +258,7 @@ When using default setup, minimum configuration requires: - `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME ``` @@ -376,13 +376,13 @@ Select one node as a primary node. 1. Open a database prompt: - ```sh + ```shell gitlab-psql -d gitlabhq_production ``` 1. Enable the `pg_trgm` extension: - ```sh + ```shell CREATE EXTENSION pg_trgm; ``` @@ -390,7 +390,7 @@ Select one node as a primary node. 1. Verify the cluster is initialized with one node: - ```sh + ```shell gitlab-ctl repmgr cluster show ``` @@ -411,7 +411,7 @@ Select one node as a primary node. 1. Set up the repmgr standby: - ```sh + ```shell gitlab-ctl repmgr standby setup MASTER_NODE_NAME ``` @@ -436,7 +436,7 @@ Select one node as a primary node. 1. Verify the node now appears in the cluster: - ```sh + ```shell gitlab-ctl repmgr cluster show ``` @@ -457,7 +457,7 @@ Before moving on, make sure the databases are configured correctly. Run the following command on the **primary** node to verify that replication is working properly: -```sh +```shell gitlab-ctl repmgr cluster show ``` @@ -475,7 +475,7 @@ If the 'Role' column for any node says "FAILED", check the Also, check that the check master command works successfully on each node: -```sh +```shell su - gitlab-consul gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node' ``` @@ -512,7 +512,7 @@ attributes set, but the following need to be set. Ensure that all migrations ran: -```sh +```shell gitlab-rake gitlab:db:configure ``` @@ -702,7 +702,7 @@ After deploying the configuration follow these steps: Enable the `pg_trgm` extension - ```sh + ```shell gitlab-psql -d gitlabhq_production ``` @@ -714,7 +714,7 @@ After deploying the configuration follow these steps: Make this node a standby of the primary - ```sh + ```shell gitlab-ctl repmgr standby setup 10.6.0.21 ``` @@ -722,7 +722,7 @@ After deploying the configuration follow these steps: Make this node a standby of the primary - ```sh + ```shell gitlab-ctl repmgr standby setup 10.6.0.21 ``` @@ -730,13 +730,13 @@ After deploying the configuration follow these steps: Set `gitlab-consul` user's PgBouncer password to `toomanysecrets` - ```sh + ```shell gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul ``` Run database migrations - ```sh + ```shell gitlab-rake gitlab:db:configure ``` @@ -863,7 +863,7 @@ If you need to failover manually, you have two options: Run: -```sh +```shell gitlab-ctl stop postgresql ``` @@ -875,14 +875,14 @@ standby nodes. 1. Ensure the old master node is not still active. 1. Login to the server that should become the new master and run: - ```sh + ```shell gitlab-ctl repmgr standby promote ``` 1. If there are any other standby servers in the cluster, have them follow the new master server: - ```sh + ```shell gitlab-ctl repmgr standby follow NEW_MASTER ``` @@ -894,7 +894,7 @@ after it has been restored to service. - If you want to remove the node from the cluster, on any other node in the cluster, run: - ```sh + ```shell gitlab-ctl repmgr standby unregister --node=X ``` @@ -902,7 +902,7 @@ after it has been restored to service. To find this, you can use: - ```sh + ```shell awk -F = '$1 == "node" { print $2 }' /var/opt/gitlab/postgresql/repmgr.conf ``` @@ -914,13 +914,13 @@ after it has been restored to service. Then you will use this id to unregister the node: - ```sh + ```shell gitlab-ctl repmgr standby unregister --node=959789412 ``` - To add the node as a standby server: - ```sh + ```shell gitlab-ctl repmgr standby follow NEW_MASTER gitlab-ctl restart repmgrd ``` @@ -972,7 +972,7 @@ the previous section: 1. On the current master node, create a password for the `gitlab` and `gitlab_repmgr` user: - ```sh + ```shell gitlab-psql -d template1 template1=# \password gitlab_repmgr Enter password: **** @@ -992,7 +992,7 @@ the previous section: 1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to when asked: - ```sh + ```shell gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*' ``` diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md index b4269cd4e38..ad00cb8df9f 100644 --- a/doc/administration/high_availability/gitlab.md +++ b/doc/administration/high_availability/gitlab.md @@ -101,7 +101,7 @@ these additional steps before proceeding with GitLab installation. On the first application server, run: -```sh +```shell sudo gitlab-ctl reconfigure ``` diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 1d0dc420987..0d88191151a 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -55,7 +55,7 @@ NOTE: **Note:** From GitLab 12.1, it will automatically be detected if Rugged ca If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using: -```sh +```shell sudo gitlab-rake gitlab:features:unset_rugged ``` @@ -82,7 +82,7 @@ on an Linux NFS server, do the following: 1. On the NFS server, run: - ```sh + ```shell echo 0 > /proc/sys/fs/leases-enable sysctl -w fs.leases-enable=0 ``` @@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in `/etc/fstab`: -```bash +```shell /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0 diff --git a/doc/administration/high_availability/nfs_host_client_setup.md b/doc/administration/high_availability/nfs_host_client_setup.md index 5b6b28bf633..75dec1eef29 100644 --- a/doc/administration/high_availability/nfs_host_client_setup.md +++ b/doc/administration/high_availability/nfs_host_client_setup.md @@ -27,7 +27,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application. -```sh +```shell apt-get update apt-get install nfs-kernel-server ``` @@ -47,7 +47,7 @@ In this setup we will share the home directory on the host with the client. Edit Restart the NFS server after making changes to the `exports` file for the changes to take effect. -```sh +```shell systemctl restart nfs-kernel-server ``` @@ -64,7 +64,7 @@ inside your HA environment to the NFS server configured above. The nfs-common provides NFS functionality without installing server components which we don't need running on the application nodes. -```sh +```shell apt-get update apt-get install nfs-common ``` @@ -76,14 +76,14 @@ Please note that if your mount point directory contains any files they will be h once the remote shares are mounted. An empty/new directory on the client is recommended for this purpose. -```sh +```shell mkdir -p /nfs/home ``` Confirm that the mount point works by mounting it on the client and checking that it is mounted with the command below: -```sh +```shell mount <host_ip_address>:/home df -h ``` @@ -134,7 +134,7 @@ Check that NFS traffic from the client is allowed by the firewall on the host by the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific client with the command below. -```sh +```shell sudo ufw allow from <client-ip-address> to any port nfs ``` diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md index 7b93159628d..cea55e6c9b4 100644 --- a/doc/administration/high_availability/pgbouncer.md +++ b/doc/administration/high_availability/pgbouncer.md @@ -57,7 +57,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Create a `.pgpass` file so Consul is able to reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked: - ```sh + ```shell gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul ``` @@ -65,7 +65,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Ensure each node is talking to the current master: - ```sh + ```shell gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD ``` @@ -77,7 +77,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Once the console prompt is available, run the following queries: - ```sh + ```shell show databases ; show clients ; ``` diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 8e94b56a940..01ee94ce208 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -8,8 +8,10 @@ type: reference The following are the requirements for providing your own Redis instance: -- Redis version 2.8 or higher. Version 3.2 or higher is recommend as this is - what ships with the GitLab Omnibus package. +- GitLab 12.0 and later requires Redis version 3.2 or higher. Version 3.2 or higher is recommend as this is + what ships with the GitLab Omnibus package. Older Redis versions do not + support an optional count argument to SPOP which is now required for + [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). - Standalone Redis or Redis high availability with Sentinel are supported. Redis Cluster is not supported. - Managed Redis from cloud providers such as AWS Elasticache will work. If these @@ -978,7 +980,7 @@ To make sure your configuration is correct: 1. To simulate a failover on master Redis, SSH into the Redis server and run: - ```bash + ```shell # port must match your master redis port, and the sleep time must be a few seconds bigger than defined one redis-cli -h localhost -p 6379 DEBUG sleep 20 ``` |