怎么在MySQL主从复制中断后根据binlog位置点快速续传-mysql教程-PHP中文网

续传前提是从库relay_master_log_file在主库show binary logs中存在，否则无法续传；需先stop slave，比对主从位点，非gtid模式用change master to重设合法file和position，gtid模式则必须启用master_auto_position=1并确保gtid集合连续。

怎么在mysql主从复制中断后根据binlog位置点快速续传

确认从库当前位点和主库binlog可用性

续传的前提是主库还存着从库要读的那个 binlog 文件，且 position 没被跳过或截断。别一上来就 START SLAVE，先看关键字段：

SHOW SLAVE STATUS\G 中关注 Relay_Master_Log_File 和 Exec_Master_Log_Pos —— 这是从库“认为自己该从哪儿接着读”
登录主库执行 SHOW BINARY LOGS;，检查列表里是否存在 Relay_Master_Log_File 对应的文件名（比如 mysql-bin.000015）
如果主库已没有该文件，Could not find first log file name in binary log index file 错误必然出现，此时无法续传，只能重建

常见误判：看到 Seconds_Behind_Master: NULL 就以为只是延迟，其实 Slave_IO_Running: No 才说明 IO 线程早停了，得先查错因，不是调位置就能解决。

非 GTID 模式下用 CHANGE MASTER TO 指定位点重连

确认主库 binlog 可用后，直接重置复制起点。注意：这不是“跳过错误”，而是让从库从一个已知安全、主库仍存在的位置重新拉日志。

在从库执行：STOP SLAVE;
查主库当前最新位置：SHOW MASTER STATUS;，记下 File 和 Position
若从库原卡在 mysql-bin.000014 的 123456，而主库最新是 mysql-bin.000015 的 789012，且 mysql-bin.000014 仍存在，则可继续用原文件+原位置：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000014', MASTER_LOG_POS=123456;
如果主库已滚动到 mysql-bin.000015，但你想让从库从新文件开头开始追（比如已确认旧文件末尾无有效事务），就指定：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=154;（binlog 文件头固定 154 字节）
最后 START SLAVE;，再 SHOW SLAVE STATUS\G 看 Slave_IO_Running 是否变为 Yes

容易踩的坑：MASTER_LOG_POS 必须是事件起始位置，不能填 end_log_pos；填错会导致解析失败或跳过半个事务。ROW 格式下尤其敏感，因为一个 UPDATE 可能跨多个事件。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

GTID 模式下必须用 MASTER_AUTO_POSITION=1

启用了 gtid_mode=ON 却还手动填 MASTER_LOG_FILE 和 MASTER_LOG_POS，MySQL 会直接忽略——它只认 GTID 集合。续传逻辑完全不同。

确保主从都开启 GTID，且 enforce_gtid_consistency=ON
从库执行：STOP SLAVE; → RESET SLAVE;（清空旧 relay log 和复制元数据）
然后只用这一条：CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;
START SLAVE; 后，MySQL 自动比对 SELECT @@GLOBAL.gtid_executed; 和主库的 GTID 集合，只拉缺失部分

关键点：如果主库执行过 PURGE BINARY LOGS 导致部分 GTID 被清理，从库 START SLAVE 会报 Cannot replicate because the master purged required binary logs —— 这说明 GTID 集合已不连续，同样无法续传，必须重建。

续传后必须验证 SQL 线程是否真在跑、数据是否漂移

看到 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 不代表万事大吉。很多静默漂移发生在续传之后。

紧盯 Seconds_Behind_Master：如果持续为 0 或稳定在个位数，说明追得上；如果缓慢上涨，可能是从库性能瓶颈或主库写入突增
检查 Relay_Log_Space 是否持续增长：不涨说明没新 relay log 写入，IO 线程可能假活
抽样比对主从同一条记录：SELECT id, updated_at FROM tbl WHERE id IN (123, 456) ORDER BY id;，时间戳或自增 ID 不一致就是漂移信号
特别注意 binlog_format=ROW 下的 binlog_row_image=MINIMAL：UPDATE 只记新值，从库回放时若旧值已变，可能覆盖错误数据，这种漂移不会报错

最易被忽略的是：续传成功后，没人去核对 gtid_executed 集合是否最终收敛。只要集合不全等，下次中断就可能再次卡住——这不是操作问题，是设计前提没守住。