Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: dm由于上游语句不兼容异常怎么解决?
It might be an exception caused by TiDB’s incompatibility with upstream MySQL statements. How should this be resolved?
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: dm由于上游语句不兼容异常怎么解决?
It might be an exception caused by TiDB’s incompatibility with upstream MySQL statements. How should this be resolved?
Skip it, and then manually compensate for it.
Method to skip:
Isn’t this just a regular delete? I don’t see anything special about it, why wouldn’t it be supported?
It doesn’t seem to be caused by incompatibility. I suggest checking the logs or inspecting the network connection.
It is also possible that other DM tasks occupied a large amount of TiDB resources during full synchronization, and the task automatically recovered after a few hours. Later, it also indicated connection issues, but the network was fine.
It is indeed possible Does this issue continue to occur?
Did this error occur again later?
Is there an error message? Paste it here and let’s take a look.
It should be the reason. After doing some stress testing, it indeed appeared and then automatically recovered.
Later, I conducted a stress test by writing data to TiDB using other methods to increase the pressure on the TiDB side. Then DM also encountered this issue, but it automatically recovered afterward. The main prompt that appeared was: connection is already closed. The above statement about incompatibility misled me.
“connection is already closed” might be a common status. The error in your data import could be due to other reasons.
The table doesn’t have a primary key or unique index, which can cause DML operations to be relatively slow.
Is this the syntax of the old version? It’s equivalent to the current handle-error, but this can only skip DDL and cannot skip DML.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.