【 TiDB 使用环境`】生产环境
【 TiDB 版本】v5.1.2
【 DM 版本】v5.3.0
【遇到的问题】 通过DM采集mysql数据到TiDB。最近总是卡住，不报异常，就是一直卡住
这个问题，最近几天经常出行，每次出现后，都是采用将TiDB中的数据库删除，之后再重新采集start-task --remove-meta
问题：
1、如何知道现在正在执行什么语句？
2、如何避免这种情况？
现在的同步基本不能用了，这是生产环境，请老师给予帮助
DM日志：
dm-worker_stderr.log (1.1 MB) dm-worker_stdout.log (351.1 KB)
检查是否有ddl执行
你好，请问如何判断是否有ddl执行？
查看正在执行的ddl
admin show ddl jobs;
admin show ddl;
看日志是频繁断开啊，建议检查下网路，是不是有超时什么的
目前TiDB使用的非常频繁，有些作业在不断的整理数据，将表进行删除再创建、导入数据。但这部分都是其他的schema，不是同步mysql的schema。当然查询的也很多。
现在卡的时间一直在增长，和上面截图当中比，一直在增长，这次的现场保留了，没有进行重新采集。
有什么命令能知道卡在哪里了么？
不是还有个dm-worker.log的问题吗？拎出来瞅瞅
FYI：https://github.com/pingcap/tiflow/issues/4317
从 stderr 看跟这个 issue 比较相似（不过修复之后不会再 panic 了），原因就是执行 SQL 的时间太长了，从 log 也可以看出有很多 timeout。猜测是下游的工作负载比较大，影响了迁移执行 SQL 的效率。
@Hacker007 @buchuitoudegou 感谢二位的回复！
昨天发现同一个数据源当中，针对同一个mysql源，到TiDB当中有两个task，分析到两个库，可能是相互之间有影响了。
现在调整为：新建了一个相同的数据源，之后将其中一个task迁移到新的数据源当中。
结果：今天观察了一天，现在没有发现卡住的问题，我们后期再观察一下
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。
