tiup dmctl check-task,长时间没有响应,跟上下游表数量有关系么?

上下游数据库表有140多个,这个一般得卡多久?官方有说明么?

看下日志,日志里面有记录进度/tidb-deploy/dm-master-8261/log/dm-master.log

不正常,最好做一下其它检查

有关系,数据量大小、网络速度、硬件性能

当你把状态表放在一个task里面的时候还要注意:当task包括很多分片合并的表,tiup dmctl start-task/check-task的时候上游的mysql 连接数量可能会不够,需要你把上游的max_connections参数调大一些。

另外上游需要合并的表多了,如果start-task出错可能根本找不到错误提示在哪里,json返回的结果只有10条数据,这10条如果恰好都是警告,你是不知道提交任务失败的真正原因的。这时候就需要你改用

tiup dmctl check-task task.yaml -e 1000 -w 1000

总之就是把-e -w后面的数字调大,让他可以在json返回结果里面输出更多的提示,方便你找到错误的原因。

看一下进度卡在哪了