relay_log_purge=OFF会导致中继日志持续累积、磁盘被撑爆且无法通过重启恢复，必须人工介入止损；MySQL彻底放弃自动清理逻辑，所有relay log文件只增不减，直至手动清理或重搭从库。

relay_log_purge=OFF 会直接导致磁盘被撑爆，且无法靠重启恢复，必须人工介入才能止损。

关闭 relay_log_purge 后，中继日志只增不减

MySQL 不会在 relay_log_purge=OFF 时做任何自动清理判断。SQL 线程执行完一个 relay-bin.000xxx 文件后，文件仍原封不动留在磁盘上；IO 线程继续追写新文件，旧文件越积越多——尤其当复制延迟高、或从库停用期间，/var/lib/mysql/ 下可能在几小时内生成数百个 relay log 文件。

• 文件系统元数据压力变大：ls -l /var/lib/mysql/ | wc -l 超过 500 就会影响目录遍历性能
• 备份工具（如 mydumper）扫描全目录时明显变慢
• xtrabackup 虽跳过 relay log，但监控脚本若遍历整个数据目录也会卡住

它不是“暂停清理”，而是彻底交出空间管理权

开启 relay_log_purge=ON 是让 MySQL 在 SQL 线程执行完 + IO 线程轮转后顺手删文件；而设为 OFF 后，MySQL 完全放弃这个逻辑，相当于把所有 relay log 的生命周期管理权移交给你自己。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 没有定时任务、没有水位告警、不响应磁盘满信号
• MySQL 重启也不会自动清理——除非你改回 ON 并手动 FLUSH LOGS 或等 SQL 线程重跑一遍
• 某些定制镜像或旧版配置里默认就是 OFF，不能只信“没配就等于 ON”

误关后最危险的连锁反应

磁盘占满 → SQL 线程 halt → Slave_SQL_Running: No → 复制中断 → 主库新 binlog 持续产生 → 从库永远追不上 → 更多 relay log 堆积，形成死循环。

• 此时 PURGE RELAY LOGS TO 'xxx' 也大概率失败：SQL 线程已停止，Relay_Log_File 不再更新，你无法安全确定哪些文件真能删
• RESET SLAVE 会清空 relay log 和复制位置，但意味着你要重搭从库，数据一致性需额外校验
• 若同时开了 relay_log_recovery=ON，崩溃重启后还会尝试重建 relay log，进一步加剧磁盘压力

真正要防的是“以为关了更安全”，结果发现清理责任根本不在数据库身上——它只管执行，不管善后。