Monkey

个人站

The master has failed more times than the beginner has tried


redis 哨兵模式详解「上」

上篇文章 搞定 Redis 主从复制,一篇就够了 介绍了 redis 的主从复制的一些内容;

回顾主从复制的大概内容

主从复制的问题

主从复制搭建完成后,我们会发现一个严重的问题,就是当主机 master 宕机以后,整个系统就挂掉了,我们需要人工解决切换问题;

实际上主从复制并没有实现高可用。高可用侧重于备份机器,利用集群中系统的冗余,当系统中某台机器发生故障损坏的时候,其他后备的机器可以迅速的接替它来启动服务;

一旦主节点宕机,写服务无法使用,就需要手动切换,重新选去主节点,手动设置主从关系

手动切换

  • 选择一台 slave 从节点,选取它来做新的主节点 「new master」,使用 SLAVEOF NO NOE, 先结束原来的主从关系。此时这台机器的角色会变成 master;

  • 把其他从节点的机器设置主节点为 新的主节点 「new master」;

  • 当 旧的 master 机器解决完宕机问题后,把这个节点设置成 新主节点「new master」的从节点;

如何解决手动切换的问题呢?

如果我们有一个监控程序能够监控各个机器的状态及时作出调整,将手动的操作变成自动的, sentinel 的出现就是为了解决这个问题;

哨兵机制的原理及实现

哨兵机制的原理:

  • redis sentinel 是一个分布式架构,其中包含若干个 sentinel 节点和 redis 数据节点。

  • 每个 sentinel 节点会对数据节点和其余的 sentinel 节点进行监控,当它发现节点不可达时,会对节点做下线标示;

  • 如果被标示的是主节点,它还会和其他 sentinel 节点进行「协商」,当大多数 sentinel 节点都认为主节点不可达时,他们会选举出一个。sentinel 节点来完成自动故障迁移的工作;

  • 同时会将这个变化实时通知给 redis 应用方;

  • 整个过程和完全是自动的,不需要人工介入,所以这套方案很有效的解决了 redis. 高可用的问题;

基本故障转移流程

  1. 主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败

  2. 每个 sentinel 节点通过定期监控发现主节点出现了故障

  3. 多个 sentinel 节点对主节点的故障达成一致会选举出其中一个节点作为领导者负责故障转移

  4. sentinel 领导者节点执行了故障转移,整个过程基本是和我们手动调整一致的,只不过是自动化完成的;

  5. 故障转移后整个。redis-sentinel 的结构,重新选举了新的主节点;

redis-sentinel 具有什么作用

  • 监控

    • Sentinel 节点会定期检测 Redis 数据节点和其他 sentinel 节点是否可达
  • 通知

    • Sentinel 节点会将故障转移的结果通知到应用方
  • 主节点故障转移

    • 实现从节点晋升到主节点的切换,并维护后续正确的主从关系
  • 配置提供者

    • 在 Redis Sentinel 结构中,客户端在初始化时连接的是 Sentinel 节点集合,从中获取主节点信息

    • 同时 Sentinel 节点集合包含了若干个节点,这样做会带来两个好处

      1. 对于节点故障的判断是由多个 Sentinel 节点来共同完成的,这样可以有效的防止误判
      2. Sentinel 节点集合是由多个节点组合的,这样即使某个节点挂掉以后,整个节点集合仍是健壮的

    Sentinel节点本身也是Redis 的独立节点,但是它是特殊的节点,它本身不提供存书数据,只支持部分命令

Sentinel 的核心配置

  1. SENTINEL monitor mymaster 127.0.0.1 2

    监控的主节点的 名称, IP 和 端口,最后一个参数「2」的意思是有几台 Sentinel 节点发现有问题,就会发生故障转移;

    • 例如:配置为 2 ,表示 至少有 2 个 Sentinel 节点认为主节点不可达,这个不可达的判定是客观的。

    • 对于设置的越小,那么达到下线的条件越宽松,反之越严格。一般建议将其设置为 Sentinel 节点的一般加一

    • 注意:最后的参数不得大于 Sentinel 节点的总数

  2. SENTINEL down-after-millseconds mymaster 30000

    超市的时间「单位是毫秒」

    • 例如: Sentinel 去 Ping 一个机器的时候,多长时间后仍 Ping 不通,那么就判定它是有问题的
  3. SENTINEL parallel-syncs mymaster 1

    每次复制的个数

    • 当 Sentinel 节点集合对主节点故障判定达成一致时,Sentinel 领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作, parallel-syncs 就是用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数,指出 Sentinel 属于并发还是串行。

    • 1 代表每次只能复制一个,可以减轻 master 的压力

  1. SENTINEL auth-pass &lt;master-name&gt;<password>

    如果 Sentinel 监控的主节点配置了密码, sentinel auth-pass 配置通过添加主节点的密码,防止 Sentinel 节点对主节点的无法监控

  2. SENTINEL failover-timeout mymaster 180000

    表示故障转移的时间「毫秒」

Sentinel 命令

  • Sentinel 支持的以下合法的命令:

    • 连接 Sentinel : Sentinel 接受 Redis 协议格式的命令请求, 所以你可以使用 redis-cli -p 端口 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。使用 -p 参数指定端口

    • SENTINEL master &lt;master name&gt; 显示被监控的所有的 master 以及它们的状态

    • SENTINEL master &lt;master name&gt; 显示指定 master 的信息和状态

    • SENTINEL slaves &lt;master name&gt; 显示指定 master 的所有 slave 以及它们的状态

    • SENTINEL get-master-addr-by-name &lt;master name&gt; 返回指定 master 的 IP 和 端口,如果正在进行 failover 或者 failover 已经完成,将会显示被提升为 master 的 slave 的 IP 和 端口

    • SENTINEL failover &lt;master name&gt; 强制 sentinel 执行 failover , 并且不需要得到其他 sentinel 的同意,但是 failover 后会将最新的配置发送给其他的 sentinel

    • SENTINEL remove test 放弃对 test 节点的监听

    • SENTINEL set failover-timeout mymaster 180000 设置配置选项

Sentinel 的搭建「操练起来😄」

  • 环境说明:

  • 使用 docker 搭建 redis 主从和哨兵

  • docker 搭建 redis 集群:一主三从三哨兵
  • 首先查看主从的配置

主节点的 IP 是 172.10.0.5

从节点 172.10.0.1

从节点 172.10.0.6 「同时是172.10.0.7的主节点,树状结构」

从节点 172.10.0.7 的配置

哨兵节点配置信息:三个节点分别是 172.10.0.9,172.10.0.10,172.10.0.11

在三台哨兵节点中分别配置 /path/to/redis-sentinel.conf 文件

sentinel monitor mymaster 172.10.0.5 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

验证配置是否正确:

我们将主节点「172.10.0.5」停用,验证哨兵是否可以自动切换从节点晋升为主节点,同时其他从节点监听新的主节点

可以看到 sentinel 选举了 172.10.0.6 为主节点,同时把 「0.5」「0.1」「0.7」 设置成从节点

我们再次启动 旧的主节点 「172.10.0.5」

至此,我们的哨兵配置完成,并且可以正常使用。再也不用担心主节点宕机问题了😄

打赏一个呗

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦