Redis Sentinel集群部署

Sentinel启动后会输出类似的日志：

$ tail -f /var/log/redis/redis-sentinel.log

6207:X 06 Jun 10:40:05.904 # Sentinel runid is 2b2446b24a2bd01b9f54a6b2ca4f945a3480dd7e
6207:X 06 Jun 10:40:05.904 # +monitor master redis-master 192.168.2.210 6379 quorum 2
6207:X 06 Jun 10:40:05.910 * +slave slave 192.168.2.211:6379 192.168.2.211 6379 @ redis-master 192.168.2.210 6379
6207:X 06 Jun 10:40:05.915 * +slave slave 192.168.2.212:6379 192.168.2.212 6379 @ redis-master 192.168.2.210 6379
6207:X 06 Jun 12:01:33.098 * +sentinel sentinel 192.168.2.211:26379 192.168.2.211 26379 @ redis-master 192.168.2.210 6379
6207:X 06 Jun 12:02:07.922 * +sentinel sentinel 192.168.2.212:26379 192.168.2.212 26379 @ redis-master 192.168.2.210 637968.2.212:6379 192.168.2.212 6379 @ redis-master 192.168.2.210 6379

输出的结果表示开始监控redis-master集群,并输出集群的基本信息.+slave和+sentinel分别代表成功发现了从数据库和其他Sentinel.

• 查看sentinel.conf

重新打开sentinel.conf文件,发现Sentinel自动生成了一些信息,记录了监控过程中的状态变化.

$ cat /etc/redis/sentinel.conf
# Generated by CONFIG REWRITE
maxclients 4064
sentinel leader-epoch redis-master 0
sentinel known-slave redis-master 192.168.2.212 6379
sentinel known-slave redis-master 192.168.2.211 6379
sentinel current-epoch 0

• 查看Sentinel监控的主从服务器

列出所有被监视的主服务器,以及这些主服务器的当前状态.

$ redis-cli ?-p 26379 -h 192.168.2.210
192.168.2.210:26379> sentinel master redis-master
 1) "name"
 2) "redis-master"
 3) "ip"
 4) "192.168.2.210"
 5) "port"
 6) "6379"
 7) "runid"
 8) "02d88a6105ce3277745c1fc65b695887f165f302"
 9) "flags"
10) "master"
11) "pending-commands"
12) "0"
13) "last-ping-sent"
14) "0"
15) "last-ok-ping-reply"
16) "1096"
17) "last-ping-reply"
18) "1096"
19) "down-after-milliseconds"
20) "5000"
21) "info-refresh"
22) "4732"
23) "role-reported"
24) "master"
25) "role-reported-time"
26) "667578"
27) "config-epoch"
28) "0"
29) "num-slaves"
30) "2"
31) "num-other-sentinels"
32) "0"
33) "quorum"
34) "2"
35) "failover-timeout"
36) "180000"
37) "parallel-syncs"
38) "2"
39) "notification-script"
40) "/etc/redis/notify.sh"

Sentinel验证

测试Failover

我们让dev-master-01主机上的redis-master主动休眠30秒来观察failover过程：

$ redis-cli -p 6379 -h 192.168.2.210 -a 000000 DEBUG sleep 30

我们可以看到每个Sentinel进程都监控到Master挂掉,从sdown状态进入odown,然后选举了一个leader来进行failover,最终192.168.2.212成为新的Master,Sentinel的日志输出：

日志的几个主要事件

在Redis Master角色上主要有以下几个事件：

• +sdown master redis-master 192.168.2.210 6379,发现Master检测失败,主观认为该节点挂掉,进入sdown状态.
• +odown master redis-master 192.168.2.210 6379 #quorum 2/2,有两个Sentinel节点认为Master 6379挂掉,达到配置的quorum值2,因此认为Master已经客观挂掉,进入odown状态.
• +try-failover master redis-master 192.168.2.210 6379,表示Sentine开始进行故障恢复.
• +vote-for-leader 2b2446b24a2bd01b9f54a6b2ca4f945a3480dd7e 1,准备选举一个 Sentinel Leader来开始failover.
• +failover-end master redis-master 192.168.2.210 6379,表示Sentinel完成故障修复,其中包括了Sentinel Leader的选举、备选从数据库的选择等较为复杂的过程.
• +switch-master redis-master 192.168.2.210 6379 192.168.2.212 6379,切换Master节点,failover完成.
• -sdown slave 192.168.2.210:6379 192.168.2.210 6379 @ redis-master 192.168.2.212 6379,192.168.2.210休眠完成后,作为Slave挂载到192.168.2.212后面,可见Sentinel确实同时在监控Slave状态,并且挂掉的节点不会自动移除,而是继续监控.

在Redis Slave角色上主要有以下几个事件：

?

Redis Slave上大多数都和Redis Master上的事件类似,不同的是Redis Slave还多了一步配置更新.

• +config-update-from sentinel 192.168.2.210:26379 192.168.2.210 26379 @ redis-master 192.168.2.210 6379

查看Sentinel配置文件变更

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!