Redis 09章——哨兵（sentinel）
一、是什么[*]吹哨人巡查监控后台master主机是否故障，如果故障了根据$\textcolor{red}{投票数}$自动将某一个从库转换为新主库，继续对外服务
[*]作用：俗称无人值守运维https://i-blog.csdnimg.cn/direct/0c6835fc6b1c47d19ff58dce60d40fb2.png
[*]官网理论：High availability with Redis Sentinel | Docs
二、能干嘛
[*]主从监控：监控主从redis库运行是否正常
[*]消息通知：哨兵可以将故障转移的结果发送给客户端
[*]故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master
[*]设置中央：客户端通过毗连哨兵来得到当前Redis服务的主节点地址
三、怎么玩（案例演示实战步骤）
（1）Redis Sentinel架构，前提阐明
[*]3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
[*]1主2从：用于数据读取和存放https://i-blog.csdnimg.cn/direct/b5e596fb296a43ad90a1159c77bf75e0.png
（2）案例步骤
3.3.1/myredis目次下新建大概拷贝sentinel.conf文件，名字绝对不能错
https://i-blog.csdnimg.cn/direct/a43bdc2a2ab641f4a094bfd3f0e60806.png
3.3.2先看看/opt/redis-7.0.0目次下默认的sentinel.conf文件的内容https://i-blog.csdnimg.cn/direct/0dd80f9471d44ca9b8749cd5e2e9771d.png
3.3.3重要参数项阐明
[*]bind：服务监听地址，用于客户端毗连，默认本机地址
[*]daemonize：是否以后台daemon方式运行
[*]protected-model：安全保护模式
[*]port：端口
[*]logfile：日记文件路径
[*]pidfile：pid文件路径
[*]dir：工作目次
[*]重点：https://i-blog.csdnimg.cn/direct/8d28821d57b146ffa13ab7f222a272ca.pnghttps://i-blog.csdnimg.cn/direct/322daa6082894d278986ba864ecd190d.png
[*]别的https://i-blog.csdnimg.cn/direct/4d8ecd21fff14295ac68a8d94139cc9c.png
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主机设置文件的阐明：https://i-blog.csdnimg.cn/direct/df2148017e47421abba55da3efb858fb.png
3.3.5先启动一主二从3个redis实例，测试正常的主从复制
[*]注意：现在也要给主机设置masterauth了（具体的ip根据自己现实情况确定）https://i-blog.csdnimg.cn/direct/d37b07af882d4514a43399cc96521458.pnghttps://i-blog.csdnimg.cn/direct/7b3135de279a4fee8f8a34c994771ba5.png
[*]请看一眼redis6379.conf、redis6380.conf、redis6381.conf我们自己填写的主从复制相干内容https://i-blog.csdnimg.cn/direct/c58e1ac43e124edd87302f8fb1374921.png
[*]3台不同的虚拟机实例，启动三台真实呆板实例并毗连
3.3.6再启动三个哨兵，完成监控
[*]redis-server sentinel26379.conf --sentinel
[*]redis-server sentinel26380.conf --sentinel
[*]redis-server sentinel26381.conf --sentinelhttps://i-blog.csdnimg.cn/direct/79a3451dc51f498daae09cd051a24c81.png
3.3.7启动三个哨兵监控后再测试一次主从复制
https://i-blog.csdnimg.cn/direct/f19f0faef92745bb8b1b8deb4abc164e.png
3.3.8原有的master挂了
（1）我们自己手动关闭6379服务器，模仿master挂了https://i-blog.csdnimg.cn/direct/366c4dddc0a6410883201c8e5f9c2cbb.png
（2）问题思考
[*]两台从机数据是否OK（要等一会儿，由于内部会重新推举）https://i-blog.csdnimg.cn/direct/32a0f394b7134b1d9d524e75529964a2.pnghttps://i-blog.csdnimg.cn/direct/63636ca81d3047d98846dd4ad2f53a44.png
[*]是否会从剩下的两台呆板上选出新的master？可以看到此时第一台从机被推举成了新的master，第二台从机成为了它的slave（可以看第一台呆板的日记文件）https://i-blog.csdnimg.cn/direct/1828049b33c44d7c9721fa1b66bb1221.pnghttps://i-blog.csdnimg.cn/direct/e2b43c0439354340b85fe9eb9661a45e.png
[*]之前宕机的master重启回来，谁将会是新老大？会不会双master冲突。答：老大还是主机宕机后，新选出来的谁人master。主机就算重启，它也不会变回master了，它只会成为新的master的slave
（3）揭晓答案
[*]数据OK
[*]两个小问题 https://i-blog.csdnimg.cn/direct/f1ebbdfbe07c451babce08e02d170ebd.pnghttps://i-blog.csdnimg.cn/direct/38bbe97ab3624332bdcdcb11272b41dd.png
[*]相识Broken Pipehttps://i-blog.csdnimg.cn/direct/275dda4c96e14a59a2d298cc3a44f6c6.png
[*]投票新选
[*]sentinel26379.log，从该日记中可以看到这个哨兵的id
[*]sentinel26380.log，从该日记中可以看到这个哨兵的id
[*]sentinel26381.log，从该日记中可以看到这个哨兵的id
[*]谁是master，仅限本次案例
[*]6380被选为新master，上位成功
[*]以前的6379被降级变成了slave
[*]6381还是slave，只不外换了个新老大6380（6379变6380）
3.3.9对比设置文件
[*]老master，vim redis6379.confhttps://i-blog.csdnimg.cn/direct/1313c5edf5e84678bafd1398cea71f90.png
[*]新master，vim redis6380.confhttps://i-blog.csdnimg.cn/direct/fec48d47282f4ddb971a1096277d72d2.png
[*]结论：（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设置了判断主观下线的时间长度
[*]阐明：https://i-blog.csdnimg.cn/direct/630f76007a7f4bc8921f177552663829.png
4.2.3ODown客观下线(Objectively Down)
[*]ODOWN必要一定命量的sentinel，多个哨兵达成一致意见才能以为一个master客观上已经宕机
[*]阐明：https://i-blog.csdnimg.cn/direct/d5992e87e1be48d8a4683bdd088c3cdb.png
4.2.4推举出向导者哨兵（哨兵中选出兵王）
[*]当主节点被判断客观下线后，各个哨兵节点会进行协商，先推举出一个向导者哨兵节点（兵王）并由该向导者也即被推举出的兵王进行failover（故障转移）
[*]三哨兵日记文件2次解读分析（举例，这个不是从我自己的三个哨兵的log文件里截取的）
[*]sentinel26379.loghttps://i-blog.csdnimg.cn/direct/668df00a9db8453fa0f93c4a645a1d32.png
[*]sentinel26380.loghttps://i-blog.csdnimg.cn/direct/88cc0540715d47828a2e82dcd1d90ed4.png
[*]sentinel26381.loghttps://i-blog.csdnimg.cn/direct/bc2de69df8fd462db61da2f14bf6df74.png
[*]哨兵向导者，兵王怎样选出来的？Raft算法https://i-blog.csdnimg.cn/direct/5aa1ec5692b34a09860f4df504671b20.png
4.2.5由兵王开始推动故障切换流程并选出新的master
（1）3步骤
一、新主登位
[*]某个Salve被选中成为新的Master
[*]选出新master的规则，剩余slave节点健康的前提下
[*]redis.conf文件中，优先级slave-priority大概replica-priority最高的从节点（数字越小优先级越高）https://i-blog.csdnimg.cn/direct/0d9b80281ef74438b80f93c069bc1ab0.png
[*]复制偏移位置offset最大的从节点（也就是在master还没有宕机时，复制到数据比其他Slave要多）
[*]最小Run ID的从节点，字典顺序，ASCII码https://i-blog.csdnimg.cn/direct/913dee2655e14a6c974575e1052d2202.png
二、群臣俯首
https://i-blog.csdnimg.cn/direct/85bfc37451684155b6756110dd14e3c1.png
三、旧主拜服https://i-blog.csdnimg.cn/direct/6980e95ccb7c4faa83b67331ffeced8f.png
（2）小总结
上述的failover操作均由sentinel自己独自完成，完全不必要人工干预https://i-blog.csdnimg.cn/direct/78c37f49f1524e8cac55d715ab5582d1.png
五、哨兵使用建议
[*]哨兵节点的数量应为多个，哨兵自己应该集群，保证高可用
[*]哨兵节点的数量应该是奇数
[*]各个哨兵节点的设置应一致
[*]如果哨兵节点部署在Docker等容器内里，尤其要注意端口的正确映射
[*]哨兵集群+主从复制，并不能保证数据零丢失（引出集群）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]