tidb-dm同步报错binlog checksum mismatch, data may be corrupted

一、问题原因：

binlog查过4G

二、处理relay

1.在上游确认出错时对应的 binlog 文件的大小超出了 4GB

2.停止 DM-worker

这里要注意，不是stop-task，而是停止对应的dm-worker进程

3.将上游对应的 binlog 文件复制到 relay log 目录作为 relay log 文件。

4.修改relay.meta 文件

更新 relay log 目录内对应的 relay.meta 文件以从下一个 binlog (这个binlog是指relay-log目录中没有的，且在二进制show master logs;能看到的)开始拉取。如果 DM worker 已开启 enable_gtid，那么在修改 relay.meta 文件时，同样需要修改下一个 binlog 对应的 GTID。如果未开启 enable_gtid 则无需修改 GTID。

例如：报错时有 binlog-name = “mysql-bin.004451” 与 binlog-pos = 2453，则将其分别更新为 binlog-name = “mysql-bin.004452” 和 binlog-pos = 4，同时更新 binlog-gtid = “f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058”。

5.重启 DM-worker。

三、relay部分处理完了之后还报错的处理方式

1.通过 stop-task 停止迁移任务。

2.更改元信息表

将下游 dm_meta 数据库中 global checkpoint 与每个 table 的 checkpoint 中的 binlog_name 更新为出错的 binlog 文件，将 binlog_pos 更新为已迁移过的一个合法的 position 值，比如 4。

例如：出错任务名为 dm_test，对应的 source-id 为 replica-1，出错时对应的 binlog 文件为 mysql-bin|000001.004451，则执行 UPDATE dm_test_syncer_checkpoint SET binlog_name=‘mysql-bin|000001.004451’, binlog_pos = 4 WHERE id=‘replica-1’;。

3.更改复制模式为安全模式

在迁移任务配置中为 syncers 部分设置 safe-mode: true 以保证可重入执行。

4.通过 start-task 启动迁移任务。

5.恢复复制模式

通过 query-status 观察迁移任务状态，当原造成出错的 relay log 文件迁移完成后，即可还原 safe-mode 为原始值并重启迁移任务。

官网地址： https://docs.pingcap.com/zh/tidb-data-migration/v1.0/error-handling，https://docs.pingcap.com/zh/tidb/stable/dm-error-handling#dm-错误系统