疑似tikv卡住，语句执行时间变长

🪐 TiDB 技术问题
1

今天在某个tikv节点重启后，整个集群插入数据好像夯住了一样，最后重启所有的tikv才解决，请问有什么排查思路嘛，tikv的日志看了很多，也没有头绪啊
tikv 明显是有堆积任务的

每个tikv实例的cpu 内存 Io不是很高

2

有锁等待信息吗,或者详细的后台日志,单从提供的性能图来看,只能看到ops这块信息

3

dashboard监控当时tikv的指标有啥异常的吗

4

感觉可能是某种内部调度导致的

5

哪里确认是有堆积任务的？

6

通过 dashboard 或者 grafana 来看，不要单纯看日志

7
  1. 第一优先级：检查是否卡在 Import Mode。 查看 TiKV 日志中是否有关于 import mode 的提示, 确认集群是否处于导入模式，如果是，手动切换回 Normal 模式。这是最符合“资源低但写入卡”特征的。
  2. 第二优先级：检查 PD 的 Region 健康度。 使用 pd-ctl 查看是否有大量 pending-peer 或 down-peer 。
  3. 第三优先级：复查 TiKV 启动日志。 寻找 ingest failed 或 RocksDB 相关的 IO 错误，确认是否有文件缺失。
8

感觉是数据恢复catch-up速度过慢导致的。

9
  • 某 TiKV 重启后，leader 选举 /peer 补副本卡住 → 写入被阻塞（最常见）
  • RocksDB 写暂停（write stall）但日志不明显
  • TiKV 内部线程池堵死（scheduler/raftstore 线程满但 CPU 不高）
10

听着像是磁盘写满了。

11

重启的tikv节点有大量的leader 热点region，来回切换，大量超时重试堵塞。
只重启1个，追数据持续堵，全重启 数据差距小 leader分布均匀 没有单节点追赶压力 迅速恢复了。
重启前 检查regin分布，是否有大量热点。主动驱离leader

12

主动驱离的话是不是切换过程比较温和一点