Remove references of repmgr from docs

Patroni replaced repmgr and was made a requirement from 14.0 and later.

doc/administration/geo/setup/database.md

@@ -616,17 +616,6 @@ On all GitLab Geo **secondary** sites:
 
 ## Multi-node database replication
 
-NOTE:
-Patroni is the supported
-[highly available PostgreSQL solution](../../postgresql/replication_and_failover.md). If you still haven't [migrated from repmgr to Patroni](#migrating-from-repmgr-to-patroni), you're highly advised to do so.
-
-### Migrating from repmgr to Patroni
-
-1. Before migrating, you should ensure there is no replication lag between the **primary** and **secondary** sites and that replication is paused. You can pause and resume replication with `gitlab-ctl geo-replication-pause` and `gitlab-ctl geo-replication-resume` on a Geo secondary database node.
-1. Follow the [instructions to migrate repmgr to Patroni](../../postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni). When configuring Patroni on each **primary** site database node, add `patroni['replication_slots'] = { '<slot_name>' => 'physical' }`
-   to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your **secondary** site. This ensures that Patroni recognizes the replication slot as permanent and doesn't drop it upon restarting.
-1. If database replication to the **secondary** site was paused before migration, resume replication after Patroni is confirmed as working on the **primary** site.
-
 ### Migrating a single PostgreSQL node to Patroni
 
 Before the introduction of Patroni, Geo had no support for Linux package installations for HA setups on the **secondary** site.
@@ -656,9 +645,6 @@ For instructions on how to set up Patroni on the primary site, see the
 
 In a Geo secondary site, the main PostgreSQL database is a read-only replica of the primary site's PostgreSQL database.
 
-If you are using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni)
-for migrating from `repmgr` to Patroni.
-
 A production-ready and secure setup requires at least:
 
 - 3 Consul nodes _(primary and secondary sites)_

doc/administration/postgresql/replication_and_failover.md

@@ -264,11 +264,6 @@ Patroni honours any other PostgreSQL configuration that was made with the `postg
 `max_wal_senders` by default is set to `5`. If you wish to change this you must set it with the `patroni['postgresql']['max_wal_senders']`
 configuration key.
 
-NOTE:
-The configuration of a Patroni node is very similar to a repmgr but shorter. When Patroni is enabled, first you can ignore
-any replication setting of PostgreSQL (which is overwritten). Then, you can remove any `repmgr[...]` or
-repmgr-specific configuration as well. Especially, make sure that you remove `postgresql['shared_preload_libraries'] = 'repmgr_funcs'`.
-
 Here is an example:
 
 ```ruby
@@ -738,10 +733,7 @@ After deploying the configuration follow these steps:
 
 ## Patroni
 
-NOTE:
-Using Patroni instead of Repmgr is supported for PostgreSQL 11 and required for PostgreSQL 12. Starting with GitLab 14.0, only PostgreSQL 12 is available and hence Patroni is mandatory to achieve failover and replication.
-
-Patroni is an opinionated solution for PostgreSQL high-availability. It takes the control of PostgreSQL, overrides its configuration, and manages its lifecycle (start, stop, restart). Patroni is the only option for PostgreSQL 12 clustering and for cascading replication for Geo deployments.
+Patroni is an opinionated solution for PostgreSQL high-availability. It takes the control of PostgreSQL, overrides its configuration, and manages its lifecycle (start, stop, restart). Patroni is the only option for PostgreSQL 12+ clustering and for cascading replication for Geo deployments.
 
 The fundamental [architecture](#example-recommended-setup-manual-steps) (mentioned above) does not change for Patroni.
 You do not need any special consideration for Patroni while provisioning your database nodes. Patroni heavily relies on Consul to store the state of the cluster and elect a leader. Any failure in Consul cluster and its leader election propagates to the Patroni cluster as well.
@@ -968,46 +960,6 @@ sudo gitlab-ctl patroni resume
 
 For further details, see [Patroni documentation on this subject](https://patroni.readthedocs.io/en/latest/pause.html).
 
-### Switching from repmgr to Patroni
-
-WARNING:
-Switching from repmgr to Patroni is straightforward, the other way around is _not_. Rolling back from Patroni to repmgr can be complicated and may involve deletion of data directory. If you need to do that, contact GitLab support.
-
-You can switch an exiting database cluster to use Patroni instead of repmgr with the following steps:
-
-1. Stop repmgr on all replica nodes and lastly with the primary node:
-
-   ```shell
-   sudo gitlab-ctl stop repmgrd
-   ```
-
-1. Stop PostgreSQL on all replica nodes:
-
-   ```shell
-   sudo gitlab-ctl stop postgresql
-   ```
-
-   NOTE:
-   Ensure that there is no `walsender` process running on the primary node.
-   `ps aux | grep walsender` must not show any running process.
-
-1. On the primary node, [configure Patroni](#configuring-patroni-cluster). Remove `repmgr` and any other
-   repmgr-specific configuration. Also remove any configuration that is related to PostgreSQL replication.
-1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) on the primary node.
-   It makes it the leader. You can check this with:
-
-   ```shell
-   sudo gitlab-ctl tail patroni
-   ```
-
-1. Repeat the last two steps for all replica nodes. `gitlab.rb` should look the same on all nodes.
-1. If present, remove the `gitlab_repmgr` database and role on the primary. If you don't delete the `gitlab_repmgr`
-   database, upgrading PostgreSQL 11 to 12 fails with:
-
-   ```plaintext
-   could not load library "$libdir/repmgr_funcs": ERROR:  could not access file "$libdir/repmgr_funcs": No such file or directory
-   ```
-
 ### Upgrading PostgreSQL major version in a Patroni cluster
 
 For a list of the bundled PostgreSQL versions and the default version for each release, see the [PostgreSQL versions of the Linux package](../package_information/postgresql_versions.md).

doc/update/versions/gitlab_14_changes.md

@@ -821,7 +821,7 @@ DETAILS:
 Prerequisites:
 
 - The [GitLab 14.0 release post contains several important notes](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#upgrade)
-  about pre-requisites including [using Patroni instead of repmgr](../../administration/postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni),
+  about pre-requisites including [using Patroni instead of repmgr](https://archives.docs.gitlab.com/15.0/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni),
   migrating to hashed storage and [to Puma](../../administration/operations/puma.md).
 - The support of PostgreSQL 11 [has been dropped](../../install/requirements.md#database). Make sure to [update your database](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) to version 12 before updating to GitLab 14.0.
 
@@ -885,7 +885,7 @@ Other issues:
 
 - The binaries for PostgreSQL 11 and repmgr have been removed. Before upgrading, you must:
   1. Ensure the installation is using [PostgreSQL 12](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
-  1. If using repmgr, [convert to using Patroni](../../administration/postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni).
+  1. If using repmgr, [convert to using Patroni](https://archives.docs.gitlab.com/15.0/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni).
 
 - In GitLab 13.0, `sidekiq-cluster` was enabled by default and the `sidekiq` service ran `sidekiq-cluster` under the hood.
   However, users could control this behavior using `sidekiq['cluster']` setting to run Sidekiq directly instead. Users