VladPolskiy/gitlab-ce
1
0
Fork 0
mirror of https://github.com/gitlabhq/gitlabhq.git synced 2025-08-15 21:22:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

Browse Source
This commit is contained in:
GitLab Bot
2024-12-23 00:30:53 +00:00
parent 1e8b913634
commit a46507fde1
3 changed files with 15 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/administration/geo/index.md
View File

@ -73,6 +73,8 @@ Benefits:
You can use Geo to migrate to new infrastructure. If you move your GitLab instance to a new server or data center, use Geo to migrate your GitLab data to the new instance in the background while your old instance continues to serve your users. Any changes to your active GitLab data are copied to your new instance, so there's no data loss during the cutover.
You cannot use Geo to migrate a PostgreSQL database from one operating system to another. See [Upgrading operating systems for PostgreSQL](../postgresql/upgrading_os.md).
Benefits:
- Significantly reduce downtime during migration compared to the backup and restore migration method. Copy data to the new instance in the background without stopping the active GitLab instance before the cutover downtime window.

21
doc/administration/geo/replication/troubleshooting/postgresql_replication.md
View File

@ -37,18 +37,21 @@ If the secondary site is not able to reconnect, use the following steps to remov
Slots where `active` is `f` are inactive.
- When this slot should be active, because you have a **secondary** site configured using that slot,
look for the [PostgreSQL logs](../../../logs/index.md#postgresql-logs) for the **secondary** site,
- If this slot should be active, because you have a **secondary** site configured using that slot:
- Look for the [PostgreSQL logs](../../../logs/index.md#postgresql-logs) for the **secondary** site,
to view why the replication is not running.
- If you are no longer using the slot (for example, you no longer have Geo enabled), or the secondary site is no longer able to reconnect,
you should remove it using the PostgreSQL console session:
- If the secondary site is no longer able to reconnect:
```sql
SELECT pg_drop_replication_slot('<name_of_inactive_slot>');
```
1. Remove the slot using the PostgreSQL console session:
1. Follow either the steps [to remove that Geo site](../remove_geo_site.md) if it's no longer required,
or [re-initiate the replication process](../../setup/database.md#step-3-initiate-the-replication-process), which recreates the replication slot correctly.
```sql
SELECT pg_drop_replication_slot('<name_of_inactive_slot>');
```
1. [Re-initiate the replication process](../../setup/database.md#step-3-initiate-the-replication-process),
which recreates the replication slot correctly.
- If you are no longer using the slot (for example, you no longer have Geo enabled), follow the steps [to remove that Geo site](../remove_geo_site.md).
## Message: `WARNING: oldest xmin is far in the past` and `pg_wal` size growing

1
doc/administration/geo/setup/database.md
View File

@ -964,6 +964,7 @@ For each node running a Patroni instance on the secondary site:
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
postgresql['listen_address'] = '0.0.0.0' # You can use a public or VPC address here instead
# GitLab Rails configuration is required for `gitlab-ctl geo-replication-pause`
gitlab_rails['db_password'] = 'POSTGRESQL_PASSWORD'
gitlab_rails['enable'] = true
gitlab_rails['auto_migrate'] = false