Temp_relay_log_file 是 MySQL 内部写 relay log 时的瞬时临时文件名前缀，毫秒级存在后即原子重命名为正式 relay log 文件，所谓“丢失”实为生命周期极短且不记录元数据的正常现象。
Temp_relay_log_file 是什么，为什么它“丢失”不是真丢失
Temp_relay_log_file 不是独立存在的文件，而是 MySQL 内部在写入 relay log 时使用的临时命名前缀（如 mysql-relay-bin.000042-1234567890），仅在 rotate 过程中短暂存在。它一旦写满或事务提交，就会被原子重命名为正式的 Relay_Log_File（如 mysql-relay-bin.000042）。所谓“丢失”，其实是没在 ls 或 SHOW SLAVE STATUS 中看到——因为它的生命周期通常只有毫秒级，且不记录在 relay-log.index 或元数据表里。
哪些操作会导致 Temp_relay_log_file 看似“消失”
这不是故障，而是正常行为，但容易被误判为异常：
- MySQL 异常终止（kill -9、断电）：正在写的
Temp_relay_log_file可能残留磁盘但未完成重命名，此时它既不在relay-log.index中，也无法被 SQL 线程读取，SHOW SLAVE STATUS会显示Relay_Log_File滞后或为空 - IO 线程停止后手动删了 relay log 目录下的所有文件：
Temp_relay_log_file本就不存在，删的只是已命名的旧mysql-relay-bin.*；重启后 IO 线程会新建下一个编号，跳过“中间空缺”，所以你找不到那个“该有却没出现”的临时文件 - 启用了
relay_log_recovery=ON并重启：MySQL 启动时检测到 relay log 不完整，会直接丢弃所有未确认的 relay log（含残留的 temp 文件），从Master_Log_File/Read_Master_Log_Pos重建，Temp_relay_log_file自然不会出现在日志路径下
别查 Temp_relay_log_file，要看这三个字段
排查 relay log 问题时，盯着 Temp_relay_log_file 没意义。真正决定复制位置和状态的是：
-
Master_Log_File和Read_Master_Log_Pos：IO 线程已拉取到主库 binlog 的哪个位置，这是唯一可信的“已接收但未执行”位点 -
Relay_Log_File和Relay_Log_Pos：SQL 线程当前正在读哪个 relay log 文件、读到哪，若它卡住不动而Seconds_Behind_Master持续增长，说明 SQL 线程阻塞，不是 temp 文件问题 -
Relay_Master_Log_File和Exec_Master_Log_Pos：已执行完的主库 binlog 位置，仅用于核对一致性，不能用于重设起点（尤其 relay log 损坏后）
真正要担心的是 Relay_Log_Space 持续上涨
如果 Relay_Log_Space 不断增大，且 Slave_SQL_Running: No，那说明 SQL 线程停在某条语句上（比如 1032/1062 错误），IO 线程还在写新的 relay log，旧文件无法清理——这时你看到的不是“temp 文件丢失”，而是 relay log 堆积。解决路径很明确：
- 先看
Last_SQL_Error，定位具体失败语句 - 不要盲目用
sql_slave_skip_counter，GTID 模式下它无效 - 修复数据一致性（比如补回缺失行），再
START SLAVE - 长期运行建议配
relay_log_space_limit = 4294967296（4GB）并监控Relay_Log_Space趋势，避免磁盘打满
Temp_relay_log_file 从来就不是可观察、可依赖的对象。盯错地方，修的就是空气。
