relay_log_purge=ON仅是开关，实际清理需SQL线程执行完且IO线程触发轮转；须查@@global.relay_log_purge确认运行值，不可仅信默认配置；手动PURGE前须验证复制状态、Relay_Log_File及Exec_Master_Log_Pos位置，严禁rm直接删除。
relay_log_purge=ON 是默认值，但不等于“一定在清理”——它只是个开关，真正删不删，全看 SQL 线程有没有执行完、IO 线程有没有触发轮转。
确认 relay_log_purge 实际是否生效
别只信配置文件或文档说的“默认开启”。运行中可能被改过，或者版本行为有差异：
- 查当前值：
SELECT @@global.relay_log_purge;—— 返回0表示关闭，1表示开启 - 查配置文件（如
/etc/my.cnf）中[mysqld]段是否有relay_log_purge = ON（注意不是relay-log-purge，横线写法无效） - MySQL 5.7+ 默认是
ON，但某些定制镜像、旧版或手动改过配置的实例可能设为OFF -
SET GLOBAL relay_log_purge = OFF会报错：ERROR 1238 (HY000): Variable 'relay_log_purge' is a read only variable，说明它只能在启动前配，不能热关
为什么 relay_log_purge=ON 还不删 relay log
自动清理不是定时任务，也不按文件年龄删。它的触发依赖两个硬性条件同时满足：
- SQL 线程必须已完整执行完某个
relay-bin.000xxx文件里的所有 event（看SHOW SLAVE STATUS\G中Relay_Master_Log_File和Exec_Master_Log_Pos是否已越过该文件对应主库 binlog 位置） - IO 线程必须写入新的 relay log 文件（即发生日志轮转），这时 MySQL 才会检查并删除“已执行完且无句柄占用”的旧文件
- 如果复制卡住（
Slave_SQL_Running_State显示Waiting for table metadata lock或长时间Reading event from the relay log），或STOP SLAVE后没再启，IO 线程停写，就不会轮转，也就不会触发清理 -
relay_log_recovery = ON时，MySQL 会强制保留至少一个 relay log 做崩溃恢复，最老的文件删不掉
手动清理前必须验证的三件事
别急着 PURGE RELAY LOGS，先确保你删的是真“已执行完”的文件：
- 执行
SHOW SLAVE STATUS\G，确认Slave_IO_Running: Yes且Slave_SQL_Running: Yes；若为No或NULL，先排查复制中断原因，禁止清理 - 记下
Relay_Log_File（比如relay-bin.000142）——这是 IO 线程正在写的最新文件，**不能删它，也不能删编号 ≥ 它的文件** - 对比
Relay_Master_Log_File和Exec_Master_Log_Pos：如果它们已指向mysql-bin.000138及更后位置，说明relay-bin.000137及之前大概率已执行完，可作为PURGE的安全边界
用 PURGE RELAY LOGS 安全删，而不是 rm 或脚本
直接 rm -f relay-bin.* 会破坏 relay-log.index 一致性，还可能导致 mysqld 持有已删文件句柄（lsof | grep DELETE 可见），空间和 inode 都不释放：
- 安全命令格式：
PURGE RELAY LOGS TO 'relay-bin.000135';—— 删除编号严格小于000135的所有文件（不含000135本身） - 务必保证
TO后的文件名与Relay_Log_File格式一致：前缀+编号，无扩展名、无.index、不加路径 - 加条件更稳妥：
PURGE RELAY LOGS TO 'relay-bin.000135' AND MASTER_LOG_FILE = 'mysql-bin.000138';，避免级联复制中误删其他主库的日志 - 裸执行
PURGE RELAY LOGS;会清空全部 relay log（包括正在读的），导致复制断裂，绝对禁止
真正容易被忽略的是：relay_log_purge 开关本身不解决“SQL 线程卡住”或“IO 线程停摆”这两个根本问题。清理只是止血，得顺着 Slave_SQL_Running_State 和 Seconds_Behind_Master 去查锁、查大事务、查磁盘 I/O，否则删完一小时又堆满。
