文章目录

• • Redis哨兵(sentinel)
  • • 官网
    • 定义
    • 作用
  • 用法(一主二从三哨兵)
  • • 哨兵配置文件`sentinel.conf`
    • 启动一主二从
    • 启动三台哨兵
    • 哨兵故障恢复
  • 哨兵运行流程和选举原理
  • • SDown主观下线(Subjectively Down)
    • ODown客观下线(Objectively Down)
    • 哨兵内部选取leader
    • • Raft算法
    • 由leader推动故障切换流程并选出一个新master
    • • 新master选举
      • 从机重新认主
      • 老master重连后也认新主
  • 哨兵使用建议

Redis哨兵(sentinel)

官网

https://redis.io/docs/manual/sentinel

定义

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务

作用

• 主从监控

  监控主从redis库运行是否正常

• 消息通知

  哨兵可以将故障转移的结果发送给客户端

• 故障转移

  如果Master异常，则会进行主从切换
  将其中一个Slave作为新Master

• 配置中心

  客户端通过连接哨兵来获得当前Redis服务的主节点地址

用法(一主二从三哨兵)

哨兵配置文件sentinel.conf

官网Redis7.0.10：https://github.com/redis/redis/blob/7.0.10/sentinel.conf

• 参数说明

  • bind 服务监听地址，用于客户端连接，默认本机地址

  • daemonize 是否以后台daemon方式运行

  • protected-mode 安全保护模式

  • port 端口

  • logfile 日志文件路径

  • pidfile pid文件路径

  • dir 工作目录

  • sentinel monitor <master-name> <ip> <redis-port> <quorum>

    quorum：确认客观下线的最少的哨兵数量

    • 至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。
    • 因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

  • sentinel auth-pass <master-name> <password>

    master设置了密码，连接master服务的密码

  • 高级配置

    • sentinel down-after-milliseconds <master-name> <milliseconds>

      指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

    • sentinel parallel-syncs <master-name> <nums>

      表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

    • sentinel failover-timeout <master-name> <milliseconds>

      故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

    • sentinel notification-script <master-name> <script-path>

      配置当某一事件发生时所需要执行的脚本

    • sentinel client-reconfig-script <master-name> <script-path>

      客户端重新配置主节点参数脚本

• 本次配置

  • sentinel26379.conf

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

  • sentinel26380.conf

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

  • sentinel26381.conf

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

启动一主二从

详情配置：https://blog.csdn.net/al6nlee/article/details/129898425

启动三台哨兵

哨兵故障恢复

• 原master挂了

  

• Broken Pipe

  什么是Broken Pipe

  • pipe是管道的意思，管道里面是数据流，通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时，会发生数据突然中断，即是broken，对于socket来说，可能是网络被拔出或另一端的进程崩溃

  解决方案

  • 其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误

  这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！

  
  

• 查看日志

  投票新选；老master下线后重新上线也只是从机了，所以redis6379.conf里应当也配master的密码

  

• 涉及到redis.conf、sentinel.conf文件的重写

  Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，master.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换redis

哨兵运行流程和选举原理

SDown主观下线(Subjectively Down)

• 定义

  所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息， 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了

• 配置

  sentinel down-after-milliseconds

  • 表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据
  • master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

  

ODown客观下线(Objectively Down)

• 定义

  ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为master客观已经岩掉

• 配置

  sentinel monitor

  • masterName是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
  • quorum这个参数是进行客观下线的一个依据，法定人数/法定票数

  意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

  

哨兵内部选取leader

当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点 (兵王) 并由该领导者节点也即被选举出的兵王进行failover(故障迁移)

Raft算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：

即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

由leader推动故障切换流程并选出一个新master

新master选举

• 选取规则

  

  • priority

    redis,conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)

    

  • Replication offset

    复制偏移位置offer最大的从节点：即选取拥有最细数据的从机为主机

  • run ID

    最小Run ID的从节点->字典顺序，ASCII码

从机重新认主

• 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
• Sentinel leader会对选举出的新master执行slaveofno one操作，将其提升为master节点
• Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave

老master重连后也认新主

• 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
• Sentinelleader会让原来的master降级为slave并恢复正常工作

哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用

• 哨兵节点的数量应该是奇数

• 各个哨兵节点的配置应一致

• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射

• 哨兵集群+主从复制，并不能保证数据零丢失