AWS DMS复制任务因MariaDB Binlog事件损坏失败求助

环境与问题描述 #

• AWS Multi-AZ MariaDB RDS，引擎版本10.6.16，承载约100次/秒连接
• DMS复制任务同步RDS数据到Kinesis流，持续失败，重启后报错涉及不同binlog文件，说明多处binlog事件损坏
• 伴随现象：show slave status无输出，BinLogDiskUsage在数天内从2GB跃升至5GB

报错详情 #

Read next binary log event failed; mariadb_rpl_fetch error 1236 (Failed to replace GTID event with backwards-compatible event: corrupt event.; 
the first event 'mysql-bin-changelog.034769' at 28382, the last event read from 'mysql-bin-changelog.034990' at 16922132, the last byte read from 'mysql-bin-changelog.034990' at 16922174.) [1020403]  (mysql_endpoint_capture.c:1163)

核心原因：binlog事件损坏，GTID事件向后兼容转换失败，且损坏点分布在多个binlog文件中

排查步骤 #

• 检查RDS实例健康：查看RDS控制台的事件日志、Multi-AZ同步状态，确认主/从节点是否存在磁盘IO瓶颈、性能告警（高连接数可能导致binlog写入不完整）
• 验证binlog完整性：执行SHOW BINARY LOGS;列出所有binlog，使用mysqlbinlog工具解析报错涉及的binlog文件，确认是否存在无法解析的片段
• 核对GTID配置：检查RDS参数组中gtid_mode、enforce_gtid_consistency是否为开启状态，确认DMS端点是否正确配置GTID捕获模式
• 检查DMS任务设置：确认DMS使用的CDC模式是否匹配MariaDB 10.6的要求，验证binlog_row_image=FULL是否已开启

修复方案 #

方案1：临时损坏，无数据丢失风险 #

1. 暂停DMS复制任务
2. 清理损坏的旧binlog：执行PURGE BINARY LOGS TO 'mysql-bin-changelog.XXXXXX';（替换XXXXXX为损坏文件之前的最后一个正常binlog文件名）
3. 重置DMS起始位置：
   • 若使用GTID：通过SHOW GLOBAL STATUS LIKE 'GTID_CURRENT_POS';获取当前有效GTID集合，在DMS任务中设置从该位置开始
   • 若使用binlog位置：找到最后一个正常binlog的文件名和位置，更新DMS任务的起始配置
4. 重启DMS任务，监控运行状态

方案2：多处损坏，需保证数据一致性 #

1. 停止DMS任务，对RDS实例创建快照备份
2. 重新初始化DMS任务：选择「全量加载+CDC」模式，基于最新快照或当前RDS数据完成全量同步后，再开启增量CDC
3. 调整binlog清理策略：检查RDS参数组expire_logs_days设置，确保旧binlog自动过期，避免堆积；同时监控磁盘IOPS、吞吐量，确认实例规格满足业务需求

长期预防措施 #

• 升级MariaDB版本：将10.6.16升级至同系列最新稳定版（如10.6.20+），修复已知的binlog、GTID相关bug
• 配置CloudWatch告警：监控BinLogDiskUsage的变化速率，以及BinLogRetentionHours参数，确保DMS有足够时间处理binlog，同时避免无限制堆积
• 优化DMS任务：调整CDC批量处理大小，匹配Kinesis流的吞吐量，避免下游阻塞导致任务异常；同时监控RDS连接数，避免高并发影响binlog写入稳定性

内容的提问来源于stack exchange，提问作者wattabak