TIDB DM同步,目标表有更多列

“Message”: “startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin|000001.000192, 9496251), gtid-set: 43febf05-bee0-11eb-9f8b-fa163e97c6ef:1-7268311,7e58ed80-e04f-11ea-99c0-fa163e00c4ce:1-333254,ff880cee-bec3-11eb-8ad5-fa163efbe4a8:1-11688]: gen insert sqls failed, sourceTable: targetTable: Column count doesn’t match value count: 34 (columns) vs 33 (values)”,

目标表有更多的列

我设置过表结构了啊,但是总感觉DM隔一阵子就会报类似错误
我每个分库每个表,都设置了表结构的, 按照目标表有更多列

现在给我感觉,这个设置的表结构,不持久, 过1,2天,就会有类似错误发生了

发生这个错误的时候上游执行的什么sql,发生错误之后是重新设置一下就好了么,上游有没有类似drop table或者drop table if exists之类的操作

因为我们这边是数据仓库部门, 上游是业务部门, 他们在做什么事情,我们不清楚的啊
但是一般来说,我们的表结构也不会随意变更的。 更不会删除表,都是有业务数据的,生产的。

我这里是100个表的分表 以及 50个表的分表
就在刚才那一阵子, 两个任务都发生了 : 提示字段数不匹配

但是。。。 设置表结构, 我真的是复制黏贴了无数次了, 重新设置一下,就好

但是操作很繁琐啊, 要先暂停,然后复制黏贴,等100个设置语句结束,再恢复。。。

而且我一个任务同步好几张表, 有时候A表好了, B表又这样了。。 所以给我感觉,之前设置的表结构, 感觉发挥不稳定

你这里可以访问上游么,对比一下上游的表结构有没有变更,我翻了下github,没有找到类似的bug,可能的原因就是上游表结构变更了

但是现在我重新设置了以后,就好了。 现在暂时稳定了。 如果表结构变更,那是永久性的吧, 我设置表结构的语句是没有变化过的。

我可以访问上游。

其实我下游的表,就加了一个字段
confluent__last_updated timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

就是当数据插入或者更新的时候,把这个时间字段,设置成当前系统时间。

我个人感觉,上游变动表结构的可能性很低, 下次如果再发生,我去看看

这个设置表结构, 设置的信息,保存在什么地方? 感觉没有保存在数据库里

这个信息, 会同步到多个master节点吗?

如果设置多次,是不是以最后一次设置为准?

我设置的时候,master地址只写了一个,应该也没问题吧

持久化在下游的 dm_meta 里。
master 之间是同步的。
以最后一次为准。

可以把日志脱敏下发出来看看,看看 DDL 执行历史

看worker节点的还是master节点的日志?
日志很大啊, 有什么办法可以快速搜索、定位到DDL相关的信息

[2022/05/31 10:47:56.565 +08:00] [WARN] [grpclog.go:66] [“transport: http2Server.HandleStreams failed to read frame: read tcp ->192.168.104.55:59960: read: connection reset by peer”] [component=“embed etcd”]
翻了翻日志, 日志里有以上这样的信息, 也不知道有没有关系

在 worker 的日志查一下"flush table info",每次将表信息同步到 checkpoint 之前都会打印一个这样的 log,如果 flush 失败就会有 error。

好像都是对的。 worker太多了,也不方便一个个看。我执行命令的时候,返回的result属性都是true

有没有可能,设置表结构都设置成功了, 读取dm_meta那个表结构字段的时候,或者解析的时候,有点问题

可以提供刚刚有问题的那个 source,所在 worker 的日志

看看这个信息够吗

又出现了。。。。 很频繁,这个问题

1 个赞

请问 order_refund_detail_31 这个表是不是新创建的呢?

看下面日志, 14点44分, 字段数不匹配这个错误又出现了。

我们这边分库分表, 分了100个分表,
我没有去每个库看, 但是我设置表结构的时候,之前就老早设置了

刚刚又有2个分表,报同样的字段数不匹配, 我设置表结构语句,复制黏贴又执行了一次,又好了。

但是执行了好多次了。。。 中午的时候执行过, 现在又执行过。 前几天也执行过。。。

这样运维有点累

你有没有限制alter table等ddl操作,或者在下游有一些ddl操作

下游这边只有我操作, 下游没有做DDL。

限制的话,alter table我只限制了删除字段, 增加字段没有限制。
但是应该不是上游增加字段,我们这边发布比较严格的,现在大白天的,不可能业务方会加字段

filters: # 定义过滤数据源特定操作的规则,可以定义多个规则
my_filter-rule-1: # 规则名称
schema-pattern: “" # 匹配数据源的库名,支持通配符 "” 和 “?”
table-pattern: “" # 匹配数据源的表名,支持通配符 "” 和 “?”
events: [“truncate table”, “drop table”,“delete”] # 匹配上 schema-pattern 和 table-pattern 的库或者表的操作类型
action: Ignore # 迁移(Do)还是忽略(Ignore)

my_filter-rule-2:
schema-pattern: “*”
events: [“drop database”,“create database”,“create table”,“create index”,“drop table”,“truncate table”,“rename table”,“drop index”]
sql-pattern: ["^ALTER\s+TABLE\s+DROP"]
action: Ignore