【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这种无中心的架构来说，如果拓扑信息不一致了，如何修复信息确实是挺麻烦的。想到好的方式后，后续补充。