Redis Cluster迁移目标节点宕机下填坑

转载自 听滴滴大神讲解redis cluster数据迁移遇到的坑

问题背景

应@冬洪兄邀请，让我把最近在处理Redis Cluster中遇到的坑分享下，由于个人时间问题，大致整理了一个比较大，比较坑的问题，它可能会导致集群部分slot不可用，甚至需要重建集群。如果对redis
cluster不了解的可以查看redis原理分享。
架构图如下



模拟迁移数据目标节点宕机场景 集群节点及槽部署信息cluster
nodes



1. 迁移8000实例的数据到8001实例

2.此时kill掉8001实例模拟目标节点宕机



3.连接8000实例查看cluster nodes发现8001实例已经fail，但是还负责槽166-234



4.连接8002端口查看cluster nodes发现8001实例已经fail，但是还负责槽166-234



5.连接8003端口查看cluster nodes发现8001实例已经fail，但是还负责槽166-234



6. 连接8004端口查看cluster nodes发现8001实例已经fail，但是还负责槽166-234



7. 连接8006端口(8001的slave升级为master)cluster nodes发现8001实例已经fail，但是槽166-234，在8000实例(源节点上)
问题

8000实例迁移数据到8001实例

kill掉8001实例(目标节点)

发现8001机器从ok->fail, 但是仍然负责一部分槽号166-234

新的slave(8006)正常升级为master

案例分析

8000实例：认为槽166-234在8001实例上

8002实例：认为槽166-234在8001实例上

8003实例：认为槽166-234在8001实例上

8004实例：认为槽166-234在8001实例上

8005实例：认为槽166-234在8001实例上

8006实例：认为槽166-234在8000实例上

说明：

只有宕机的8001实例的slave8006升级为master之后，认为槽166-234在(8000实例)源节点上，其他的master节点均认为该槽166-234在(8001实例)目标节点上。
修复步骤

1.此时通过redis-trib.rbfix 127.0.0.1:8002，不成功，报错如下



2.在8001实例(源节点)上强制把166-234指向自己，并且让大家强制同意

cluster setslot 166 node4ce27a0b8359a894c0ee6d2d6899df80d0910a75

cluster setslot 234 node4ce27a0b8359a894c0ee6d2d6899df80d0910a75

cluster bumpepoch



3.redis-trib.rb check集群



源码分析跟踪

1. 植入日志打印slot->nodeid信息cluster.c clusterUpdateSlotsConfWith函数



2.查询部署的clusternodes(此时，已经模拟完迁移的时候，目标节点宕机)

3.分析8000实例日志信息142槽

4.分析8002实例日志信息142槽

5.分析8003实例日志信息142槽

6.分析8004实例日志信息142槽

7.分析8005实例日志信息142槽

8.分析8006实例日志信息142槽

9.分析8007实例日志信息142槽

10.分析8008实例 日志信息142槽

11.分析8009实例 日志信息142槽

说明：

迁移完的槽142， 除了8006实例(8001实例的slave升级为master的实例)，其他所有的master节点都认为8001实例目标节点。

所有的slave节点和新的master实例8006都认为槽142在8000实例源节点。
总结

由于迁移速度比较快，虽然迁移完毕了，但是也需要一段时间同步给其他节点。而这个信息靠新的owner来同步，此时还没来得及gossip消息传播。有可能迁移结束了, 但是这个槽信息同步到了除了slave的所有节点上面。总体来说redis cluster问题还是不少的。

在扩容的时候也遇到过脑裂的请情况，投票各自占一半的情况，最后也是通过手动强制指定slot来修复的。还有更多小问题就不细说了。