Managing Redis replication with sentinel

Setting up Redis replication is simple. But to support high availability, we need to set up sentinel. Sentinel’s main functions are as follows.

• To monitor master and slave state
• If a master is down, sentinel promotes a new master among slaves (automatic fail over)
• If the old master runs again, sentinel changes it’s role as slave (automatic fail back is not supported)
• If multiple sentinels are running, they vote each other to decide Redis status and which node to promote as a new master

Sentinel configuration step by step

Let us suppose that we have configured 2 Redis, one is master (port : 6379) and another is slave (port : 6479)

1. Sentinel configuration

To support quorum, we need to set up 3 Sentinels. (This example runs on one host)

<sentinel#1>

protected-mode no
port 5000
daemonize yes
pidfile "/home/tkstone/redis-4.0.6/redis_sentinel1.pid"
logfile "/home/tkstone/redis-4.0.6/logs/sentinel1.log"
loglevel notice
dir "/home/tkstone/redis-4.0.6/work"
sentinel monitor M1 127.0.0.1 6379 2
sentinel down-after-milliseconds M1 2000
sentinel failover-timeout M1 60000
sentinel parallel-syncs M1 2

<sentinel#2>

protected-mode no
port 5001
daemonize yes
pidfile "/home/tkstone/redis-4.0.6/redis_sentinel2.pid"
logfile "/home/tkstone/redis-4.0.6/logs/sentinel2.log"
loglevel notice
dir "/home/tkstone/redis-4.0.6/work"
sentinel monitor M1 127.0.0.1 6379 2
sentinel down-after-milliseconds M1 2000
sentinel failover-timeout M1 60000
sentinel parallel-syncs M1 2

<sentinel#3>

protected-mode no
port 5002
daemonize yes
pidfile "/home/tkstone/redis-4.0.6/redis_sentinel3.pid"
logfile "/home/tkstone/redis-4.0.6/logs/sentinel3.log"
loglevel notice
dir "/home/tkstone/redis-4.0.6/work"
sentinel monitor M1 127.0.0.1 6379 2
sentinel down-after-milliseconds M1 2000
sentinel failover-timeout M1 60000
sentinel parallel-syncs M1 2

Notice that there are no settings for slaves and other sentinels. They are set up automatically

2. To run sentinel

Running Sentinel is similar to running redis server

#${REDIS_HOME}/bin/redis-sentinel /path/to/sentinel.conf

3. Verefying processes

4. Check sentinel.conf again

After sentinel starts, sentinel.conf is changed as follows.

protected-mode no
port 5000
daemonize yes
pidfile "/home/tkstone/redis-4.0.6/redis_sentinel1.pid"
logfile "/home/tkstone/redis-4.0.6/logs/sentinel1.log"
loglevel notice
dir "/home/tkstone/redis-4.0.6/work"
sentinel myid 59eadb47a4acc86546820bbf7c6879e80f6ae3a5
sentinel monitor M1 127.0.0.1 6379 2
sentinel down-after-milliseconds M1 2000
sentinel failover-timeout M1 60000

# Generated by CONFIG REWRITE
maxclients 4064
sentinel parallel-syncs M1 2
sentinel config-epoch M1 0
sentinel leader-epoch M1 0
sentinel known-slave M1 127.0.0.1 6479
sentinel known-sentinel M1 127.0.0.1 5002 06471b3df582bac1cd6b9b45c2e382076ffd570d
sentinel known-sentinel M1 127.0.0.1 5001 9052ef5bd69832c1c00a56641296b96431bfabd0
sentinel current-epoch 0

You can check that sentinel#1 now knows the other sentinels and Redis slave automatically.

Sentinel commands

You can connect to Sentinel and get some information on managed Redis

Connect to Sentinel

#${REDIS_HOME}/bin/redis-cli -p 5000 (Sentinel port, not Redis’s)

To get current master node

127.0.0.1:5000> sentinel get-master-addr-by-name M1
1) "127.0.0.1"
2) "6379"

To get master – slave info

127.0.0.1:5000> sentinel master M1
1) "name"
2) "M1"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6379"
7) "runid"
8) "0d5413945d08bdcc71b7a5b8be1855dd19eec65b"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
...

To change master node manually

127.0.0.1:5000> sentinel failover M1
OK

More commands => https://redis.io/topics/sentinel