relay_log_purge=on是自动清理中继日志的唯一有效开关，仅在sql线程执行完对应日志后立即删除，需确保sql已追平io（relay_master_log_file序号≤relay_log_file序号）才可安全启用。
relay_log_purge=ON 是自动清理中继日志的唯一有效开关
MySQL 从库默认开启 relay_log_purge，但很多生产环境因误操作或定制镜像被设为 OFF，导致 relay-bin.000xxx 文件持续堆积、磁盘爆满。它不是定时任务，也不看时间或大小，只在 SQL 线程执行完某段中继日志后立刻删除该文件——前提是 relay_log_purge=ON。
检查当前状态：SELECT @@global.relay_log_purge;，返回 0 就必须处理。
- 运行时启用：
SET GLOBAL relay_log_purge = ON; - 持久化配置：在
/etc/my.cnf的[mysqld]段添加relay_log_purge = ON，重启生效 - 注意：
relay_log_purge是只读变量，不能在运行中设为OFF；设为ON后，旧日志不会“马上消失”，要等 SQL 线程追平才删
清理前必须确认 SQL 线程已追平，否则会丢数据
盲目开 relay_log_purge 可能删掉还没执行的日志。关键看 SHOW SLAVE STATUS\G 里两个字段：
-
Relay_Log_File：IO 线程正在写的中继日志（比如relay-bin.000142） -
Relay_Master_Log_File：SQL 线程已执行到的主库 binlog（比如mysql-bin.000140）
只有当 Relay_Master_Log_File 对应的序号 ≤ Relay_Log_File 的序号（即 SQL 已追上 IO），才能安全启用自动清理。如果差距大（如 relay-bin.000135 vs mysql-bin.000120），先等同步，或手动 STOP SLAVE; START SLAVE; 触发一次重载检查。
relay_log_space_limit 是防积压的兜底机制
relay_log_purge=ON 解决的是“执行完就删”，但扛不住突发卡顿（比如主库批量写入、从库锁等待）。这时候靠 relay_log_space_limit 限制总空间，避免磁盘被撑死。
- 单位是字节，例如设为
4294967296（4GB） - 必须写进配置文件
[mysqld]段，不支持动态修改 - 超出后 SQL 线程会报错停止，并在 error log 记录：
Relay log write failure: The relay log is full - 和
relay_log_purge搭配使用，才是稳态组合
RESET SLAVE 不是日常清理手段，而是异常兜底
当复制中断、Seconds_Behind_Master 为 NULL 或 SQL 线程卡死时，relay_log_purge 不起作用，中继日志会越积越多。此时不能 rm -f，也不能指望 FLUSH LOGS（它对 relay log 完全无效）。
正确做法是：RESET SLAVE —— 它会清空所有中继日志文件、重置 Relay_Log_File 和 Relay_Log_Pos，但保留主库连接信息（MASTER_HOST 等），执行后需手动 START SLAVE。
⚠️ 注意：RESET SLAVE ALL 会连连接信息一起清，除非你要彻底重建复制链路，否则别用。
真正容易被忽略的点是：自动清理依赖 SQL 线程进度，而进度又受主从延迟、锁、大事务影响。光配 relay_log_purge=ON 不够，得配合 relay_log_space_limit + 定期检查 SHOW SLAVE STATUS 中的 Relay_Master_Log_File 和 Relay_Log_File 差距。
