位点配置错误需以主库SHOW MASTER STATUS输出的File和Position为准重设，GTID模式下必须启用MASTER_AUTO_POSITION=1且禁用MASTER_LOG_FILE/POS。
SHOW SLAVE STATUS\G 显示 Exec_Master_Log_Pos 或 Relay_Log_Pos 停滞、Seconds_Behind_Master 为 NULL，且 Slave_IO_Running 和 Slave_SQL_Running 都是 No，基本可以判定是位点（position）配置错误 —— 从库试图从一个主库已删除或根本不存在的 binlog 文件/位置开始读取。
为什么位点会错？常见触发场景
位点错误不是随机发生的，几乎都源于人工干预或配置疏漏：
- 主库 binlog 被手动
PURGE BINARY LOGS清理，但从库还记着旧文件名（如mysql-bin.000012）和旧位置（如123456789） - 从库重启后未指定正确
MASTER_LOG_FILE和MASTER_LOG_POS，直接START SLAVE导致沿用上次中断点（而该点已失效） - 主库重置过 binlog（
RESET MASTER），但从库没同步更新配置 - 误用
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=0，把位置设为 0（binlog 文件头不可执行）
如何快速确认是位点问题？看这三个字段
在从库执行 SHOW SLAVE STATUS\G 后，重点盯住：
-
Last_IO_Error出现Could not find first log file name in binary log index file或Could not open log file→ IO 线程根本连不到 binlog 文件，100% 是MASTER_LOG_FILE错了 -
Last_SQL_Error是Could not parse relay log event entry或位置越界提示 → SQL 线程读到了损坏或不匹配的 relay log，大概率是MASTER_LOG_POS超出当前 binlog 实际长度 -
Relay_Master_Log_File和Exec_Master_Log_Pos长期不变，且Seconds_Behind_Master为NULL→ 位点卡死，复制线程无法推进
修复步骤：先查主库当前位点，再重设从库
不能靠猜，必须严格对齐主库实时状态：
- 在主库执行
SHOW MASTER STATUS\G，记录下File（如mysql-bin.000023）和Position（如1987） - 在从库停掉复制：
STOP SLAVE; - 用
CHANGE MASTER TO重设位点，注意必须同时指定文件名和位置：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000023', MASTER_LOG_POS=1987; - 启动复制：
START SLAVE; - 立刻验证：
SHOW SLAVE STATUS\G，确认Slave_IO_Running和Slave_SQL_Running都是Yes，且Seconds_Behind_Master开始下降
如果主库启用了 GTID（gtid_mode=ON），位点修复逻辑完全不同 —— 此时不能用 MASTER_LOG_FILE/POS，必须用 SET GTID_NEXT 注入空事务或执行 RESET SLAVE ALL 后重新 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1。强行混用会直接导致复制永久中断。
