我看正常能检出的时候也是报这个，worker log在check的时候没有任何日志
是我的文件有问题吗
check-task 是 master 在做，worker 没有 log 正常。或者您试一下增加一下 dumpers 设置里的 thread 数量试试？因为表结构的检查是并行的，并行度取决于这个配置。
mydumpers:
global:
- threads: 16
FYI: https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full
不过表这么少感觉不像是 DM 并行度低的问题。也许跟上游执行 SQL 语句的速度有关系
改了还是不行，应该不是这个问题
表太少了，跟并发度确实不会有很大关系…不过这里的 log 太少了，也不太好定位问题呢
我先去建个 issue 吧，这里可能需要更多的 log 才能排查（个人觉得是 SQL 执行的速度问题？）
如果是这样的话，减少表试试。估计是实际环境的处理能力限制了吞吐。
确实日志有点少，打印一行检查开始，然后就一直要到检查结束有个时长，具体执行的sql是什么呀，如果是sql应该也不会这么慢呀，只有几张表的时候就很快，多一点表就突然假死了
尝试帮您复现了一下：https://github.com/pingcap/tiflow/issues/5759 ，有兴趣的话您可以点进来看看具体原因
现有版本应该有一些问题。您可以检查一下：
- dumper threads 是否足够大
- 所有表的结构都满足约束（比如，TiDB 支持的 charset 和 collation，primary key 等）
如果实在绕不过去，也只能 ignore 掉这个检查项了
我就是一次录了很多表，想让检查一下看看哪些表不满足，然后我去数据库处理下，或者单独dump
是的，不应该被卡住，所以是个 bug
分批量来 check 一下吧，check 完之后再把约束改好。
因为我们好多表都是从hive同步到的之前的mysql，一般只有hive的分区字段设置了一个普通索引（大部分表数据量不大），想问一下如果没有主键和唯一键是否可以绕过（全都改也挺麻烦的），如果绕过了会影响数据一致性吗
1）所谓的卡住是在什么阶段？
2）刚启动就卡住，那就是全量阶段？
3）如果表没有PK或者UK，启动任务的时候有warning的，这些表的同步就可能忽略？
4）如果是全量阶段卡住，是dm在校验表结构是否满足同步条件？上游mysql 有在执行什么语句吗？
1、执行check-task一开始，感觉就是1s后就不再有上游mysql查询行为，可以看我上面发的mysql的历史纪录，只有第一秒有查询表结构，后面就没有了；
2、是否可以让表没有PK或者UK也能同步，我们的这种报表数据很多都只有一个日期索引
现在的dm版本6.0.0，可以支持我说的第二种情况吗（让表没有PK或者UK也能同步）
这个有进展了吗，我可以通过升级解决吗
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。