查询变卡，关掉其中一个tikv节点后恢复

zengchaojie · 2022 年7 月 25 日 13:09

【 TiDB 版本】5.4.1
【遇到的问题】中午15点左右，tidb查询突然变慢，dm也不同步，后面发现其中一个tikv节点cpu很高（一共7个tikv节点），停掉这个tikv节点后集群恢复正常。

anafin · 2022 年7 月 25 日 14:01

补充下：日志出现比较多 check leader rpc costs too long

songxuecheng · 2022 年7 月 26 日 00:41

1.完整的tikv监控发一下 2. 当时的热力图 3.tikv问题节点的日志

anafin · 2022 年7 月 26 日 01:50

tidb-app-TiKV-Details - Grafana.pdf (1.0 MB) 70kvlog.zip (1.7 MB)
分布是kv 监控及故障节点（192.168.10.70）的kv的日志文件（内容太多，已过滤掉INFO级别的日志）
故障持续时间：25日 15:00-17:27，期间做了一轮kv，tiflash，db节点重启均无效果，sql无论查询还是update都很慢（sql 的qps比正常期间少，因为已经转移走了一部分流量），17:27时stop 掉故障节点后机器sql处理恢复正常

anafin · 2022 年7 月 26 日 02:14

热力图哪里可以看到？

TiDBer_jYQINSnf · 2022 年7 月 26 日 02:51

看日志，很多key is locked，参考下面帖子吧。

zengchaojie · 2022 年7 月 26 日 04:13

tidb-app-TiKV-Details_2022-07-26T02_30_25.857Z.json (41.3 MB)
这是不可用那3个小时的tikv监控

anafin · 2022 年7 月 26 日 04:15

这个解析不通为什么stop 这个kv节点后就集群正常了；感觉这个不是根因。补充下信息：

这个节点的cpu配置比其他kv的更好，故障期间内存正常，磁盘容量不超60%、io使用率下降，io量下降，网络流量下降（我理解这些下降，因为流量下降），异常点：cpu使用率比其他正常的6个kv节点高很多；

TiDBer_jYQINSnf · 2022 年7 月 26 日 06:21

我看看下面导出的详细日志。

TiDBer_jYQINSnf · 2022 年7 月 26 日 07:06

看15点的时候，raft的write请求很高。写延迟也增加了。那会儿你们业务有什么变化？
还有机器的io情况有什么变化？
70这台机器的读请求也很高，不均衡。是不是有都热点。

zengchaojie · 2022 年7 月 26 日 07:32

业务没有什么变化，这是机器的监控Prometheus监控_2022-07-26T07_31_22.362Z.json (1.1 MB)

TiDBer_jYQINSnf · 2022 年7 月 26 日 09:43

看很多transport full
这个storeid是什么？tikv给他发消息总是发不过去。

TiDBer_jYQINSnf · 2022 年7 月 26 日 09:51

看了下上面，是53连不上了吧，看下53是什么情况？

songxuecheng · 2022 年7 月 26 日 10:41

检查一下这个store 1422582 看起来是有问题的。

避免向非健康状态的 TiKV 节点发送请求，以提升可用性。这个是5.4.2，可以适当升级
https://github.com/pingcap/tidb/issues/34906

zengchaojie · 2022 年7 月 26 日 10:52

应该是在手动重启

zengchaojie · 2022 年7 月 27 日 02:09

请问你和上面那个回复说的store_id要怎么查看

TiDBer_jYQINSnf · 2022 年7 月 27 日 02:50

pd-ctl store 这里面就有storeid对应的tikv是哪个。

zengchaojie · 2022 年7 月 27 日 02:54

找到这个表了，按照上面的回复，10.52和10.53都有问题？

TiDBer_jYQINSnf · 2022 年7 月 27 日 02:58

52\53 是tiflash吗？看起来是因为和他们发消息不通。至于是不是导致cpu骤增的原因，不确定。

zengchaojie · 2022 年7 月 27 日 03:01

52是tikv，53是tiflash