mysql主从复制中的复制错误与日志修复方法-mysql教程-PHP中文网

MySQL主从复制中断时，先用SHOW SLAVE STATUS\G检查Seconds_Behind_Master、Slave_IO_Running和Slave_SQL_Running状态，再根据IO_Error或SQL_Error定位网络、权限、binlog缺失或数据不一致问题。

mysql主从复制中的复制错误与日志修复方法

主从复制中断时如何快速定位错误类型

MySQL 主从复制中断后，SHOW SLAVE STATUS\G 是第一响应命令。重点看 Seconds_Behind_Master 是否为 NULL，以及 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes。若其中任一为 No，需进一步查 IO_Error 或 SQL_Error 字段——前者多为网络、权限、binlog 文件缺失问题；后者才是真正的数据不一致或语句执行失败，比如主库执行了 DROP TABLE，但从库该表已被手动删过，就会报 ERROR 1051 (42S02)。

跳过单条 SQL 错误的实操步骤与风险控制

仅当确认出错语句可安全忽略（如重复插入、已存在的 DDL）时，才用跳过方式恢复同步。操作前必须备份从库当前状态（至少 mysqldump --single-transaction 导出关键库）。跳过逻辑依赖 sql_slave_skip_counter，但该变量在 GTID 模式下不可用——务必先确认：

SELECT @@GLOBAL.gtid_mode;

若返回 ON，则必须改用 SET GTID_NEXT + 空事务方式跳过：

SET GTID_NEXT='xxx-xxx-xxx:12345';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';

其中 xxx-xxx-xxx:12345 需替换为报错事件对应的 GTID 值，可通过 SHOW BINLOG EVENTS IN 'mysql-bin.000001' FROM 12345 LIMIT 1 查得。

基于 relay log 手动重放修复数据不一致

当跳过导致从库数据落后于主库（如漏掉几条 UPDATE），不能只靠 START SLAVE 恢复，需人工补数据。核心是解析 relay log 获取缺失变更：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/relay-bin.000002 | grep -A 20 "table_name"

找到对应 UPDATE 或 INSERT 的行事件后，提取 SET @1=... @2=... 变量，转换为可执行 SQL。注意：relay log 默认不记录完整 SQL，开启需在从库配置 log_slave_updates=ON（重启生效），否则只能靠 row 格式反推，复杂度陡增。

修复后验证主从一致性不能只看 Seconds_Behind_Master

Seconds_Behind_Master = 0 仅表示 SQL 线程追平了 relay log，并不保证数据一致。必须做校验：

用 pt-table-checksum 对全库逐表计算 CRC32 校验和（推荐，支持在线、断点续校）
对关键业务表，直接比对主从的 COUNT(*) 和 MIN(id), MAX(id)（适合无删除场景）
检查 SHOW MASTER STATUS 与 SHOW SLAVE STATUS 中的 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 是否相等且稳定

若发现某张表校验失败，pt-table-sync 可生成修复语句，但务必先在测试环境验证，再人工审核后执行。