我从三个MySQL源使用DM进行分库分表合并，我在其中一个MySQL上进行了DD了变更（加字段），TiDB进行了同步，然后我在另一个还未DDL变更的MySQL上进行DML操作，对应的worker就挂掉了，说是insert的value和TiDB字段不匹配，怎么跳过这个DML，让该worker继续工作呢？
分库分表合并场景出现这个报错不符合预期，请检查 task 配置中的 is-sharding 是否为 true；正常情况下不建议跳过 DML，可能导致数据不一致，如果确实需要跳过这个 DML，可以修改下游记录 syncer 同步位置的 checkpoint 表。 相关原理可以参考 https://pingcap.com/blog-cn/dm-source-code-reading-9/
根据给到的截图信息，建议先看下报错信息里面的对应目录下 relay log 文件是否有异常，另外最好能提供下 worker log 的信息，配合着一起分析会更好些。
初始化之后同步状态是什么样子？
我复述下问题的经过啊：
- 第一次我是按照官网上那个分库分表的例子进行测试的，当时由于没有添加is-sharding：true的标识，导致ddl 同步有问题
2.后来我就用 ansible-playbook unsafe_cleanup.yml 铲掉了dm集群，然后重新部署的，部署前，dm上面的目录都是清理掉的
3.再start-task ./task.yaml 时就报上面的这种错误
4.我的inventory.ini 文件内容见下图
现在三个dm-worker的relay-log都是一样的，不知道为啥会出现这种情况，我再inventory.ini中指定的relay-log是当时在MySQL端 show master status查出来的
dm-worker.log的报错日志跟query-status 显示出来的是一样的内容
看起来像是 这个 relay log 文件写坏了，重新拉取，重放该 binlog 即可。
我都已经重新部署dm了，怎么重新拉取binlog呢？
旧集群的信息没有清理掉，重新部署时，注意删除下游的 dm_meta 库。重新部署重新拉取即可。
我重新unsafe_clean了一遍，下游的dm_meta数据库也删除了，重新部署后，load阶段过后，就卡在rsync阶段，报错如下图，dm-worker 和 dm-master的log里面也没有error信息，但是dm-worker的relay-log里面又变成空了，下面有各种日志，我已经不止两次出现，loader完之后，dm-worker的relay-log就变成" ", binlog-pos= 4 的情况，三个dm-worker节点都一样，这是什么原因啊？
–query-status日志
–dm-worker日志
–dm-worker 的relay-log日志
–dm-master的日志
这个 DM-worker 报错的意思是说, loader 阶段结束后，没有等到上游 relay log 同步到 (mysql-bin.000005, 16950) 这个位置，默认等待时间是 5 分钟。
- 可以确认一下，上游是否有 mysql-bin.000005 这个文件。
- 如果 1 确认，可以把 relay.meta 修改为
binlog-name = "mysql-bin.000005"
binlog-pos = 4
binlog-gtid = ""
resume-relay 再试一下
- loader过后不应该自动sync阶段嘛，relay log为啥没有同步到指定的位置？
2.手动修改dm-worker上面的relay-log位置，再resume-relay 报如下错误
-w 参数后面需要接着 worker 的 ip 才行，可以 query-status 看一下对应 worker 具体的 ip
刚 resume 的 worker 下 relay_log 里面有在更新数据吗? 可以看一下最新的文件是文件名是多少吗？不过看起来这次的 binlog pos 已经更新了到 mysql-bin.000025 了
我给你截的两个worker的图不是同一个，这个worker的relay-log 也是空，然后我手动改成mysql-bin.000025，resume-relay后，还是在这个点上，没有更新数据
下面是我处理第一个worker的处理过程：
–resume-relay
–pause-relay
–query-status
query-status 中有个 relayStatus, 这里能截图一下吗？
