case study两个redis cluster集群拓扑混掉故障处理

Posted 小树桩的朋友

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了case study两个redis cluster集群拓扑混掉故障处理相关的知识,希望对你有一定的参考价值。

【背景】

        XXX服务,前后使用了两个redis cluster集群:集群A(2018.1.23前使用,在1.23之后没有流量,但是服务没停),集群B(2018.1.23后使用)。

 

【原因】

        根本原因:两个集群使用相同的实例,导致两个集群的拓扑信息互相伤害拓扑乱掉

        诱因:老集群下线流程有误,服务未停,却把记录服务实例信息的db数据删除了

        恢复缓慢原因:缺少处理cluster的工具&经验,临时写脚本处理   

 

【过程】

        1、给集群B增加新的redis实例(其中选出了和集群A相同的ip和port)

        2、启动集群B的新实例失败,发现和集群B的某个实例相同的ip和port

        3、停掉集群A的具有相同ip和port的实例,集群A的相应实例起来(目前集群B还未将该实例加入自己集群,该实例目前与集群A的其他实例通信)

        4、对集群B操作同步拓扑信息(将上诉实例加入了集群B,上诉实例与集群B中的其他实例相互交换拓扑信息)

        5、集群B中的主都把自己作为了集群A中实例的从,开始主从同步,集群崩溃

 

【处理过程】

        1、停掉集群A的所有实例

        2、强制提升集群B中的相应实例为主(cluster failover takeover -> 将某个从强制提升为主且不与其他实例通信)

        3、修复拓扑状态,检查slot分配,给没有分配master的slot分配master(cluster setslot <slot> node <node-id> -> 发给每个主分配slot信息)

        4、给缺少slave的master挂上slave(cluster replicate ip port)

 

【改进方案】

        1、完善集群下线流程:1)避免删除集群基本信息;2)下线集群时停掉服务(停服务发现、检查流量、停服务、注销systemd)

        2、针对cluster的拓扑修复,提供工具:1)集群拓扑比较工具,找出拓扑不一致的实例;2)批量将实例踢出集群;3)批量提升实例为主??

 

【思考】

        对于redis cluster这种无中心的架构来说,如果拓扑信息不一致了,如何修复信息确实是挺麻烦的。想到好的方式后,后续补充。

 

以上是关于case study两个redis cluster集群拓扑混掉故障处理的主要内容,如果未能解决你的问题,请参考以下文章

多标签分类问题 [case study]

Redis(1.11)Redis cluster 分布式集群搭建

MIS501 Case Study

journal / case study网站推荐

redis源码分析--cluster消息

redis cluster 一直在等待 Waiting for the cluster to join