悠悠楠杉
网站页面
MySQL主从复制错误如何排查
11/22
![]()
主从复制机制简述
MySQL主从复制是数据库高可用和读写分离架构中的核心组成部分。它通过将主库（Master）上的数据变更记录在二进制日志（binlog）中，再由从库（Slave）的I/O线程拉取这些日志，并由SQL线程重放，从而实现数据同步。虽然这一机制成熟稳定，但在实际运维中，网络波动、配置失误、数据不一致等问题常导致复制中断或出错。
当复制异常发生时，如果不及时处理，轻则造成业务读取延迟，重则引发数据丢失或主从数据分裂。因此，掌握系统化的排查方法至关重要。
检查复制状态的基本命令
排查的第一步是确认当前复制的状态。登录从库后执行：
sql
SHOW SLAVE STATUS\G
重点关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog。Slave_SQL_Running：是否正常执行重放操作。Last_Error和Last_IO_Error：最近发生的错误信息。Seconds_Behind_Master：从库延迟时间。
若两个Running状态均为Yes，且无错误提示，则复制正常。一旦出现No或错误信息，就需要进一步分析。
常见错误类型及应对策略
1. IO线程连接失败
当Slave_IO_Running: No且Last_IO_Error提示“Can't connect to master”时，通常是网络或权限问题。
检查项包括：
- 主库是否开启log_bin并配置了server_id；
- 从库配置的主库IP、端口、用户名、密码是否正确；
- 主库的防火墙或安全组是否放行3306端口；
- 主库的复制用户是否有REPLICATION SLAVE权限。
可通过在从库执行telnet master_ip 3306测试连通性，并在主库运行SHOW GRANTS FOR 'repl'@'%'验证权限。
2. SQL线程执行错误
当Slave_SQL_Running: No，通常意味着从库在重放SQL时遇到冲突，如主键重复、表不存在等。
典型错误示例：
Error 'Duplicate entry '1001' for key 'PRIMARY'' on query
这类问题多因手动修改从库数据、主库误操作或DDL语句未同步引起。解决方式有：
跳过错误：适用于非关键性错误。可执行：
sql SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
注意此操作会跳过一条事件，需谨慎使用。重建从库：若数据偏差较大，建议重新备份主库并恢复到从库，再重新配置复制，确保数据一致性。
3. GTID模式下的复制问题
启用GTID（全局事务标识）后，复制更可靠，但也可能因GTID集合冲突导致无法启动。
常见报错：“The slave is connecting using CHANGE MASTER TO MASTERAUTOPOSITION = 1, but the master has purged binary logs...”
此时需确保从库的gtid_purged与主库一致。可通过导出主库的GTID集合并手动设置：
sql
RESET MASTER;
SET GLOBAL gtid_purged = 'xxxxxxxx:1-100';
CHANGE MASTER TO MASTER_HOST='...', MASTER_AUTO_POSITION=1;
START SLAVE;
监控与预防措施
除了故障排查，日常监控同样重要。建议部署Zabbix、Prometheus等工具，监控Seconds_Behind_Master、复制线程状态、磁盘空间等指标。同时，定期检查主从数据一致性，可使用pt-table-checksum工具进行校验。
此外，避免在从库执行写操作，所有变更应集中在主库；DDL操作前后应暂停复制，防止结构不一致。
总结
MySQL主从复制的稳定性直接影响业务连续性。面对复制错误，应遵循“观察状态 → 定位错误 → 分析原因 → 对症修复”的流程。熟练掌握SHOW SLAVE STATUS输出含义，理解常见错误场景，并结合日志与工具辅助，才能快速恢复服务。更重要的是，建立完善的监控和应急预案，将问题消灭在萌芽阶段。
