MySQL主从复制同步失败排查与修复指南

一、问题/场景描述

在MySQL主从复制架构中，从库（Slave）因网络中断、主库（Master）宕机、数据不一致或二进制日志（binlog）损坏等原因，导致复制线程停止，出现如Slave_IO_Running: No或Slave_SQL_Running: No的错误状态。此时主库写入的数据无法同步到从库，影响读写分离和数据备份的可用性。

二、原因分析

主从同步失败常见原因包括：

• 网络故障导致IO线程无法连接主库或接收日志。
• 主库binlog被清理或损坏，从库请求的日志位置不存在。
• 从库执行SQL时遇到主键冲突、表不存在或数据类型不匹配。
• 主从服务器配置不一致，如server-id重复或binlog_format不同。
• 从库的relay-log损坏或磁盘空间不足。

三、详细解决步骤

步骤1：检查复制状态

登录从库MySQL，执行以下命令查看复制线程状态：

SHOW SLAVE STATUSG

关注关键字段：

• Slave_IO_Running：是否Yes。
• Slave_SQL_Running：是否Yes。
• Last_IO_Error和Last_SQL_Error：错误详情。
• Seconds_Behind_Master：延迟秒数。

步骤2：修复IO线程问题

若Slave_IO_Running: No，检查网络和主库连接配置。重启IO线程：

STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

若错误为Got fatal error 1236（binlog位置丢失），需重新同步主从数据：

STOP SLAVE;
RESET SLAVE ALL;
-- 在主库执行 SHOW MASTER STATUS 获取当前binlog文件名和位置
CHANGE MASTER TO MASTER_HOST='主库IP',
MASTER_USER='复制用户',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE;

步骤3：修复SQL线程错误

若Slave_SQL_Running: No，查看Last_SQL_Error。常见解决方式：

• 主键冲突：跳过错误事件，但谨慎使用，避免数据不一致。

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

• 表不存在：在主库创建缺失的表，或从主库导出导入。
• 数据类型不匹配：检查表结构是否一致，使用mysqldump重建从库表。

步骤4：数据不一致的全面修复

若多次跳过错误仍失败，建议重新初始化从库：

# 在主库导出数据（忽略锁表）
mysqldump -u root -p --all-databases --master-data=2 > master_dump.sql

# 将dump文件传输到从库
scp master_dump.sql slave_user@从库IP:/tmp/

# 在从库导入
mysql -u root -p < /tmp/master_dump.sql

导入后，在从库执行：

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_HOST='主库IP',
MASTER_USER='复制用户',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE;

其中MASTER_LOG_FILE和MASTER_LOG_POS从master_dump.sql文件头部的注释中获取。

步骤5：验证修复结果

SHOW SLAVE STATUSG
-- 确保 Slave_IO_Running: Yes, Slave_SQL_Running: Yes

四、注意事项

修复前务必备份从库数据，避免误操作导致数据丢失。跳过SQL错误应仅用于临时恢复，长期需排查应用层写入逻辑。生产环境中建议开启sync_binlog=1和innodb_flush_log_at_trx_commit=1保证数据一致性。若使用GTID复制，需使用CHANGE MASTER TO MASTER_AUTO_POSITION=1简化操作。

五、适用环境

本文适用于MySQL 5.7、8.0及以上版本，在Linux（如CentOS 7、Ubuntu 20.04）或Windows Server环境下均可行。