大量的truncate table和update tiflash replica status任务

wakaka · 2022 年8 月 8 日 12:57

【 TiDB 使用环境`】生产环境
【 TiDB 版本】 5.0.6
【遇到的问题】突然出现大量的DDL任务卡住，包括truncate和update tiflash replica status
【复现路径】

【问题现象及影响】
看见一直堆积truncate任务和update tiflash replica status ，并且只有这两个，没有alter之类的，一瞬时执行的admin show ddl jobs有600多个。
不知道是为什么原因会堵塞，按道理truncate会很快？

【附件】相关日志及监控（https://metricstool.pingcap.com/)

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

h5n1 · 2022 年8 月 8 日 23:53

admin show ddl jobs列下

wakaka · 2022 年8 月 9 日 03:38

就是看着有几百个，如下所示，这是前几天出现过一次类似的

Min_Chen · 2022 年8 月 12 日 03:06

DDL 大面积卡住。
麻烦执行 ADMIN SHOW DDL; 查看 DDL owner 是哪个。

wakaka · 2022 年8 月 12 日 09:34

就是一个tidb节点，那台节点cpu、内存等监控都是正常范围内

wish-PingCAP · 2022 年8 月 15 日 08:04

Hi，

增加 TiFlash 副本后，TiDB 内部会持续发起 update tiflash replica status 的 DDL，用于更新 tiflash replica 同步进度。该 DDL 执行速度很快。从图中看，由于 TiDB 的 DDL 是按队列依次执行的，因此它其实是被表中第二行 DDL truncate table（job id = 8988326）阻塞了。建议通过日志排查该 truncate table DDL 阻塞的原因。

wakaka · 2022 年8 月 16 日 00:40

也是truncate语句，不太清楚为啥会执行慢。正常应该很快的

alfred · 2022 年8 月 17 日 15:15

如果truncate的数据量较大，也会慢

wakaka · 2022 年8 月 18 日 01:47

truncate正常不会慢的数据量大也不会吧

wish-PingCAP · 2022 年8 月 19 日 04:30

已在这个帖子中回复，请看一下是否可以解决问题~

system · 2022 年10 月 18 日 04:30

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。