Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

4 files changed, 87 insertions, 5 deletions

diff --git a/doc/administration/postgresql/external.md b/doc/administration/postgresql/external.md
index 5d693793a92..7036502e377 100644
--- a/doc/administration/postgresql/external.md
+++ b/doc/administration/postgresql/external.md
@@ -21,7 +21,7 @@ If you use a cloud-managed service, or provide your own PostgreSQL instance:
 1. If you are using a cloud-managed service, you may need to grant additional
    roles to your `gitlab` user:
    - Amazon RDS requires the [`rds_superuser`](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Roles) role.
-   - Azure Database for PostgreSQL requires the [`azure_pg_admin`](https://docs.microsoft.com/en-us/azure/postgresql/howto-create-users#how-to-create-additional-admin-users-in-azure-database-for-postgresql) role. Azure Database for PostgreSQL - Flexible Server requires [allow-listing extensions before they can be installed](https://docs.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions#how-to-use-postgresql-extensions).
+   - Azure Database for PostgreSQL requires the [`azure_pg_admin`](https://docs.microsoft.com/en-us/azure/postgresql/single-server/how-to-create-users#how-to-create-additional-admin-users-in-azure-database-for-postgresql) role. Azure Database for PostgreSQL - Flexible Server requires [allow-listing extensions before they can be installed](https://docs.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions#how-to-use-postgresql-extensions).
    - Google Cloud SQL requires the [`cloudsqlsuperuser`](https://cloud.google.com/sql/docs/postgres/users#default-users) role.
 
    This is for the installation of extensions during installation and upgrades. As an alternative,
@@ -48,3 +48,20 @@ If you use a cloud-managed service, or provide your own PostgreSQL instance:
    ```shell
    sudo gitlab-ctl reconfigure
    ```
+
+## Troubleshooting
+
+### Resolve `SSL SYSCALL error: EOF detected` error
+
+When using an external PostgreSQL instance, you may see an error like:
+
+```shell
+pg_dump: error: Error message from server: SSL SYSCALL error: EOF detected
+```
+
+To resolve this error, ensure that you are meeting the
+[minimum PostgreSQL requirements](../../install/requirements.md#postgresql-requirements). After
+upgrading your RDS instance to a suitable version, you should be able to perform a backup without
+this error. Refer to issue #64763
+([Segmentation fault citing `LooseForeignKeys::CleanupWorker` causes complete database restart](https://gitlab.com/gitlab-org/gitlab/-/issues/364763))
+for more information.
diff --git a/doc/administration/postgresql/moving.md b/doc/administration/postgresql/moving.md
new file mode 100644
index 00000000000..23d377dba37
--- /dev/null
+++ b/doc/administration/postgresql/moving.md
@@ -0,0 +1,65 @@
+---
+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/engineering/ux/technical-writing/#assignments
+---
+
+# Moving GitLab databases to a different PostgreSQL instance **(FREE SELF)**
+
+Sometimes it is necessary to move your databases from one PostgreSQL instance to
+another. For example, if you are using AWS Aurora and are preparing to
+enable Database Load Balancing, you will need to move your databases to
+RDS for PostgreSQL.
+
+To move databases from one instance to another:
+
+1. Gather the source and destination PostgreSQL endpoint information:
+
+   ```shell
+   SRC_PGHOST=<source postgresql host>
+   SRC_PGUSER=<source postgresql user>
+
+   DST_PGHOST=<destination postgresql host>
+   DST_PGUSER=<destination postgresql user>
+   ```
+
+1. Stop GitLab:
+
+   ```shell
+   sudo gitlab-ctl stop
+   ```
+
+1. Dump the databases from the source:
+
+   ```shell
+   /opt/gitlab/embedded/bin/pg_dump -h $SRC_PGHOST -U $SRC_PGUSER -c -C -f gitlabhq_production.sql gitlabhq_production
+   /opt/gitlab/embedded/bin/pg_dump -h $SRC_PGHOST -U $SRC_PGUSER -c -C -f praefect_production.sql praefect_production
+   ```
+
+1. Restore the databases to the destination (this will overwrite any existing databases with the same names):
+
+   ```shell
+   /opt/gitlab/embedded/bin/psql -h $DST_PGHOST -U $DST_PGUSER -f praefect_production.sql postgres
+   /opt/gitlab/embedded/bin/psql -h $DST_PGHOST -U $DST_PGUSER -f gitlabhq_production.sql postgres
+   ```
+
+1. Configure the GitLab application servers with the appropriate connection details
+   for your destination PostgreSQL instance in your `/etc/gitlab/gitlab.rb` file:
+
+   ```ruby
+   gitlab_rails['db_host'] = '<destination postgresql host>'
+   ```
+
+   For more information on GitLab multi-node setups, refer to the [reference architectures](../reference_architectures/index.md).
+
+1. Reconfigure for the changes to take effect:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Restart GitLab:
+
+   ```shell
+   sudo gitlab-ctl start
+   ```
diff --git a/doc/administration/postgresql/pgbouncer.md b/doc/administration/postgresql/pgbouncer.md
index 8ae2b6497f8..b12edd4b9ad 100644
--- a/doc/administration/postgresql/pgbouncer.md
+++ b/doc/administration/postgresql/pgbouncer.md
@@ -173,7 +173,7 @@ ote_pid | tls
 Some database changes have to be done directly, and not through PgBouncer.
 
 Read more about the affected tasks: [database restores](../../raketasks/backup_restore.md#back-up-and-restore-for-installations-using-pgbouncer)
-and [GitLab upgrades](../../update/zero_downtime.md#use-postgresql-ha).
+and [GitLab upgrades](../../update/zero_downtime.md#postgresql).
 
 1. To find the primary node, run the following on a database node:
 
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index e9b607ad5d4..37471a4f491 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -996,7 +996,7 @@ You can switch an exiting database cluster to use Patroni instead of repmgr with
 
 ### Upgrading PostgreSQL major version in a Patroni cluster
 
-As of GitLab 13.3, PostgreSQL 11.7 and 12.3 are both shipped with Omnibus GitLab by default. As of GitLab 13.7, PostgreSQL 12 is the default. If you want to upgrade to PostgreSQL 12 in versions prior to GitLab 13.7, you must ask for it explicitly.
+As of GitLab 14.1, PostgreSQL 12.6 and 13.3 are both shipped with Omnibus GitLab by default. As of GitLab 15.0, PostgreSQL 13 is the default. If you want to upgrade to PostgreSQL 13 in versions prior to GitLab 15.0, you must ask for it explicitly.
 
 WARNING:
 The procedure for upgrading PostgreSQL in a Patroni cluster is different than when upgrading using repmgr.
@@ -1046,7 +1046,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
 1. Upgrade PostgreSQL on **the leader node** and make sure that the upgrade is completed successfully:
 
    ```shell
-   sudo gitlab-ctl pg-upgrade -V 12
+   sudo gitlab-ctl pg-upgrade -V 13
    ```
 
    NOTE:
@@ -1073,7 +1073,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
 1. Upgrade PostgreSQL **on replicas** (you can do this in parallel on all of them):
 
    ```shell
-   sudo gitlab-ctl pg-upgrade -V 12
+   sudo gitlab-ctl pg-upgrade -V 13
    ```
 
 NOTE: