Redis 09章——哨兵（sentinel）

一、是什么

吹哨人巡查监控后台master主机是否故障，如果故障了根据 $\\textcolor{red}{投票数}$ 自动将某一个从库转换为新主库，继续对外服务
作用：俗称无人值守运维
官网理论：High availability with Redis Sentinel | Docs

二、能干嘛

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master
配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

三、怎么玩（案例演示实战步骤）

（1）Redis Sentinel架构，前提说明

3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
1主2从：用于数据读取和存放

（2）案例步骤

3.3.1/myredis目录下新建或者拷贝sentinel.conf文件，名字绝对不能错

3.3.2先看看/opt/redis-7.0.0目录下默认的sentinel.conf文件的内容

3.3.3重要参数项说明

bind：服务监听地址，用于客户端连接，默认本机地址
daemonize：是否以后台daemon方式运行
protected-model：安全保护模式
port：端口
logfile：日志文件路径
pidfile：pid文件路径
dir：工作目录
重点：
其它

3.3.4本次案例哨兵sentinel文件通用配置

由于机器硬件的关系，我们的3个哨兵都同时配置到192.168.200.130同一台机器

sentinel26379.conf

复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir ./
sentinel monitor mymaster 192.168.200.130 6379 2  #这个2代表只要两个哨兵同意
sentinel auth-pass mymaster 111111

sentinel26380.conf

复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir ./
sentinel monitor mymaster 192.168.200.130 6379 2
sentinel auth-pass mymaster 111111

sentinel26381.conf

复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir ./
sentinel monitor mymaster 192.168.200.130 6379 2
sentinel auth-pass mymaster 111111

注意：上述的logfile和dir都要根据自己的实际情况决定，因为我们的配置文件现在就在/opt/redis-7.0.0/myredis里，所以我这么填写
master主机配置文件的说明 ：

3.3.5先启动一主二从3个redis实例，测试正常的主从复制

注意：现在也要给主机设置masterauth了（具体的ip根据自己实际情况确定）
请看一眼redis6379.conf、redis6380.conf、redis6381.conf我们自己填写的主从复制相关内容
3台不同的虚拟机实例，启动三台真实机器实例并连接

3.3.6再启动三个哨兵，完成监控

redis-server sentinel26379.conf --sentinel
redis-server sentinel26380.conf --sentinel
redis-server sentinel26381.conf --sentinel

3.3.7启动三个哨兵监控后再测试一次主从复制

3.3.8原有的master挂了

（1）我们自己手动关闭6379服务器，模拟master挂了

（2）问题思考

两台从机数据是否OK（要等一会儿，因为内部会重新选举）
是否会从剩下的两台机器上选出新的master？可以看到此时第一台从机被选举成了新的master，第二台从机成为了它的slave（可以看第一台机器的日志文件）
之前宕机的master重启回来，谁将会是新老大？会不会双master冲突。答：老大还是主机宕机后，新选出来的那个master。主机就算重启，它也不会变回master了，它只会成为新的master的slave

（3）揭晓答案

数据OK
1. 两个小问题
2. 了解Broken Pipe
投票新选
1. sentinel26379.log，从该日志中可以看到这个哨兵的id
2. sentinel26380.log，从该日志中可以看到这个哨兵的id
3. sentinel26381.log，从该日志中可以看到这个哨兵的id
谁是master，仅限本次案例
1. 6380被选为新master，上位成功
2. 以前的6379被降级变成了slave
3. 6381还是slave，只不过换了个新老大6380（6379变6380）

3.3.9对比配置文件

老master，vim redis6379.conf
新master，vim redis6380.conf
结论：（1）文件的内容，在运行期间会被sentinel动态进行更改（2）Mater-Slave切换后，master的conf，slave的conf，sentinel的conf内容都会发生改变，及master的conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

（3）其它备注

生产上都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况
可以同时金童监控master，一行一个

四、哨兵运行流程和选举原理

（1）介绍

当一个主从配置中master失效后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

（2）运行流程，故障切换

4.2.1三个哨兵监控一主二从，正常运行中......

4.2.2SDown主观下线（Subjectively Down）

SDOWN（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
说明：

4.2.3ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
说明：

4.2.4选举出领导者哨兵（哨兵中选出兵王）

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者也即被选举出的兵王进行failover（故障转移）
三哨兵日志文件2次解读分析（举例，这个不是从我自己的三个哨兵的log文件里截取的）
1. sentinel26379.log
2. sentinel26380.log
3. sentinel26381.log
哨兵领导者，兵王如何选出来的？Raft算法

4.2.5由兵王开始推动故障切换流程并选出新的master

（1）3步骤

一、新主登基

某个Salve被选中成为新的Master
选出新master的规则，剩余slave节点健康的前提下
1. redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
2. 复制偏移位置offset最大的从节点（也就是在master还没有宕机时，复制到数据比其他Slave要多）
3. 最小Run ID的从节点，字典顺序，ASCII码

二、群臣俯首

三、旧主拜服

（2）小总结

上述的failover操作均由sentinel自己独自完成，完全不需要人工干预

五、哨兵使用建议

哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
哨兵节点的数量应该是奇数
各个哨兵节点的配置应一致
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
哨兵集群+主从复制，并不能保证数据零丢失（引出集群）