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
  1. bind 0.0.0.0
  2. daemonize yes
  3. protected-mode no
  4. port 26379
  5. logfile "sentinel26379.log"
  6. pidfile /var/run/redis-sentinel26379.pid
  7. dir ./
  8. sentinel monitor mymaster 192.168.200.130 6379 2  #这个2代表只要两个哨兵同意
  9. sentinel auth-pass mymaster 111111

  复制代码
• sentinel26380.conf
  1. bind 0.0.0.0
  2. daemonize yes
  3. protected-mode no
  4. port 26380
  5. logfile "sentinel26380.log"
  6. pidfile /var/run/redis-sentinel26380.pid
  7. dir ./
  8. sentinel monitor mymaster 192.168.200.130 6379 2
  9. sentinel auth-pass mymaster 111111

  复制代码
• sentinel26381.conf
  1. bind 0.0.0.0
  2. daemonize yes
  3. protected-mode no
  4. port 26381
  5. logfile "sentinel26381.log"
  6. pidfile /var/run/redis-sentinel26381.pid
  7. dir ./
  8. sentinel monitor mymaster 192.168.200.130 6379 2
  9. 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
  
  
  • 两个小问题                                                                                                                        
    
    
    
    
  • 相识Broken Pipe
    
    
    
  
  
• 投票新选
  
  
  • 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.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文件里截取的）
  
  
  • sentinel26379.log
    
    
    
  • sentinel26380.log
    
    
    
  • sentinel26381.log
    
    
    
  
  
• 哨兵向导者，兵王怎样选出来的？Raft算法
  
  
  

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

（1）3步骤

一、新主登位

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

二、群臣俯首

三、旧主拜服

（2）小总结

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

五、哨兵使用建议

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。