使用syncer从mariadb同步数据到tidb启动失败

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

  • 【TiDB 版本】:5.7.25-TiDB-v3.0.1
  • 【问题描述】:数据从mariadb-10.2.16迁移到tidb中,全量同步使用mydumper\myloader已同步完成,由于环境数据量较小,使用syncer做同步,启动报错

启动命令为./syncer -config config.toml

config.toml内容如下

syncer.meta文件内容如下:

image

源mariadb数据库的binlog模式为row,这个是row格式是在使用mydumper备份之前修改的
image

请问下,是我配置的问题,还是数据的问题,导致同步启动失败呢

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1、你那里单独把语句拿出来可以在 tidb 执行成功吗?

2、我这里本地测试看下~

我单独执行命令,是成功的。

1、请使用最新版本的 syncer 工具,下载链接如下:

https://pingcap.com/docs-cn/stable/reference/tools/download/#syncerloader-和-mydumper

2、请确认上游 mariadb 的 binlog 参数 binlog_row_image

1 binlog_row_image结果

image

2 已下载最新的loader

执行结果和之前一样,没有任何变化

1、看下 syncer 的版本具体是什么

2、这里本地测试是支持的,方便的话,请提供下表结构和相关的语句,我们测试复现下

1 syncer版本 v1.0.0-78-g6aea485

2 建表语句 CREATE TABLE Code0Cache ( id bigint(20) NOT NULL AUTO_INCREMENT, apiTypeId int(11) NOT NULL, aid smallint(6) DEFAULT NULL, k varchar(100) NOT NULL, v mediumtext NOT NULL, createTime datetime NOT NULL, timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uq_t_k (apiTypeId,k), KEY idx_t_ts (apiTypeId,timestamp) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=423347103;

执行命令: INSERT IGNORE INTO Code0Cache(apiTypeId, aid, k, v, createTime) VALUES (21, 578, ‘13837628606|411503198210220037|张欣’, ‘{“code”:0,“message”:“成功”,“result”: {“resultCode”:4,“unmatched”:null},“l”:null}’, NOW()) ON DUPLICATE KEY UPDATE aid=578, v=’{“code”:0,“message”:“成功”,“result”:{“resultCode”:4,“unmatched”:null},“l”:null}’, timestamp=CURRENT_TIMESTAMP

是不是因为syncer拖下来的sql命令有ON DUPLICATE KEY UPDATE这种语法,所以被认定为非row格式呢

上游 mariadb 的版本请提供下,这边测试的 5.7 环境使用上述表结构和语句可以正常同步~

上游数据库版本 mariadb-10.2.12

稍等,需要重新搭建 mariadb 环境复现,有进度会跟帖回复

搭建的mariadb,最好binlog_format格式,最好是从mixed,修改为row格式后,再导出、同步,我是这样操作的。

1、你那里有查看过 binlog format 修改后,binlog 里面记录的内容都是 row 格式吗?能否重新 flush log,确认下

2、在确认 binlog 是 row,并且 image 为 full ,能否再次 mydumper + loader + syncer 同步看下

1 我看了目前的binlog,格式和报错的格式都是一样的,我flush logs后,用mysqlbinlog -vv 观察SQLbinlog中的记录,仍然有duplicate 的命令格式

2 我最新的环境,都是确认binlog为row,image为full,重新做的操作。

看你发过来的 binlog 的日志的格式,不是 row 格式的,还是 statement 或者是 mix 格式:

你那里修改 binlog 格式应该通过 set global binlog_format=‘row’ 这种方式修改的。如果是,那么新建立会话会使用 row 格式,已有的通过连接池的方式连接数据库的会话,仍然使用的是混合模式。建议重启应用系统后,确保新会话使用的均为 row 后,再重新使用 syncer 试下。

好的,感谢,我重启数据库再试试。

如果重启后仍然有问题,可继续跟帖~~

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