relay_log_purge=off会导致中继日志持续累积、磁盘空间耗尽、io性能下降及备份变慢；即使设为on，清理仍依赖sql线程执行完且io线程轮转，否则不触发删除；purge relay logs需谨慎按文件名操作，避免误删；relay_log_recovery=on与relay_log_purge=off共用存在数据一致性风险。
relay_log_purge=OFF 会显著放大磁盘 I/O 和空间管理负担
关闭自动清理不是“不删日志”那么简单，而是把日志生命周期完全交给人肉运维。MySQL 不再判断哪些文件已执行完、可安全释放，所有 relay log 都会一直留在磁盘上，直到你手动干预。这意味着：
-
Relay_Log_Space持续增长，尤其在主库高写入或从库 SQL 线程卡顿（如锁表、大事务）时，可能几小时内就占满分区 - IO 线程持续追写新文件，同时文件系统要维护数百个
mysqld-relay-bin.000xxx文件的元数据，ls -l /var/lib/mysql/ | wc -l超过 500 就会影响目录遍历性能 - 备份工具（如
mysqldump、mydumper）扫描数据目录时更慢，某些物理备份方案（如 xtrabackup）虽跳过 relay log，但监控脚本若遍历全目录也会卡住
relay_log_purge=ON 并不等于“零开销”，它依赖 SQL 和 IO 线程协同触发
开启只是放行了清理逻辑，真正删除动作由两个线程状态共同决定：SQL 线程必须已执行完某文件全部 event，且 IO 线程必须完成一次轮转（即写入新文件）。常见误判是看到 SELECT @@global.relay_log_purge 返回 1 就以为万事大吉——但若复制中断、Slave_SQL_Running: No，或 STOP SLAVE 后未重启，IO 线程停摆，就不会轮转，也就不会触发任何删除。
典型表现是 Relay_Log_Space 不降反升，而 SHOW SLAVE STATUS\G 中 Relay_Master_Log_File 和 Exec_Master_Log_Pos 已停滞多小时。
PURGE RELAY LOGS 手动清理时，时间精度和文件边界容易出错
用 PURGE RELAY LOGS BEFORE '2024-05-20 00:00:00' 看似安全，但该时间是 MySQL 服务器时区（SELECT @@time_zone），不是系统时区；若设为 SYSTEM 或未显式指定，可能因时区配置差异误删正在读的文件。
更常用的是按文件名清理：PURGE RELAY LOGS TO 'mysqld-relay-bin.000123'。注意这个 000123 是“保留编号 ≥ 123 的文件”，即删除所有编号小于它的文件。但必须先确认当前 Relay_Log_File 是 mysqld-relay-bin.000125，否则删到 000123 就等于删掉了 SQL 线程下一个要读的文件，导致复制报错 Could not parse relay log event entry。
relay_log_recovery=ON + relay_log_purge=OFF 组合存在一致性风险
这是最危险的配置组合。文档明确警告：Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.
原因在于崩溃恢复流程：MySQL 重启时，若 relay_log_recovery=ON，会丢弃旧 relay-log.info，根据 slave_relay_log_info 表中最后执行位置重新拉取 binlog；但若 relay_log_purge=OFF，旧 relay log 还在磁盘上，而新拉取的内容可能和旧文件中未执行完的部分重叠或缺失——轻则重复执行，重则漏执行，最终主从数据不一致。
这种问题不会立刻暴露，往往在 failover 后才浮现，排查成本极高。
