relay_log_purge=ON仅在SQL线程执行完且IO线程轮转时条件性清理单个文件，不保证自动清除堆积；须先查SELECT @@global.relay_log_purge确认运行值为1，再通过STOP SLAVE→PURGE RELAY LOGS TO→START SLAVE安全清理。
relay_log_purge=ON 默认开着，但不等于 relay log 会自动清掉——它只在特定条件下顺手删一个文件，高延迟、空闲、卡住时基本不干活。真要清理堆积，得人工介入判断 + 命令执行。
确认 relay_log_purge 实际是否生效
别信配置文件里写的 relay_log_purge = ON，也别信“MySQL 5.7+ 默认开启”这种说法。运行中可能被改过，或某些定制镜像默认关了：
- 查当前值：
SELECT @@global.relay_log_purge;—— 返回1才真开着，0就是关了 -
SET GLOBAL relay_log_purge = OFF会报错ERROR 1238 (HY000): Variable 'relay_log_purge' is a read only variable，说明它只能启动前配，不能热改 - 配置文件中写成
relay-log-purge = ON（带横线）无效，必须是relay_log_purge = ON
PURGE RELAY LOGS TO 命令为什么总删错？
这个命令看着精准，实则风险高，因为 MySQL 不校验你删的文件是不是还在被读：
- 它按文件名**字典序**删，不是按内容顺序；如果 relay log 文件名跳号（比如 .000010 后直接 .000015），
PURGE RELAY LOGS TO 'mysql-relay-bin.000012'可能误删正在写的 .000015 - 命令执行前不检查
Relay_Log_File是否已越过目标编号，删完才发现 SQL 线程还在读 .000011 -
PURGE RELAY LOGS BEFORE '2026-04-10 00:00:00'是非法语法，MySQL 直接报ERROR 1064 (42000)
安全清理 relay log 的三步操作流
不能靠等自动，也不能直接 rm -f。每次清理都必须停复制、核对位置、再执行：
- 先看复制状态：
SHOW SLAVE STATUS\G，确认Slave_IO_Running: Yes、Slave_SQL_Running: Yes，且Seconds_Behind_Master接近 0 - 记下
Relay_Log_File: mysql-relay-bin.000027，说明编号 ≤ .000026 的文件大概率已执行完（需再比对Relay_Master_Log_File和Exec_Master_Log_Pos是否已越过对应主库 binlog 位置） - 执行：
STOP SLAVE;→PURGE RELAY LOGS TO 'mysql-relay-bin.000027';→START SLAVE;
RESET SLAVE 和 RESET SLAVE ALL 到底该用哪个？
这两个命令不是“清理 relay log 的快捷方式”，而是重置复制元数据的重型操作：
-
RESET SLAVE;清空所有 relay log 文件，并重置relay-log.info（或mysql.slave_relay_log_info表），但保留CHANGE MASTER TO配置信息，适合临时清空后快速恢复同步 -
RESET SLAVE ALL;除了清日志，还会清掉 master host/port/user/password 等全部复制配置，相当于把从库“变回白板”，仅适用于重建复制场景 - 两者都会导致
Relay_Log_File从头开始命名（如mysqld-relay-bin.000001），但不会影响已应用的数据
Exec_Master_Log_Pos 是否真的跑过了目标文件对应的主库 binlog 位点——这点一旦错，复制就断，且无法自动修复。 
