MySQL主从复制当中，对于Relay log认知，都是MySQL自行回放，自行管理的。但偶尔情况也会发现Relay Log堆积，无法自动删除的情况。
MySQL主从复制中，从库接受主库binlog之后，写入Relay log里。从库回放Relay Log文件里的SQL语句。
这里Relay Log文件的格式与binlog文件相同，由一组编号文件和一个索引文件组成，前者包含描述数据库更改的事件，后者包含所有使用的log文件的名称。
备注：Relay Log可以使用mysqlbinlog读取的，碰到一些故障和分析问题时，可以一样读取Relay Log。
那什么时候删除Relay Log文件，有谁负责处理这个文件
从库复制机制里重要角色就是IO Thread 和 SQL Thread。
- IO Thread负责写入完Relay Log之后，判断当前文件是否超过max_relay_log_size 如果超过则自动生成一个新的relay-log-file。
- SQL Thread每执行完一个events时判断，如果该Relay Log已经不再需要则自动删除Relay Log文件。目前除了这个，没有明确的机制。
但是，FLUSH logs会旋转Relay Log，这会影响复制SQL Thread删除 Relay Log的清除。
所以总结下来，清除Relay Log是由SQL Thread负责。如果SQL Thread 太繁忙就有可能，导致Relay Log无法及时清除。
解决relaylog占用空间大的问题
可以使用以下几种：
-
relay_log_purge:
从库的复制线程在应用完Relay Log中的事务后，自动清空不再需要Relay Log。默认值为1(启用)。 -
relay-log-space-limit:
对复制副本上所有中继日志的总大小（以字节为单位）设置了上限。值0表示“无限制”。这对于磁盘空间有限的复制副本服务器主机非常有用。当达到限制时，I/O（接收器）线程停止从源服务器读取二进制日志事件，直到SQL线程赶上并删除了一些未使用的中继日志。这个限制并不是绝对的：在某些情况下，SQL（应用程序）线程需要更多的事件才能删除中继日志。在这种情况下，接收器线程会超过限制，直到应用程序线程可以删除一些中继日志。 -
max_relay_log_size
如果复制副本对其Relay Log的写入导致当前日志文件大小超过此变量的值，则复制会旋转Relay Log（关闭当前文件并打开下一个文件）。如果max_relay_log_size为0，则服务器对binlog和Relay Log都使用max_binlog_size。如果max_relay_log_size大于0，则会限制中继日志的大小，从而使两个日志的大小不同。 -
手动清理。从库上有些命令，也会导致Relay Log文件被清除，比如：RESET SALVE和 RESET SLAVE ALL。这两个命令会将Relay Log文件全部删除，并且生成新的索引从1开始的Relay Log文件。切记记录gtid信息之后，需要从库重新搭建复制点。
总结
只要开启relay_log_purge参数，Relay Log通常不需要人工清理。手动清理方式虽然比较危险，但碰到无法删除的情况，可以谨慎执行。
