Leonard
(Hacker Byb Hr4 Nu)
1
【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.1
【操作系统】centos7
【部署方式】docker 部署
【集群数据量】45g
【集群节点数】 3kv，3pd，3tidb，2ticdc
【问题复现路径】没做操作
【遇到的问题：问题现象及影响】
23:48分数据库延迟突然变高
查看监控，store4的cpu 突然变高
同时tikv trouble shooting中的serverbusy慢慢变高
running tasks也慢慢变高一直到8000停止
23:48分的tikv也开始有ERROR日志
检查：网络，磁盘，cpu，内存，均为到达瓶颈
【复制黏贴 ERROR 报错的日志】
[“cdc initialize fail: Request error message: "peer is not leader for region 3337, leader may None" not_leader { region_id: 3337 }”] [request_id=RequestId(19)] [conn_id=ConnId(1)] [region_id=3337] [thread_id=93]
【其他附件：截图/日志/监控】
这个kv已经缩掉了，在pd里面查不到了，为什么kv日志还在打
Leonard
(Hacker Byb Hr4 Nu)
2
最终，通过将store4的region leader驱逐后，将该kv重启。所有监控和日志恢复正常。
怀疑是v8.5.1的bug
重启kv之后，延迟恢复为正常
1 个赞
小龙虾爱大龙虾
(Minghao Ren)
4
先看 cpu 高的问题，掉 leader 可能是受 cpu 资源不足影响的
running task打高 基本都是unified read pool不够用的结果
lllzd
(时光旅行者)
7
检查监控指标（如 tikv_scheduler_processed_requests_total、tikv_scheduler_commands) 来确认当前负载情况，看看是不是写入或读取压力过大。
Leonard
(Hacker Byb Hr4 Nu)
8
不是的，上面已经说了，重启有问题的tikv之后，所有指标完全恢复正常
db_user
(Db User)
10
那台机器的dmesg信息有么，先排除下内存，cpu和磁盘的问题
Leonard
(Hacker Byb Hr4 Nu)
12
这个kv已经缩掉了，在pd里面查不到了，为什么kv日志还在打
db_user
(Db User)
14
登录到机器上，执行sudo dmesg -T,看下有没有对应内存之类的报错
kkpeter
(Upstream889)
15
这个有没有不重启的办法， 这个看起来应该还是个bug, 重启对集群还是会有短暂影响
这个问题解决了吗？ 遇到同样问题，报错 invalid store ID，一个不存在的store id，重启kv恢复正常，但是我这重复发生了
