TiKV宕机无限OOM起不来，如何正确恢复

spc_monkey · 2021 年9 月 30 日 07:56

重启一下吧，先看看结果

Lawrence · 2021 年9 月 30 日 07:56

我还没重启呢，就显示这个了，但实际是up状态的

spc_monkey · 2021 年9 月 30 日 07:57

只重启tidbServer

Lawrence · 2021 年9 月 30 日 07:58

嗯嗯，感觉这个错误应该是tikv直接拒绝了pd的通信了都。。。

spc_monkey · 2021 年9 月 30 日 07:59

先不管这个，一会我再解释

Lawrence · 2021 年9 月 30 日 08:00

3个tidb都重启了，接下来怎么操作

spc_monkey · 2021 年9 月 30 日 08:00

看看业务OK了不，就用刚才报错的语句验证就行

Lawrence · 2021 年9 月 30 日 08:03

spc_monkey · 2021 年9 月 30 日 08:05

还不行？看tidb日志，找到reggon id，然后pdctl reggon命令，考虑这个region 的状态

Lawrence · 2021 年9 月 30 日 08:07

看日志他是去一个offline节点取了啊。。怪不得不可用，可是为啥呢，都offline了，为啥还会分配过去呢、。、

spc_monkey · 2021 年9 月 30 日 08:10

如果region 少，先手动transfer leader 一下，多的话，用改变 store状态的命令把这个store状态变成tombstone状态

spc_monkey · 2021 年9 月 30 日 08:11

命令asktug 搜一下，或官网搜 curl Tombstnoe

Lawrence · 2021 年9 月 30 日 08:11

region不少，改变tombstone的在5.0.3应该已经不可用了，我试过了

Lawrence · 2021 年9 月 30 日 08:12

spc_monkey · 2021 年9 月 30 日 08:12

你的store没有tombstone状态啊，是offline状态，offjine状态的是可以提供服务的

Lawrence · 2021 年9 月 30 日 08:14

那如何变为tombstone呢，那个curl是不管用的，pd中27的脏数据我一直想删删不掉

spc_monkey · 2021 年9 月 30 日 08:15

把这个tikv先关掉进程，再Curl试试呢

Lawrence · 2021 年9 月 30 日 08:17

27的20160早没了。。集群拓扑里都没这个节点了，是之前 --force强制下线的

spc_monkey · 2021 年9 月 30 日 08:18

如果不行，就是用脚本先手动切换一下leader，现在是业务可用第一，办法啥都行

Lawrence · 2021 年9 月 30 日 08:19

这个去读27:20160，关键是这个节点没leader啊。。