Syncer同步报columns length不一致

为提高效率,提问时请尽量提供详细背景信息,问题描述清晰可优先响应。以下信息点请尽量提供:

  • 系统版本 & kernel 版本:
  • TiDB 版本:
  • 磁盘型号:
  • 集群节点分布:
  • 数据量 & region 数量 & 副本数:
  • 集群 QPS、.999-Duration、读写比例:1TIDB,1PD 3TIKV,测试环境
  • 问题描述(我做了什么): 使用syncer同步时报错,gen update sqls failed: update columns and data mismatch in length: 16 vs 15 查看上下游表结构,数量一致,没有使用rds特性的那个隐藏主键问题,辛苦大佬看下

麻烦脱敏贴下 syncer 报错 log 的上下文内容

syncer.log (18.8 KB) 这是我这边的syncer.log,辛苦您看下还有什么其他问题

数据上下游一值不一定binlog时间点的数据列与现在一致。
可能是表结构改过,之前的列数为16,进行数据插入时有16列,你修改上游表结构为15,同步未成功,手动修改下游表结构为15,导致binlog为修改表结构之前的16列数据无法插入到现在列为15的表里。

可以报表结构改回原来的的16列的,数据插入可以跳过,然后再修改表结构。
感觉你目前的结构有乱了,如果可以建议你重新由当前时点重新dumper、loader,然后再sycner。

同步未成功会是syncer的问题?这个不应该不成功吧

但是整个过程只是dumper,loader,然后就syncer了,没有手动修改任何从库的信息,这个数据的所有同步应该都是syncer去控制的才对吧

真正的原因是你binglog的insert(或者其他操作)列长度与下游数据库列长度不同

你可以看一下要同步的binlog的列和下游数据库列是否一致。如果时这个原因,导致binlog与下游数据库不一致原因也有很多,你可以根据你们操作考虑一下问题在哪

但是为什么会长度不同呢,我loader恢复的数据应该和我当时上游的备份数据一致才对吧,没有问题的情况恢复完是和当时一样的,此时我后续的操作都是syncer去同步binlog,无论怎么变更表结构都是应该同步的,这个问题是因为

我知道,但是不知道为什么会这样

这个正常loader恢复没有报错的情况下,这个上下游的列应该是肯定一致的吧

你可以考虑一下是否会是事务影响导致binlog滞后造成的不一致

查看分析一下错误点的binlog,具体分析一下

想不通····ddl是直接记binlog的,原集群如果因为事务的原因被阻塞一段时间记binlog那我相同的去应用不应该有问题,我的syncer是记录当时备份的GTID点的

还有下游数据库的修改时间点、上有数据库的修改时间点、报错语句的执行开始结束时间

日志里面没有报错语句吧,现在的解决方案从同步的原理上说不通吧,除非是dumper记录的时间点或者syncer执行的时间点不对才会有这种问题吧

你也可以直接resume-task任务试试dumper用改不会出问题,可能是binlog或者syncer问题

搜了一下binlog,9月18日这个表结构就变更了,我23日才做了备份,而且备份后这个表没有做任何的变更,那这个问题还有可能在哪儿呢,mydumper的时候位置记录不对?

你可以看看mydumper的时候位置记录与你报错时候的位置记录