Moved database pages to setup folder

Moved the pages into the setup folder and fixed the broken
links in the other pages. This brings us closer to a more
jobs to be done focused documentation.

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -45,7 +45,7 @@ To bring the former **primary** node up to date:
    all the writes to this node](planned_failover.md#prevent-updates-to-the-primary-node)
    during this procedure.
 
-1. [Setup database replication](../replication/database.md). Note that in this
+1. [Setup database replication](../setup/database.md). Note that in this
    case, **primary** node refers to the current **primary** node, and **secondary** node refers to the
    former **primary** node.
 

doc/administration/geo/disaster_recovery/index.md

@@ -375,7 +375,7 @@ and after that you also need two extra steps.
    gitlab_rails['auto_migrate'] = false
    ```
 
-   (For more details about these settings you can read [Configure the primary server](../replication/database.md#step-1-configure-the-primary-server))
+   (For more details about these settings you can read [Configure the primary server](../setup/database.md#step-1-configure-the-primary-server))
 
 1. Save the file and reconfigure GitLab for the database listen changes and
    the replication slot changes to be applied.
@@ -408,7 +408,7 @@ and after that you also need two extra steps.
 ### Step 2. Initiate the replication process
 
 Now we need to make each **secondary** node listen to changes on the new **primary** node. To do that you need
-to [initiate the replication process](../replication/database.md#step-3-initiate-the-replication-process) again but this time
+to [initiate the replication process](../setup/database.md#step-3-initiate-the-replication-process) again but this time
 for another **primary** node. All the old replication settings will be overwritten.
 
 ## Troubleshooting

doc/administration/geo/replication/external_database.md

 ---
-stage: Enablement
-group: Geo
-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/#designated-technical-writers
-type: howto
+redirect_to: '../setup/external_database.md'
 ---
 
-# Geo with external PostgreSQL instances **(PREMIUM ONLY)**
-
-This document is relevant if you are using a PostgreSQL instance that is *not
-managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or
-manually installed and configured PostgreSQL instances.
-
-NOTE: **Note:**
-We strongly recommend running Omnibus-managed instances as they are actively
-developed and tested. We aim to be compatible with most external
-(not managed by Omnibus) databases but we do not guarantee compatibility.
-
-## **Primary** node
-
-1. SSH into a GitLab **primary** application server and login as root:
-
-   ```shell
-   sudo -i
-   ```
-
-1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** ID for your node (arbitrary value):
-
-   ```ruby
-   # The unique identifier for the Geo node.
-   gitlab_rails['geo_node_name'] = '<node_name_here>'
-   ```
-
-1. Reconfigure the **primary** node for the change to take effect:
-
-   ```shell
-   gitlab-ctl reconfigure
-   ```
-
-1. Execute the command below to define the node as **primary** node:
-
-   ```shell
-   gitlab-ctl set-geo-primary-node
-   ```
-
-   This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
-
-### Configure the external database to be replicated
-
-To set up an external database, you can either:
-
-- Set up streaming replication yourself (for example, in AWS RDS).
-- Perform the Omnibus configuration manually as follows.
-
-#### Leverage your cloud provider's tools to replicate the primary database
-
-Given you have a primary node set up on AWS EC2 that uses RDS.
-You can now just create a read-only replica in a different region and the
-replication process will be managed by AWS. Make sure you've set Network ACL, Subnet, and
-Security Group according to your needs, so the secondary application node can access the database.
-
-The following instructions detail how to create a read-only replica for common
-cloud providers:
-
-- Amazon RDS - [Creating a Read Replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)
-- Azure Database for PostgreSQL - [Create and manage read replicas in Azure Database for PostgreSQL](https://docs.microsoft.com/en-us/azure/postgresql/howto-read-replicas-portal)
-
-Once your read-only replica is set up, you can skip to [configure you secondary application node](#configure-secondary-application-nodes-to-use-the-external-read-replica).
-
-#### Manually configure the primary database for replication
-
-The [`geo_primary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
-configures the **primary** node's database to be replicated by making changes to
-`pg_hba.conf` and `postgresql.conf`. Make the following configuration changes
-manually to your external database configuration and ensure that you restart PostgreSQL
-afterwards for the changes to take effect:
-
-```plaintext
-##
-## Geo Primary Role
-## - pg_hba.conf
-##
-host    all         all               <trusted primary IP>/32       md5
-host    replication gitlab_replicator <trusted primary IP>/32       md5
-host    all         all               <trusted secondary IP>/32     md5
-host    replication gitlab_replicator <trusted secondary IP>/32     md5
-```
-
-```plaintext
-##
-## Geo Primary Role
-## - postgresql.conf
-##
-wal_level = hot_standby
-max_wal_senders = 10
-wal_keep_segments = 50
-max_replication_slots = 1 # number of secondary instances
-hot_standby = on
-```
-
-## **Secondary** nodes
-
-### Manually configure the replica database
-
-Make the following configuration changes manually to your `pg_hba.conf` and `postgresql.conf`
-of your external replica database and ensure that you restart PostgreSQL afterwards
-for the changes to take effect:
-
-```plaintext
-##
-## Geo Secondary Role
-## - pg_hba.conf
-##
-host    all         all               <trusted secondary IP>/32     md5
-host    replication gitlab_replicator <trusted secondary IP>/32     md5
-host    all         all               <trusted primary IP>/24       md5
-```
-
-```plaintext
-##
-## Geo Secondary Role
-## - postgresql.conf
-##
-wal_level = hot_standby
-max_wal_senders = 10
-wal_keep_segments = 10
-hot_standby = on
-```
-
-### Configure **secondary** application nodes to use the external read-replica
-
-With Omnibus, the
-[`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
-has three main functions:
-
-1. Configure the replica database.
-1. Configure the tracking database.
-1. Enable the [Geo Log Cursor](../index.md#geo-log-cursor) (not covered in this section).
-
-To configure the connection to the external read-replica database and enable Log Cursor:
-
-1. SSH into a GitLab **secondary** application server and login as root:
-
-   ```shell
-   sudo -i
-   ```
-
-1. Edit `/etc/gitlab/gitlab.rb` and add the following
-
-   ```ruby
-   ##
-   ## Geo Secondary role
-   ## - configure dependent flags automatically to enable Geo
-   ##
-   roles ['geo_secondary_role']
-
-   # note this is shared between both databases,
-   # make sure you define the same password in both
-   gitlab_rails['db_password'] = '<your_password_here>'
-
-   gitlab_rails['db_username'] = 'gitlab'
-   gitlab_rails['db_host'] = '<database_read_replica_host>'
-
-   # Disable the bundled Omnibus PostgreSQL, since we are
-   # using an external PostgreSQL
-   postgresql['enable'] = false
-   ```
-
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
-
-### Configure the tracking database
-
-**Secondary** nodes use a separate PostgreSQL installation as a tracking
-database to keep track of replication status and automatically recover from
-potential replication issues. Omnibus automatically configures a tracking database
-when `roles ['geo_secondary_role']` is set.
-If you want to run this database external to Omnibus, please follow the instructions below.
-
-If you are using a cloud-managed service for the tracking database, you may need
-to grant additional roles to your tracking database user (by default, this is
-`gitlab_geo`):
-
-- 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.
-
-If you have an external database ready to be used as the tracking database,
-follow the instructions below to use it:
-
-NOTE: **Note:**
-If you want to use AWS RDS as a tracking database, make sure it has access to
-the secondary database. Unfortunately, just assigning the same security group is not enough as
-outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to explicitly add an inbound
-rule to the read-replica's security group allowing any TCP traffic from
-the tracking database on port 5432.
-
-1. Ensure that your secondary node can communicate with your tracking database by
-   manually changing the `pg_hba.conf` that is associated with your tracking database.
-   Remember to restart PostgreSQL afterwards for the changes to take effect:
-
-    ```plaintext
-    ##
-    ## Geo Tracking Database Role
-    ## - pg_hba.conf
-    ##
-    host    all         all               <trusted tracking IP>/32      md5
-    host    all         all               <trusted secondary IP>/32     md5
-    ```
-
-1. SSH into a GitLab **secondary** server and login as root:
-
-   ```shell
-   sudo -i
-   ```
-
-1. Edit `/etc/gitlab/gitlab.rb` with the connection parameters and credentials for
-   the machine with the PostgreSQL instance:
-
-   ```ruby
-   geo_secondary['db_username'] = 'gitlab_geo'
-   geo_secondary['db_password'] = '<your_password_here>'
-
-   geo_secondary['db_host'] = '<tracking_database_host>'
-   geo_secondary['db_port'] = <tracking_database_port>      # change to the correct port
-   geo_postgresql['enable'] = false     # don't use internal managed instance
-   ```
-
-1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
-
-1. Run the tracking database migrations:
-
-   ```shell
-   gitlab-rake geo:db:create
-   gitlab-rake geo:db:migrate
-   ```
+This document was moved to [another location](../setup/external_database.md).

doc/administration/geo/replication/multiple_servers.md

@@ -147,7 +147,7 @@ The following documentation assumes the database will be run on
 a single node only. Multi-node PostgreSQL on **secondary** nodes is
 [not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
 
-Configure the [**secondary** database](database.md) as a read-only replica of
+Configure the [**secondary** database](../setup/database.md) as a read-only replica of
 the **primary** database. Use the following as a guide.
 
 1. Generate an MD5 hash of the desired password for the database user that the
@@ -222,7 +222,7 @@ the **primary** database. Use the following as a guide.
 After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
 
 If using an external PostgreSQL instance, refer also to
-[Geo with external PostgreSQL instances](external_database.md).
+[Geo with external PostgreSQL instances](../setup/external_database.md).
 
 ### Step 3: Configure the tracking database on the **secondary** node
 
@@ -294,7 +294,7 @@ Configure the tracking database.
 After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
 
 If using an external PostgreSQL instance, refer also to
-[Geo with external PostgreSQL instances](external_database.md).
+[Geo with external PostgreSQL instances](../setup/external_database.md).
 
 ### Step 4: Configure the frontend application servers on the **secondary** node
 

doc/administration/geo/replication/troubleshooting.md

@@ -251,7 +251,7 @@ sudo gitlab-rake gitlab:geo:check
 
    When performing a PostgreSQL major version (9 > 10) update this is expected. Follow:
 
-   - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
+   - [initiate-the-replication-process](../setup/database.md#step-3-initiate-the-replication-process)
 
 ## Fixing replication errors
 
@@ -268,7 +268,7 @@ default to 1. You may need to increase this value if you have more
 
 Be sure to restart PostgreSQL for this to take
 effect. See the [PostgreSQL replication
-setup](database.md#postgresql-replication) guide for more details.
+setup](../setup/database.md#postgresql-replication) guide for more details.
 
 ### Message: `FATAL:  could not start WAL streaming: ERROR:  replication slot "geo_secondary_my_domain_com" does not exist`?
 
@@ -276,11 +276,11 @@ This occurs when PostgreSQL does not have a replication slot for the
 **secondary** node by that name.
 
 You may want to rerun the [replication
-process](database.md) on the **secondary** node .
+process](../setup/database.md) on the **secondary** node .
 
 ### Message: "Command exceeded allowed execution time" when setting up replication?
 
-This may happen while [initiating the replication process](database.md#step-3-initiate-the-replication-process) on the **secondary** node,
+This may happen while [initiating the replication process](../setup/database.md#step-3-initiate-the-replication-process) on the **secondary** node,
 and indicates that your initial dataset is too large to be replicated in the default timeout (30 minutes).
 
 Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
@@ -754,7 +754,7 @@ This error refers to a problem with the database replica on a **secondary** node
 which Geo expects to have access to. It usually means, either:
 
 - An unsupported replication method was used (for example, logical replication).
-- The instructions to setup a [Geo database replication](database.md) were not followed correctly.
+- The instructions to setup a [Geo database replication](../setup/database.md) were not followed correctly.
 - Your database connection details are incorrect, that is you have specified the wrong
   user in your `/etc/gitlab/gitlab.rb` file.
 
@@ -774,7 +774,7 @@ The most common problems that prevent the database from replicating correctly ar
 - Database replication slot is misconfigured.
 - Database is not using a replication slot or another alternative and cannot catch-up because WAL files were purged.
 
-Make sure you follow the [Geo database replication](database.md) instructions for supported configuration.
+Make sure you follow the [Geo database replication](../setup/database.md) instructions for supported configuration.
 
 ### Geo database version (...) does not match latest migration (...)
 

doc/administration/geo/replication/version_specific_updates.md

@@ -343,7 +343,7 @@ Support for TLS-secured PostgreSQL replication has been added. If you are
 currently using PostgreSQL replication across the open internet without an
 external means of securing the connection (e.g., a site-to-site VPN), then you
 should immediately reconfigure your **primary** and **secondary** PostgreSQL instances
-according to the [updated instructions](database.md).
+according to the [updated instructions](../setup/database.md).
 
 If you *are* securing the connections externally and wish to continue doing so,
 ensure you include the new option `--sslmode=prefer` in future invocations of
@@ -441,7 +441,7 @@ Omnibus is the following:
 1. Check the steps about defining `postgresql['sql_user_password']`, `gitlab_rails['db_password']`.
 1. Make sure `postgresql['max_replication_slots']` matches the number of **secondary** Geo nodes locations.
 1. Install GitLab on the **secondary** server.
-1. Re-run the [database replication process](database.md#step-3-initiate-the-replication-process).
+1. Re-run the [database replication process](../setup/database.md#step-3-initiate-the-replication-process).
 
 ## Updating to GitLab 9.0
 

doc/administration/geo/setup/external_database.md

+---
+stage: Enablement
+group: Geo
+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/#designated-technical-writers
+type: howto
+---
+
+# Geo with external PostgreSQL instances **(PREMIUM ONLY)**
+
+This document is relevant if you are using a PostgreSQL instance that is *not
+managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or
+manually installed and configured PostgreSQL instances.
+
+NOTE: **Note:**
+We strongly recommend running Omnibus-managed instances as they are actively
+developed and tested. We aim to be compatible with most external
+(not managed by Omnibus) databases but we do not guarantee compatibility.
+
+## **Primary** node
+
+1. SSH into a GitLab **primary** application server and login as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** ID for your node (arbitrary value):
+
+   ```ruby
+   # The unique identifier for the Geo node.
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+   ```
+
+1. Reconfigure the **primary** node for the change to take effect:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+1. Execute the command below to define the node as **primary** node:
+
+   ```shell
+   gitlab-ctl set-geo-primary-node
+   ```
+
+   This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
+
+### Configure the external database to be replicated
+
+To set up an external database, you can either:
+
+- Set up streaming replication yourself (for example, in AWS RDS).
+- Perform the Omnibus configuration manually as follows.
+
+#### Leverage your cloud provider's tools to replicate the primary database
+
+Given you have a primary node set up on AWS EC2 that uses RDS.
+You can now just create a read-only replica in a different region and the
+replication process will be managed by AWS. Make sure you've set Network ACL, Subnet, and
+Security Group according to your needs, so the secondary application node can access the database.
+
+The following instructions detail how to create a read-only replica for common
+cloud providers:
+
+- Amazon RDS - [Creating a Read Replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)
+- Azure Database for PostgreSQL - [Create and manage read replicas in Azure Database for PostgreSQL](https://docs.microsoft.com/en-us/azure/postgresql/howto-read-replicas-portal)
+
+Once your read-only replica is set up, you can skip to [configure you secondary application node](#configure-secondary-application-nodes-to-use-the-external-read-replica).
+
+#### Manually configure the primary database for replication
+
+The [`geo_primary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
+configures the **primary** node's database to be replicated by making changes to
+`pg_hba.conf` and `postgresql.conf`. Make the following configuration changes
+manually to your external database configuration and ensure that you restart PostgreSQL
+afterwards for the changes to take effect:
+
+```plaintext
+##
+## Geo Primary Role
+## - pg_hba.conf
+##
+host    all         all               <trusted primary IP>/32       md5
+host    replication gitlab_replicator <trusted primary IP>/32       md5
+host    all         all               <trusted secondary IP>/32     md5
+host    replication gitlab_replicator <trusted secondary IP>/32     md5
+```
+
+```plaintext
+##
+## Geo Primary Role
+## - postgresql.conf
+##
+wal_level = hot_standby
+max_wal_senders = 10
+wal_keep_segments = 50
+max_replication_slots = 1 # number of secondary instances
+hot_standby = on
+```
+
+## **Secondary** nodes
+
+### Manually configure the replica database
+
+Make the following configuration changes manually to your `pg_hba.conf` and `postgresql.conf`
+of your external replica database and ensure that you restart PostgreSQL afterwards
+for the changes to take effect:
+
+```plaintext
+##
+## Geo Secondary Role
+## - pg_hba.conf
+##
+host    all         all               <trusted secondary IP>/32     md5
+host    replication gitlab_replicator <trusted secondary IP>/32     md5
+host    all         all               <trusted primary IP>/24       md5
+```
+
+```plaintext
+##
+## Geo Secondary Role
+## - postgresql.conf
+##
+wal_level = hot_standby
+max_wal_senders = 10
+wal_keep_segments = 10
+hot_standby = on
+```
+
+### Configure **secondary** application nodes to use the external read-replica
+
+With Omnibus, the
+[`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
+has three main functions:
+
+1. Configure the replica database.
+1. Configure the tracking database.
+1. Enable the [Geo Log Cursor](../index.md#geo-log-cursor) (not covered in this section).
+
+To configure the connection to the external read-replica database and enable Log Cursor:
+
+1. SSH into a GitLab **secondary** application server and login as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` and add the following
+
+   ```ruby
+   ##
+   ## Geo Secondary role
+   ## - configure dependent flags automatically to enable Geo
+   ##
+   roles ['geo_secondary_role']
+
+   # note this is shared between both databases,
+   # make sure you define the same password in both
+   gitlab_rails['db_password'] = '<your_password_here>'
+
+   gitlab_rails['db_username'] = 'gitlab'
+   gitlab_rails['db_host'] = '<database_read_replica_host>'
+
+   # Disable the bundled Omnibus PostgreSQL, since we are
+   # using an external PostgreSQL
+   postgresql['enable'] = false
+   ```
+
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+
+### Configure the tracking database
+
+**Secondary** nodes use a separate PostgreSQL installation as a tracking
+database to keep track of replication status and automatically recover from
+potential replication issues. Omnibus automatically configures a tracking database
+when `roles ['geo_secondary_role']` is set.
+If you want to run this database external to Omnibus, please follow the instructions below.
+
+If you are using a cloud-managed service for the tracking database, you may need
+to grant additional roles to your tracking database user (by default, this is
+`gitlab_geo`):
+
+- 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.
+
+If you have an external database ready to be used as the tracking database,
+follow the instructions below to use it:
+
+NOTE: **Note:**
+If you want to use AWS RDS as a tracking database, make sure it has access to
+the secondary database. Unfortunately, just assigning the same security group is not enough as
+outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to explicitly add an inbound
+rule to the read-replica's security group allowing any TCP traffic from
+the tracking database on port 5432.
+
+1. Ensure that your secondary node can communicate with your tracking database by
+   manually changing the `pg_hba.conf` that is associated with your tracking database.
+   Remember to restart PostgreSQL afterwards for the changes to take effect:
+
+    ```plaintext
+    ##
+    ## Geo Tracking Database Role
+    ## - pg_hba.conf
+    ##
+    host    all         all               <trusted tracking IP>/32      md5
+    host    all         all               <trusted secondary IP>/32     md5
+    ```
+
+1. SSH into a GitLab **secondary** server and login as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` with the connection parameters and credentials for
+   the machine with the PostgreSQL instance:
+
+   ```ruby
+   geo_secondary['db_username'] = 'gitlab_geo'
+   geo_secondary['db_password'] = '<your_password_here>'
+
+   geo_secondary['db_host'] = '<tracking_database_host>'
+   geo_secondary['db_port'] = <tracking_database_port>      # change to the correct port
+   geo_postgresql['enable'] = false     # don't use internal managed instance
+   ```
+
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+
+1. Run the tracking database migrations:
+
+   ```shell
+   gitlab-rake geo:db:create
+   gitlab-rake geo:db:migrate
+   ```

doc/administration/geo/setup/index.md

@@ -21,7 +21,7 @@ If you installed GitLab using the Omnibus packages (highly recommended):
 
 1. [Install GitLab Enterprise Edition](https://about.gitlab.com/install/) on the server that will serve as the **secondary** node. Do not create an account or log in to the new **secondary** node.
 1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary** node to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
-1. [Set up the database replication](../replication/database.md) (`primary (read-write) <-> secondary (read-only)` topology).
+1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
 1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md). This step is required and needs to be done on **both** the **primary** and **secondary** nodes.
 1. [Configure GitLab](../replication/configuration.md) to set the **primary** and **secondary** nodes.
 1. Optional: [Configure a secondary LDAP server](../../auth/ldap/index.md) for the **secondary** node. See [notes on LDAP](../index.md#ldap).

doc/administration/troubleshooting/postgresql.md

@@ -34,7 +34,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - [More about external PostgreSQL](../postgresql/external.md)
 
-- [Running Geo with external PostgreSQL](../geo/replication/external_database.md)
+- [Running Geo with external PostgreSQL](../geo/setup/external_database.md)
 
 - [Upgrades when running PostgreSQL configured for HA.](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-gitlab-ha-cluster)
 

doc/gitlab-geo/database.md

 ---
-redirect_to: '../administration/geo/replication/database.md'
+redirect_to: '../administration/geo/setup/database.md'
 ---
 
-This document was moved to [another location](../administration/geo/replication/database.md).
+This document was moved to [another location](../administration/geo/setup/database.md).

doc/gitlab-geo/database_source.md

 ---
-redirect_to: '../administration/geo/replication/database.md'
+redirect_to: '../administration/geo/setup/database.md'
 ---
 
-This document was moved to [another location](../administration/geo/replication/database.md).
+This document was moved to [another location](../administration/geo/setup/database.md).