Fix markdown for HA topic
This commit is contained in:
parent
858d1fa7ed
commit
3fb5952efd
|
@ -23,10 +23,10 @@ environments including [Basic Scaling](README.md#basic-scaling) and
|
|||
|
||||
### Provide your own PostgreSQL instance **[CORE ONLY]**
|
||||
|
||||
If you want to use your own deployed PostgreSQL instance(s),
|
||||
If you want to use your own deployed PostgreSQL instance(s),
|
||||
see [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance-core-only)
|
||||
for more details. However, you can use the GitLab Omnibus package to easily
|
||||
deploy the bundled PostgreSQL.
|
||||
for more details. However, you can use the GitLab Omnibus package to easily
|
||||
deploy the bundled PostgreSQL.
|
||||
|
||||
### Standalone PostgreSQL using GitLab Omnibus **[CORE ONLY]**
|
||||
|
||||
|
@ -36,19 +36,19 @@ deploy the bundled PostgreSQL.
|
|||
- Do not complete any other steps on the download page.
|
||||
1. Generate a password hash for PostgreSQL. This assumes you will use the default
|
||||
username of `gitlab` (recommended). The command will request a password
|
||||
and confirmation. Use the value that is output by this command in the next
|
||||
and confirmation. Use the value that is output by this command in the next
|
||||
step as the value of `POSTGRESQL_PASSWORD_HASH`.
|
||||
|
||||
```sh
|
||||
sudo gitlab-ctl pg-password-md5 gitlab
|
||||
```
|
||||
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add the contents below, updating placeholder
|
||||
values appropriately.
|
||||
|
||||
values appropriately.
|
||||
|
||||
- `POSTGRESQL_PASSWORD_HASH` - The value output from the previous step
|
||||
- `APPLICATION_SERVER_IP_BLOCKS` - A space delimited list of IP subnets or IP
|
||||
addresses of the GitLab application servers that will connect to the
|
||||
addresses of the GitLab application servers that will connect to the
|
||||
database. Example: `%w(123.123.123.123/32 123.123.123.234/32)`
|
||||
|
||||
```ruby
|
||||
|
@ -65,11 +65,11 @@ deploy the bundled PostgreSQL.
|
|||
postgresql['listen_address'] = '0.0.0.0'
|
||||
postgresql['port'] = 5432
|
||||
|
||||
# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
|
||||
# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
|
||||
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
|
||||
|
||||
# Replace XXX.XXX.XXX.XXX/YY with Network Address
|
||||
# ????
|
||||
# ????
|
||||
postgresql['trust_auth_cidr_addresses'] = %w(APPLICATION_SERVER_IP_BLOCKS)
|
||||
|
||||
# Disable automatic database migrations
|
||||
|
@ -77,12 +77,12 @@ deploy the bundled PostgreSQL.
|
|||
```
|
||||
|
||||
NOTE: **Note:** The role `postgres_role` was introduced with GitLab 10.3
|
||||
|
||||
|
||||
1. [Reconfigure GitLab] for the changes to take effect.
|
||||
1. Note the PostgreSQL node's IP address or hostname, port, and
|
||||
plain text password. These will be necessary when configuring the GitLab
|
||||
application servers later.
|
||||
|
||||
|
||||
Advanced configuration options are supported and can be added if
|
||||
needed.
|
||||
|
||||
|
@ -101,18 +101,19 @@ environments including [Horizontal](README.md#horizontal),
|
|||
If you want to use your own deployed PostgreSQL instance(s),
|
||||
see [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance-core-only)
|
||||
for more details. However, you can use the GitLab Omnibus package to easily
|
||||
deploy the bundled PostgreSQL.
|
||||
deploy the bundled PostgreSQL.
|
||||
|
||||
### High Availability with GitLab Omnibus **[PREMIUM ONLY]**
|
||||
|
||||
> Important notes:
|
||||
>
|
||||
> - This document will focus only on configuration supported with [GitLab Premium](https://about.gitlab.com/pricing/), using the Omnibus GitLab package.
|
||||
> - If you are a Community Edition or Starter user, consider using a cloud hosted solution.
|
||||
> - This document will not cover installations from source.
|
||||
>
|
||||
> - If HA setup is not what you were looking for, see the [database configuration document](http://docs.gitlab.com/omnibus/settings/database.html)
|
||||
> for the Omnibus GitLab packages.
|
||||
|
||||
>
|
||||
> Please read this document fully before attempting to configure PostgreSQL HA
|
||||
> for GitLab.
|
||||
>
|
||||
|
@ -122,9 +123,9 @@ The recommended configuration for a PostgreSQL HA requires:
|
|||
|
||||
- A minimum of three database nodes
|
||||
- Each node will run the following services:
|
||||
- `PostgreSQL` - The database itself
|
||||
- `repmgrd` - A service to monitor, and handle failover in case of a failure
|
||||
- `Consul` agent - Used for service discovery, to alert other nodes when failover occurs
|
||||
- `PostgreSQL` - The database itself
|
||||
- `repmgrd` - A service to monitor, and handle failover in case of a failure
|
||||
- `Consul` agent - Used for service discovery, to alert other nodes when failover occurs
|
||||
- A minimum of three `Consul` server nodes
|
||||
- A minimum of one `pgbouncer` service node
|
||||
|
||||
|
@ -142,7 +143,7 @@ Database nodes run two services with PostgreSQL:
|
|||
- Selecting a new master for the cluster.
|
||||
- Promoting the new node to master.
|
||||
- Instructing remaining servers to follow the new master node.
|
||||
|
||||
|
||||
On failure, the old master node is automatically evicted from the cluster, and should be rejoined manually once recovered.
|
||||
- Consul. Monitors the status of each node in the database cluster and tracks its health in a service definition on the consul cluster.
|
||||
|
||||
|
@ -171,13 +172,10 @@ Similarly, PostgreSQL access is controlled based on the network source.
|
|||
|
||||
This is why you will need:
|
||||
|
||||
> IP address of each nodes network interface
|
||||
> - This can be set to `0.0.0.0` to listen on all interfaces. It cannot
|
||||
> be set to the loopack address `127.0.0.1`
|
||||
>
|
||||
> Network Address
|
||||
> - This can be in subnet (i.e. `192.168.0.0/255.255.255.0`) or CIDR (i.e.
|
||||
> `192.168.0.0/24`) form.
|
||||
- IP address of each nodes network interface. This can be set to `0.0.0.0` to
|
||||
listen on all interfaces. It cannot be set to the loopack address `127.0.0.1`.
|
||||
- Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
|
||||
or CIDR (i.e. `192.168.0.0/24`) form.
|
||||
|
||||
##### User information
|
||||
|
||||
|
@ -199,7 +197,7 @@ When using default setup, minimum configuration requires:
|
|||
sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME
|
||||
```
|
||||
|
||||
- `CONSUL_SERVER_NODES`. The IP addresses or DNS records of the Consul server nodes.
|
||||
- `CONSUL_SERVER_NODES`. The IP addresses or DNS records of the Consul server nodes.
|
||||
|
||||
Few notes on the service itself:
|
||||
|
||||
|
@ -220,8 +218,7 @@ the number of database nodes in the cluster.
|
|||
This is used to prevent replication from using up all of the
|
||||
available database connections.
|
||||
|
||||
> Note:
|
||||
> - In this document we are assuming 3 database nodes, which makes this configuration:
|
||||
In this document we are assuming 3 database nodes, which makes this configuration:
|
||||
|
||||
```
|
||||
postgresql['max_wal_senders'] = 4
|
||||
|
@ -277,7 +274,7 @@ be allowed to authenticate with the service.
|
|||
Few notes on the service itself:
|
||||
|
||||
- The service runs under the same system account as the database
|
||||
- In the package, this is by default `gitlab-psql`
|
||||
- In the package, this is by default `gitlab-psql`
|
||||
- The service will have a superuser database user account generated for it
|
||||
- This defaults to `gitlab_repmgr`
|
||||
|
||||
|
@ -327,7 +324,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
|
||||
/opt/gitlab/embedded/bin/consul members
|
||||
```
|
||||
|
||||
|
@ -401,14 +398,15 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
|
|||
repmgr['master_on_initialization'] = false
|
||||
```
|
||||
|
||||
1. [Reconfigure GitLab] for te changes to take effect.
|
||||
1. [Reconfigure GitLab] for the changes to take effect.
|
||||
|
||||
> Please note:
|
||||
>
|
||||
> - If you want your database to listen on a specific interface, change the config:
|
||||
> `postgresql['listen_address'] = '0.0.0.0'`
|
||||
> `postgresql['listen_address'] = '0.0.0.0'`.
|
||||
> - If your Pgbouncer service runs under a different user account,
|
||||
> you also need to specify: `postgresql['pgbouncer_user'] = PGBOUNCER_USERNAME` in
|
||||
> your configuration
|
||||
> your configuration.
|
||||
|
||||
##### Database nodes post-configuration
|
||||
|
||||
|
@ -449,7 +447,6 @@ Select one node as a primary node.
|
|||
is not an IP address, it will need to be a resolvable name (via DNS or
|
||||
`/etc/hosts`)
|
||||
|
||||
|
||||
###### Secondary nodes
|
||||
|
||||
1. Set up the repmgr standby:
|
||||
|
@ -500,7 +497,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
|
||||
gitlab-ctl repmgr cluster show
|
||||
```
|
||||
|
||||
|
@ -518,7 +515,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
|
||||
su - gitlab-consul
|
||||
gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node'
|
||||
```
|
||||
|
@ -649,7 +646,7 @@ in the Troubleshooting section before proceeding.
|
|||
##### Ensure GitLab is running
|
||||
|
||||
At this point, your GitLab instance should be up and running. Verify you are
|
||||
able to login, and create issues and merge requests. If you have troubles check
|
||||
able to login, and create issues and merge requests. If you have troubles check
|
||||
the [Troubleshooting section](#troubleshooting).
|
||||
|
||||
#### Example configuration
|
||||
|
@ -665,13 +662,13 @@ can connect to each freely other on those addresses.
|
|||
|
||||
Here is a list and description of each machine and the assigned IP:
|
||||
|
||||
* `10.6.0.11`: Consul 1
|
||||
* `10.6.0.12`: Consul 2
|
||||
* `10.6.0.13`: Consul 3
|
||||
* `10.6.0.21`: PostgreSQL master
|
||||
* `10.6.0.22`: PostgreSQL secondary
|
||||
* `10.6.0.23`: PostgreSQL secondary
|
||||
* `10.6.0.31`: GitLab application
|
||||
- `10.6.0.11`: Consul 1
|
||||
- `10.6.0.12`: Consul 2
|
||||
- `10.6.0.13`: Consul 3
|
||||
- `10.6.0.21`: PostgreSQL master
|
||||
- `10.6.0.22`: PostgreSQL secondary
|
||||
- `10.6.0.23`: PostgreSQL secondary
|
||||
- `10.6.0.31`: GitLab application
|
||||
|
||||
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
|
||||
|
||||
|
@ -735,7 +732,7 @@ consul['configuration'] = {
|
|||
|
||||
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
|
||||
configuration:
|
||||
|
||||
```
|
||||
# HA setting to specify if a node should attempt to be master on initialization
|
||||
|
@ -839,10 +836,10 @@ In this example we start with all servers on the same 10.6.0.0/16 private networ
|
|||
|
||||
Here is a list and description of each machine and the assigned IP:
|
||||
|
||||
* `10.6.0.21`: PostgreSQL master
|
||||
* `10.6.0.22`: PostgreSQL secondary
|
||||
* `10.6.0.23`: PostgreSQL secondary
|
||||
* `10.6.0.31`: GitLab application
|
||||
- `10.6.0.21`: PostgreSQL master
|
||||
- `10.6.0.22`: PostgreSQL secondary
|
||||
- `10.6.0.23`: PostgreSQL secondary
|
||||
- `10.6.0.31`: GitLab application
|
||||
|
||||
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
|
||||
|
||||
|
@ -853,6 +850,7 @@ Please note that after the initial configuration, if a failover occurs, the Post
|
|||
##### Example minimal configuration for database servers
|
||||
|
||||
##### Primary node
|
||||
|
||||
On primary database node edit `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
```ruby
|
||||
|
@ -1047,7 +1045,6 @@ For example:
|
|||
repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
|
||||
```
|
||||
|
||||
|
||||
##### MD5 Authentication
|
||||
|
||||
If you are running on an untrusted network, repmgr can use md5 authentication
|
||||
|
@ -1114,7 +1111,7 @@ steps to fix the problem:
|
|||
1. Change to the `gitlab-consul` user - `su - gitlab-consul`
|
||||
1. Try the check command again - `gitlab-ctl repmgr-check-master`.
|
||||
|
||||
Now there should not be errors. If errors still occur then there is another problem.
|
||||
Now there should not be errors. If errors still occur then there is another problem.
|
||||
|
||||
#### PGBouncer error `ERROR: pgbouncer cannot connect to server`
|
||||
|
||||
|
@ -1157,8 +1154,6 @@ If you're running into an issue with a component not outlined here, be sure to c
|
|||
**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only).
|
||||
If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-ce/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
|
||||
|
||||
---
|
||||
|
||||
Read more on high-availability configuration:
|
||||
|
||||
1. [Configure Redis](redis.md)
|
||||
|
|
Loading…
Reference in New Issue