通过这几篇文章已解决，后续我会整理下这块的文档，感谢老师放假期间还在奋力支持，非常感谢
https://asktug.com/t/topic/36199
https://asktug.com/t/topic/34246
1 个赞
我们版本是5.0.3，3台tikv，当时的情况是这样的：
- tikv第一个节点宕机且无限重启，无限OOM，该节点不可用了，我们对他进行了正常的下线
2.下线持续了5-6个小时没任何动静且还处在offline状态，我们结合之前4.0.11版本的经验，就直接对他进行了–force强制下线
3.强制下线后，该节点被T出了拓扑图，但是pd的数据中还记录着该节点 store是 offline，当时我们就觉得有点不对经，我们之前4.0.11的经验是，可以直接–force下线，数据会清理干净，然后在本地直接重新扩容就可以的
4.我们重新在本节点扩容报错，报该store已经存在，我们就发现了这个4.0.x和5.0.x的不同之处，4.0是可以删除干净并直接重新扩容的，5.0 pd有残留数据，无奈之下我们只能在本节点换个端口重启tikv，然后我们等着副本同步和转移
5.补副本的过程持续了近一天，然后第二个tikv节点又宕机了，这时我们没有敢–force下线了，我们直接在本节点改端口重新扩容一个新的tikv，现在的情况就是2个挂掉的tikv，3台正常tikv
6.我们还是等着补副本的过程，但是写数据开始报错了，报Region is Unavaliable，tikv server timeout等错误，排查日志发现tikv一直在连接那两个挂掉的tikv
7.我们当时以为是没有补充完副本，我们怀疑pd调度有问题，有些region没有正常调度补副本，于是我们又重开了一台机器，4台tikv看pd能否恢复正常调度，然而并没有用
8.在本帖和相关老师沟通后，知道大致原因应该是3台tikv挂掉2台，有些region不满足多数副本导致不能被正常调度，解决办法是手动补副本
9.我们使用相关pd-ctl命令开始补副本，但是所有的操作都没有，从监控看add-remove peer等操作直接被skip了，我们觉得是3个副本挂掉2个，pd觉得该region不可用就不调度了，但实际上挂掉的两台机器上都是follower region，活着的一个region都是leader，按理说leader region存活应该是可以调度，这里应该是pd的一个bug
10.最后我们只能尝试tikv ctl的删除region的方式把那些不正常的region给删了，然后重启后，pd开始正常调度补副本了，后续补完副本集群恢复正常了
所以我们这里面有几个问题：
1.4.0.x和5.0.x的下线方式有点不一样，官网并未提及，4.0.x下线时可以直接–force强制下线的，即使默认副本设置的是3，强制下线是允许的，下线后副本为2，但是在5.0.x如果副本数>机器数是不允许下线的，导致该节点一致卡在offline状态，region无任何调度，而这个时候一旦强制下线了，真实数据被清理了，pd元数据却还在，后续就会有问题
2.pd调度有问题，当3个副本有2个宕机机，活着的一个即使是leader，机器数即使>=副本数，该region也不会被调度补充，除非停机，使用tikv ctl删除掉宕机的peer才可以。这应该是个pd的bug
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。