1、哨兵简介
master宕机场景的处理：
问题：
怎么确认master确实宕机了？（中间断网1s就认为人挂了不合适）
怎么找一个slave来暂替master？
旧的master恢复以后怎么处理？
哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行
监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
哨兵的三点作用：
- 监控
不断的检查master和slave是否正常运行。 - 通知
当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知 - 自动故障转移
断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
注：
- 哨兵也是一台redis服务器，只是不提供数据服务
- 通常哨兵配置数量为单数，3、5、7……
2、启用哨兵模式
2.1 哨兵配置
查看哨兵的配置文件，过滤注释与空行：
具体配置参数整理：
| 配置项 | 实例 | 含义 |
|---|---|---|
| sentinel auth-pass 服务器名 密码 | sentinel auth-pass mymaster 9527 | 连接服务器时的验证密码 |
| sentinel down-after-milliseconds 自定的服务器名 masterIP Port 票选数量 | sentinel monitor mymaster 1.2.3.4 6379 2 | 后面的2，即两个哨兵认为master挂了就是真的挂了，常为哨兵数的1/2+1 |
| sentinel down-after-milliseconds 服务器名 毫秒数 | sentinel down-after-milliseconds mymaster 3000 | 哨兵判定master挂掉的时间周期 |
| sentinel parallel-syncs 服务器名 服务器数 | sentinel parallel-syncs mymaster 1 | 指定同时进行主从的slave数量，数值越大，要求网络资源越高，数值约小，同步时间约长 |
| sentinel failover-timeout 服务器名 毫秒数 | sentinel failover-timeout mymaster 9000 | 出现故障后，故障切换的最大超时时间3分钟，超过则认定切换失败 |
| sentinel notification-script 服务名 脚本路径 | 服务器无法正常联通时，设定的执行脚本，通常调试使用 |
使用sed编辑文件，并重定向。生成三个哨兵的配置文件（用三个不同端口模拟三个哨兵）
哨兵启动指令：
redis-sentinel sentinel-端口号.conf
先启动master、再slave、最后启动哨兵
=====================================================
2.2 哨兵模拟搭建实验
以本机的6379位master、6380、6381为slave，26379、26380、26381为三个sentinel，模拟实验：
①启动master和slave后，启动26379sentinel：
②连接哨兵的客户端，验证其确实不能进行set等指令：
③启动哨兵26380
注意此时哨兵26379的配置文件会相应的发生变化：
④模拟master宕机，CTRL+C掉6379的server端
⑤6379重新连接服务端以后，查看哨兵控制台日志：取消了6379的s_down标记，但并未恢复其master的身份
=====================================================
3、哨兵工作原理
哨兵在进行主从切换过程中经历三个阶段：
监控
通知
故障转移
3.1 监控阶段
sentinel会向master和slave要信息，各个sentinel之间有专门通路进行信息交换，如此便形成了一个网络：
3.2 通知阶段
就像一个小的朋友圈，sentinel之间互相进行信息的传播，保持信息的对等：
3.3 故障转移阶段
①哨兵1持续发消息给master均无反应，标记master为S_DOWN，也叫主观下线
②哨兵1标记后，并将这个消息带回sentinel的圈子里，告诉其余哨兵，可能master挂了，于是其余哨兵开始发送消息给master验证消息是否属实
③验证结果确实如此，只要半数以上哨兵认为挂了，则标记变为O_DOWN（这也是哨兵数量要求奇数的原因），这时，O_DOWN就是客观下线了
④既然确认master挂了，那就要去处理，哪个哨兵去处理呢，每个哨兵发送挂的IP、挂的端口、自己曾经竞选的次数、自己的runID，以便选个领头的哨兵
最后由竞选出来的1号哨兵去处理：
⑤ 从slave中挑选备选master，首先淘汰掉：
- 不在线的
- 响应慢的
- 与原master断开时间久的
对于剩下的备选，则考虑优先级、offset、runid等等
⑥向新选出的master发送slaveof no one，断开原主从连接，并向其他slave发送slaveof 新masterIP端口
至此，故障转移完成！！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/146160.html
