MySQL主从复制故障排查及解决方案

引言

在 MySQL 生产运维里，主从复制是数据备份、读写分离、高可用架构的核心，但配置、网络、磁盘、数据一致性、日志清理等问题，总能让复制突然中断。

今天我把实战中 9 类高频主从复制故障整理成文，包含问题模拟、报错分析、分步解决方案，遇到问题直接对照处理，高效救场！

1. server_id 重复导致复制中断

问题现象

从库启动复制报错：server_id of slave is equal to server_id of master，IO 线程无法启动。

解决方案

1. 主从节点 server_id 必须唯一，修改从库：

set global server_id=唯一ID;

2. 重启复制并验证：

stop slave;
start slave;
show slave status\G

看到 Slave_IO_Running/Slave_SQL_Running 均为 Yes 即恢复。

2. 主从 3306 端口不通

问题现象

从库状态显示 Slave_IO_Running: Connecting，报错连接超时 / 拒绝。

解决方案

1. 主库放行从库 IP 的 3306 端口，清空拦截规则：

iptables -D INPUT 规则行号

2. 从库验证端口连通性：

telnet 主库IP 3306

3. 重启复制即可恢复。

3. 从库磁盘空间满

问题现象

磁盘使用率 100%，复制延迟飙升，甚至 MySQL 进程崩溃。

解决方案

1. 清理无用大文件、过期日志：

rm -f 无用文件

2. 磁盘释放后重启 MySQL 与复制：

/etc/init.d/mysql.server start
stop slave; start slave;

4. 主从数据冲突（对象已存在）

问题现象

从库已有主库要同步的库 / 表，SQL 线程中断。

解决方案

• GTID 模式：跳过冲突事务

stop slave;
set @@session.gtid_next=冲突GTID;
begin; commit;
set session gtid_next='AUTOMATIC';
start slave;

• 位点模式：跳过 1 个事务

stop slave;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave;

5. 主库更新记录在从库缺失

问题现象

更新主库存在、从库已删的记录，报错：Can’t find record。

解决方案

1. 解析 Relay Log 定位缺失数据：

mysqlbinlog 中继日志 --start-position=位点 --base64-output=decode-rows -v > 解析文件

2. 从库补全记录后重启复制。

6. 主库 Binlog 被清理，位点找不到

问题现象

从库提示：Could not find first log file name。

解决方案

1. 有正常从库：直接从正常从库重建复制。
2. 无正常从库：用 XtraBackup 备份主库，重建从库复制关系。

7. GTID 空洞问题

产生原因

手动跳过事务、主从切换、盲目配置 slave-skip-errors=all。

规避建议

• GTID 模式禁止用 SQL_SLAVE_SKIP_COUNTER
• 主从切换前保证全量同步
• 不全局跳过所有错误

8. 主从 UUID 重复

问题原因

服务器克隆导致 auto.cnf 文件一致，UUID 相同。

解决方案

1. 停止从库 MySQL
2. 删除 data/auto.cnf
3. 重启 MySQL，自动生成新 UUID
4. 重新建立主从关系

9. 从库会读到比主库更新的数据？

在 “一主两从” 架构（1 个异步从库 + 1 个半同步从库）中，需结合 MySQL 复制类型和两阶段提交原理分析：

前置知识

1. 两阶段提交：InnoDB 事务提交分两步：
   • Prepare 阶段：写入 Redo Log，标记事务为 “准备提交”；
   • Commit 阶段：写入 Binlog，再将 Redo Log 标记为 “已提交”。
2. 复制类型：
   • 异步复制：主库提交事务后立即返回客户端，不等待从库同步；
   • 半同步复制（after_commit）：主库执行 Commit 阶段后，等待从库确认接收 Binlog 再返回；
   • 增强半同步复制（after_sync）：主库执行 Prepare 阶段后，先发送 Binlog 给从库，待从库确认后再执行 Commit 阶段。

结论

特定场景会出现：增强半同步 after_sync 模式下，从库已落盘、主库未提交，从库可读到更新数据。

规避

改为 after_commit 模式，保证一致性。

排查总思路

1. 先看线程：IO 线程问题→网络 / 配置 / 权限；SQL 线程问题→数据冲突 / 结构不一致
2. 查日志：show slave status\G + 系统错误日志
3. 按复制模式（GTID / 位点）选修复方案

日常运维建议

• 定期检查磁盘、复制延迟、GTID 完整性
• 主库 Binlog 保留足够时长
• 禁止手动修改从库数据
• 半同步优先用 after_commit

以上就是MySQL主从复制故障排查及解决方案的详细内容，更多关于MySQL主从复制故障排查解决的资料请关注脚本之家其它相关文章！