主从复制位点配置错误时，必须以主库执行 SHOW MASTER STATUS 输出的 File 和 Position 为准进行重新设置；如果使用 GTID 模式，则必须开启 MASTER_AUTO_POSITION=1，并且不能再同时使用 MASTER_LOG_FILE / MASTER_LOG_POS。
当你执行 SHOW SLA VE STATUSG 命令后，如果发现 Exec_Master_Log_Pos 或 Relay_Log_Pos 一直没有变化，Seconds_Behind_Master 显示为 NULL，并且 Sla ve_IO_Running 与 Sla ve_SQL_Running 都是 No，那么基本可以判断是 MySQL 主从复制位点（position）配置错误。这通常表示从库正尝试从主库已经删除，或者根本不存在的 binlog 文件及位置开始读取日志数据。
为什么位点会错？常见触发场景
MySQL 复制位点出错并不是偶然现象，绝大多数情况都与人工操作或配置遗漏有关：
- 主库 binlog 被手动执行
PURGE BINARY LOGS清理，但从库仍然记录着旧的日志文件名（如mysql-bin.000012）和旧位置（如123456789） - 从库重启之后，没有重新指定正确的
MASTER_LOG_FILE和MASTER_LOG_POS，直接执行START SLA VE，导致继续使用上一次中断的失效位点 - 主库执行过 binlog 重置（
RESET MASTER），但从库端并未同步更新复制配置 - 错误使用
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=0，把复制位置设置为 0，而 binlog 文件头本身是不可执行的
如何快速确认是位点问题？看这三个字段
在从库执行 SHOW SLA VE STATUSG 后，建议重点检查以下几个关键字段：
Last_IO_Error出现Could not find first log file name in binary log index file或Could not open log file→ 说明 IO 线程无法读取对应的 binlog 文件，基本可以确定是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→ 说明复制位点已经卡住，主从复制线程无法继续推进
修复步骤：先查主库当前位点，再重设从库
修复 MySQL 主从复制位点错误不能靠猜，必须严格以主库当前状态为准：
- 先在主库执行
SHOW MASTER STATUSG，记录当前的File（例如mysql-bin.000023）和Position（例如1987） - 然后在从库停止复制：
STOP SLA VE; - 通过
CHANGE MASTER TO重新设置复制位点，注意文件名和位置必须同时指定：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000023', MASTER_LOG_POS=1987; - 重新启动复制：
START SLA VE; - 最后立即验证：
SHOW SLA VE STATUSG，确认Sla ve_IO_Running和Sla ve_SQL_Running都恢复为Yes，并且Seconds_Behind_Master开始逐步下降
如果主库已经开启 GTID（gtid_mode=ON），那么修复复制位点的方式就完全不同了。此时不能再继续使用 MASTER_LOG_FILE / MASTER_LOG_POS，而是应结合实际情况通过 SET GTID_NEXT 注入空事务，或者先执行 RESET SLA VE ALL，再重新执行 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1。如果把传统位点模式与 GTID 自动定位混用，往往会导致 MySQL 主从复制直接中断，且难以自动恢复。
