Add latest changes from gitlab-org/gitlab@13-0-stable-ee

13 files changed, 149 insertions, 138 deletions

diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index 55ec3b8d6c4..d36b029cbb3 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -1,7 +1,7 @@
 ---
-type: reference, concepts
+redirect_to: ../reference_architectures/index.md
 ---
 
-# High Availability
+# Reference Architectures
 
-This content has been moved to the [availability page](../availability/index.md).
+This document was moved to [another location](../reference_architectures/index.md).
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md
index 6762a81f671..1f22c46a0ad 100644
--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -4,14 +4,17 @@ type: reference
 
 # Working with the bundled Consul service **(PREMIUM ONLY)**
 
-As part of its High Availability stack, GitLab Premium includes a bundled version of [Consul](https://www.consul.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
+As part of its High Availability stack, GitLab Premium includes a bundled version of [Consul](https://www.consul.io/) that can be managed through `/etc/gitlab/gitlab.rb`. Consul is a service networking solution. When it comes to [GitLab Architecture](../../development/architecture.md), Consul utilization is supported for configuring:
+
+1. [Monitoring in Scaled and Highly Available environments](monitoring_node.md)
+1. [PostgreSQL High Availability with Omnibus](database.md#high-availability-with-omnibus-gitlab-premium-only)
 
 A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the Consul cluster.
 
 ## Prerequisites
 
 First, make sure to [download/install](https://about.gitlab.com/install/)
-GitLab Omnibus **on each node**.
+Omnibus GitLab **on each node**.
 
 Choose an installation method, then make sure you complete steps:
 
@@ -107,7 +110,7 @@ For larger clusters, it is possible to restart multiple agents at a time. See th
 
 Nodes running GitLab-bundled Consul should be:
 
-- Members of a healthy cluster prior to upgrading the GitLab Omnibus package.
+- Members of a healthy cluster prior to upgrading the Omnibus GitLab package.
 - Upgraded one node at a time.
 
 NOTE: **NOTE:**
diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md
index f06870be93c..6f1873af993 100644
--- a/doc/administration/high_availability/database.md
+++ b/doc/administration/high_availability/database.md
@@ -24,16 +24,16 @@ If you use a cloud-managed service, or provide your own PostgreSQL:
 
 ## PostgreSQL in a Scaled and Highly Available Environment
 
-This section is relevant for [Scalable and Highly Available Setups](../scaling/index.md).
+This section is relevant for [Scalable and Highly Available Setups](../reference_architectures/index.md).
 
 ### Provide your own PostgreSQL instance **(CORE ONLY)**
 
 If you want to use your own deployed PostgreSQL instance(s),
 see [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance-core-only)
-for more details. However, you can use the GitLab Omnibus package to easily
+for more details. However, you can use the Omnibus GitLab package to easily
 deploy the bundled PostgreSQL.
 
-### Standalone PostgreSQL using GitLab Omnibus **(CORE ONLY)**
+### Standalone PostgreSQL using Omnibus GitLab **(CORE ONLY)**
 
 1. SSH into the PostgreSQL server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -92,7 +92,7 @@ deploy the bundled PostgreSQL.
 Advanced configuration options are supported and can be added if
 needed.
 
-### High Availability with GitLab Omnibus **(PREMIUM ONLY)**
+### High Availability with Omnibus GitLab **(PREMIUM ONLY)**
 
 > Important notes:
 >
@@ -125,7 +125,7 @@ otherwise the networks will become a single point of failure.
 
 #### Architecture
 
-![PG HA Architecture](img/pg_ha_architecture.png)
+![PostgreSQL HA Architecture](img/pg_ha_architecture.png)
 
 Database nodes run two services with PostgreSQL:
 
@@ -271,7 +271,7 @@ Few notes on the service itself:
 #### Installing Omnibus GitLab
 
 First, make sure to [download/install](https://about.gitlab.com/install/)
-GitLab Omnibus **on each node**.
+Omnibus GitLab **on each node**.
 
 Make sure you install the necessary dependencies from step 1,
 add GitLab package repository from step 2.
@@ -969,7 +969,7 @@ repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
 ##### MD5 Authentication
 
 If you are running on an untrusted network, repmgr can use md5 authentication
-with a [`.pgpass` file](https://www.postgresql.org/docs/9.6/libpq-pgpass.html)
+with a [`.pgpass` file](https://www.postgresql.org/docs/11/libpq-pgpass.html)
 to authenticate.
 
 You can specify by IP address, FQDN, or by subnet, using the same format as in
@@ -1091,7 +1091,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](#high-availability-with-gitlab-omnibus-premium-only).
+**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-omnibus-gitlab-premium-only).
 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/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
 
 Read more on high-availability configuration:
diff --git a/doc/administration/high_availability/gitaly.md b/doc/administration/high_availability/gitaly.md
index 5d66d3c5c94..2e6bcabeb06 100644
--- a/doc/administration/high_availability/gitaly.md
+++ b/doc/administration/high_availability/gitaly.md
@@ -4,14 +4,10 @@ type: reference
 
 # Configuring Gitaly for Scaled and High Availability
 
-Gitaly does not yet support full high availability. However, Gitaly is quite
-stable and is in use on GitLab.com. Scaled and highly available GitLab environments
-should consider using Gitaly on a separate node.
+A [Gitaly Cluster](../gitaly/praefect.md) can be used to increase the fault
+tolerance of Gitaly in high availability configurations.
 
-See the [Gitaly HA Epic](https://gitlab.com/groups/gitlab-org/-/epics/289) to
-track plans and progress toward high availability support.
-
-This document is relevant for [Scalable and Highly Available Setups](../scaling/index.md).
+This document is relevant for [scalable and highly available setups](../reference_architectures/index.md).
 
 ## Running Gitaly on its own server
 
@@ -19,7 +15,7 @@ See [Running Gitaly on its own server](../gitaly/index.md#running-gitaly-on-its-
 in Gitaly documentation.
 
 Continue configuration of other components by going back to the
-[High Availability](../availability/index.md#gitlab-components-and-configuration-instructions) page.
+[reference architecture](../reference_architectures/index.md#configure-gitlab-to-scale) page.
 
 ## Enable Monitoring
 
diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md
index c9c425d366b..cdafdbc4954 100644
--- a/doc/administration/high_availability/gitlab.md
+++ b/doc/administration/high_availability/gitlab.md
@@ -2,7 +2,9 @@
 type: reference
 ---
 
-# Configuring GitLab for Scaling and High Availability
+# Configuring GitLab application (Rails)
+
+This section describes how to configure the GitLab application (Rails) component.
 
 NOTE: **Note:** There is some additional configuration near the bottom for
 additional GitLab application servers. It's important to read and understand
@@ -34,7 +36,7 @@ is recommended over [NFS](nfs.md) wherever possible for improved performance.
    mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
    ```
 
-1. Download/install GitLab Omnibus using **steps 1 and 2** from
+1. Download/install Omnibus GitLab using **steps 1 and 2** from
    [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
    steps on the download page.
 1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration.
@@ -79,8 +81,8 @@ is recommended over [NFS](nfs.md) wherever possible for improved performance.
 
    NOTE: **Note:** To maintain uniformity of links across HA clusters, the `external_url`
    on the first application server as well as the additional application
-   servers should point to the external url that users will use to access GitLab.
-   In a typical HA setup, this will be the url of the load balancer which will
+   servers should point to the external URL that users will use to access GitLab.
+   In a typical HA setup, this will be the URL of the load balancer which will
    route traffic to all GitLab application servers in the HA cluster.
 
    NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
@@ -131,6 +133,9 @@ need some extra configuration.
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
+NOTE: **Note:** You will need to restart the GitLab applications nodes after an update has occurred and database
+migrations performed.
+
 ## Enable Monitoring
 
 > [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3786) in GitLab 12.0.
@@ -157,7 +162,7 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
    node_exporter['listen_address'] = '0.0.0.0:9100'
    gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
    sidekiq['listen_address'] = "0.0.0.0"
-   unicorn['listen'] = '0.0.0.0'
+   puma['listen'] = '0.0.0.0'
 
    # Add the monitoring node's IP address to the monitoring whitelist and allow it to
    # scrape the NGINX metrics. Replace placeholder `monitoring.gitlab.example.com` with
@@ -169,9 +174,11 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
    CAUTION: **Warning:**
-   After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
-   it can take an extended period of time for Unicorn to complete reloading after receiving a `HUP`.
-   For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
+   If running Unicorn, after changing `unicorn['listen']` in `gitlab.rb`, and
+   running `sudo gitlab-ctl reconfigure`, it can take an extended period of time
+   for Unicorn to complete reloading after receiving a `HUP`. For more
+   information, see the
+   [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
 
 ## Troubleshooting
 
diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md
index 43a7c442d8c..beeb57a0e32 100644
--- a/doc/administration/high_availability/load_balancer.md
+++ b/doc/administration/high_availability/load_balancer.md
@@ -66,7 +66,7 @@ for details on managing SSL certificates and configuring NGINX.
 | 443     | 443          | TCP or HTTPS (*1*) (*2*) |
 | 22      | 22           | TCP                      |
 
-- (*1*): [Web terminal](../../ci/environments.md#web-terminals) support requires
+- (*1*): [Web terminal](../../ci/environments/index.md#web-terminals) support requires
   your load balancer to correctly handle WebSocket connections. When using
   HTTP or HTTPS proxying, this means your load balancer must be configured
   to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
diff --git a/doc/administration/high_availability/monitoring_node.md b/doc/administration/high_availability/monitoring_node.md
index 79e583c5fcb..409a4dfecb9 100644
--- a/doc/administration/high_availability/monitoring_node.md
+++ b/doc/administration/high_availability/monitoring_node.md
@@ -8,10 +8,10 @@ type: reference
 
 You can configure a Prometheus node to monitor GitLab.
 
-## Standalone Monitoring node using GitLab Omnibus
+## Standalone Monitoring node using Omnibus GitLab
 
-The GitLab Omnibus package can be used to configure a standalone Monitoring node running [Prometheus](../monitoring/prometheus/index.md) and [Grafana](../monitoring/performance/grafana_configuration.md).
-The monitoring node is not highly available. See [Scaling and High Availability](../scaling/index.md)
+The Omnibus GitLab package can be used to configure a standalone Monitoring node running [Prometheus](../monitoring/prometheus/index.md) and [Grafana](../monitoring/performance/grafana_configuration.md).
+The monitoring node is not highly available. See [Scaling and High Availability](../reference_architectures/index.md)
 for an overview of GitLab scaling and high availability options.
 
 The steps below are the minimum necessary to configure a Monitoring node running Prometheus and Grafana with
@@ -64,7 +64,7 @@ Omnibus:
    redis['enable'] = false
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
-   unicorn['enable'] = false
+   puma['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
    ```
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index 66f2986ab2a..d2b8cf65b35 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -7,14 +7,16 @@ type: reference
 You can view information and options set for each of the mounted NFS file
 systems by running `nfsstat -m` and `cat /etc/fstab`.
 
+CAUTION: **Caution:**
+From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
+support for NFS for Git repositories is scheduled to be removed. Upgrade to
+[Gitaly Cluster](../gitaly/praefect.md) as soon as possible.
+
 NOTE: **Note:** Filesystem performance has a big impact on overall GitLab
 performance, especially for actions that read or write to Git repositories. See
 [Filesystem Performance Benchmarking](../operations/filesystem_benchmarking.md)
 for steps to test filesystem performance.
 
-NOTE: **Note:** [Cloud Object Storage service](object_storage.md) with [Gitaly](gitaly.md)
-is recommended over NFS wherever possible for improved performance.
-
 ## NFS Server features
 
 ### Required features
@@ -73,7 +75,7 @@ To disable NFS server delegation, do the following:
 #### Important notes
 
 The kernel bug may be fixed in
-[more recent kernels with this commit](https://github.om/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
+[more recent kernels with this commit](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
 
 Red Hat Enterprise 7 [shipped a kernel update](https://access.redhat.com/errata/RHSA-2019:2029)
 on August 6, 2019 that may also have resolved this problem.
@@ -184,7 +186,7 @@ The NFS man page states:
 Read the [Linux man page](https://linux.die.net/man/5/nfs) to understand the difference,
 and if you do use `soft`, ensure that you've taken steps to mitigate the risks.
 
-If you experience behaviour that might have been caused by
+If you experience behavior that might have been caused by
 writes to disk on the NFS server not occurring, such as commits going missing,
 use the `hard` option, because (from the man page):
 
@@ -271,7 +273,7 @@ following are the 4 locations need to be shared:
 
 Other GitLab directories should not be shared between nodes. They contain
 node-specific files and GitLab code that does not need to be shared. To ship
-logs to a central location consider using remote syslog. GitLab Omnibus packages
+logs to a central location consider using remote syslog. Omnibus GitLab packages
 provide configuration for [UDP log shipping](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
 
 Having multiple NFS mounts will require manually making sure the data directories
diff --git a/doc/administration/high_availability/nfs_host_client_setup.md b/doc/administration/high_availability/nfs_host_client_setup.md
index 6823c1d9abe..7519ebf028d 100644
--- a/doc/administration/high_availability/nfs_host_client_setup.md
+++ b/doc/administration/high_availability/nfs_host_client_setup.md
@@ -36,7 +36,7 @@ apt-get install nfs-kernel-server
 
 In this setup we will share the home directory on the host with the client. Edit the exports file as below to share the host's home directory with the client. If you have multiple clients running GitLab you must enter the client IP addresses in line in the `/etc/exports` file.
 
-```text
+```plaintext
 #/etc/exports for one client
 /home <client-ip-address>(rw,sync,no_root_squash,no_subtree_check)
 
@@ -96,7 +96,7 @@ NFS version 4. NFSv3 also supports locking as long as Linux Kernel 2.6.5+ is use
 We recommend using version 4 and do not specifically test NFSv3.
 See [NFS documentation](nfs.md#nfs-client-mount-options) for guidance on mount options.
 
-```text
+```plaintext
 #/etc/fstab
 10.0.0.1:/nfs/home  /nfs/home  nfs4 defaults,hard,vers=4.1,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2
 ```
@@ -111,7 +111,7 @@ default file locations in `gitlab.rb` on the client allows you to have one main
 point and have all the required locations as subdirectories to use the NFS mount for
 `git-data`.
 
-```text
+```plaintext
 git_data_dirs({"default" => {"path" => "/nfs/home/var/opt/gitlab-data/git-data"}})
 gitlab_rails['uploads_directory'] = '/nfs/home/var/opt/gitlab-data/uploads'
 gitlab_rails['shared_path'] = '/nfs/home/var/opt/gitlab-data/shared'
diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md
index f0e76172a00..4c672f49e26 100644
--- a/doc/administration/high_availability/pgbouncer.md
+++ b/doc/administration/high_availability/pgbouncer.md
@@ -165,7 +165,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
 
 1. Run `gitlab-ctl reconfigure`
 
-1. On the node running Unicorn, make sure the following is set in `/etc/gitlab/gitlab.rb`
+1. On the node running Puma, make sure the following is set in `/etc/gitlab/gitlab.rb`
 
    ```ruby
    gitlab_rails['db_host'] = 'PGBOUNCER_HOST'
@@ -215,7 +215,7 @@ To start a session, run
 ```shell
 # gitlab-ctl pgb-console
 Password for user pgbouncer:
-psql (9.6.8, server 1.7.2/bouncer)
+psql (11.7, server 1.7.2/bouncer)
 Type "help" for help.
 
 pgbouncer=#
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md
index 1e19e7e6c01..d52c80aec0d 100644
--- a/doc/administration/high_availability/redis.md
+++ b/doc/administration/high_availability/redis.md
@@ -27,24 +27,24 @@ These will be necessary when configuring the GitLab application servers later.
 
 ## Redis in a Scaled and Highly Available Environment
 
-This section is relevant for [Scalable and Highly Available Setups](../scaling/index.md).
+This section is relevant for [scalable and highly available setups](../reference_architectures/index.md).
 
 ### Provide your own Redis instance **(CORE ONLY)**
 
 If you want to use your own deployed Redis instance(s),
 see [Provide your own Redis instance](#provide-your-own-redis-instance-core-only)
-for more details. However, you can use the GitLab Omnibus package to easily
+for more details. However, you can use the Omnibus GitLab package to easily
 deploy the bundled Redis.
 
-### Standalone Redis using GitLab Omnibus **(CORE ONLY)**
+### Standalone Redis using Omnibus GitLab **(CORE ONLY)**
 
-The GitLab Omnibus package can be used to configure a standalone Redis server.
+The Omnibus GitLab package can be used to configure a standalone Redis server.
 In this configuration Redis is not highly available, and represents a single
 point of failure. However, in a scaled environment the objective is to allow
 the environment to handle more users or to increase throughput. Redis itself
 is generally stable and can handle many requests so it is an acceptable
-trade off to have only a single instance. See [High Availability](../availability/index.md)
-for an overview of GitLab scaling and high availability options.
+trade off to have only a single instance. See the [reference architectures](../reference_architectures/index.md)
+page for an overview of GitLab scaling and high availability options.
 
 The steps below are the minimum necessary to configure a Redis server with
 Omnibus:
@@ -63,7 +63,7 @@ Omnibus:
    ## Disable all other services
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   unicorn['enable'] = false
+   puma['enable'] = false
    postgresql['enable'] = false
    nginx['enable'] = false
    prometheus['enable'] = false
@@ -89,16 +89,16 @@ Advanced configuration options are supported and can be added if
 needed.
 
 Continue configuration of other components by going back to the
-[High Availability](../availability/index.md#gitlab-components-and-configuration-instructions) page.
+[reference architectures](../reference_architectures/index.md#configure-gitlab-to-scale) page.
 
-### High Availability with GitLab Omnibus **(PREMIUM ONLY)**
+### High Availability with Omnibus GitLab **(PREMIUM ONLY)**
 
 > Experimental Redis Sentinel support was [introduced in GitLab 8.11](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/1877).
 Starting with 8.14, Redis Sentinel is no longer experimental.
 If you've used it with versions `< 8.14` before, please check the updated
 documentation here.
 
-High Availability with [Redis](https://redis.io/) is possible using a **Master** x **Slave**
+High Availability with [Redis](https://redis.io/) is possible using a **Master** x **Replica**
 topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
 start the failover procedure.
 
@@ -130,12 +130,12 @@ make sure you read this Overview section to better understand how the components
 are tied together.
 
 You need at least `3` independent machines: physical, or VMs running into
-distinct physical machines. It is essential that all master and slaves Redis
+distinct physical machines. It is essential that all master and replica Redis
 instances run in different machines. If you fail to provision the machines in
 that specific way, any issue with the shared environment can bring your entire
 setup down.
 
-It is OK to run a Sentinel alongside of a master or slave Redis instance.
+It is OK to run a Sentinel alongside of a master or replica Redis instance.
 There should be no more than one Sentinel on the same machine though.
 
 You also need to take into consideration the underlying network topology,
@@ -156,16 +156,16 @@ components below.
 High Availability with Redis requires a few things:
 
 - Multiple Redis instances
-- Run Redis in a **Master** x **Slave** topology
+- Run Redis in a **Master** x **Replica** topology
 - Multiple Sentinel instances
 - Application support and visibility to all Sentinel and Redis instances
 
 Redis Sentinel can handle the most important tasks in an HA environment and that's
 to help keep servers online with minimal to no downtime. Redis Sentinel:
 
-- Monitors **Master** and **Slaves** instances to see if they are available
-- Promotes a **Slave** to **Master** when the **Master** fails
-- Demotes a **Master** to **Slave** when the failed **Master** comes back online
+- Monitors **Master** and **Replicas** instances to see if they are available
+- Promotes a **Replica** to **Master** when the **Master** fails
+- Demotes a **Master** to **Replica** when the failed **Master** comes back online
   (to prevent data-partitioning)
 - Can be queried by the application to always connect to the current **Master**
   server
@@ -185,8 +185,8 @@ For a minimal setup, you will install the Omnibus GitLab package in `3`
 **independent** machines, both with **Redis** and **Sentinel**:
 
 - Redis Master + Sentinel
-- Redis Slave + Sentinel
-- Redis Slave + Sentinel
+- Redis Replica + Sentinel
+- Redis Replica + Sentinel
 
 If you are not sure or don't understand why and where the amount of nodes come
 from, read [Redis setup overview](#redis-setup-overview) and
@@ -197,14 +197,14 @@ the Omnibus GitLab package in `5` **independent** machines, both with
 **Redis** and **Sentinel**:
 
 - Redis Master + Sentinel
-- Redis Slave + Sentinel
-- Redis Slave + Sentinel
-- Redis Slave + Sentinel
-- Redis Slave + Sentinel
+- Redis Replica + Sentinel
+- Redis Replica + Sentinel
+- Redis Replica + Sentinel
+- Redis Replica + Sentinel
 
 ### Redis setup overview
 
-You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they
+You must have at least `3` Redis servers: `1` Master, `2` Replicas, and they
 need to each be on independent machines (see explanation above).
 
 You can have additional Redis nodes, that will help survive a situation
@@ -221,7 +221,7 @@ nodes to be provisioned. See [Sentinel setup overview](#sentinel-setup-overview)
 documentation for more information.
 
 All Redis nodes should be configured the same way and with similar server specs, as
-in a failover situation, any **Slave** can be promoted as the new **Master** by
+in a failover situation, any **Replica** can be promoted as the new **Master** by
 the Sentinel servers.
 
 The replication requires authentication, so you need to define a password to
@@ -241,9 +241,9 @@ need to be available and reachable, so that they can elect the Sentinel **leader
 who will take all the decisions to restore the service availability by:
 
 - Promoting a new **Master**
-- Reconfiguring the other **Slaves** and make them point to the new **Master**
+- Reconfiguring the other **Replicas** and make them point to the new **Master**
 - Announce the new **Master** to every other Sentinel peer
-- Reconfigure the old **Master** and demote to **Slave** when it comes back online
+- Reconfigure the old **Master** and demote to **Replica** when it comes back online
 
 You must have at least `3` Redis Sentinel servers, and they need to
 be each in an independent machine (that are believed to fail independently),
@@ -280,18 +280,18 @@ the official documentation:
   already tried against the same master by a given Sentinel, is two
   times the failover timeout.
 
-- The time needed for a slave replicating to a wrong master according
+- The time needed for a replica replicating to a wrong master according
   to a Sentinel current configuration, to be forced to replicate
   with the right master, is exactly the failover timeout (counting since
   the moment a Sentinel detected the misconfiguration).
 
 - The time needed to cancel a failover that is already in progress but
-  did not produced any configuration change (SLAVEOF NO ONE yet not
-  acknowledged by the promoted slave).
+  did not produced any configuration change (REPLICAOF NO ONE yet not
+  acknowledged by the promoted replica).
 
-- The maximum time a failover in progress waits for all the slaves to be
-  reconfigured as slaves of the new master. However even after this time
-  the slaves will be reconfigured by the Sentinels anyway, but not with
+- The maximum time a failover in progress waits for all the replicas to be
+  reconfigured as replicas of the new master. However even after this time
+  the replicas will be reconfigured by the Sentinels anyway, but not with
   the exact parallel-syncs progression as specified.
 
 ### Available configuration setups
@@ -306,12 +306,12 @@ Pick the one that suits your needs.
   documentation.
 - [Omnibus GitLab **Community Edition** (CE) package](https://about.gitlab.com/install/?version=ce): Redis is bundled, so you
   can use the package with only the Redis service enabled as described in steps
-  1 and 2 of this document (works for both master and slave setups). To install
+  1 and 2 of this document (works for both master and replica setups). To install
   and configure Sentinel, jump directly to the Sentinel section in the
   [Redis HA installation from source](redis_source.md#step-3-configuring-the-redis-sentinel-instances) documentation.
 - [Omnibus GitLab **Enterprise Edition** (EE) package](https://about.gitlab.com/install/?version=ee): Both Redis and Sentinel
   are bundled in the package, so you can use the EE package to set up the whole
-  Redis HA infrastructure (master, slave and Sentinel) which is described in
+  Redis HA infrastructure (master, replica and Sentinel) which is described in
   this document.
 - If you have installed GitLab using the Omnibus GitLab packages (CE or EE),
   but you want to use your own external Redis server, follow steps 1-3 in the
@@ -328,9 +328,9 @@ This is the section where we install and set up the new Redis instances.
 > - We assume that you have installed GitLab and all HA components from scratch. If you
 >   already have it installed and running, read how to
 >   [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha).
-> - Redis nodes (both master and slaves) will need the same password defined in
+> - Redis nodes (both master and replica) will need the same password defined in
 >   `redis['password']`. At any time during a failover the Sentinels can
->  reconfigure a node and change its status from master to slave and vice versa.
+>  reconfigure a node and change its status from master to replica and vice versa.
 
 ### Prerequisites
 
@@ -392,9 +392,9 @@ The prerequisites for a HA Redis setup are the following:
 > `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
-### Step 2. Configuring the slave Redis instances
+### Step 2. Configuring the replica Redis instances
 
-1. SSH into the **slave** Redis server.
+1. SSH into the **replica** Redis server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
    package you want using **steps 1 and 2** from the GitLab downloads page.
    - Make sure you select the correct Omnibus package, with the same version
@@ -404,8 +404,8 @@ The prerequisites for a HA Redis setup are the following:
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
    ```ruby
-   # Specify server role as 'redis_slave_role'
-   roles ['redis_slave_role']
+   # Specify server role as 'redis_replica_role'
+   roles ['redis_replica_role']
 
    # IP address pointing to a local IP that the other machines can reach to.
    # You can also set bind to '0.0.0.0' which listen in all interfaces.
@@ -435,10 +435,10 @@ The prerequisites for a HA Redis setup are the following:
    ```
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
-1. Go through the steps again for all the other slave nodes.
+1. Go through the steps again for all the other replica nodes.
 
 > Note: You can specify multiple roles like sentinel and Redis as:
-> `roles ['redis_sentinel_role', 'redis_slave_role']`. Read more about high
+> `roles ['redis_sentinel_role', 'redis_replica_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
 ---
@@ -542,18 +542,18 @@ multiple machines with the Sentinel daemon.
    ##   already tried against the same master by a given Sentinel, is two
    ##   times the failover timeout.
    ##
-   ## - The time needed for a slave replicating to a wrong master according
+   ## - The time needed for a replica replicating to a wrong master according
    ##   to a Sentinel current configuration, to be forced to replicate
    ##   with the right master, is exactly the failover timeout (counting since
    ##   the moment a Sentinel detected the misconfiguration).
    ##
    ## - The time needed to cancel a failover that is already in progress but
-   ##   did not produced any configuration change (SLAVEOF NO ONE yet not
-   ##   acknowledged by the promoted slave).
+   ##   did not produced any configuration change (REPLICAOF NO ONE yet not
+   ##   acknowledged by the promoted replica).
    ##
-   ## - The maximum time a failover in progress waits for all the slaves to be
-   ##   reconfigured as slaves of the new master. However even after this time
-   ##   the slaves will be reconfigured by the Sentinels anyway, but not with
+   ## - The maximum time a failover in progress waits for all the replica to be
+   ##   reconfigured as replicas of the new master. However even after this time
+   ##   the replicas will be reconfigured by the Sentinels anyway, but not with
    ##   the exact parallel-syncs progression as specified.
    # sentinel['failover_timeout'] = 60000
    ```
@@ -612,7 +612,7 @@ replicate from this machine first, before de-activating the Redis instance
 inside it.
 
 Your single-machine install will be the initial **Master**, and the `3` others
-should be configured as **Slave** pointing to this machine.
+should be configured as **Replica** pointing to this machine.
 
 After replication catches up, you will need to stop services in the
 single-machine install, to rotate the **Master** to one of the new nodes.
@@ -627,7 +627,7 @@ redis['enable'] = false
 
 If you fail to replicate first, you may loose data (unprocessed background jobs).
 
-## Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels
+## Example of a minimal configuration with 1 master, 2 replicas and 3 Sentinels
 
 >**Note:**
 Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For
@@ -649,8 +649,8 @@ discussed in [Redis setup overview](#redis-setup-overview) and
 Here is a list and description of each **machine** and the assigned **IP**:
 
 - `10.0.0.1`: Redis Master + Sentinel 1
-- `10.0.0.2`: Redis Slave 1 + Sentinel 2
-- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.2`: Redis Replica 1 + Sentinel 2
+- `10.0.0.3`: Redis Replica 2 + Sentinel 3
 - `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
@@ -684,12 +684,12 @@ sentinel['quorum'] = 2
 
 [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
-### Example configuration for Redis slave 1 and Sentinel 2
+### Example configuration for Redis replica 1 and Sentinel 2
 
 In `/etc/gitlab/gitlab.rb`:
 
 ```ruby
-roles ['redis_sentinel_role', 'redis_slave_role']
+roles ['redis_sentinel_role', 'redis_replica_role']
 redis['bind'] = '10.0.0.2'
 redis['port'] = 6379
 redis['password'] = 'redis-password-goes-here'
@@ -706,12 +706,12 @@ sentinel['quorum'] = 2
 
 [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
-### Example configuration for Redis slave 2 and Sentinel 3
+### Example configuration for Redis replica 2 and Sentinel 3
 
 In `/etc/gitlab/gitlab.rb`:
 
 ```ruby
-roles ['redis_sentinel_role', 'redis_slave_role']
+roles ['redis_sentinel_role', 'redis_replica_role']
 redis['bind'] = '10.0.0.3'
 redis['port'] = 6379
 redis['password'] = 'redis-password-goes-here'
@@ -847,11 +847,11 @@ mailroom['enable'] = false
 
 -------
 
-## Redis master/slave Role
+## Redis master/replica Role
 redis_master_role['enable'] = true # enable only one of them
-redis_slave_role['enable'] = true # enable only one of them
+redis_replica_role['enable'] = true # enable only one of them
 
-# When Redis Master or Slave role are enabled, the following services are
+# When Redis Master or Replica role are enabled, the following services are
 # enabled/disabled. Note that if Redis and Sentinel roles are combined, both
 # services will be enabled.
 
@@ -863,7 +863,7 @@ postgresql['enable'] = false
 gitlab_rails['enable'] = false
 mailroom['enable'] = false
 
-# For Redis Slave role, also change this setting from default 'true' to 'false':
+# For Redis Replica role, also change this setting from default 'true' to 'false':
 redis['master'] = false
 ```
 
@@ -894,13 +894,13 @@ You can check if everything is correct by connecting to each server using
 ```
 
 When connected to a `master` Redis, you will see the number of connected
-`slaves`, and a list of each with connection details:
+`replicas`, and a list of each with connection details:
 
 ```plaintext
 # Replication
 role:master
-connected_slaves:1
-slave0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
+connected_replicas:1
+replica0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
 master_repl_offset:208037658
 repl_backlog_active:1
 repl_backlog_size:1048576
@@ -908,21 +908,21 @@ repl_backlog_first_byte_offset:206989083
 repl_backlog_histlen:1048576
 ```
 
-When it's a `slave`, you will see details of the master connection and if
+When it's a `replica`, you will see details of the master connection and if
 its `up` or `down`:
 
 ```plaintext
 # Replication
-role:slave
+role:replica
 master_host:10.133.1.58
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:1
 master_sync_in_progress:0
-slave_repl_offset:208096498
-slave_priority:100
-slave_read_only:1
-connected_slaves:0
+replica_repl_offset:208096498
+replica_priority:100
+replica_read_only:1
+connected_replicas:0
 master_repl_offset:0
 repl_backlog_active:0
 repl_backlog_size:1048576
diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md
index 95b1397bab4..97be480bc3b 100644
--- a/doc/administration/high_availability/redis_source.md
+++ b/doc/administration/high_availability/redis_source.md
@@ -40,7 +40,7 @@ This is the section where we install and set up the new Redis instances.
 - Since Redis 3.2, you must define a password to receive external connections
   (`requirepass`).
 - If you are using Redis with Sentinel, you will also need to define the same
-  password for the slave password definition (`masterauth`) in the same instance.
+  password for the replica password definition (`masterauth`) in the same instance.
 
 In addition, read the prerequisites as described in the
 [Omnibus Redis HA document](redis.md#prerequisites) since they provide some
@@ -72,9 +72,9 @@ Assuming that the Redis master instance IP is `10.0.0.1`:
 
 1. Restart the Redis service for the changes to take effect.
 
-### Step 2. Configuring the slave Redis instances
+### Step 2. Configuring the replica Redis instances
 
-Assuming that the Redis slave instance IP is `10.0.0.2`:
+Assuming that the Redis replica instance IP is `10.0.0.2`:
 
 1. [Install Redis](../../install/installation.md#7-redis).
 1. Edit `/etc/redis/redis.conf`:
@@ -95,12 +95,12 @@ Assuming that the Redis slave instance IP is `10.0.0.2`:
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
 
-   ## Define `slaveof` pointing to the Redis master instance with IP and port.
-   slaveof 10.0.0.1 6379
+   ## Define `replicaof` pointing to the Redis master instance with IP and port.
+   replicaof 10.0.0.1 6379
    ```
 
 1. Restart the Redis service for the changes to take effect.
-1. Go through the steps again for all the other slave nodes.
+1. Go through the steps again for all the other replica nodes.
 
 ### Step 3. Configuring the Redis Sentinel instances
 
@@ -131,7 +131,7 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
    masterauth redis-password-goes-here
 
    ## Define with `sentinel auth-pass` the same shared password you have
-   ## defined for both Redis master and slaves instances.
+   ## defined for both Redis master and replicas instances.
    sentinel auth-pass gitlab-redis redis-password-goes-here
 
    ## Define with `sentinel monitor` the IP and port of the Redis
@@ -149,18 +149,18 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
    ##   already tried against the same master by a given Sentinel, is two
    ##   times the failover timeout.
    ##
-   ## * The time needed for a slave replicating to a wrong master according
+   ## * The time needed for a replica replicating to a wrong master according
    ##   to a Sentinel current configuration, to be forced to replicate
    ##   with the right master, is exactly the failover timeout (counting since
    ##   the moment a Sentinel detected the misconfiguration).
    ##
    ## * The time needed to cancel a failover that is already in progress but
-   ##   did not produced any configuration change (SLAVEOF NO ONE yet not
-   ##   acknowledged by the promoted slave).
+   ##   did not produced any configuration change (REPLICAOF NO ONE yet not
+   ##   acknowledged by the promoted replica).
    ##
-   ## * The maximum time a failover in progress waits for all the slaves to be
-   ##   reconfigured as slaves of the new master. However even after this time
-   ##   the slaves will be reconfigured by the Sentinels anyway, but not with
+   ## * The maximum time a failover in progress waits for all the replicas to be
+   ##   reconfigured as replicas of the new master. However even after this time
+   ##   the replicas will be reconfigured by the Sentinels anyway, but not with
    ##   the exact parallel-syncs progression as specified.
    sentinel failover_timeout 30000
    ```
@@ -203,7 +203,7 @@ setup:
 
 1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
-## Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels
+## Example of minimal configuration with 1 master, 2 replicas and 3 Sentinels
 
 In this example we consider that all servers have an internal network
 interface with IPs in the `10.0.0.x` range, and that they can connect
@@ -215,13 +215,13 @@ outside ([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353
 
 For this example, **Sentinel 1** will be configured in the same machine as the
 **Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the
-**Slave 1** and **Slave 2** respectively.
+**Replica 1** and **Replica 2** respectively.
 
 Here is a list and description of each **machine** and the assigned **IP**:
 
 - `10.0.0.1`: Redis Master + Sentinel 1
-- `10.0.0.2`: Redis Slave 1 + Sentinel 2
-- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.2`: Redis Replica 1 + Sentinel 2
+- `10.0.0.3`: Redis Replica 2 + Sentinel 3
 - `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
@@ -257,7 +257,7 @@ or a failover promotes a different **Master** node.
 
 1. Restart the Redis service for the changes to take effect.
 
-### Example configuration for Redis slave 1 and Sentinel 2
+### Example configuration for Redis replica 1 and Sentinel 2
 
 1. In `/etc/redis/redis.conf`:
 
@@ -266,7 +266,7 @@ or a failover promotes a different **Master** node.
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
-   slaveof 10.0.0.1 6379
+   replicaof 10.0.0.1 6379
    ```
 
 1. In `/etc/redis/sentinel.conf`:
@@ -282,7 +282,7 @@ or a failover promotes a different **Master** node.
 
 1. Restart the Redis service for the changes to take effect.
 
-### Example configuration for Redis slave 2 and Sentinel 3
+### Example configuration for Redis replica 2 and Sentinel 3
 
 1. In `/etc/redis/redis.conf`:
 
@@ -291,7 +291,7 @@ or a failover promotes a different **Master** node.
    port 6379
    requirepass redis-password-goes-here
    masterauth redis-password-goes-here
-   slaveof 10.0.0.1 6379
+   replicaof 10.0.0.1 6379
    ```
 
 1. In `/etc/redis/sentinel.conf`:
diff --git a/doc/administration/high_availability/sidekiq.md b/doc/administration/high_availability/sidekiq.md
index ed273c3b113..493929dcf3b 100644
--- a/doc/administration/high_availability/sidekiq.md
+++ b/doc/administration/high_availability/sidekiq.md
@@ -88,12 +88,15 @@ you want using steps 1 and 2 from the GitLab downloads page.
    postgresql['enable'] = false
    redis['enable'] = false
    redis_exporter['enable'] = false
-   unicorn['enable'] = false
+   puma['enable'] = false
    gitlab_exporter['enable'] = false
    ```
 
 1. Run `gitlab-ctl reconfigure`.
 
+NOTE: **Note:** You will need to restart the Sidekiq nodes after an update has occurred and database
+migrations performed.
+
 ## Example configuration
 
 Here's what the ending `/etc/gitlab/gitlab.rb` would look like:
@@ -116,7 +119,7 @@ postgres_exporter['enable'] = false
 postgresql['enable'] = false
 redis['enable'] = false
 redis_exporter['enable'] = false
-unicorn['enable'] = false
+puma['enable'] = false
 gitlab_exporter['enable'] = false
 
 ########################################