【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
出现这种错误，从上游导表到下游，没有解决，希望能有好的解决方案，以希望大佬们跟我说下为什么会出现这种问题
下游表已经有这个字段了？
是的，所以我应该把这个字段删了？
这种类似的错误偶尔就会出现，按照我的理解，binlog同步都是从上到下的，为什么会出现这种错误，就像mysql主从一样从来不会有这种类似的错误
下游确定没有别人操作么，确定一开始的表结构就是一致的，从零同步么，确实没有遇到这个情况，如果低版本的dm遇到if not exists相关语句可能会出现一些bug,但不是这种
最好能确定下下游是否有人更改过表结构，另外确定下dm版本和配置，有没有类似的路由配置
我想知道遇到这种情况如何解决
确定一开始是一致的，这个问题偶尔就会有，很常见的
这种感觉是重复消费了binlog，你看下DM-worker日志里，是不是有DDL执行超时的报错，导致DM自动重试了。我记得DM在2的某个版本修复了这个BUG，建议升级一下DM版本
用binlog-schema list看看dm中的表结构是不是没变啊
辛苦把DM报错时间的日志拿下，另外可以筛选下对这张表执行的DDL都是什么
问题难就难在这里，我不知道具体什么时间报错，报错了好多天了，现在的错误就是这个，执行的ddl，我也只能说我尽量找找看，最好能给我一个你们找dm报错日志的教程
现在错误已经解决了，解决方案是手动导表，然后使用handle-error 命令跳过
知道具体报错时间点相对方便点，可以根据报错时候的binlog地址，然后分析binlog来确定对应的时间，找到对应的dm-worker日志就行
然后你下面说的那些其实没太看懂啥意思，是那个流程导致的这个帖子的报错么
请问是什么版本？
你的意思是不会将delete操作同步下去？
确定一下是不是有其他任务也同步了这张表？
tiup dmctl --master-addr 127.0.0.1:8261 start-task --remove-meta testdm-task.yaml 我从新dm导入了