Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: DM 启动任务报错
|
username: jerry
TiDB Version: 5.7.25-TiDB-v5.0.0
DM webUI 6.0
Issue: Synchronizing other databases works fine, but when synchronizing the transaction database, some tables report “fail to initial unit Load of subtask.”
Is there any difference between this table and other tables? Can you show the table structure?
The error message indicates that there is an error in the table creation statement. Try executing that table creation statement in the downstream TiDB to see what happens.
The downstream of TiDB has this table, with the same table structure.
I mean the “create table dm_meta” statement, run this statement, and it would be best if you could send the error from the dm logs.
It should have nothing to do with the table structure. I have checked the table structure and there is no problem.
Yes, also if you have detailed logs of the worker, please provide them as well.
The table under dm_date is missing 3 compared to the normal one
So, are you executing that create table SQL downstream to see if there are any errors?
Two things, if it’s convenient for you, please do:
Okay, it needs to be put into production. Once there are results, I will send them to you for assistance. Thank you.
Okay, that sounds a bit troublesome. If it doesn’t involve any confidentiality, please send me the table creation statement, and I’ll execute it here. Also, I would like to ask about the version of DM.
DM version 6.0 webUI
Thank you. I just tried this task in the development environment and there was no problem. Then I compared the fields in development and production, and there was no issue. What could be the reason?
I suspect that the table name for this task is too long and exceeds the limit, causing the table creation to fail. If the task name in the test environment is the same, the final generated task table in dm_meta will be the same as the task table in your error report, and if the character set collation in the test and production environments is the same, then my guess is wrong. You can investigate along this line of thought. It might be difficult for you to provide information, so this blind guess is as far as I can go. The length is the same as the length of the table in your error report.
You can manually create this database downstream, and then grant the following permissions: GRANT Select, Insert, Update, Delete, Create, Drop, Alter, Index ON dm_meta.* TO user@‘’; After granting the permissions, it should work.
Thank you very much, it has been resolved. I would like to ask if you have encountered this kind of issue while running tasks?
The execution of the statement failed because TiDB and MySQL are not fully compatible. Some statements may fail on the TiDB side due to incompatibility or configuration issues. When encountering such problems, you can find the actual statement executed by MySQL based on the binary location and check what error is reported downstream. If possible, modify the statement; if not, you can use a workaround or other methods.
Did you manage to copy successfully just by shortening the table name?
|
username: 
|
username: 
|
username: 