TiKV节点突然Leader下降很多导致kv request请求变慢,进而影响到server节点查询的原因是什么?

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署(腾讯云云)
【集群数据量】 6.7TB
【集群节点数】5 server + 11 tikv
【问题复现路径】
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件:截图/日志/监控】

kv request 时间突然变得很慢

看到store8 的Leader突然下降很多

然后检查日志,在pd的日志中看到

[2025/11/11 16:14:48.981 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=153015267] [slow-stores="[8]"]
[2025/11/11 16:14:50.264 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=7] [slow-stores="[8]"]
[2025/11/11 16:14:50.524 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=4] [slow-stores="[8]"]
[2025/11/11 16:14:50.573 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=10] [slow-stores="[8]"]
[2025/11/11 16:14:50.691 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=9] [slow-stores="[8]"]
[2025/11/11 16:14:51.133 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=11] [slow-stores="[8]"]
[2025/11/11 16:14:51.314 +08:00] [INFO] [cluster.go:983] ["forcely awaken hibernated regions"] [store-id=6] [slow-stores="[8]"]

是因为store变成了 slow-store,然后把 该store的Leader给迁移到其他节点了。

那这里的store变成slow-store的根源是什么导致的,怎么排查呢?

存储异常了?

leader切了。

这个问题有点诡异啊。你本地盘性能下滑了?

怀疑是 Store 8 的磁盘 I/O 出现了严重瓶颈

检查一下磁盘I/O

存储空间是足够的,也没有收到相关报警

从监控看磁盘iops下降是结果,不是原因

出现问题之前,cpu iowait 开始有点高

没有看到pd leader切换的日志

建议排查磁盘I/O

这个应该可以先排查一下看看

嗯,目前看到是这个节点的磁盘iowait有点高, 读延迟那会增大了很多

而且系统盘和数据盘读延迟都很高。tikv节点是部署在系统盘的,所以服务的日志写入是系统盘,数据存储是独立的数据盘。

为啥是两个都高呢?

带宽流量也没有出现突增的情况

还有是检查 store8 节点上是否有其他进程占用了大量资源

嗯看到磁盘读延迟很高,但是系统盘和数据盘都很高

没有呢,除了虚拟机本身的进程外,就是tikv和自带的monitor了

会不会是网络问题,网络延迟或丢包也可能导致store被标记为slow,我们以前有过类似原因

应该不是呢,网络带宽什么都不高。目前没有内网延迟和丢包的监控。这个不好说
问题应该还是磁盘IO的问题

从云主机监控看到那个点 磁盘IO等待很长

看着是那个瞬间IO要长,楼上有个大佬,也是建议先排查IO,一般因为磁盘IO的概率要高

建议都搞数据盘里。

执行一个sql,trace一下看看慢到哪个部件了