Merge branch 'docs-anchors4-ha-ee' into 'master'

Docs: (EE Port) Fix anchors in HA docs

See merge request gitlab-org/gitlab-ee!9615

doc/administration/high_availability/alpha_database.md

-# Configuring a Database for GitLab HA
+---
+redirect_to: 'database.md'
+---
 
-This documentation has been moved to the main [database documentation](database.md#configure_using_omnibus_for_high_availability).
+This documentation has been moved to the main
+[database documentation](database.md#configure_using_omnibus_for_high_availability).

doc/administration/high_availability/database.md

@@ -294,7 +294,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 
 On each Consul node perform the following:
 
-1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul_information) before executing the next step.
+1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul-information) before executing the next step.
 
 1. Edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
@@ -345,7 +345,7 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
 
 #### Configuring the Database nodes
 
-1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul_information), [`PGBOUNCER_PASSWORD_HASH`](#pgbouncer_information), [`POSTGRESQL_PASSWORD_HASH`](#postgresql_information), [`Number of db nodes`](#postgresql_information), and [`Network Address`](#network_address) before executing the next step.
+1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul-information), [`PGBOUNCER_PASSWORD_HASH`](#pgbouncer-information), [`POSTGRESQL_PASSWORD_HASH`](#postgresql-information), the [number of db nodes](#postgresql-information), and the [network address](#network-information) before executing the next step.
 
 1. On the master database node, edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
@@ -530,7 +530,7 @@ Check the [Troubleshooting section](#troubleshooting) before proceeding.
 
 #### Configuring the Pgbouncer node
 
-1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul_information), [`CONSUL_PASSWORD_HASH`](#consul_information), and [`PGBOUNCER_PASSWORD_HASH`](#pgbouncer_information) before executing the next step.
+1. Make sure you collect [`CONSUL_SERVER_NODES`](#consul-information), [`CONSUL_PASSWORD_HASH`](#consul-information), and [`PGBOUNCER_PASSWORD_HASH`](#pgbouncer-information) before executing the next step.
 
 1. Edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
@@ -832,8 +832,8 @@ After deploying the configuration follow these steps:
 
 This example uses 3 postgresql servers, and 1 application node.
 
-It differs from the [recommended setup](#example_recommended_setup) by moving the consul servers into the same servers we use for PostgreSQL.
-The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover_procedure) and [restore](#restore_procedure) procedures in addition to [consul outage recovery](consul.md#outage_recovery) on the same set of machines.
+It differs from the [recommended setup](#example-recommended-setup) by moving the consul servers into the same servers we use for PostgreSQL.
+The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover-procedure) and [restore](#restore-procedure) procedures in addition to [consul outage recovery](consul.md#outage-recovery) on the same set of machines.
 
 In this example we start with all servers on the same 10.6.0.0/16 private network range, they can connect to each freely other on those addresses.
 
@@ -936,7 +936,7 @@ consul['configuration'] = {
 
 ##### Example minimal setup manual steps
 
-The manual steps for this configuration are the same as for the [example recommended setup](#example_recommended_setup_manual_steps).
+The manual steps for this configuration are the same as for the [example recommended setup](#example-recommended-setup-manual-steps).
 
 #### Failover procedure
 
@@ -1154,7 +1154,7 @@ If you're running into an issue with a component not outlined here, be sure to c
 
 ## Configure using Omnibus
 
-**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#configure_using_omnibus_for_high_availability).
+**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#configure-using-omnibus-for-high-availability).
 If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-ce/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
 
 ---

doc/administration/high_availability/redis.md

@@ -468,7 +468,7 @@ Now that the Redis servers are all set up, let's configure the Sentinel
 servers.
 
 If you are not sure if your Redis servers are working and replicating
-correctly, please read the [Troubleshooting Replication](#troubleshooting-replication)
+correctly, please read the [Troubleshooting Replication](#troubleshooting-redis-replication)
 and fix it before proceeding with Sentinel setup.
 
 You must have at least `3` Redis Sentinel servers, and they need to

doc/administration/high_availability/redis_source.md

@@ -46,7 +46,7 @@ valuable information for the general setup.
 
 Assuming that the Redis master instance IP is `10.0.0.1`:
 
-1. [Install Redis](../../install/installation.md#6-redis)
+1. [Install Redis](../../install/installation.md#7-redis).
 1. Edit `/etc/redis/redis.conf`:
 
     ```conf
@@ -72,7 +72,7 @@ Assuming that the Redis master instance IP is `10.0.0.1`:
 
 Assuming that the Redis slave instance IP is `10.0.0.2`:
 
-1. [Install Redis](../../install/installation.md#6-redis)
+1. [Install Redis](../../install/installation.md#7-redis).
 1. Edit `/etc/redis/redis.conf`:
 
     ```conf

doc/university/high-availability/aws/README.md

@@ -3,7 +3,7 @@ comments: false
 ---
 
 > **Note**: We **do not** recommend using the AWS Elastic File System (EFS), as it can result
-in [significantly degraded performance](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/administration/high_availability/nfs.md#aws-elastic-file-system).
+in [significantly degraded performance](../../../administration/high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs).
 
 # High Availability on AWS
 
@@ -182,7 +182,7 @@ Another option is to build a simple NFS server using a vanilla Linux server back
 by AWS Elastic Block Storage (EBS).
 
 > **Note:** GitLab does not recommend using AWS Elastic File System (EFS). See
-  details in [High Availability NFS documentation](../../../administration/high_availability/nfs.md#aws-elastic-file-system)
+  details in [High Availability NFS documentation](../../../administration/high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs)
 
 ***