leader region 分布不均匀排查

gzp1 · 2020 年5 月 6 日 07:10

单机单实例误用labels，如何去掉?

inventory.ini 配置

[tikv_servers]
TiKV1    ansible_host=xx.xx.xx.74
TiKV2    ansible_host=xx.xx.xx.75
TiKV3    ansible_host=xx.xx.xx.76
TiKV4    ansible_host=xx.xx.xx.77

tidb版本 v4.0-rc

去掉的原因：怀疑，会造成leader region 分布不均匀。在集群不重做的情况下，如何去掉？

yilong · 2020 年5 月 6 日 07:19

这个不是 labels，只是别名，没有影响，也不会造成 leader region 不均匀.
labels 指的是如下图
https://pingcap.com/docs-cn/v3.0/how-to/deploy/orchestrated/ansible/

image961×237 7.97 KB

gzp1 · 2020 年5 月 6 日 08:08

尴尬了，还以为是这个导致的…

从上图看，leader突然消失，看了log，也没有任何error…

yilong · 2020 年5 月 6 日 08:19

看起来这个tikv似乎down掉了，执行 dmesg 看下是不是 tikv进程异常重启了。可能是 OOM 之类的
也可以从 tikv.log 看下那个时间段有没有 Welcome 重启的关键字

gzp1 · 2020 年5 月 6 日 09:10

没有down啊，可以看到region数量还在上涨，只是没有了leader region
看了日志，该时间点没有welcome的重启日志。通过dmesg 也看了，没有OOM, tikv-server相关的信息，按理说mem 一直够用。dmesg -T | grep -i 'tikv-server' / dmesg -T | grep -i oom

gzp1 · 2020 年5 月 6 日 09:12

不过该tikv节点，一直刷这个日志，好几天了。

[2020/05/06 17:10:44.688 +08:00] [INFO] [region.rs:474] ["register deleting data in range"] [end_key=7A7480000000000000FF175F728000000000FF00F7990000000000FA] [start_key=7A7480000000000000FF1700000000000000F8] [region_id=287021]
[2020/05/06 17:10:45.208 +08:00] [WARN] [endpoint.rs:536] [error-response] [err="Region error (will back off and retry) message: \"region 287021 is missing\" region_not_found { region_id: 287021 }"]
[2020/05/06 17:10:45.439 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=RAFT] [peer_id=320776] [region_id=287021]
[2020/05/06 17:10:47.438 +08:00] [WARN] [endpoint.rs:536] [error-response] [err="Region error (will back off and retry) message: \"region 287021 is missing\" region_not_found { region_id: 287021 }"]
[2020/05/06 17:10:48.134 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=SPLIT_REGION_CHECK] [peer_id=320755] [region_id=320627]
[2020/05/06 17:10:48.134 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=RAFT_LOG_GC] [peer_id=320755] [region_id=320627]
[2020/05/06 17:10:49.434 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=RAFT_LOG_GC] [peer_id=320776] [region_id=287021]
[2020/05/06 17:10:49.434 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=SPLIT_REGION_CHECK] [peer_id=320776] [region_id=287021]
[2020/05/06 17:11:01.239 +08:00] [INFO] [raft.rs:997] ["[logterm: 354, index: 1958147, vote: 320424] ignored vote from 320420 [logterm: 354, index: 1958147]: lease is not expired"] ["msg type"=MsgRequestPreVote] ["remaining ticks"=9] [term=354] [msg_index=1958147] [msg_term=354] [from=320420] [vote=320424] [log_index=1958147] [log_term=354] [raft_id=320252] [region_id=208574]
[2020/05/06 17:11:03.236 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=PD_HEARTBEAT] [peer_id=320755] [region_id=320627]
[2020/05/06 17:11:08.441 +08:00] [INFO] [peer.rs:714] ["failed to schedule peer tick"] [err="sending on a disconnected channel"] [tick=PD_HEARTBEAT] [peer_id=320776] [region_id=287021]

不能从其他节点上调度leader region ?

yilong · 2020 年5 月 6 日 10:10

麻烦上传此 tikv.log 日志，包含问题出现时间段前后1小时，多谢。
报错看起来是找不到要删除的region，能否找一下，这个region 287021 的其他日志，麻烦上传，多谢。

gzp1 · 2020 年5 月 6 日 10:55

我打算直接重启下该节点，试一下

看之前的提问：TiKV个别节点leader region数目为0

4月30号从tidb v3.0.9 -> v4.0-rc版本。和他的情况很类似。

话说，咋删除调度器啊，你们文档好像没给…

yilong · 2020 年5 月 6 日 11:37

参考此文章，pd-ctl 支持动态创建和删除 Scheduler，你可以通过这些操作来控制 PD 的调度行为

https://pingcap.com/docs-cn/v3.0/reference/best-practices/pd-scheduling/#启停调度器

先查看当前的store 状态， pd-ctl 命令行执行store，查看当前store 状态。方便的话，还是反馈下tikv.log日志，多谢

gzp1 · 2020 年5 月 7 日 00:51

pd-ctl store命令没啥，节点是up，就leader count、 leader_score 、leader_size 数是0

pd-ctl发现：

» scheduler show
[
  "balance-leader-scheduler",
  "balance-region-scheduler",
  "evict-leader-scheduler",
  "label-scheduler",
  "balance-hot-region-scheduler"
]

有evict-leader-*存在，但和官方文档描述有出入，不是evict-leader-{store-id}。

还是删掉了： scheduler remove evict-leader-scheduler

此时 store后，该节点leader相关一切正常，各节点leader数平衡了，只花了不到1min。

gzp1 · 2020 年5 月 7 日 00:52

事故原因我觉得还要排查下，

执行滚动升级，evict-leader-scheduler 不能正常移除？

lemontree8801 · 2020 年5 月 7 日 01:27

应该是滚动升级的时候，加了驱逐leader策略然后升级完成后，没有把这个策略删除把。。以前从2.0.13升级到3.0.3的时候也遇到过这个问题。

来了老弟 · 2020 年5 月 7 日 02:52

目前有两种情况会加上这个调度：

1、rolling update 时候自动添加，正常是升级完一个 tikv 之后自动再删除掉这个调度；如果中途出现了报错，就会有 evict 调度遗留。ps：如果重新 rolling update 成功，最终也会删掉。

2、人为通过 pd-ctl 添加 evict 调度

不知道目前 tidb 是否满足以上情况，

system · 2022 年10 月 31 日 19:06

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。

leader region 分布不均匀 排查

leader region 分布不均匀排查