我要评论引言
在 mysql 生产运维里，主从复制是数据备份、读写分离、高可用架构的核心，但配置、网络、磁盘、数据一致性、日志清理等问题，总能让复制突然中断。
今天我把实战中 9 类高频主从复制故障整理成文，包含问题模拟、报错分析、分步解决方案，遇到问题直接对照处理，高效救场！
1. server_id 重复导致复制中断
问题现象
从库启动复制报错：server_id of slave is equal to server_id of master，io 线程无法启动。
解决方案
- 主从节点 server_id 必须唯一，修改从库：
set global server_id=唯一id;
- 重启复制并验证：
stop slave; start slave; show slave status\g
看到 slave_io_running/slave_sql_running 均为 yes 即恢复。
2. 主从 3306 端口不通
问题现象
从库状态显示 slave_io_running: connecting，报错连接超时 / 拒绝。
解决方案
- 主库放行从库 ip 的 3306 端口，清空拦截规则：
iptables -d input 规则行号
- 从库验证端口连通性：
telnet 主库ip 3306
- 重启复制即可恢复。
3. 从库磁盘空间满
问题现象
磁盘使用率 100%，复制延迟飙升，甚至 mysql 进程崩溃。
解决方案
- 清理无用大文件、过期日志：
rm -f 无用文件
- 磁盘释放后重启 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。
解决方案
- 解析 relay log 定位缺失数据：
mysqlbinlog 中继日志 --start-position=位点 --base64-output=decode-rows -v > 解析文件
- 从库补全记录后重启复制。
6. 主库 binlog 被清理，位点找不到
问题现象
从库提示：could not find first log file name。
解决方案
- 有正常从库：直接从正常从库重建复制。
- 无正常从库：用 xtrabackup 备份主库，重建从库复制关系。
7. gtid 空洞问题
产生原因
手动跳过事务、主从切换、盲目配置 slave-skip-errors=all。
规避建议
- gtid 模式禁止用
sql_slave_skip_counter - 主从切换前保证全量同步
- 不全局跳过所有错误
8. 主从 uuid 重复
问题原因
服务器克隆导致 auto.cnf 文件一致，uuid 相同。
解决方案
- 停止从库 mysql
- 删除
data/auto.cnf - 重启 mysql，自动生成新 uuid
- 重新建立主从关系
9. 从库会读到比主库更新的数据？
在 “一主两从” 架构（1 个异步从库 + 1 个半同步从库）中，需结合 mysql 复制类型和两阶段提交原理分析：
前置知识
- 两阶段提交：innodb 事务提交分两步：
- prepare 阶段：写入 redo log，标记事务为 “准备提交”；
- commit 阶段：写入 binlog，再将 redo log 标记为 “已提交”。
- 复制类型：
- 异步复制：主库提交事务后立即返回客户端，不等待从库同步；
- 半同步复制（after_commit）：主库执行 commit 阶段后，等待从库确认接收 binlog 再返回；
- 增强半同步复制（after_sync）：主库执行 prepare 阶段后，先发送 binlog 给从库，待从库确认后再执行 commit 阶段。
结论
特定场景会出现：增强半同步 after_sync 模式下，从库已落盘、主库未提交，从库可读到更新数据。
规避
改为 after_commit 模式，保证一致性。
排查总思路
- 先看线程：io 线程问题→网络 / 配置 / 权限；sql 线程问题→数据冲突 / 结构不一致
- 查日志：
show slave status\g+ 系统错误日志 - 按复制模式（gtid / 位点）选修复方案
日常运维建议
- 定期检查磁盘、复制延迟、gtid 完整性
- 主库 binlog 保留足够时长
- 禁止手动修改从库数据
- 半同步优先用 after_commit
以上就是mysql主从复制故障排查及解决方案的详细内容，更多关于mysql主从复制故障排查解决的资料请关注代码网其它相关文章！
发表评论