奇怪的DM同步上下游表列异常问题（ 以参考官方资料后 ）

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】生产环境
【TiDB 版本】V7.5.1
【操作系统】
【部署方式】
【集群数据量】
【集群节点数】
【问题复现路径】
【遇到的问题：】
上游mysql 5.7.25 。通过dm同步数据时，出现 “ErrCode”: 36027 。
这个有问题的表原来上游有59个列，下游61个列。通过官方资料https://docs.pingcap.com/zh/tidb/stable/migrate-with-more-columns-downstream/#上游表结构
得到解决。后来任务根据需要就停止了。
昨天晚上在上游表中又加了一个列，上游列数达到60个 。然后把TIDB的同步任务打开，就出现了这次的提示 。
处置过程：

还是按照官方资料操作步骤（上次已经操作过一次）进行处理 ，

tiup dmctl --master-addr 192.168.xxx.xxx:8261 binlog-schema update -s mysql50130 ycspt50130new DB1 agency_XXXX_info --from-source
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 resume-task ycspt50130new
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 query-status ycspt50130new

问题依旧
然后就换了一种方法，在上游执行 show create table agency_XXXX_info 。生成一个SQL。
执行

tiup dmctl --master-addr 192.168.xxx.xxxx:8261 binlog-schema update -s mysql50130 ycspt50130new DB1 agency_XXXX_info  DB1.agency_XXXX_info.sql
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 resume-task ycspt50130new
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 query-status ycspt50130new

问题依旧
然后又执行

tiup dmctl --master-addr 192.168.xxx.xxxx:8261 binlog-schema delete -s mysql50130  ycspt50130new DB1 agency_XXXX_info 
tiup dmctl --master-addr 192.168.xxx.xxx:8261 binlog-schema update -s mysql50130 ycspt50130new DB1 agency_XXXX_info --from-source
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 resume-task ycspt50130new
tiup dmctl --master-addr 192.168.xxx.xxxx:8261 query-status ycspt50130new

问题依旧。

最后直接把TIDB中的表drop掉，用上游表结构直接创建新表，停掉任务，重启开启，还是提示同样的错误，可是这时上下游的表结构是一样的 。
已知的招数都用了，麻烦大佬指点！

【资源配置】**
【复制黏贴 ERROR 报错的日志】

 "ErrCode": 36027,
 "ErrClass": "sync-unit",
 "ErrScope": "internal",
 "ErrLevel": "high",
 "Message": "startLocation: [position: (mysql57-bin.003975, 803093), gtid-set: 00000000-0000-0000-0000-000000000000:0], endLocation: [position: (mysql57-bin.003975, 804198), gtid-set: 00000000-0000-0000-0000-000000000000:0]: gen insert sqls failed, sourceTable: `DB1.`agency_XXX_info`, targetTable: `DB1`.`agency_XXX_info`: Column count doesn't match value count: 60 (columns) vs 59 (values)",
                                "RawCause": "",
                                "Workaround": "Please check the log files to see if a related DDL has been skipped, and you could use `operate-schema` to get and set the table structure."

【其他附件：截图/日志/监控】

2

上游是云 RDS 还是官方 MySQL？

3

社区版5.7.25

4

感觉是位点问题，task 重启时候会从上次停止地方来拉取 binlog 的，这个位点是不是你第一次停止的位点？

5

这个含义是，dm 记录的表 schema 有60列，但是 binlog 中只解析到了59个字段

7

是的 ，我的pos点位值时，没有新加列，是 59个列，当时tidb是61个，所以执行的 from source 操作 ，执行后，无效。

8

如果是位点问题，中间的增量更新也不需要，可以直接调整 task_mode 为 increment，然后指定最新位点来重建任务，记得重建时候加下–remove-meta。
如果增量更新需要，binlog 也没丢，直接在 TiDB 上改成之前的59列的表结构，让正常同步就好了

1 个赞
9

好的，我试试

10

处置过程：
1、把TIDB中相关表多的列都删除，使得上下游表结构完全相同
2、由于同步任务处于pause状态 ，所以直接 resume-task ，然后查询任务，问题没有得到解决。
3、停掉任务，重新开启任务 同时加上–remove-meta
4、查询状态，问题已被解决。

11

这个时候，其实应该在执行一下binlog-schema update --from-target将 dm 内存中的 60 行schema 更新为下游 TiDB 中 59 行表结构，就可以了。

直接加上--remove-meta，如果task_mode=all可能会涉及到重新导出+导入数据，如果是increment就会只同步增量

1 个赞
12

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。