Does the tiup dmctl check-task command not respond for a long time? Is it related to the number of upstream and downstream tables?

This topic has been translated from a Chinese forum by GPT and might contain errors.

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

| username: TiDBer_b1iRkG7I

There are more than 140 upstream and downstream database tables. How long does this usually take? Is there an official explanation?

| username: IanWong | Original post link

Check the logs, the progress is recorded in the logs /tidb-deploy/dm-master-8261/log/dm-master.log

| username: dba远航 | Original post link

It’s abnormal, it’s best to perform some other checks.

| username: redgame | Original post link

It is related to the size of the data, network speed, and hardware performance.

| username: TiDBer_小阿飞 | Original post link

When you place the state table within a task, you should also note: if the task includes many tables that need to be merged from different shards, the number of MySQL connections upstream might be insufficient when you use tiup dmctl start-task/check-task. You may need to increase the max_connections parameter upstream.

Additionally, if there are many tables to be merged upstream, and an error occurs during start-task, you might not be able to find the error message. The JSON response only contains 10 entries, and if these 10 entries are all warnings, you won’t know the real reason for the task submission failure. In this case, you need to use:

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

In summary, increase the numbers after -e and -w so that the JSON response can output more messages, making it easier for you to find the cause of the error.

| username: 小于同学 | Original post link

Check where the progress is stuck.