上游字段变更导致 DM 同步报错

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.2
  • 【问题描述】:上游mysql表的字段过大,表的有效数据长度为 varchar(32),需要将大小varchar(200)修改为varchar(64),,DM同步报错 ,然后尝试跳过此表结构修改,DM同步恢复。登录 tidb数据库,查看此表,正在同步上游binlog数据,查看表结构还是varchar(200),又过一段时间,再次查看此表表已经修改为varchar(64). ,查看DM没有报错信息,正常!!!!

麻烦注意下,这两个表是不一样的,按照 query-status 对应的表名的列是否有更改。辛苦。

上游mysql修改表结构使用的PT-OSC修改的,上面的那个是pt-osc创建的表,我需要看哪个,下面的这个表结构就是正在同步mysql的表结构啊

1.确认下下游该表当前是否存在,如果存在,看下表结构

2.是通过什么方式跳过 ddl 的,sql-skip 还是 binlog filter ?

3.麻烦提供下该时间段内的 dm-worker 的日志

4.从 information_schema.tables 中查看下该表 user_vcoin_order_trade_log 的相关信息反馈下。辛苦

PT-OSC创建的表,mysql和tidb都没有此表,该表是PT工具自动创建,修改表结构成功后会自动删除,MySQL和tidb表数量和表名都是一样的。上面截图就是tidb的表结构。使用 sql_skip跳过的。

pt-osc 工具是创建一个新表,在新表上执行 ddl 操作,所有操作结束后,新表 rename 成旧表,替换原表。删除的是原表吧。看这个表的创建时间是上午 10:42 ,辛苦提供下日志吧。

表结构修改,由于DM不支持,然后DM中断了,MYSQL却还是在一直往前走。今天早上对DM进行SQL SKIP跳过操作只是alter table 那个语句,而PT工具修改流程并没有跳过,DM再次同步binlog,是应用了PT的工作流程。应该是这样

从日志上面,实际逻辑应该是不是通过 alter table 修改成功了, 而是 create table 操作已经包含了 pay_trade_no varchar(64) ,DDL 同步到下游 TiDB 。 另外 DM 也是支持 pt-osc 操作,可以通过在 sql-paterner 里面添加 online-ddl-scheme: pt 就可以同步 。

PT工具是创建和原来表一样的空表表结构,新表也是varchar(200),在新表进行alter table 操作,在新表改字段的大小,但是对于tidb来说,还是不行的。那create table 操作已经包含了pay_trade_no varchar(64)那么这个是alter 操作修改来的,都是走binlog的,同步到下游 tidb还是不行啊,

alter table modify 不能有损调整 varchar 类型的列属性,这个是已知,并且在语法检测时候就会报错不支持。所以需要跳过。

意思是说,使用PT工具是可以修改字段长度的,但是需要跳过alter有损变更的语句。。。

这个不是自动跳过的,应该是没有同步成功。具体要看一下 dm-worker 日志确认一下。

我是手动跳过的,查看日志,从故障那一刻开始的第一条日志就是修改new表的表结构。在往前的日志信息没有

辛苦导一份 dm-worker 日志看下,文本格式,我们具体分析下,感谢

文件发给谁

E-mail:zhongshu.li@pingcap.com

有结果了么

目前来看,该表的表结构确实是重建的,并不是 alter 修改成功。时间也和 information_schema.tables 查看的创建时间相同。

另外方便提供下 DM 的版本吗 ?看下 mysqlbinlog 中是否存在这个 wbcomic_user._user_vcoin_order_trade_log_new 这个建表语句 ?我们排除下其他原因 。

版本1.1.0, 指的是tidb的binlog还是mysql的binlog,mysql的binlog肯定存在啊。