down-peer-region-count和pending-peer-region-count很多如何排查处理

Meditator · 2021 年12 月 20 日 06:51

@spc_monkey 大佬帮看看

spc_monkey · 2021 年12 月 20 日 08:08

现在是啥问题，上面的问题还是开头说的 pending/down peer 的问题

spc_monkey · 2021 年12 月 20 日 08:09

感觉无论是哪个，好像是集群本身就有问题了，尤其是上面的 down/pengding，如果持续增加，还是怀疑有个 store 本身出问题了

haizi · 2021 年12 月 20 日 08:24

首先是有一个节点出现了pending/down peer的问题
然后我们就想着加一个节点，把有问题的这个节点给换下来。
先是扩容了一个新的节点，然后缩容了那个有问题的节点。大致的流程就是这样

spc_monkey · 2021 年12 月 20 日 09:05

新扩容 store 之后，down peer 和 pending 问题有缓解嘛（这个现象，建议用一个具体的 peer 来跟踪一下进行排查比较好：具体就是看pd leader 和 tikv 日志）

spc_monkey · 2021 年12 月 20 日 09:07

另外：开头问的是怎么确定 peer 属于哪个 table：利用 pd-ctl region /region check 命令，找到 region，然后 region regionid 应该就有 table id 等一些信息（忘记了，就算没有，也有相关系统表可以查）

haizi · 2021 年12 月 21 日 01:13

新扩容store之后，down peer 和 pending 还是在一直增加的，从information_schema.tikv_region_peers表里查出来，还是在有问题的那个store上一直在增加。

haizi · 2021 年12 月 21 日 01:17

现在我们想stop 那台有问题的store，如果直接执行 systemctl stop tikv-20160.service ，那么它上面的leader region会不会同步到其他store上去？会不会对数据有啥影响？比如丢数据之类的？

spc_monkey · 2021 年12 月 21 日 02:43

不会丢数据，可以在下线前，手动在要下线的 store 上添加一个 evict-leader 的调度：参考（https://docs.pingcap.com/zh/tidb/v5.2/pd-scheduling-best-practices/#启停调度器）

spc_monkey · 2021 年12 月 21 日 02:45

不过你不断增加，tikv 和 pd 日志没有异常？（你现在的状态可能只是端口起来服务了，但tikv 之间的网络，比较怀疑有问题，我觉得日志肯定有异常的，你只需要 pd-ctl store 命令找到 store，然后过滤 grep storeid pd.log或 tikv.log 应该能看出原因）

haizi · 2021 年12 月 21 日 03:02

[2021/12/21 09:08:36.316 +08:00] [INFO] [operator_controller.go:424] [“add operator”] [region-id=33132] [operator="“remove-orphan-peer {rm peer: store [3]} (kind:region, region:33132(418,23), createAt:2021-12-21 09:08:36.31680021 +0800 CST m=+10882612.174309628, startAt:0001-01-01 00:00:00 +0000 UTC, currentStep:0, steps:[remove peer on store 3])”"] [“additional info”=]
[2021/12/21 09:08:36.316 +08:00] [INFO] [operator_controller.go:620] [“send schedule command”] [region-id=33132] [step=“remove peer on store 3”] [source=create]
[2021/12/21 09:08:36.318 +08:00] [INFO] [cluster.go:551] [“region ConfVer changed”] [region-id=33132] [detail=“Remove peer:{id:1595158 store_id:3 is_learner:true }”] [old-confver=23] [new-confver=24]
[2021/12/21 09:08:36.319 +08:00] [INFO] [operator_controller.go:537] [“operator finish”] [region-id=33132] [takes=2.191023ms] [operator="“remove-orphan-peer {rm peer: store [3]} (kind:region, region:33132(418,23), createAt:2021-12-21 09:08:36.31680021 +0800 CST m=+10882612.174309628, startAt:2021-12-21 09:08:36.316831504 +0800 CST m=+10882612.174340925, currentStep:1, steps:[remove peer on store 3]) finished”"] [“additional info”=]
[2021/12/21 09:40:06.167 +08:00] [INFO] [operator_controller.go:537] [“operator finish”] [region-id=1405573] [takes=1.300592ms] [operator="“remove-orphan-peer {rm peer: store [1]} (kind:region, region:1405573(40465,137), createAt:2021-12-21 09:40:06.165774805 +0800 CST m=+10884502.023284223, startAt:2021-12-21 09:40:06.165803872 +0800 CST m=+10884502.023313295, currentStep:1, steps:[remove peer on store 1]) finished”"] [“additional info”=]
[2021/12/21 10:47:59.130 +08:00] [INFO] [operator_controller.go:424] [“add operator”] [region-id=33132] [operator="“replace-rule-offline-peer {mv peer: store [2] to [3]} (kind:region,replica, region:33132(418,24), createAt:2021-12-21 10:47:59.13004767 +0800 CST m=+10888574.987557092, startAt:0001-01-01 00:00:00 +0000 UTC, currentStep:0, steps:[add learner peer 1596345 on store 3, promote learner peer 1596345 on store 3 to voter, remove peer on store 2])”"] [“additional info”=]
[2021/12/21 10:47:59.130 +08:00] [INFO] [operator_controller.go:620] [“send schedule command”] [region-id=33132] [step=“add learner peer 1596345 on store 3”] [source=create]
[2021/12/21 10:47:59.131 +08:00] [INFO] [cluster.go:551] [“region ConfVer changed”] [region-id=33132] [detail=“Add peer:{id:1596345 store_id:3 is_learner:true }”] [old-confver=24] [new-confver=25]
[2021/12/21 10:47:59.131 +08:00] [INFO] [operator_controller.go:620] [“send schedule command”] [region-id=33132] [step=“add learner peer 1596345 on store 3”] [source=heartbeat]
…
[2021/12/21 10:57:54.926 +08:00] [INFO] [operator_controller.go:620] [“send schedule command”] [region-id=33132] [step=“add learner peer 1596345 on store 3”] [source=heartbeat]
[2021/12/21 10:58:00.242 +08:00] [INFO] [operator_controller.go:560] [“operator timeout”] [region-id=33132] [takes=10m1.112458294s] [operator="“replace-rule-offline-peer {mv peer: store [2] to [3]} (kind:region,replica, region:33132(418,24), createAt:2021-12-21 10:47:59.13004767 +0800 CST m=+10888574.987557092, startAt:2021-12-21 10:47:59.130113642 +0800 CST m=+10888574.987623063, currentStep:0, steps:[add learner peer 1596345 on store 3, promote learner peer 1596345 on store 3 to voter, remove peer on store 2]) timeout”"]

pd上有很多迁移peer超时的日志，像上面这种

haizi · 2021 年12 月 21 日 03:06

新增加的那个tikv节点上 tikv的日志里有这个警告。

spc_monkey · 2021 年12 月 21 日 07:23

可以往前面看看日志（或者直接重启 tikv，看看有啥报错，还是怀疑网络问题：除了ping，可以看看端口服务是否都ok）：调度超时，多是 tikv 侧出问题

haizi · 2021 年12 月 21 日 08:01

tikv节点全部重启过一次了，现在这台是下线状态的tikv节点上的leader region 每天也是在减少的。每天大概减少1000个leader。都迁移到另外的节点上去了。

网络都没问题的，端口也都是通的

spc_monkey · 2021 年12 月 21 日 08:05

要不提供一下 pd leader 和这个 store 的 tikv日志

haizi · 2021 年12 月 21 日 08:22

麻烦你往上翻，前面已经上传过了

spc_monkey · 2021 年12 月 21 日 09:21

1、你用 pd-ctl 的 store 命令，看看 store id 为 3 和为2 ，在 11-26 03:09：38 到 49 左右的日志，看看有无异常（2个 store 都要看）

spc_monkey · 2021 年12 月 21 日 09:23

2、需要你用 pd-ctl region checker 直接找到一个 down-peer 或 pending
-peer ，找到这个 region id，然后告诉我一下 region id 和 down/pending peer 的id（我要根据这个信息，看日志）

haizi · 2021 年12 月 21 日 10:02

3上的日志

2上的日志

spc_monkey · 2021 年12 月 21 日 10:29

问一下：1、咱们有没有开启 hibernate region 功能啊（上面的信息看起来问题不大，正常情况下也会有，如果数量太多，要考虑为啥会发起选举，得往上翻一下日志：拿一个具体的 region id 看就ok）