relay_log_purge=on仅是开关，实际清理需sql线程执行完且io线程触发轮转；须查@@global.relay_log_purge确认运行值，不可仅信默认配置；手动purge前须验证复制状态、relay_log_file及exec_master_log_pos位置，严禁rm直接删除。
relay_log_purge=ON 不等于“自动清完”，不干预就等着磁盘爆满
查 relay_log_purge 实际是否生效
别只看配置文件写了 relay_log_purge = ON，它可能被启动时忽略，或运行中被覆盖。MySQL 5.7+ 默认是 ON，但某些定制镜像、手动改过配置的实例可能设为 OFF。
- 查当前运行值：
SELECT @@global.relay_log_purge;—— 返回1才真开启，0表示关闭 - 查配置文件（如
/etc/my.cnf）中[mysqld]段：必须是relay_log_purge = ON，写成relay-log-purge（带横线）无效 -
SET GLOBAL relay_log_purge = OFF在 MySQL 5.7+ 会报错ERROR 1238 (HY000): Variable 'relay_log_purge' is a read only variable，说明它只能启动前配，不能热关
判断哪些 relay log 真的可删
MySQL 不按时间、不按大小删，只删「SQL 线程已执行完 + IO 线程已轮转出新文件」的旧文件。关键看 SHOW SLAVE STATUS\G 里三组值：
-
Relay_Log_File：IO 线程当前正在写的文件（比如mysql-relay-bin.000127） -
Relay_Master_Log_File和Exec_Master_Log_Pos：SQL 线程已执行到主库哪个 binlog 的哪个位置 - 只有当
Relay_Master_Log_File对应的 binlog 文件编号 ≤mysql-relay-bin.000126（即比Relay_Log_File小），且Exec_Master_Log_Pos已越过该文件末尾，才说明.000126及更早的 relay log 确实已执行完
如果 Seconds_Behind_Master 持续增长，或 Slave_SQL_Running_State 显示 Waiting for table metadata lock，那旧文件根本不会被标记为“可删”。
PURGE RELAY LOGS 命令怎么用才安全
PURGE RELAY LOGS TO 是最常用也最容易误删的命令。它不校验内容，只按文件名字典序删——一旦 relay log 编号跳变或被重命名，就可能把正在写的文件干掉。
- 执行前必须
STOP SLAVE;：确保 IO 和 SQL 线程都停住，避免删到一半被覆盖 - 目标文件名要保守：比如
Relay_Log_File是mysql-relay-bin.000127，那就PURGE RELAY LOGS TO 'mysql-relay-bin.000127';（删的是.000126及之前） - 不支持
BEFORE '2026-06-01 00:00:00'语法，MySQL 直接报ERROR 1064 (42000) - 加
AND MASTER_LOG_FILE = 'binlog.000456'可多一层过滤，防止跨主库 binlog 范围误删
RESET SLAVE 什么情况下能用
RESET SLAVE 会清空所有 relay log 并重置复制状态（包括 master.info 和 relay-log.info），等价于从头开始同步。它不是“清理”，而是“重建”。
- 仅适用于：从库已彻底失效、无法追平、准备重搭；或磁盘已满到连
STOP SLAVE都执行不了 -
RESET SLAVE ALL还会清掉CHANGE MASTER TO配置，慎用——之后必须重新执行CHANGE MASTER TO - 绝对不要在复制正常时跑
RESET SLAVE：它不检查是否追平，直接丢弃全部中继日志，可能导致数据丢失
真正难的不是命令怎么敲，而是每次清理前得确认 SQL 线程到底执行到哪了——这个位置藏在 Relay_Master_Log_File 和 Exec_Master_Log_Pos 的组合里，少看一眼就可能删错。
