从库重连主库做增量同步的核心是确保从库能准确“追上”主库中断后产生的所有变更，需先确认中断点并校验binlog可用性，再根据场景选择自动恢复、手动重置位置或gtid自动续接。
从库重连主库时做增量同步，核心是让从库“追上”主库自上次中断后产生的所有变更，而不是全量重建。关键不在于重连动作本身，而是确保复制能从正确的位置继续、且中间没有数据断层。
确认中断点并校验 binlog 可用性
从库重连前，先确认主库是否还保留着从库缺失的 binlog 文件：
- 在从库执行
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File和Exec_Master_Log_Pos—— 这是从库已成功执行到的主库 binlog 位置 - 登录主库，运行
SHOW BINARY LOGS;，检查上述文件名是否仍在列表中；若已滚动删除（如提示 “Could not find first log file name”），说明 binlog 断档，必须重建从库 - 若文件存在，再用
SHOW MASTER STATUS;确认当前最新位置，比对差距大小，判断是否适合增量追平
直接恢复复制链路（推荐场景）
适用于：网络闪断、临时宕机、权限短暂失效等短时中断，且 binlog 完整未丢。
- 在从库执行：
STOP SLAVE; - 检查
SHOW SLAVE STATUS\G中的Last_IO_Error或Last_SQL_Error，针对性修复（比如修复网络通路、重置复制账号密码、补授权） - 无需修改
CHANGE MASTER TO—— 位置信息仍保留在内存中，直接执行：START SLAVE; - 观察
Seconds_Behind_Master是否开始下降，Slave_IO_Running和Slave_SQL_Running均为Yes即表示增量同步已自动恢复
手动重置复制位置（位置偏移或配置丢失时）
适用于：从库重启后复制位点丢失、误执行了 RESET SLAVE、或主库发生过 FLUSH LOGS 导致 position 不连续。
- 在主库执行
SHOW MASTER STATUS;，获取当前File和Position - 在从库执行：
STOP SLAVE; - 执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=123456;（填入主库刚查到的值） - 再执行
START SLAVE; - 注意：该操作会丢弃从库尚未应用的 relay log，但只要主库 binlog 没丢，就不会漏数据
GTID 模式下的增量续接（更可靠）
如果主从均启用 GTID（gtid_mode=ON），重连逻辑更简单，不依赖文件名和 position：
- 从库执行：
STOP SLAVE; - 确认主库 GTID 集合：
SELECT @@global.gtid_executed; - 从库执行：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1; - 再执行：
START SLAVE; - MySQL 自动计算缺失事务并拉取应用，无需人工定位位置，抗中断能力更强
