tikv 节点异常下线，强制删除节点导致无法自动补充peers

🪐 TiDB 技术问题
,
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】 v4.0.0-rc
【复现路径】

  1. 起因是集群中其中一个tikv节点的磁盘故障，故障的tikv节点id为 84033989
  2. 尝试删除故障节点，pd-ctl 执行store delete 84033989， 节点状态变为 offline
  3. 其他kv节点日志一直报错

[ERROR] [transport.rs:163] [“send raft msg err”] [err=“Other("[src/server/raft_client.rs:208]: RaftClient send fail")”]

  1. 执行 curl -X POST http://xxx:2379/pd/api/v1/store/84033989/state?state=Tombstone 以及 tiup ctl pd --pd http://xxx:2379 store delete 84033989 尝试删除 尝试将故障节点强制下线。修改成功后tiup display集群显示已无上述kv节点
  2. 查看发现仍然有大量的 pending-peer 和 down-peer ，其他kv节点日志中一直报错

[ERROR] [util.rs:356] [“request failed”] [err=“Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some("invalid store ID 84033989, not found") }))”]

【遇到的问题：问题现象及影响】

  1. 目前集群还能正常使用，但其他kv节点一直在报错找不到已被删除的 store id
  2. 主要问题是异常节点的 pending-peers 和 down-peers 数量一直不变，集群没办法自动补充新的peer
  3. 现在该如何操作能使得故障节点的 down-peers 能在其他正常kv节点上面补全

image
image1422×770 56.7 KB

2

看下 PD 监控，看下调度生成情况，还有 checker 工作情况

3

你一共有几个tikv节点，三个的话，先扩容一个再说

4

kv 节点非常多，可以先不扩。主要是现在坏掉的store里面那一堆peer都没了，一直处于down-peers状态。pd里面已经把这个store给delete掉了，但其他kv一直还在报连不上这个故障节点

image
image894×548 110 KB

5

enable-remove-down-replica 用于开启自动删除 DownReplica 的特性。当设置为 false 时，PD 不会自动清理宕机状态的副本。

  • enable-replace-offline-replica 用于开启迁移 OfflineReplica 的特性。当设置为 false 时，PD 不会迁移下线状态的副本。
  • enable-make-up-replica 用于开启补充副本的特性。当设置为 false 时，PD 不会为副本数不足的 Region 补充副本。
    https://docs.pingcap.com/zh/tidb/stable/pd-control

检查检查这几个配置

1 个赞
6

pd-ctl store 84033989 这个还能看到吗，目前是什么状态？你强制设置tombstone了 试试
pd-ctl -u http://pd_ip:2379 store remove-tombstone
或 curl -X DELETE pd-addr:port/pd/api/v1/stores/remove-tombstone

1 个赞
7

就是强制设置了Tomstone，设置成功后pd store 里面 和 tiup display cluster 都看不到这个kv和store了。但就是down-peers和 pending-peers还在，而且没有补充新的peer
store 已经查不到了：

image
image911×64 4.63 KB

8

查了是开着的

image
image1030×56 8.56 KB

9

这个感觉不是查不到了 是报错了，你看pd-ctl region store 84033989 可以查到这个store上的region信息吗？目前想到的1、按上面的清理下tombstone 信息 2、针对store 84033989上的region 通过pd-ctl operator add remove-peer的方式手工添加调度
image

10

  1. store remove-tombstone 这个已经执行过了，可能由于pd store里面已经没有这个store了，执行成功但没什么反应

    image
    image956×138 20.7 KB

  2. region store 是有的： 大致跟down-peers 查出来的数量一致，非常多

    image
    image999×903 29.1 KB

11

还有个 enable-remove-down-replica 这个选项。
检查下都开着的话，pd应该自己就能把这个活干了。
如果都开着还不行，pd的日志级别调整成debug，看看pd为什么不能正确处理。

12

可以参考下面脚本，手工做下调度：

 store_list='xxx'
 for i in $store_list
 do
    for j in `pd-ctl region store "$i" | jq ".regions[] | {id: .id}"|grep id|awk '{print $2}'`
     do
        pd-ctl operator add remove-peer $j $i
     done
   pd-ctl store $i
 done
13

好的，我尝试一下。 其实我已经在check down-peer 里面生成了类似语句，但还没执行，我试试你的脚本看看是否出来的结果一致

tiup ctl pd --pd http://192.168.100.151:2379 region check down-peer |grep -B 1 "start_key" |grep '"id":'|awk '{print "tiup ctl pd --pd http://192.168.100.151:2379 operator add remove-peer "$NF" 1"}'|sed s/,//g

image

14

都是开着的，我想大概是我某些操作顺序不当导致出现的这种情况

image
image1224×67 11 KB

还有就是这个集群版本确实比较旧了，之前没出问题就一直没去动它

15

如果你就坏了一个节点，你这个操作没什么问题，尽快修复吧，否则再坏一个就不能提供服务了。至于是用h5n1大神的手动修复还是看看pd抽什么风，都可以，尽快修复是王道。我是感觉最好看看pd为什么不能自动修复这种情况，把问题解决下，否则未来再有副本的丢失的话，pd不能自己干活，纯靠人工无法做到7x24。

16

缩容tikv建议使用官方提供的步骤；
参考下这篇文章，看看能不能修复：专栏 - TiKV缩容下线异常处理的三板斧 | TiDB 社区

1 个赞
17

这样的话，感觉还真是你的pd是有点问题的，没有自动补充region的副本到其他节点。。。应该是版本太老的问题

18

好的，我这边今天操作一下。如果有其他问题再来请教各位

19

目前已经在执行remove-peer中，请问remove掉坏的peer之后，集群会自动补全peer吗。目前我找了一个region看是剩下2个peer的
{
“id”: 23,
“start_key”: “7480000000000000FF0900000000000000F8”,
“end_key”: “7480000000000000FF0B00000000000000F8”,
“epoch”: {
“conf_ver”: 1470,
“version”: 5
},
“peers”: [
{
“id”: 297349803,
“store_id”: 5278949
},
{
“id”: 298501324,
“store_id”: 203515481
}
],
“leader”: {
“id”: 298501324,
“store_id”: 203515481
},
“written_bytes”: 0,
“read_bytes”: 538,
“written_keys”: 0,
“read_keys”: 4,
“approximate_size”: 1,
“approximate_keys”: 0
},

20

得补，你这个pd肯定是有问题了，不能自动修复问题。