Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: “ErrCode”: 44006 Duplicate column name 错误
【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】
【Reproduction Path】What operations were performed when the issue occurred
【Encountered Issue: Issue Phenomenon and Impact】
【Resource Configuration】
【Attachments: Screenshots / Logs / Monitoring】
This error occurred when importing tables from upstream to downstream. It hasn’t been resolved yet. I hope there is a good solution, and I would like the experts to explain why this issue occurs.
Does the downstream table already have this field?
Yes, so should I delete this field?
This kind of similar error occasionally occurs. According to my understanding, binlog synchronization is top-down. Why does this error occur? It’s like MySQL master-slave replication never has such similar errors.
Are you sure that no one else is operating on the downstream? Are you sure that the initial table structures are consistent and that synchronization started from scratch? I haven’t encountered this situation before. If an older version of DM encounters an “IF NOT EXISTS” related statement, it might have some bugs, but not like this.
It’s best to confirm whether anyone has modified the table structure downstream. Additionally, check the DM version and configuration, and see if there are any similar routing configurations.
The image is not visible. Please provide the text you need translated.
I would like to know how to solve this situation.
It is certain that it is consistent at the beginning. This problem occurs occasionally and is quite common.
It feels like the binlog has been consumed repeatedly. Check the DM-worker logs to see if there are any timeout errors for DDL execution, which might have caused DM to automatically retry. I remember that DM fixed this bug in version 2.x. It is recommended to upgrade the DM version.
Use binlog-schema list to check if the table structure in DM has not changed.
Please extract the logs for the time when the DM error occurred, and also filter out what DDL operations were executed on this table.
The difficulty lies here; I don’t know the exact time the error occurred. It has been reporting errors for many days. The current error is this one, related to executing DDL. I can only say that I will try to find it. It would be best if you could provide me with a tutorial on how to find DM error logs.
The error has now been resolved. The solution was to manually import the table and then use the handle-error command to skip.
It should be this process. At the beginning, there was an error due to a missing table. I manually created a table downstream, and then because I manually created it, there was a field error. That means our configuration still does not support delete.
But there’s no mention of delete in the filter either.
Knowing the specific error time point is relatively convenient. You can analyze the binlog based on the binlog address at the time of the error to determine the corresponding time and find the corresponding dm-worker log.
As for what you mentioned below, I didn’t quite understand what it means. Is it the process that caused the error in this post?
Do you mean that the delete operation will not be synchronized?
Confirm if there are other tasks that also synchronize this table?
I re-imported from the new DM.
|
username: Jjjjayson_zeng
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: