使用DM迁移MySQL5.6数据库报错[code=38032:class=dm-master:scope=internal:level=high]

【TiDB 使用环境】生产环境
【TiDB/DM 版本】v5.4.3
【问题复现路径】做过哪些操作出现的问题

使用DM做MySQL数据库的迁移,
上下游MySQL都是 v5.6.24 版本
DM v5.4.3

【遇到的问题:问题现象及影响】
其他一切顺利,直到任务启动

tiup dmctl --master-addr 10.1.1.1:8261  start-task task-name 报错:

 "msg": "[code=38032:class=dm-master:scope=internal:level=high], Message: some error occurs in dm-worker: ErrCode:10006 ErrClass:\"database\" ErrScope:\"not-set\" ErrLevel:\"high\" Message:\"fail to initial unit Sync of subtask vip-syncer : execute statement failed: CREATE TABLE IF NOT EXISTS `dm_meta`.`vip-syncer_syncer_checkpoint` (\\n\\t\\t\\tid VARCHAR(32) NOT NULL,\\n\\t\\t\\tcp_schema VARCHAR(128) NOT NULL,\\n\\t\\t\\tcp_table VARCHAR(128) NOT NULL,\\n\\t\\t\\tbinlog_name VARCHAR(128),\\n\\t\\t\\tbinlog_pos INT UNSIGNED,\\n\\t\\t\\tbinlog_gtid TEXT,\\n\\t\\t\\texit_safe_binlog_name VARCHAR(128) DEFAULT '',\\n\\t\\t\\texit_safe_binlog_pos INT UNSIGNED DEFAULT 0,\\n\\t\\t\\texit_safe_binlog_gtid TEXT,\\n\\t\\t\\ttable_info JSON NOT NULL,\\n\\t\\t\\tis_global BOOLEAN,\\n\\t\\t\\tcreate_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,\\n\\t\\t\\tupdate_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,\\n\\t\\t\\tUNIQUE KEY uk_id_schema_table (id, cp_schema, cp_table)\\n\\t\\t)\" RawCause:\"Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'JSON NOT NULL,\\n\\t\\t\\tis_global BOOLEAN,\\n\\t\\t\\tcreate_time timestamp NOT NULL DEFAULT C' at line 11\" , Workaround: Please execute `query-status` to check status.",

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

因为下游MySQL5.6版本太低不支持JSON类型和BOOLEAN类型,所以报错。
尝试了在下游用其他字段类型替代JSON,但是DM 无法跳过这个high级别的报错.

CREATE TABLE `vip-syncer_syncer_checkpoint` (
  `id` varchar(32) NOT NULL,
  `cp_schema` varchar(128) NOT NULL,
  `cp_table` varchar(128) NOT NULL,
  `binlog_name` varchar(128) DEFAULT NULL,
  `binlog_pos` int(10) unsigned DEFAULT NULL,
  `binlog_gtid` text DEFAULT NULL,
  `exit_safe_binlog_name` varchar(128) DEFAULT '',
  `exit_safe_binlog_pos` int(10) unsigned DEFAULT '0',
  `exit_safe_binlog_gtid` text DEFAULT NULL,
  `table_info` text NOT NULL,
  `is_global` tinyint(1) DEFAULT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY `uk_id_schema_table` (`id`,`cp_schema`,`cp_table`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

使用 tiup dmctl --master-addr 10.1.1.1:8261 handle-error task-name skip想跳过这个DDL,但是也报错了:

"result": false,
            "msg": "[code=38008:class=dm-master:scope=internal:level=high], Message: grpc request error, RawCause: rpc error: code = Unavailable desc = transport is closing",

所以,最终用 DM 迁移MySQL5.6 的数据库作罢。
求问万能的社区,有其他办法?:rose:

dm是从mysql到tidb,上下游都是mysql,直接用mysql的主从不完事了

试试DM2.0

嗯,你说的也可以。ღ( ´・ᴗ・` )比心
主要想把DM当成通用迁移工具来着,之前5.7的迁了好几个都OK,没想到卡5.6这了。。。 :rofl:

感谢!:rose:
这样好像需要再搭一个DM v2集群,成本有点高,实践上有点难,不过是个办法。

:thinking:不过按理说应该兼容低版本才对,不知道里面是不是有bug

不造了~
目前使用DM迁移,下游是MySQL5.6.24,目前是卡住了。
尝试了下游是 MySQL5.7.26是OK的。
ღ( ´・ᴗ・` )比心

1 个赞

学习了

建议你试试cloudcanal做迁移。全量、增量、实时同步都挺好的。

你修改下目标库的checkpoint 表中 is_global为1 的记录,把当前点位改成ddl结束点位,就跳过了

看来问题还是出在下游上,换了下游就解决了。

这也行 :rofl:数据一致性不验证下?

ヾ(o′▽`o)ノ°°谢谢

是的,下游不支持JSON类型就会出现上面报错。

1 个赞

受教了,下回测试看看。ღ( ´・ᴗ・` )比心

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