前言

闲暇之余，搭建了个redis的哨兵系统。

针对，redis的主从虽然能保证数据的冷备份，方便进行故障恢复，或者主从实现读写分离，能够负载读压力，但是存在一个问题是：故障恢复无法自动化，因为有了哨兵，进一步提高系统的可用性。

作用

1、监控：检测主、从节点是否正常
2、自动故障恢复
3、配置提供者：给客户端使用时，可以用哨兵获取主节点地址（注意是提供配置，方便故障转移时自动链接，而非代理）
4、通知：将故障转移结果发给客户端

架构

这里搭建仅用了一个sentinel
哨兵节点是一种特殊的redis节点。

部署

配置

1、主节点

关键配置：redis.conf

logfile "/var/log/redis/redis-server.log"
pidfile "/var/run/redis/redis-server.pid"
port 6379
bind 0.0.0.0
dbfilename "dump.rdb"
masterauth "XXX"
requirepass "XXX"

2、从节点1

关键配置：slave1.conf

logfile "/var/log/redis/redis-server-slave1.log"
pidfile "/var/run/redis/redis-server-slave1.pid"
port 6378
bind 0.0.0.0
dbfilename "dump-slave1.rdb"
slaveof 127.0.0.1 6379
masterauth "XXX"
requirepass "XXX"

3、从节点2

关键配置：slave2.conf

logfile "/var/log/redis/redis-server-slave2.log"
pidfile "/var/run/redis/redis-server-slave2.pid"
port 6377
bind 0.0.0.0
dbfilename "dump-slave2.rdb"
slaveof 127.0.0.1 6379
masterauth "XXX"
requirepass "XXX"

4、哨兵节点 sentinel

daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
port 26379
# 监控命名为mymaster的主节点，ip + 端口 + 1（数字1表示故障转移时，至少需要多少个哨兵节点同意，才能判定主节点故障并进行故障转移，从主观变客观下线，一般哨兵节点一半加1个。）
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel auth-pass mymaster XXX

启动

依次执行如下启动命令：
主节点：systemctl start redis-server
从节点1：redis-server /etc/redis/slave1.conf
从节点2：redis-server /etc/redis/slave2.conf
哨兵：systemctl start redis-sentinel

启动后执行命令如下所示： ps -ef | grep redis

连接sentinel：redis-cli -p 26379
执行命令：info Sentinel

根据最后一行：master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1
监听1个名为mymaster的主机节点，同时有2个从节点，1个sentinel

查看连接从节点的状态，执行命令：sentinel slaves mymaster
7) "runid"
8) "6582ade03ccd6efaec657c633dcb8602acd01680"
9) "flags"
10) "slave"
关注这几行，可判断是否正常。

演练故障

主节点故障
执行命令：systemctl stop redis-server

观察sentinel日志：

// +sdown 主节点进入主观下线状态
29994:X 10 Oct 21:50:01.572 # +sdown master mymaster 127.0.0.1 6379
// +odown 客观下线，真正下线（经由1/1个哨兵投票）
29994:X 10 Oct 21:50:01.572 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
// 哨兵检查出故障，+new-epoch加1，从0变成1
29994:X 10 Oct 21:50:01.572 # +new-epoch 1
29994:X 10 Oct 21:50:01.572 # +try-failover master mymaster 127.0.0.1 6379
// 投票选举哨兵领导者
29994:X 10 Oct 21:50:01.575 # +vote-for-leader ae794ad42657621e4811436c1445a0b17c91ce8a 4
// 哨兵领导者选择完成
29994:X 10 Oct 21:50:01.575 # +elected-leader master mymaster 127.0.0.1 6379
// 准备故障转移，选择新的从节点
29994:X 10 Oct 21:50:01.575 # +failover-state-select-slave master mymaster 127.0.0.1 6379
// 故障切换，选择slave2，对应端口为6377的从节点做主节点
29994:X 10 Oct 21:50:01.675 # +selected-slave slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
// slave2执行slaveof-noone，从从节点变成主节点
29994:X 10 Oct 21:50:01.675 * +failover-state-send-slaveof-noone slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
29994:X 10 Oct 21:50:01.737 * +failover-state-wait-promotion slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
// 从节点成功变成主节点
29994:X 10 Oct 21:50:01.792 # +promoted-slave slave 127.0.0.1:6377 127.0.0.1 6377 @ mymaster 127.0.0.1 6379
// failover状态变为reconf-slaves
29994:X 10 Oct 21:50:01.792 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
// 领导者将其它从节点，指向新的主节点
29994:X 10 Oct 21:50:01.851 * +slave-reconf-sent slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
29994:X 10 Oct 21:50:02.842 * +slave-reconf-inprog slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
29994:X 10 Oct 21:50:02.842 * +slave-reconf-done slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6379
29994:X 10 Oct 21:50:02.904 # +failover-end master mymaster 127.0.0.1 6379
// 转移结束，6377成为新的主节点
29994:X 10 Oct 21:50:02.904 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6377
// 6378从节点，成为 6377的从节点了。
29994:X 10 Oct 21:50:02.904 * +slave slave 127.0.0.1:6378 127.0.0.1 6378 @ mymaster 127.0.0.1 6377
// 原主节点6379 成为 6377的从节点了。
29994:X 10 Oct 21:50:02.904 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6377

新的环境：哨兵新的info信息

注意

1、哨兵在进行故障转移时，会进行原从节点重新配置，主要为slaveof的改变，并修改到.conf中。但不会修改masterauth，所以可能导致故障转移后，从节点无法连接到新的主节点上，报错：

22542:S 10 Oct 20:57:33.658 * MASTER <-> SLAVE sync started
22542:S 10 Oct 20:57:33.658 * Non blocking connect for SYNC fired the event.
22542:S 10 Oct 20:57:33.658 * Master replied to PING, replication can continue...
// 如，主节点设置密码，从节点未设置密码（requirepass）的情况下，
// 从节点会配置masterauth；故障转移后，新的主节点是没有requirepass的，导致从节点连接新的注解点会报错。
22542:S 10 Oct 20:57:33.659 # Unable to AUTH to MASTER: -ERR Client sent AUTH, but no password is set

所以：需要将原主节点和从节点都配置相同的requirepass和masterauth。或者都不配置（不太安全）

2、在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)

3、哨兵系统的主从节点，和正常的主从无区别，主要是加入了哨兵这个特殊的redis节点，帮助故障的检测和自动转移。
另外，例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor

原理

流程

1、redis使用一组sentinel节点监听主从节点的可用性
2、一旦监听到主节点失效，将会从哨兵节点中选一个领导者
3、哨兵领导者来选择从节点作为新的主节点

如何监控

sentinel有3个定时任务检测redis节点可用性：
1、每隔10秒，向主从节点发送info命令，获取redis拓扑结构信息，包括主从角色，IP，端口。
2、每隔2秒，向sentinel:hello频道同步自身sentinel得到的主节点信息及当前哨兵节点的信息，同时可传达给其它哨兵节点当前获取的信息。
3、每隔1秒，向主从节点和其它哨兵节点ping命令，检测节点的状态

心跳检测

如果ping命令无法在固定的时间内（down-after-milliseconds）响应或返回错误的回复，那么会判断该节点（主从/哨兵）主观下线 sdown。

主观下线(sdown)：心跳检测失败则认为节点主观下线

客观下线(odown)：指针对主节点，当一个哨兵任务主节点主观下线时，会通过命令（sentinelis-master-down-byaddr）询问其它哨兵节点主节点的状态，超过一定数量的哨兵节点认为主节点下线了，则此时对主节点进行客观下线

选举一个sentinel作为领导者

当主节点客观下线后，会在sentinel中选择一个节点作为领导者，收到半数以上的节点同意即可

选择新的主节点

过滤掉不健康的从节点，由领导者从健康的从节点中选择一个新的主节点。（要么slave-priority最高，要么复制偏移量最大，要么就是runId最小，一层层筛选）

执行failover切换

领导者向选择的从节点发送slaveof no one提升其为主节点。
然后向其它从节点发送slaveof命令使其成为新的主节点的从节点，原来的主节点更新为新的从节点(启动后链接新的主节点)。