故障定位与状态检查
当主从同步中断时，首先需登录从库，通过命令确认同步状态与错误信息：
- 执行 SHOW SLAVE STATUS\G，重点关注 Slave_IO_Running、Slave_SQL_Running 和 Last_Error 字段。
- 若 IO 线程为 No，检查网络连通性、主库 binlog 位置以及复制用户权限。
- 若 SQL 线程为 No，则需分析 Last_Error 中的具体异常（如主键冲突、表不存在、binlog 格式不兼容等）。
按错误类型执行修复
SQL 线程报错（常见于数据冲突）
可通过跳过单条或批量错误来恢复同步（仅限可接受数据不一致的场景）：
- 临时设置 SET GLOBAL sql_slave_skip_counter = 1;，然后执行 START SLAVE; 跳过一步。
- 若需批量跳过，可修改从库配置 slave_skip_errors（如 1062,1032 等错误代码），重启从库后生效。
- 注意：跳过操作会丢失数据，建议先记录错误位置并在主库补偿缺失数据。
IO 线程报错（binlog 丢失或网络问题）
当主库 binlog 已被清理或从库 relay log 损坏时，需重新搭建从库：
- 在主库执行 FLUSH TABLES WITH READ LOCK; 获取当前 GTID 或 binlog 位置（若使用 GTID 模式则可省略此步）。
- 使用 mysqldump 或 XtraBackup 对主库进行一致性备份。
- 将备份恢复到从库，并配置新的 CHANGE MASTER TO 语句，指定正确的 binlog 文件名和偏移量（或 GTID 集合）。
- 解除主库锁：UNLOCK TABLES;，然后启动从库：START SLAVE;。
验证同步完整性
修复完成后，持续监控从库状态：
- 确认 Seconds_Behind_Master 逐渐减小直至 0。
- 在主库执行更新操作，观察从库是否立即同步。
- 检查 Relay_Log_Space 是否稳定，避免 relay log 堆积。
预防措施与最佳实践
- 启用 GTID 模式（gtid_mode=ON）简化主从切换与修复流程。
- 设置合理的 binlog 过期时间（expire_logs_days）及 relay log 自动清理策略。
- 定期对从库运行 CHECK TABLE 和 PT-Heartbeat 监控延迟。
- 主库与从库之间使用专线或高可用网络，避免因网络抖动导致 IO 中断。
