MySQL从库IO线程卡在“找文件”失败，主库binlog被清理导致ERROR 1236，Slave_IO_Running变为No且Last_IO_Error常为空；GTID模式下若主库gtid_purged不全，同样卡住且无明显报错。
从库IO线程卡在“找文件”这一步就失败了
MySQL从库的IO_THREAD不是边拉边猜，而是带着明确坐标去主库请求：「我要读mysql-bin.000127这个文件，从位置124893开始」。如果主库磁盘上已经没有mysql-bin.000127（比如被expire_logs_days=1自动清理，或人为PURGE BINARY LOGS），主库直接返回错误ERROR 1236 (HY000): Could not find first log file name in binary log index file。IO线程无法继续，立刻停止，Slave_IO_Running变成No，后续所有同步动作全部冻结。
复制坐标（Relay_Master_Log_File + Exec_Master_Log_Pos）指向一个不存在的文件
从库内部靠两个关键字段记住自己“看到哪儿了”：Relay_Master_Log_File记录它上次成功读取的主库binlog文件名，Exec_Master_Log_Pos记录对应位置。一旦这个文件被主库删掉，这两个值就变成了“无效地址”。你执行START SLAVE时，MySQL不会自动帮你往前或往后跳——它只会忠实地尝试重连并读那个已消失的文件，反复失败。
- 强行
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy可能跳过，但风险极高：位置错一点，轻则数据不一致，重则SQL线程解析失败报错 -
SET GLOBAL sql_slave_skip_counter = 1对IO线程错误完全无效，它只影响SQL线程回放阶段 - 重启mysqld、重连网络、检查权限……这些操作全无意义，因为问题不在连接层，而在binlog生命周期管理本身
GTID模式下看似能“自动定位”，但前提是你没丢GTID集合
MySQL 5.7+启用GTID后，从库不再依赖文件名+位置，而是靠Executed_Gtid_Set和Retrieved_Gtid_Set来判断缺失哪些事务。但这有个硬前提：主库必须保留所有已分配GTID对应的binlog事件。如果主库删掉了包含uuid:1-1000的mysql-bin.000127，而从库还没执行完uuid:999，那它就永远卡在“我需要uuid:999，但主库说查无此事务”状态——SHOW SLAVE STATUS里Retrieved_Gtid_Set停住不动，Seconds_Behind_Master为NULL，Slave_IO_Running为No。
- 主库
gtid_purged必须包含所有已提交但未被从库接收的GTID，否则GTID复制链就断了 -
RESET MASTER会清空gtid_purged并重置所有binlog，等同于主动切断所有从库的GTID同步能力 - 别信“GTID能自动修复一切”，它只是把“找文件”换成了“找GTID”，底层依赖没变：binlog还在，GTID才有意义
真正要命的是：它不报错到日志里，就卡在那儿等你发现
很多运维第一次遇到这个问题，是业务方反馈“从库查不到最新数据”，才去查SHOW SLAVE STATUS。而Last_IO_Error字段往往为空，Seconds_Behind_Master是NULL，不像SQL线程报错那样有明显Last_SQL_Error提示。最容易被忽略的信号其实是：Slave_IO_Running: No且Slave_SQL_Running: Yes——说明SQL线程还在跑旧relay log，但新数据根本进不来。这时候翻error log，才能看到那行被刷上去又淹没的Got fatal error 1236 from master。
