我的DM同步任务中，没有设置safe-mode:false
貌似把上游的一个update语句，自动拆分成了 delete + replace语句
虽然我配置文件中屏蔽了delete，但是这个是update拆分的，所以还是发给下游执行了
看日志，用到了参数替换， 替换问号。 但是这条记录，字段值里带有???， 是不是就是这个原因，导致DM执行这个删除语句失败了， 然后就同步不下去了？？？
另外， 此时我把safe-mode设置成false，也就是不拆分update语句，但是好像也没用了
是不是relay-log生成的时候，就已经把当时的update语句拆分好了， 所以即使这个时候我修改了配置文件， 原先已经生成的relay-log里， 依然存在了这个delete语句， 所以还是执行不下去
context dealine exceeded 说明 sql 执行到下游超时了，safemode 当任务重启时会开启，不会影响任务
应该不是简单的超时啊。 这个任务，无论怎么重启，都无法执行下去了， 应该是某个binlog动作执行出错了。
我配置文件里，屏蔽了delete， 但是日志里还是在执行delete，说明这个delete不是原生的，而是被拆分改写出来的。 按理我开启safemode=false，就不会拆分改写了
有真实的上游语句么，这个是利用prepare来做的，还是什么样的呢
DM并不是生成relay-log,而是在内存里实时拆分的，拆分完直接在tidb执行该sql，理论上再次启动，他不会主动给你拆分。
有没有可能是对delete的过滤条件失效了，我知道有些上游压缩场景，会delete数据
上游真实的语句我不知道啊，我这个是worker日志里拿到的
这个库的表，我一共配置了17个任务， 另外16个任务都是很正常的， 就这个任务， 最近几天2次出现这种情况， 看日志， 全部是卡在delete from 语句的处理上， 看日志内容，感觉是delete语句在tidb里执行失败了， 一直执行失败， 一直没法推进binlog， 所以出现了binlog落后master binlog的现象
delete过滤失效应该不至于，首先我们业务上约定，不能物理删除，只能把deleted字段从F改成T，进行逻辑删除。 而且delete后面的库名表名，是我下游的库名表名。
我最初是怀疑，是不是我这条数据里，有一个字段是json的，里面有一个属性值title 是???
而我看DM执行删除操作，用的是问号参数替换这种， 会不会是程序的BUG？
刚发现，开启了safemode=false后，同步过来的数据，有重复记录了。。。
Resume 的时候会根据需要自动开启一段时间的 safe mode(因为出于性能考虑，checkpoint不是实时持久化的)
我把这张表清空了， 然后 看下面的日志 delete执行正常了， replace into也执行正常了
说明之前表里有数据的时候， DM执行delete失败。。。 这是什么原因？ 表中现有数据影响到了DM的delete?
给我感觉就是，DM执行delete失败，然后同步不下去了， 日志里有记录的ID
如果我这个时候，手工去把目标表的记录，通过ID删除掉的话，那么DM应该可以继续推进下去了。
我刚才动作搞太大，直接把表清空了，之后DM也能正常继续了。。。
我看到了binlog-gitd，可以直接binlogdump捞下这个时段上游的binlog，然后搜下这个binlog-gtid，看看到底这段时间上游发生了啥。
另外你的数据。。没脱敏，如果是商业数据的话，会被你们安全团队找的。。
我把那几个带日志的帖子删除得了
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。