MySQL主从复制是数据库架构中常见的数据同步方案，能够实现读写分离、数据备份等需求，但在实际运行过程中，很容易因为网络波动、配置错误、数据冲突等原因出现复制中断的问题，需要针对性排查修复。
主从复制故障排查基础步骤
当发现主从复制异常时，首先需要在从库执行以下命令查看复制状态：
SHOW SLAVE STATUSG;
重点关注两个核心字段：Slave_IO_Running和Slave_SQL_Running，正常状态下两者都应为Yes，如果出现No则说明对应线程异常。同时需要记录Last_IO_Error和Last_SQL_Error字段的报错信息，这是定位问题的关键依据。
常见故障场景与解决方法
场景一：IO线程运行异常
IO线程负责从主库拉取binlog日志并写入本地relay_log，常见报错是连接主库失败，比如报错信息为error connecting to master 'repl@192.168.0.1:3306' - retry-time: 60。
这类问题通常排查方向如下：
- 检查主库复制账号的权限是否正确，是否允许从库IP访问
- 验证主从库之间的网络是否通畅，端口是否可通
- 确认主库的
server-id和从库的server-id是否不同，避免冲突
如果是账号密码错误，需要重新配置从库的主库连接信息：
-- 停止从库复制 STOP SLAVE; -- 重新配置主库连接信息，替换为实际的账号密码和主库地址 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154; -- 启动从库复制 START SLAVE;
场景二：SQL线程运行异常
SQL线程负责执行relay_log中的事件，常见报错是执行SQL时违反约束，比如报错Duplicate entry '1001' for key 'PRIMARY'，说明从库已经存在主键为1001的记录，再次插入时出现冲突。
这种数据冲突问题的解决方法需要结合业务场景选择：
- 如果是测试环境，可以先跳过当前冲突的事务，继续执行后续同步
- 如果是生产环境，需要先排查主从数据差异，修复不一致的数据后再恢复复制
临时跳过单个事务的操作如下，注意需要记录当前出错的binlog文件和位置：
-- 停止从库复制 STOP SLAVE; -- 跳过当前1个事务，也可以根据报错调整跳过的数量 SET GLOBAL sql_slave_skip_counter = 1; -- 重新启动从库复制 START SLAVE;
如果频繁出现同类型冲突，需要检查主从库的配置，比如是否开启了log_slave_updates，是否存在双写的情况。
场景三：主从数据不一致导致复制中断
如果主从数据长期不一致，可能会触发更复杂的复制错误，此时需要先校验主从数据差异。可以使用pt-table-checksum工具在主库执行数据校验：
pt-table-checksum --host=192.168.0.1 --user=root --password=root_password --databases=test_db --replicate=test_db.checksum_table
校验完成后，在从库查询差异结果：
SELECT * FROM test_db.checksum_table WHERE master_cnt != this_cnt OR master_crc != this_crc OR ISNULL(master_crc) != ISNULL(this_crc);
确认差异数据后，可以使用pt-table-sync工具修复不一致的数据：
pt-table-sync --execute --replicate=test_db.checksum_table --host=192.168.0.1 --user=root --password=root_password
主从复制日常维护建议
为了减少主从复制故障的发生，日常运维中可以做好以下几点：
- 定期检查从库的
SHOW SLAVE STATUS结果，监控复制状态 - 避免直接在从库写入数据，防止数据冲突
- 主库执行大事务时尽量拆分，避免生成过大的binlog导致从库同步延迟
- 定期备份主从库数据，出现不可逆故障时可以快速恢复
遇到主从复制问题时，不要盲目重启或跳过事务，先通过报错信息定位根因，再选择对应的解决方法，才能避免问题反复出现。