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

原创已于 2023-06-09 14:45:21 修改 · 556 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

于 2021-08-19 14:56:23 首次发布

TIDB 专栏收录该内容

63 篇文章

订阅专栏

当DM集群中的binlog文件超过4GB时，需要进行一系列处理以恢复数据同步。首先，确认上游binlog文件大小，然后停止对应DM-worker，将上游binlog复制到relaylog目录，并更新relay.meta文件。如果使用了GTID，还需更新binlog-GTID。接着，通过stop-task停止迁移任务，更新dm_meta数据库中的checkpoint信息，切换到安全模式启动迁移任务。完成迁移后，恢复复制模式。本文提供了详细的步骤和错误处理指南。

一、问题原因：

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’;。