1.[Reconfigure GitLab](https://docs.gitlab.com/ee/administration/restart_gitlab.html#omnibus-gitlab-reconfigure) to apply the configuration changes.
...
...
@@ -791,9 +791,9 @@
used on the GitLab Rails instance. To amend GitLab configuration, edit
`/etc/gitlab/gitlab.rb` and specify the value of `postgresql['version']`:
```ruby
postgresql['version'] = 14
```
```ruby
postgresql['version']=14
```
1. Reconfigure GitLab:
...
...
@@ -1046,10 +1046,10 @@
1. Secondary nodes must be upgraded before the primary node.
1. On the secondary nodes, edit `/etc/gitlab/gitlab.rb` to include the following:
```shell
# Replace X with the number of DB nodes + 1
postgresql['max_replication_slots']= X
```
```shell
# Replace X with the number of DB nodes + 1
postgresql['max_replication_slots'] = X
```
1. Run `gitlab-ctl reconfigure` to update the configuration.
1. Run `sudo gitlab-ctl restart postgresql` to get PostgreSQL restarted with the new configuration.
...
...
@@ -1064,10 +1064,10 @@
1. Once all secondary nodes are upgraded, run `pg-upgrade` on the primary node.
1. On the primary node, edit `/etc/gitlab/gitlab.rb` to include the following:
```shell
# Replace X with the number of DB nodes + 1
postgresql['max_replication_slots'] = X
```
```shell
# Replace X with the number of DB nodes + 1
postgresql['max_replication_slots'] = X
```
1. Run `gitlab-ctl reconfigure` to update the configuration.
1. Run `sudo gitlab-ctl restart postgresql` to get PostgreSQL restarted with the new configuration.
...
...
@@ -1096,7 +1096,6 @@
```shell
pg_basebackup: could not create temporary replication slot "pg_basebackup_12345": ERROR: all replication slots are in use
HINT: Free one or increase max_replication_slots.
```
### Upgrading a Geo instance
...
...
@@ -1238,3 +1237,13 @@
```shell
sudo gitlab-ctl reconfigure
```
### Database CPU load very high
If the database CPU load is very high, it could be caused by the [auto cancel redundant pipelines setting](https://docs.gitlab.com/ee/ci/pipelines/settings.html#auto-cancel-redundant-pipelines). For more details, see [issue 435250](https://gitlab.com/gitlab-org/gitlab/-/issues/435250).
To work around this issue:
- You can allocate more CPU resources to the database server.
- If Sidekiq is overloaded, you might need to [add more Sidekiq processes](https://gitlab.com/gitlab-org/gitlab/-/administration/sidekiq/extra_sidekiq_processes.md#start-multiple-processes) for the `ci_cancel_redundant_pipelines` queue if your projects have a very large number of pipelines.
- You can enable the `disable_cancel_redundant_pipelines_service` feature flag to disable this setting instance-wide and see if the CPU load goes down. This disables the feature for all projects, and can lead to increased resource use by pipelines that are no longer being cancelled automatically.