必须主动干预，先通过show slave status\g定位io/sql线程状态及last_io/sql_error，再据错误类型选择跳过、重设位置或重建从库；自动重连仅是基础，关键在保障relay log与binlog连续一致。
MySQL 主从复制中断后，不能靠“等它自己恢复”，必须主动干预。自动重连只是基础能力，真正关键的是确保中继日志（Relay Log）和主库二进制日志（Binlog）的连续性与一致性。
检查中断原因再操作
复制中断通常不是网络抖动那么简单，需先定位根本原因，否则重连后很快再次失败。
- 执行 SHOW SLAVE STATUS\G，重点看 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 和 Last_IO_Error/Last_SQL_Error
- 常见错误类型：连接拒绝（主库宕机/防火墙）、SQL线程报错（主键冲突、表结构不一致）、GTID模式下事务缺失或跳过异常
- 确认主库是否正常提供 Binlog，且 server_id 唯一、log_bin 开启、binlog_format=ROW（推荐）
启用自动重连机制
MySQL 5.6+ 默认开启 IO 线程自动重试，但默认参数偏保守，建议显式优化：
- 在从库配置文件中设置：
master-retry-count = 86400（最大重试次数，0 表示无限）
master-connect-retry = 10（重连间隔秒数，建议 5–30 秒） - 重启从库或执行 CHANGE MASTER TO ... 后，这些参数才生效（注意：动态 SET 不影响已运行的复制通道）
- 若使用 MySQL 8.0+ 多源复制，需对每个通道单独配置 MASTER_RETRY_COUNT 和 MASTER_CONNECT_RETRY
修复日志断点并同步数据
单纯 START SLAVE 往往无效，尤其当 Relay Log 已损坏或位置落后于主库 Binlog 时，必须手动对齐日志位点。
- 若错误可跳过（如唯一键冲突且业务允许），用 SET GLOBAL sql_slave_skip_counter = 1（传统复制）或 SELECT GTID_SUBTRACT(...) + SET GTID_NEXT（GTID 模式）
- 若需精确恢复：在主库查出中断时刻的 Binlog 文件名和位置（SHOW MASTER LOGS + mysqlbinlog --base64-output=decode-rows -v 分析），再在从库执行 CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy
- GTID 场景更推荐用 RESET SLAVE ALL + CHANGE MASTER TO MASTER_AUTO_POSITION = 1，让从库自动拉取缺失事务（前提是主库 Binlog 未被清理）
预防后续中断的关键配置
避免反复人工介入，核心是增强复制鲁棒性和可观测性。
- 主库开启 binlog_gtid_simple_recovery=ON，减少 GTID 集合计算错误
- 从库启用 relay_log_purge=ON（默认）并定期清理旧 Relay Log；同时设置 relay_log_recovery=ON，崩溃重启后自动重建 Relay Log
- 部署监控：监听 Seconds_Behind_Master > 60 或 Slave_SQL_Running=No，配合告警（如 Prometheus + mysqld_exporter）
- 避免在从库写入，禁止 read_only=OFF（除非明确需要临时写）
