Redis哨兵配置及部署

哨兵

哨兵介绍

作用: 监控Redis系统的运行情况

功能:

  • 监控主数据库和从数据库是否正常运行
  • 主数据库出现故障时自动将从数据库转换为主数据库

一个典型的哨兵架构

在这里插入图片描述

虚线表示主从复制,实线表示哨兵的监控路径

多个哨兵监控

在这里插入图片描述

哨兵不仅会监控主数据库和从数据库,哨兵之间也会互相监控

哨兵的应用配置

  1. 建立一个配置文件,如sentinel.conf,内部为
    sentinel monitor mymaster 127.0.0.1 6379 1
    • mymaster表示要监控的主数据库的名字,可以自己定义,只能由大小写字母 数字 ".-_"这三个字符组成
    • 127.0.0.1 6379 表示主数据库的地址和端口号
    • 1 表示最低通过票数
    • 配置哨兵监控一个系统的时候,只需要交控主数据库即可,哨兵会自动发现所有复制该主数据库的从数据库
  2. 启动Sentinel进程,并将上述配置文件的路径传递给哨兵
    redis-sentinel /path/to/sentinel.conf
  3. 返回值
    • +slave 表示发现了从数据库
    • +sdown表示哨兵主观认为主数据库停止服务了
    • +odown表示哨兵客观认为主数据库停止服务了
    • +try-failover表示哨兵开始进行故障恢复
    • +failover-end表示哨兵完成故障恢复
    • +switch-master表示主数据库从…端口迁移到…端口
    • -sdown表示实例已经恢复
    • +convert-to-slave表示将…端口实例设置为现在主数据库的从数据库

哨兵的实现原理

  • 一个哨兵节点可以同时监控多个redis主从环境
  • 多个哨兵节点可以同时监控同一个Redis主从环境,形成网状结构
  1. 哨兵启动后,会与要监控的主数据库建立两条连接,其中一条连接用来订阅主数据的__sentinel__:hello频道以获取其他同样监控该数据库的哨兵节点的信息
    另外哨兵也需要定期向主数据库发送INFO命令来获取主数据库本身的信息
  2. 三个贯穿哨兵进程的生命周期的操作
    1. 每10s哨兵会向主数据库和从数据库发送INFO命令
      • 发送INFO命令使得哨兵可以获得当前数据库的相关信息从而实现新节点的主动发现
    2. 每2s哨兵会向主数据库和从数据库的__sentinel__:hello频道发送自己的信息
    3. 每1s哨兵会向主数据库 从数据库和其他哨兵节点发送ping命令
      • 配置发送ping命令的时间通过down-after-milliseconds
      • sentinel down-after-milliseconds mymaster 60000 // 每隔1s发送一次ping命令
      • 当参数值小于1s时,哨兵会每隔设置的值的时间发送ping命令,当参数的值大于1s是,哨兵会每隔1s发送一次ping命令

主观下线:
当超过down-after-milliseconds选项指定的时间后,如果ping的数据库或节点仍然未进行回复,则哨兵认为主观下线
客观下线:
主观下线表示从当前的哨兵进程来看,该节点已经下线,如果该节点是主数据库,则哨兵会进一步判断是否需要对其进行故障恢复:
哨兵发送sentinel is-master-down-by-addr命令询问其他哨兵节点以了解他们是否也认为该数据库主观下线,如果达到指定数量时,
哨兵会认为其客观下线,并选举领头的哨兵节点对主从系统发起故障恢复
指定数量指的是: sentinel monitor mymaster 127.0.0.1 6379 1 中的1
领头哨兵选举(Raft算法)

  • 发现主数据库客观下线的哨兵节点(下面称作A)向每个哨兵节点发送命令,要求对方选自己成为领头哨兵
  • 如果目标哨兵节点没有选过其他人,则会同意A设置成零头哨兵
  • 如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵,则A成功成为领头哨兵
  • 当有多个哨兵节点同时参选领头哨兵,则会出现没有任何节点当选的可能.此时每个参选节点将等待一个随机时间重新发起参选请求,进行下一轮选举,直到选举成功
    领头哨兵挑选数据库的依据
  • 在所有在线的从数据库中,选择优先级最高的从数据库,优先级可以通过slave-priority选项来设置
  • 如果有多个最高优先级的数据库,则复制的命令偏移量越大(即复制越完整)越优先
  • 如果以上条件都一样,则选择运行ID较小的数据库

哨兵部署

  • 一个主系统中哨兵数量少,可靠性就会降低,当只有一个哨兵,容易发生单点故障
  • 相对稳妥的是使哨兵的视角尽可能与每一个节点的视角一致
    • 为每个节点(无论是主数据库还是从数据库)部署一个哨兵
    • 使每个哨兵与其对应的节点的网络环境相同或相近
  • 设置quorum的值为N/2 + 1(其中N为哨兵节点数量),这样使得只有当大部分哨兵点同意后才会进行故障恢复
  • 具体配置还要根据实际情况,因为当节点较多时,会产生大量冗余连接,同时如果redis节点负载较高,会在一定程度上影响其对哨兵的回复以及与其同机的哨兵与其他节点的通信
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章