281 lines
12 KiB
Markdown
281 lines
12 KiB
Markdown
---
|
|
stage: Data Stores
|
|
group: Database
|
|
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
|
type: reference
|
|
---
|
|
|
|
# Working with the bundled PgBouncer service **(FREE SELF)**
|
|
|
|
NOTE:
|
|
PgBouncer is bundled in the `gitlab-ee` package, but is free to use.
|
|
For support, you need a [Premium subscription](https://about.gitlab.com/pricing/).
|
|
|
|
[PgBouncer](https://www.pgbouncer.org/) is used to seamlessly migrate database
|
|
connections between servers in a failover scenario. Additionally, it can be used
|
|
in a non-fault-tolerant setup to pool connections, speeding up response time
|
|
while reducing resource usage.
|
|
|
|
GitLab Premium includes a bundled version of PgBouncer that can be managed
|
|
through `/etc/gitlab/gitlab.rb`.
|
|
|
|
## PgBouncer as part of a fault-tolerant GitLab installation
|
|
|
|
This content has been moved to a [new location](replication_and_failover.md#configure-pgbouncer-nodes).
|
|
|
|
## PgBouncer as part of a non-fault-tolerant GitLab installation
|
|
|
|
1. Generate PGBOUNCER_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 pgbouncer`
|
|
|
|
1. Generate SQL_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 gitlab`. Enter the plaintext SQL_USER_PASSWORD later.
|
|
|
|
1. On your database node, ensure the following is set in your `/etc/gitlab/gitlab.rb`
|
|
|
|
```ruby
|
|
postgresql['pgbouncer_user_password'] = 'PGBOUNCER_USER_PASSWORD_HASH'
|
|
postgresql['sql_user_password'] = 'SQL_USER_PASSWORD_HASH'
|
|
postgresql['listen_address'] = 'XX.XX.XX.Y' # Where XX.XX.XX.Y is the ip address on the node postgresql should listen on
|
|
postgresql['md5_auth_cidr_addresses'] = %w(AA.AA.AA.B/32) # Where AA.AA.AA.B is the IP address of the pgbouncer node
|
|
```
|
|
|
|
1. Run `gitlab-ctl reconfigure`
|
|
|
|
NOTE:
|
|
If the database was already running, it needs to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
|
|
|
|
1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
|
|
|
|
```ruby
|
|
pgbouncer['enable'] = true
|
|
pgbouncer['databases'] = {
|
|
gitlabhq_production: {
|
|
host: 'DATABASE_HOST',
|
|
user: 'pgbouncer',
|
|
password: 'PGBOUNCER_USER_PASSWORD_HASH'
|
|
}
|
|
}
|
|
```
|
|
|
|
You can pass additional configuration parameters per database, for example:
|
|
|
|
```ruby
|
|
pgbouncer['databases'] = {
|
|
gitlabhq_production: {
|
|
...
|
|
pool_mode: 'transaction'
|
|
}
|
|
}
|
|
```
|
|
|
|
Use these parameters with caution. For the complete list of parameters refer to the
|
|
[PgBouncer documentation](https://www.pgbouncer.org/config.html#section-databases).
|
|
|
|
1. Run `gitlab-ctl reconfigure`
|
|
|
|
1. On the node running Puma, make sure the following is set in `/etc/gitlab/gitlab.rb`
|
|
|
|
```ruby
|
|
gitlab_rails['db_host'] = 'PGBOUNCER_HOST'
|
|
gitlab_rails['db_port'] = '6432'
|
|
gitlab_rails['db_password'] = 'SQL_USER_PASSWORD'
|
|
```
|
|
|
|
1. Run `gitlab-ctl reconfigure`
|
|
|
|
1. At this point, your instance should connect to the database through PgBouncer. If you are having issues, see the [Troubleshooting](#troubleshooting) section
|
|
|
|
## Backups
|
|
|
|
Do not backup or restore GitLab through a PgBouncer connection: it causes a GitLab outage.
|
|
|
|
[Read more about this and how to reconfigure backups](../../raketasks/backup_restore.md#back-up-and-restore-for-installations-using-pgbouncer).
|
|
|
|
## Enable Monitoring
|
|
|
|
> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3786) in GitLab 12.0.
|
|
|
|
If you enable Monitoring, it must be enabled on **all** PgBouncer servers.
|
|
|
|
1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
|
|
|
|
```ruby
|
|
# Enable service discovery for Prometheus
|
|
consul['enable'] = true
|
|
consul['monitoring_service_discovery'] = true
|
|
|
|
# Replace placeholders
|
|
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
|
|
# with the addresses of the Consul server nodes
|
|
consul['configuration'] = {
|
|
retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
|
|
}
|
|
|
|
# Set the network addresses that the exporters will listen on
|
|
node_exporter['listen_address'] = '0.0.0.0:9100'
|
|
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
|
|
```
|
|
|
|
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
|
|
|
|
## Administrative console
|
|
|
|
As part of Omnibus GitLab, a command is provided to automatically connect to the
|
|
PgBouncer administrative console. See the
|
|
[PgBouncer documentation](https://www.pgbouncer.org/usage.html#admin-console)
|
|
for detailed instructions on how to interact with the console.
|
|
|
|
To start a session run the following and provide the password for the `pgbouncer`
|
|
user:
|
|
|
|
```shell
|
|
sudo gitlab-ctl pgb-console
|
|
```
|
|
|
|
To get some basic information about the instance:
|
|
|
|
```shell
|
|
pgbouncer=# show databases; show clients; show servers;
|
|
name | host | port | database | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
|
|
---------------------+-----------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
|
|
gitlabhq_production | 127.0.0.1 | 5432 | gitlabhq_production | | 100 | 5 | | 0 | 1
|
|
pgbouncer | | 6432 | pgbouncer | pgbouncer | 2 | 0 | statement | 0 | 0
|
|
(2 rows)
|
|
|
|
type | user | database | state | addr | port | local_addr | local_port | connect_time | request_time | ptr | link
|
|
| remote_pid | tls
|
|
------+-----------+---------------------+--------+-----------+-------+------------+------------+---------------------+---------------------+-----------+------
|
|
+------------+-----
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44590 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12444c0 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44592 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12447c0 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44594 | 127.0.0.1 | 6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x1244940 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44706 | 127.0.0.1 | 6432 | 2018-04-24 22:14:22 | 2018-04-24 22:16:31 | 0x1244ac0 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44708 | 127.0.0.1 | 6432 | 2018-04-24 22:14:22 | 2018-04-24 22:15:15 | 0x1244c40 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44794 | 127.0.0.1 | 6432 | 2018-04-24 22:15:15 | 2018-04-24 22:15:15 | 0x1244dc0 |
|
|
| 0 |
|
|
C | gitlab | gitlabhq_production | active | 127.0.0.1 | 44798 | 127.0.0.1 | 6432 | 2018-04-24 22:15:15 | 2018-04-24 22:16:31 | 0x1244f40 |
|
|
| 0 |
|
|
C | pgbouncer | pgbouncer | active | 127.0.0.1 | 44660 | 127.0.0.1 | 6432 | 2018-04-24 22:13:51 | 2018-04-24 22:17:12 | 0x1244640 |
|
|
| 0 |
|
|
(8 rows)
|
|
|
|
type | user | database | state | addr | port | local_addr | local_port | connect_time | request_time | ptr | link | rem
|
|
ote_pid | tls
|
|
------+--------+---------------------+-------+-----------+------+------------+------------+---------------------+---------------------+-----------+------+----
|
|
--------+-----
|
|
S | gitlab | gitlabhq_production | idle | 127.0.0.1 | 5432 | 127.0.0.1 | 35646 | 2018-04-24 22:15:15 | 2018-04-24 22:17:10 | 0x124dca0 | |
|
|
19980 |
|
|
(1 row)
|
|
```
|
|
|
|
## Procedure for bypassing PgBouncer
|
|
|
|
### Omnibus installations
|
|
|
|
Some database changes have to be done directly, and not through PgBouncer.
|
|
|
|
The main affected tasks are [database restores](../../raketasks/backup_restore.md#back-up-and-restore-for-installations-using-pgbouncer)
|
|
and [GitLab upgrades with database migrations](../../update/zero_downtime.md#postgresql).
|
|
|
|
1. To find the primary node, run the following on a database node:
|
|
|
|
```shell
|
|
sudo gitlab-ctl patroni members
|
|
```
|
|
|
|
1. Edit `/etc/gitlab/gitlab.rb` on the application node you're performing the task on, and update
|
|
`gitlab_rails['db_host']` and `gitlab_rails['db_port']` with the database
|
|
primary's host and port.
|
|
|
|
1. Run reconfigure:
|
|
|
|
```shell
|
|
sudo gitlab-ctl reconfigure
|
|
```
|
|
|
|
After you've performed the tasks or procedure, switch back to using PgBouncer:
|
|
|
|
1. Change back `/etc/gitlab/gitlab.rb` to point to PgBouncer.
|
|
1. Run reconfigure:
|
|
|
|
```shell
|
|
sudo gitlab-ctl reconfigure
|
|
```
|
|
|
|
### Helm chart installations
|
|
|
|
High-availability deployments also need to bypass PgBouncer for the same reasons as Omnibus-based ones.
|
|
For this type of installation:
|
|
|
|
- Database backup and restore tasks are performed by the toolbox container.
|
|
- Migration tasks are performed by the migrations container.
|
|
|
|
You should override the PostgreSQL port on each subchart, so these tasks can execute and connect to PostgreSQL directly:
|
|
|
|
- [Toolbox](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/charts/toolbox/values.yaml#L40)
|
|
- [Migrations](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/charts/migrations/values.yaml#L46)
|
|
|
|
## Fine tuning
|
|
|
|
PgBouncer's default settings suit the majority of installations.
|
|
In specific cases you may want to change the performance-specific and resource-specific variables to either increase possible
|
|
throughput or to limit resource utilization that could cause memory exhaustion on the database.
|
|
|
|
You can find the parameters and respective documentation on the [official PgBouncer documentation](https://www.pgbouncer.org/config.html).
|
|
Listed below are the most relevant ones and their defaults on an Omnibus GitLab installation:
|
|
|
|
- `pgbouncer['max_client_conn']` (default: `2048`, depends on server file descriptor limits)
|
|
This is the "frontend" pool in PgBouncer: connections from Rails to PgBouncer.
|
|
- `pgbouncer['default_pool_size']` (default: `100`)
|
|
This is the "backend" pool in PgBouncer: connections from PgBouncer to the database.
|
|
|
|
The ideal number for `default_pool_size` must be enough to handle all provisioned services that need to access
|
|
the database. Each of the listed services below use the following formula to define database pool size:
|
|
|
|
- `puma` : `max_threads + headroom` (default `14`)
|
|
- `max_threads` is configured via: `gitlab['puma']['max_threads']` (default: `4`)
|
|
- `headroom` can be configured via `DB_POOL_HEADROOM` environment variable (default to `10`)
|
|
- `sidekiq` : `max_concurrency + 1 + headroom` (default: `31`)
|
|
- `max_concurrency` is configured via: `sidekiq['max_concurrency']` (default: `20`)
|
|
- `headroom` can be configured via `DB_POOL_HEADROOM` environment variable (default to `10`)
|
|
- `geo-logcursor`: `1+headroom` (default: `11`)
|
|
- `headroom` can be configured via `DB_POOL_HEADROOM` environment variable (default to `10`)
|
|
|
|
To calculate the `default_pool_size`, multiply the number of instances of `puma`, `sidekiq` and `geo-logcursor` by the
|
|
number of connections each can consume as per listed above. The total is the suggested `default_pool_size`.
|
|
|
|
If you are using more than one PgBouncer with an internal Load Balancer, you may be able to divide the
|
|
`default_pool_size` by the number of instances to guarantee an evenly distributed load between them.
|
|
|
|
The `pgbouncer['max_client_conn']` is the hard limit of connections PgBouncer can accept. It's unlikely you need
|
|
to change this. If you are hitting that limit, you may want to consider adding additional PgBouncers with an internal
|
|
Load Balancer.
|
|
|
|
When setting up the limits for a PgBouncer that points to the Geo Tracking Database,
|
|
you can likely ignore `puma` from the equation, as it is only accessing that database sporadically.
|
|
|
|
## Troubleshooting
|
|
|
|
In case you are experiencing any issues connecting through PgBouncer, the first
|
|
place to check is always the logs:
|
|
|
|
```shell
|
|
sudo gitlab-ctl tail pgbouncer
|
|
```
|
|
|
|
Additionally, you can check the output from `show databases` in the
|
|
[administrative console](#administrative-console). In the output, you would expect
|
|
to see values in the `host` field for the `gitlabhq_production` database.
|
|
Additionally, `current_connections` should be greater than 1.
|
|
|
|
### Message: `LOG: invalid CIDR mask in address`
|
|
|
|
See the suggested fix [in Geo documentation](../geo/replication/troubleshooting.md#message-log--invalid-cidr-mask-in-address).
|
|
|
|
### Message: `LOG: invalid IP mask "md5": Name or service not known`
|
|
|
|
See the suggested fix [in Geo documentation](../geo/replication/troubleshooting.md#message-log--invalid-ip-mask-md5-name-or-service-not-known).
|