可以查看 task1 的状态里面的source 地址确认一下是M 还是 S ？

虽然看起来没什么直接关系，但是既然 M 实例存在这个锁的问题，那还是得分析下是什么导致的锁。 这个是可以复现的是吧？可以看看出现 wait 的时候是否有一些事务没有提交，或者是否存在死锁的情况。

DM 之前就包含了 M datasource1，一个 S datasource2 数据源是吧？现在增加了一个 datasource2 为数据源的 task1 是吗？

当前 M 库

可以看看当前数据库是否存在其它 lock 信息导致无法获取到全局读锁。

是否可以按照下面的方法导出一下文件： https://docs.pingcap.com/zh/tidb/v5.3/sql-plan-replayer

你好，经过确认，可以删除。 总结一下： 1、在 v5.0.3 之前 TiCDC 的临时排序文件夹参数是：sorter.sort-dir 2、 v5.0.3 之后 TiCDC 的临时排序文件夹参数是：data-dir，可参考：https://docs.pingcap.com/zh/tidb/stable/ticdc-overview#sort-dir-及-data-dir-配置项的兼容性说明 3、用户从其它版本升级到了v5.0.3，data-dir 设置为 data，是个相对路径，所以存储在了 cdc binary 目录下，里面tmp文件的大小为92G。如果没有设置默认是 /tmp/cd…

麻烦确认一下 cdc binary 所在的目录下面有没有 data 目录

麻烦确认下，这个集群是否从其它的版本升级到v5.0.3 的呢？

麻烦查看下 new_collations_enabled_on_first_bootstrap 参数值是不是设置为true了？

你的统计信息导入时候有异常：ERROR 1406 (22001): Data Too Long, field len 15, data len 16 请问你的TiDB 版本是 v5.3.0 是吧？是否从其它版本升级过来的呢？

可以尝试把 tidb_distsql_scan_concurrency 设置为1测试下。

麻烦导出一下 tbl_order_detail 表的统计信息： curl http://tidb_ip:status_port/stats/dump/db_name/table_name >table_name.json

监控数据导出可以按照：https://metricstool.pingcap.com/#backup-with-dev-tools 的指引导出。

该问题应该是个开发相关的问题，欢迎把问题发到开发者社区，和开发者们一起交流吧！

1、请问下，TiCDC的下游是什么呢？ 2、麻烦提供下TiCDC 的监控：https://metricstool.pingcap.com/#backup-with-dev-tools

1、v3.0 时候只要 hash 冲突就会卡住，所以就换成了冲突后继续判断的做法。做了这个改变后，测试下来发现继续判断实际冲突的消耗很小，就顺便把 scheduler-concurrency 调低了来降低内存开销。 2、v4.0 latch 实现方式变化了。如果 hash 冲突，会去实际检查冲突的 key 是否相等，不会误判等待。

1、你好，这个测试是可复现的吗？ 2、如果可复现，麻烦提供跑q5 过程中的 TiFlash的日志和TiFlash的监控。https://metricstool.pingcap.com/#backup-with-dev-tools

该问题应该是个开发相关的问题，欢迎把问题发到开发者社区，和开发者们一起交流吧！