虽然看起来没什么直接关系，但是既然 M 实例存在这个锁的问题，那还是得分析下是什么导致的锁。
这个是可以复现的是吧？可以看看出现 wait 的时候是否有一些事务没有提交，或者是否存在死锁的情况。
2 年前
DM 之前就包含了 M datasource1，一个 S datasource2 数据源是吧？现在增加了一个 datasource2 为数据源的 task1 是吗？
2 年前
是否可以按照下面的方法导出一下文件：
https://docs.pingcap.com/zh/tidb/v5.3/sql-plan-replayer
2 年前
你好，经过确认，可以删除。
总结一下：
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…
2 年前
麻烦查看下 new_collations_enabled_on_first_bootstrap 参数值是不是设置为true了？
2 年前
你的统计信息导入时候有异常：ERROR 1406 (22001): Data Too Long, field len 15, data len 16
请问你的TiDB 版本是 v5.3.0 是吧？是否从其它版本升级过来的呢？
2 年前
麻烦导出一下 tbl_order_detail 表的统计信息：
curl http://tidb_ip:status_port/stats/dump/db_name/table_name >table_name.json
2 年前
监控数据导出可以按照：https://metricstool.pingcap.com/#backup-with-dev-tools 的指引导出。
2 年前
1、请问下，TiCDC的下游是什么呢？
2、麻烦提供下TiCDC 的监控：https://metricstool.pingcap.com/#backup-with-dev-tools
2 年前
1、v3.0 时候只要 hash 冲突就会卡住，所以就换成了冲突后继续判断的做法。做了这个改变后，测试下来发现继续判断实际冲突的消耗很小，就顺便把 scheduler-concurrency 调低了来降低内存开销。
2、v4.0 latch 实现方式变化了。如果 hash 冲突，会去实际检查冲突的 key 是否相等，不会误判等待。
2 年前
1、你好，这个测试是可复现的吗？
2、如果可复现，麻烦提供跑q5 过程中的 TiFlash的日志和TiFlash的监控。https://metricstool.pingcap.com/#backup-with-dev-tools
2 年前
没有更多内容了