阅读 97

07 哨兵机制:主库挂了,如何不间断服务

07 哨兵机制:主库挂了,如何不间断服务

本篇重点

哨兵机制的“监控”、“选主”、“通知”

0.0 背景

主从库采取“读写分离”模式,主库挂了,Redis读操作可以由从库执行,但写操作智能由主库执行后同步给从库,一旦主库挂了,写服务终端,从库无法进行数据同步

解决方案:运行新主库:即从从库中选举一个从库作为新主库,这种主库挂了后从库选举新主库的机制就是Redis哨兵机制

0.1 前言

  • 哨兵机制需要考虑的三个问题

    • 主库真的挂了吗?

    • 该选择哪个库作为新主库?

    • 怎么把新主库的相关信息通知给从库和客户端?

  • 哨兵机制的三个功能

    • 监控主库运行状态,判断主库是否“客观下线”

    • 在主库“客观下线”后,选举新主库

    • 将新主库信息通知给从库和客户端

    • 监控-选主-通知

  • 哨兵集群

    • 哨兵需要监控主从库的状态并在主库下线后及时选举从库,因此需要多个哨兵组成哨兵集群

    • 这篇先引出哨兵集群的概念,具体集群中的一些操作见下篇[链接]

1.1 监控

判断主库是否下线的两个标准:主观下线、客观下线

哨兵会定期给主库(和其他从库)执行ping判断对方是否在线

  • 主观下线

    • 哨兵A ——> 主库 : ping; 若主库响应超时,则哨兵A判定主库主观下线

    • 主观下线存在误判情况:主库在线,但由于网络拥塞/Redis集群网络压力较大等导致主库没有及时响应ping

  • 客观下线

    • 哨兵集群 ——> 主库 :ping;每个哨兵都将自己ping主库的结果拿出来

    • 若判定主库状态为“(主观)下线”的哨兵数 > 哨兵集群总数一半,即判断主库客观下线“少数服从多数”

1.2 选主

步骤: “筛选” + “打分” 、 “一定的筛选条件”、“一定的打分规则”

  • “筛选”:筛选出从库状态良好的那些参与选举。筛选条件参考如下

    • 从库在线

    • 从库网络连接状态良好(需保证在一段时间内该从库与主库的网络断连次数在一定阈值内)

      可通过down-after-miliseconds设定主从库网络断连的最大连接超时时间

      例子:设置down-after-milliseconds * 10,则表示down-after-milliseconds 毫秒内,主从节点都没有通过网络联系上,认为主从节点断连。如果发生断连的次数超过了 10 次,就说明这个从库的网络状况不好,不适合作为新主库。

  • “打分”:依次比较从库的优先级、复制进度、ID号,选出最适合的

    • 从库优先级: 通过slave_priority设置, 优先级越高,得分越高,优先级最高且唯一的作为新主库。(若这一轮没有选举出来,则进行下一轮——从库复制进度的选举)

    • 从库复制进度:通过比较master_repl_offsetslave_repl_offset,选出与主库同步程度最接近的从库作为新主库。(若这一轮没有选举出来,则进行最后一轮——从库ID的选举)

    • 从库ID号:每个从库都有唯一的ID,在这一轮选取ID号最小的从库作为新主库

1.3 通知

新主库选举出来后,需要通知给其他从库:以后从新主库同步数据;通知给客户端:与新主库进行写操作

  • 通知给其他从库

    • 其他从库需要执行replicaof与新主库建立“主-从”关系并进行“数据同步”

  • 通知给客户端

Q&A

  1. 主从库切换的时间段内,客户端能否正常请求操作?

  2. 若想应用程序不感知服务中断,还需要哨兵或Client做什么?

图片来源于极客时间专栏《Redis核心技术与实战》

来源https://www.cnblogs.com/GuoYuying/p/15080861.html

文章分类
后端
版权声明:本站是系统测试站点,无实际运营。本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 XXXXXXo@163.com 举报,一经查实,本站将立刻删除。
相关推荐