diff options
author | Achilleas Pipinellis <axilleas@axilleas.me> | 2016-11-16 14:17:58 +0100 |
---|---|---|
committer | Achilleas Pipinellis <axilleas@axilleas.me> | 2016-11-16 14:25:15 +0100 |
commit | 465c61ee6889e03016712cbda7fd48e0e973cb76 (patch) | |
tree | d7ebfdf104759f9743ab888bc169b287ea03bb67 /doc/administration | |
parent | b7aae9a6cde71dfc448d8da34ebe38104068387c (diff) | |
download | gitlab-ce-465c61ee6889e03016712cbda7fd48e0e973cb76.tar.gz |
Remove login as root step from Redis HA docsdoc/sentinel
[ci skip]
Diffstat (limited to 'doc/administration')
-rw-r--r-- | doc/administration/high_availability/redis.md | 31 |
1 files changed, 9 insertions, 22 deletions
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index f9bc4f59345..1fa3560e932 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -107,10 +107,12 @@ to help keep servers online with minimal to no downtime. Redis Sentinel: - Promotes a **Slave** to **Master** when the **Master** fails - Demotes a **Master** to **Slave** when the failed **Master** comes back online (to prevent data-partitioning) -- Can be queried by clients to always connect to the current **Master** server +- Can be queried by the application to always connect to the current **Master** + server -When a **Master** fails to respond, it's the client's responsibility to handle -timeout and reconnect (querying a **Sentinel** for a new **Master**). +When a **Master** fails to respond, it's the application's responsibility +(in our case GitLab) to handle timeout and reconnect (querying a **Sentinel** +for a new **Master**). To get a better understanding on how to correctly setup Sentinel, please read the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as @@ -289,12 +291,7 @@ The prerequisites for a HA Redis setup are the following: ### Step 1. Configuring the master Redis instance -1. SSH into the **master** Redis server and login as root: - - ``` - sudo -i - ``` - +1. SSH into the **master** Redis server. 1. [Download/install](https://about.gitlab.com/installation) 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 @@ -334,12 +331,7 @@ The prerequisites for a HA Redis setup are the following: ### Step 2. Configuring the slave Redis instances -1. SSH into the **slave** Redis server and login as root: - - ``` - sudo -i - ``` - +1. SSH into the **slave** Redis server. 1. [Download/install](https://about.gitlab.com/installation) 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 @@ -417,12 +409,7 @@ multiple machines with the Sentinel daemon. --- -1. SSH into the server that will host Redis Sentinel and login as root: - - ``` - sudo -i - ``` - +1. SSH into the server that will host Redis Sentinel. 1. **You can omit this step if the Sentinels will be hosted in the same node as the other Redis instances.** @@ -437,7 +424,6 @@ multiple machines with the Sentinel daemon. Sentinels in the same node as the other Redis instances, some values might be duplicate below): - ```ruby redis_sentinel_role['enable'] = true @@ -530,6 +516,7 @@ it needs to access at least one of the listed. The following steps should be performed in the [GitLab application server](gitlab.md) which ideally should not have Redis or Sentinels on it for a HA setup. +1. SSH into the server where the GitLab application is installed. 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: ``` |