CHANGE MASTER TO 指向的 binlog 位置必须精确匹配主库当前状态，即严格等于主库 SHOW MASTER STATUS 输出的 File 和 Position；填错会导致同步失败、跳过数据或卡死，GTID 模式下须用 MASTER_AUTO_POSITION=1 并校准 gtid_purged。
CHANGE MASTER TO 指向的 binlog 位置必须精确匹配主库当前状态
从库执行 CHANGE MASTER TO 后无法启动复制，大概率是 MASTER_LOG_FILE 或 MASTER_LOG_POS 偏离了主库真实位置。这个位置不是“大概接近”就行，而是必须严格等于主库 SHOW MASTER STATUS 输出的 File 和 Position（或 GTID 集合）。尤其在迁移后，主库可能已写入新事务、滚动了 binlog，甚至清空过旧日志。
常见错误现象：
-
START SLAVE后Slave_IO_Running: No，Last_IO_Error显示Could not find first log file name in binary log index file - 错误提示
Client requested master to start replication from position > file size - 从库拉到空 relay log，SQL 线程一直卡在
Waiting for dependent transaction to commit
实操建议：
- 主库锁表后立刻执行
SHOW MASTER STATUS，不要中间穿插其他命令 - 若用
mysqldump --master-data=2备份，dump 文件里注释行的CHANGE MASTER TO是备份时刻的位置，但导入从库耗时长，该位置很可能已失效——必须在主库重新查一次 - 如果主库已重启或
PURGE BINARY LOGS过，SHOW BINARY LOGS最老文件早于你记下的MASTER_LOG_FILE，说明位置不可用，不能硬试
GTID 模式下不能靠 position 指定，必须用 GTID_SET 对齐
启用了 gtid_mode=ON 的集群，CHANGE MASTER TO MASTER_LOG_FILE 和 MASTER_LOG_POS 参数会被忽略。强行指定不仅无效，还可能触发 ERROR 1777 (HY000): Setting MASTER_LOG_POS when MASTER_AUTO_POSITION is active is prohibited。
正确做法是让从库的 gtid_executed 包含主库缺失的部分：
- 主库执行
SELECT @@global.gtid_executed;，拿到完整 GTID 集合 - 从库执行
SELECT @@global.gtid_executed;，对比差异 - 若从库 GTID 集合缺失某段，需先重置：
RESET SLAVE ALL;，再设置SET GLOBAL gtid_purged = 'xxx-xxx-xxx:1-1000';（值来自主库输出，且不能包含从库已有部分） - 最后执行
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
注意：gtid_purged 只能设为比当前 gtid_executed 更小的集合，且必须是主库实际产生过的 GTID；设错会导致 START SLAVE 报 ERROR 3546。
从库 relay log 损坏时，CHANGE MASTER TO 会失败但不报明显错误
迁移过程中若从库异常中断、磁盘满或强制 kill mysqld，relay log 文件可能损坏。此时即使 CHANGE MASTER TO 语法正确、位置有效，START SLAVE 仍会卡在 Reading event from the relay log 或直接静默失败——SHOW SLAVE STATUS 中 Seconds_Behind_Master 为 NULL，Relay_Log_File 指向一个不存在或为空的文件。
验证和修复步骤：
- 检查从库数据目录下
relay-log.info文件内容是否与SHOW SLAVE STATUS中显示的Relay_Log_File/Relay_Log_Pos一致 - 用
mysqlbinlog尝试读取当前Relay_Log_File，看是否报Invalid argument或解析失败 - 确认损坏后，必须停复制：
STOP SLAVE IO_THREAD;（别只停 SQL 线程），再删掉所有host-relay-bin.*文件和relay-log.info - 执行
CHANGE MASTER TO ...重新指定位置，再START SLAVE;
迁移后首次 START SLAVE 必须盯住 Seconds_Behind_Master 下降趋势
CHANGE MASTER TO 成功只是起点，真正恢复同步要看数据是否在追平。刚启动时 Seconds_Behind_Master 可能为 NULL 或极大值，这是正常的；但 30 秒内它必须开始下降，且下降速度应与主库写入节奏基本一致。
如果出现以下情况，说明底层仍有隐性问题：
-
Seconds_Behind_Master长时间卡死不动（超 2 分钟） - 数值忽增忽减，反复震荡
- 下降极慢（如每分钟只减 1–2 秒），而主库并无高负载
此时应立刻查：
-
SHOW PROCESSLIST中system user线程是否卡在Waiting for table metadata lock（说明有长事务或 DDL 阻塞） - 从库
innodb_row_lock_waits是否突增（行锁冲突） - 主库
SHOW MASTER STATUS的Position是否在持续增长，排除主库假死
位置对了，线程起了，不代表链路真通——追平过程才是检验同步质量的唯一标尺。
