某台机器上 TIKV 节点 突然Leader数量跌为0

【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0.12
【复现路径】针对一张有10个索引的表,进行数据删除
【遇到的问题:问题现象及影响】
环境:其中tidb 集群有6个KV节点,分布在3台机器,每个机器上有两个KV进程。
问题:KV 的三台机器分别为xxx.xxx.xxx.10,xxx.xxx.xxx.16,xxx.xxx.xxx.17。其中xxx.xxx.xxx.17和 xxx.xxx.xxx.10 ,频繁出现Leader 数量 跌为0,之后立马又开始balance leader,恢复到平衡状态。 其中,跌为0,为该机器上的两个实例一起出现该现象。

跌为0的时候到执行balance 的时候,存在一段时间数据盘 IO util 非常高,然后恢复正常。

没有删除数据的时候,不会出现Leader跌0 的状态。

查看出问题点的Leader跌0 的 TIKV 的日志,有出现比较多的
[2022/11/23 21:20:04.988 +08:00] [WARN] [store.rs:645] [“[store 33447] handle 971 pending peers include 917 ready, 1558 entries, 6144 messages and 0 snapshots”] [takes=39049]

有怀疑过机器的问题,但是查询硬件的磁盘均没有出现任何报错,而且两台机器交替出现比较奇怪。

监控信息 Clinic Service

【资源配置】
【附件:截图/日志/监控】

上述截图中间的图,交替数量变换,是在reload tikv 节点,可以忽略,观察左右的三个leader 跌0 的时间

6个KV节点,分布在3台机器,每个机器上有两个KV进程

  1. 磁盘的性能是否无法撑住 两个 KV的实例?

  2. 网络是否有被打满的情况?(导致心跳无法有效传递)

你好

  1. leader 没跌0 的时候,IO 使用率在60%,使用率不高。
  2. 网卡为万兆Bond,我看网卡流量也才39MB,远没达到瓶颈 。

可以看下是不是store的score是不是100,貌似慢节点达到100,上边所有的leader都会被驱逐


感觉这里描述的场景,比较贴合你的描述

不过看描述应该只有一个慢节点时候,才会触发leader被驱逐的情况,你这里是两个节点同时被驱逐了,理论上不会被驱逐leader的。


额,忽略吧,没注意你的版本是4.X的。。。

嗯,感谢,如果是scheduler的话,应该是慢慢驱逐,表现是一下子跌0,很像机器坏的,但是机器层面又没有相关的异常,就奇怪

tikv 有重启的现象吗

没有出现,一直是正常运行

亲有啥发现么

clinic 地址 : Clinic Service

这个问题是gc导致的,gc的时候reslove lock ,会导致某些节点压力太大,导致假死,然后pd会立刻驱逐leader,然后节点之后恢复,pd又重新reblance-leader 导致这样的场景。

你可以看一下你的leader下掉的时间点和
tikv details监控里面 - GC里面 - reslovedlocks是否一致。
然后我猜测应该是一致的 ,然后你可以看到当时的io,GC scan_lock会导致io打满之类的问题。

image
你需要给帮忙解决问题的小伙伴,授权,他们才能看

嗯,看着像是删除速度太快,GC 压力大,GC 的线程 一直100% 了

1 个赞