"ErrCode": 44006 Duplicate column name 错误

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】

出现这种错误,从上游导表到下游,没有解决,希望能有好的解决方案,以希望大佬们跟我说下为什么会出现这种问题

image
下游表已经有这个字段了?

是的,所以我应该把这个字段删了?

这种类似的错误偶尔就会出现,按照我的理解,binlog同步都是从上到下的,为什么会出现这种错误,就像mysql主从一样从来不会有这种类似的错误

下游确定没有别人操作么,确定一开始的表结构就是一致的,从零同步么,确实没有遇到这个情况,如果低版本的dm遇到if not exists相关语句可能会出现一些bug,但不是这种

最好能确定下下游是否有人更改过表结构,另外确定下dm版本和配置,有没有类似的路由配置

image

我想知道遇到这种情况如何解决

确定一开始是一致的,这个问题偶尔就会有,很常见的

这种感觉是重复消费了binlog,你看下DM-worker日志里,是不是有DDL执行超时的报错,导致DM自动重试了。我记得DM在2的某个版本修复了这个BUG,建议升级一下DM版本

用binlog-schema list看看dm中的表结构是不是没变啊

辛苦把DM报错时间的日志拿下,另外可以筛选下对这张表执行的DDL都是什么

问题难就难在这里,我不知道具体什么时间报错,报错了好多天了,现在的错误就是这个,执行的ddl,我也只能说我尽量找找看,最好能给我一个你们找dm报错日志的教程

现在错误已经解决了,解决方案是手动导表,然后使用handle-error 命令跳过


应该是这个流程,刚开始是少表的错误,我手动下游建了个表,然后因为我手动建导致字段报错,那就说明我们配置还是不支持delete


但是过滤里面也没有写delete

知道具体报错时间点相对方便点,可以根据报错时候的binlog地址,然后分析binlog来确定对应的时间,找到对应的dm-worker日志就行

然后你下面说的那些其实没太看懂啥意思,是那个流程导致的这个帖子的报错么

请问是什么版本?

你的意思是不会将delete操作同步下去?

确定一下是不是有其他任务也同步了这张表?

tiup dmctl --master-addr 127.0.0.1:8261 start-task --remove-meta testdm-task.yaml 我从新dm导入了