MySQL的relay log是用于主从复制过程中，从服务器（Slave）记录来自主服务器（Master）的二进制日志事件的临时文件。随着时间推移，这些日志可能占用大量磁盘空间，因此需要定期清理。
清理relay log的核心原则是：确保不影响正在进行的复制任务，避免误删关键日志导致复制中断或数据不一致。
1. 启用自动清理（推荐）
最安全、最常用的方式是开启MySQL的自动清理功能。通过设置参数 relay_log_purge 为 ON（默认值），MySQL会在SQL线程应用完relay log后自动清除它们。
操作方法：
在从库的配置文件 my.cnf 或 my.ini 中添加或确认以下配置： relay_log_purge = ON 重启MySQL服务使配置生效（如果之前未启用）。这样，当IO线程接收到新的binlog事件并写入relay log，而SQL线程已经执行完毕后，系统会自动清理已处理的relay log文件。
2. 手动清理relay log
在某些维护场景下，可能需要手动清理relay log，比如重置复制或修复异常状态。
注意：手动操作前请确认复制已停止或处于安全状态，避免数据丢失。
登录MySQL从库，执行： STOP SLAVE; 然后执行： RESET SLAVE; 该命令会删除所有relay log文件，并清空master.info和relay-log.info信息。 若只想删除relay log但保留复制位置信息，可使用： RESET SLAVE PURGE RELAY LOGS; 完成后如需恢复复制，需重新执行 CHANGE MASTER TO ... 命令。3. 使用 SQL 命令控制清理行为
MySQL提供了一些命令用于管理relay log，适合日常运维。
PURGE RELAY LOGS：可以指定清理到某个relay log文件之前的内容。例如：
PURGE RELAY LOGS TO 'relay-bin.000005'; 这会删除编号小于 000005 的所有relay log文件。 执行此命令前建议确认SQL线程已执行到该文件之后的位置，可通过 SHOW SLAVE STATUS 查看 Relay_Log_File 值。4. 监控与检查
在清理前，应检查复制状态是否正常：
SHOW SLAVE STATUS\G 关注 Relay_Master_Log_File、Exec_Master_Log_Pos 和 Relay_Log_Space 等字段。 确认SQL线程无延迟且运行中（Slave_SQL_Running: Yes）。也可以通过操作系统命令查看relay log文件大小和数量：
ls -lh /path/to/relay-logs/路径通常在datadir下，文件名类似 hostname-relay-bin.xxxxxx。
基本上就这些。只要开启了 relay_log_purge=ON，大多数情况下不需要手动干预。特殊操作前务必确认复制状态，避免破坏数据一致性。
