summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAchilleas Pipinellis <axilleas@axilleas.me>2016-11-16 14:17:58 +0100
committerAchilleas Pipinellis <axilleas@axilleas.me>2016-11-16 14:25:15 +0100
commit465c61ee6889e03016712cbda7fd48e0e973cb76 (patch)
treed7ebfdf104759f9743ab888bc169b287ea03bb67
parentb7aae9a6cde71dfc448d8da34ebe38104068387c (diff)
downloadgitlab-ce-doc/sentinel.tar.gz
Remove login as root step from Redis HA docsdoc/sentinel
[ci skip]
-rw-r--r--doc/administration/high_availability/redis.md31
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:
```