diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-18 06:08:23 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-18 06:08:23 +0300 |
commit | 47e35934185ed4292b1b7ef365a3156cc3e0293f (patch) | |
tree | 3880aa972283ab7d88448b2b51af29e88b2c9da4 /doc/administration/high_availability | |
parent | a1565a8243dd2cce29d0489d5ed40f9291d828d4 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration/high_availability')
-rw-r--r-- | doc/administration/high_availability/consul.md | 18 | ||||
-rw-r--r-- | doc/administration/high_availability/database.md | 24 | ||||
-rw-r--r-- | doc/administration/high_availability/gitlab.md | 6 | ||||
-rw-r--r-- | doc/administration/high_availability/nfs.md | 4 | ||||
-rw-r--r-- | doc/administration/high_availability/pgbouncer.md | 4 | ||||
-rw-r--r-- | doc/administration/high_availability/redis.md | 16 |
6 files changed, 36 insertions, 36 deletions
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md index 790296e8db9..71d380dbec7 100644 --- a/doc/administration/high_availability/consul.md +++ b/doc/administration/high_availability/consul.md @@ -64,7 +64,7 @@ command to verify all server nodes are communicating: The output should be similar to: -``` +```plaintext Node Address Status Type Build Protocol DC CONSUL_NODE_ONE XXX.XXX.XXX.YYY:8301 alive server 0.9.2 2 gitlab_consul CONSUL_NODE_TWO XXX.XXX.XXX.YYY:8301 alive server 0.9.2 2 gitlab_consul @@ -80,8 +80,8 @@ check the [Troubleshooting section](#troubleshooting) before proceeding. To see which nodes are part of the cluster, run the following on any member in the cluster -``` -# /opt/gitlab/embedded/bin/consul members +```shell +$ /opt/gitlab/embedded/bin/consul members Node Address Status Type Build Protocol DC consul-b XX.XX.X.Y:8301 alive server 0.9.0 2 gitlab_consul consul-c XX.XX.X.Y:8301 alive server 0.9.0 2 gitlab_consul @@ -127,7 +127,7 @@ By default, the server agents will attempt to [bind](https://www.consul.io/docs/ You will see messages like the following in `gitlab-ctl tail consul` output if you are running into this issue: -``` +```plaintext 2017-09-25_19:53:39.90821 2017/09/25 19:53:39 [WARN] raft: no known peers, aborting election 2017-09-25_19:53:41.74356 2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader ``` @@ -154,7 +154,7 @@ In the case that a node has multiple private IPs the agent be confused as to whi You will see messages like the following in `gitlab-ctl tail consul` output if you are running into this issue: -``` +```plaintext 2017-11-09_17:41:45.52876 ==> Starting Consul agent... 2017-11-09_17:41:45.53057 ==> Error creating agent: Failed to get advertise address: Multiple private IPs found. Please configure one. ``` @@ -181,10 +181,10 @@ If you lost enough server agents in the cluster to break quorum, then the cluste By default, GitLab does not store anything in the Consul cluster that cannot be recreated. To erase the Consul database and reinitialize -``` -# gitlab-ctl stop consul -# rm -rf /var/opt/gitlab/consul/data -# gitlab-ctl start consul +```shell +gitlab-ctl stop consul +rm -rf /var/opt/gitlab/consul/data +gitlab-ctl start consul ``` After this, the cluster should start back up, and the server agents rejoin. Shortly after that, the client agents should rejoin as well. diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md index 02684f575d4..8e57b049730 100644 --- a/doc/administration/high_availability/database.md +++ b/doc/administration/high_availability/database.md @@ -229,7 +229,7 @@ available database connections. In this document we are assuming 3 database nodes, which makes this configuration: -``` +```ruby postgresql['max_wal_senders'] = 4 ``` @@ -352,7 +352,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value. to inform `gitlab-ctl` that they are standby nodes initially and it need not attempt to register them as primary node - ``` + ```ruby # HA setting to specify if a node should attempt to be master on initialization repmgr['master_on_initialization'] = false ``` @@ -396,7 +396,7 @@ Select one node as a primary node. The output should be similar to the following: - ``` + ```plaintext Role | Name | Upstream | Connection String ----------+----------|----------|---------------------------------------- * master | HOSTNAME | | host=HOSTNAME user=gitlab_repmgr dbname=gitlab_repmgr @@ -442,7 +442,7 @@ Select one node as a primary node. The output should be similar to the following: - ``` + ```plaintext Role | Name | Upstream | Connection String ----------+---------|-----------|------------------------------------------------ * master | MASTER | | host=MASTER_NODE_NAME user=gitlab_repmgr dbname=gitlab_repmgr @@ -463,7 +463,7 @@ gitlab-ctl repmgr cluster show The output should be similar to: -``` +```plaintext Role | Name | Upstream | Connection String ----------+--------------|--------------|-------------------------------------------------------------------- * master | MASTER | | host=MASTER port=5432 user=gitlab_repmgr dbname=gitlab_repmgr @@ -652,7 +652,7 @@ On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the configuration added to primary node, noted above. In addition, append the following configuration: -``` +```ruby # HA setting to specify if a node should attempt to be master on initialization repmgr['master_on_initialization'] = false ``` @@ -706,7 +706,7 @@ After deploying the configuration follow these steps: gitlab-psql -d gitlabhq_production ``` - ``` + ```shell CREATE EXTENSION pg_trgm; ``` @@ -804,7 +804,7 @@ consul['configuration'] = { On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the information added to primary node, noted above. In addition, append the following configuration -``` +```ruby # HA setting to specify if a node should attempt to be master on initialization repmgr['master_on_initialization'] = false ``` @@ -908,7 +908,7 @@ after it has been restored to service. It will output something like: - ``` + ```plaintext 959789412 ``` @@ -1052,7 +1052,7 @@ Now there should not be errors. If errors still occur then there is another prob You may get this error when running `gitlab-rake gitlab:db:configure` or you may see the error in the PgBouncer log file. -``` +```plaintext PG::ConnectionBad: ERROR: pgbouncer cannot connect to server ``` @@ -1063,13 +1063,13 @@ You can confirm that this is the issue by checking the PostgreSQL log on the mas database node. If you see the following error then `trust_auth_cidr_addresses` is the problem. -``` +```plaintext 2018-03-29_13:59:12.11776 FATAL: no pg_hba.conf entry for host "123.123.123.123", user "pgbouncer", database "gitlabhq_production", SSL off ``` To fix the problem, add the IP address to `/etc/gitlab/gitlab.rb`. -``` +```ruby postgresql['trust_auth_cidr_addresses'] = %w(123.123.123.123/32 <other_cidrs>) ``` diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md index 71ab169a801..b4269cd4e38 100644 --- a/doc/administration/high_availability/gitlab.md +++ b/doc/administration/high_availability/gitlab.md @@ -11,7 +11,7 @@ these additional steps before proceeding with GitLab installation. 1. If necessary, install the NFS client utility packages using the following commands: - ``` + ```shell # Ubuntu/Debian apt-get install nfs-common @@ -24,7 +24,7 @@ these additional steps before proceeding with GitLab installation. to configure your NFS server. See [NFS documentation](nfs.md) for the various options. Here is an example snippet to add to `/etc/fstab`: - ``` + ```plaintext 10.1.0.1:/var/opt/gitlab/.ssh /var/opt/gitlab/.ssh nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/uploads nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 @@ -35,7 +35,7 @@ these additional steps before proceeding with GitLab installation. 1. Create the shared directories. These may be different depending on your NFS mount locations. - ``` + ```shell mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data ``` diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index f7c5593e211..1d0dc420987 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -132,7 +132,7 @@ For supported database architecture, please see our documentation on Below is an example of an NFS mount point defined in `/etc/fstab` we use on GitLab.com: -``` +```plaintext 10.1.1.1:/var/opt/gitlab/git-data /var/opt/gitlab/git-data nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 ``` @@ -149,7 +149,7 @@ Note there are several options that you should consider using: It's recommended to nest all GitLab data dirs within a mount, that allows automatic restore of backups without manually moving existing data. -``` +```plaintext mountpoint └── gitlab-data ├── builds diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md index 09b33c3554a..7b93159628d 100644 --- a/doc/administration/high_availability/pgbouncer.md +++ b/doc/administration/high_availability/pgbouncer.md @@ -83,7 +83,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data The output should be similar to the following: - ``` + ```plaintext name | host | port | database | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections ---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+--------------------- gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production | | 20 | 0 | | 0 | 0 @@ -102,7 +102,7 @@ If you're running more than one PgBouncer node as recommended, then at this time As an example here's how you could do it with [HAProxy](https://www.haproxy.org/): -``` +```plaintext global log /dev/log local0 log localhost local1 notice diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 9b733034f5b..8e94b56a940 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -391,7 +391,7 @@ The prerequisites for a HA Redis setup are the following: prevent database migrations from running on upgrade, add the following configuration to your `/etc/gitlab/gitlab.rb` file: - ``` + ```ruby gitlab_rails['auto_migrate'] = false ``` @@ -439,7 +439,7 @@ The prerequisites for a HA Redis setup are the following: 1. To prevent reconfigure from running automatically on upgrade, run: - ``` + ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` @@ -569,7 +569,7 @@ multiple machines with the Sentinel daemon. 1. To prevent database migrations from running on upgrade, run: - ``` + ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` @@ -898,14 +898,14 @@ Before proceeding with the troubleshooting below, check your firewall rules: You can check if everything is correct by connecting to each server using `redis-cli` application, and sending the `info replication` command as below. -``` +```shell /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication ``` When connected to a `master` Redis, you will see the number of connected `slaves`, and a list of each with connection details: -``` +```plaintext # Replication role:master connected_slaves:1 @@ -920,7 +920,7 @@ repl_backlog_histlen:1048576 When it's a `slave`, you will see details of the master connection and if its `up` or `down`: -``` +```plaintext # Replication role:slave master_host:10.133.1.58 @@ -959,7 +959,7 @@ To make sure your configuration is correct: 1. SSH into your GitLab application server 1. Enter the Rails console: - ``` + ```shell # For Omnibus installations sudo gitlab-rails console @@ -985,7 +985,7 @@ To make sure your configuration is correct: 1. Then back in the Rails console from the first step, run: - ``` + ```ruby redis.info ``` |