合理值为4GB（4294967296字节），中等负载推荐；超大流量可设8GB，但不可为0；需配合relay_log_purge=ON使用，且仅在SQL线程正常运行时生效。
relay_log_space_limit设多少才合理
设太小会频繁触发SQL线程停止，设太大又起不到保护作用。4GB（4294967296）是多数中等负载从库的平衡点，超大流量场景可上到8GB（8589934592），但不能设为0（即不限制）。该值单位是字节，不是MB或GB字符串，写错会导致配置无效。
必须配合relay_log_purge = ON使用——relay_log_space_limit只负责“硬性截断”，不负责自动清理；真正删文件靠的是SQL线程执行完后触发的unlink()。如果复制卡住，哪怕设了8GB，空间照样会打满。
- 检查当前值：
SELECT @@global.relay_log_space_limit;，返回0表示未启用限制 - 动态生效：
SET GLOBAL relay_log_space_limit = 4294967296;，但重启失效，必须写入/etc/my.cnf的[mysqld]段 - 上线前验证：改完重启，执行
SHOW VARIABLES LIKE 'relay_log_space_limit';确认已加载
为什么调了relay_log_space_limit还是爆盘
常见原因是SQL线程没在跑，或者卡在某个事务里不动。此时relay_log_space_limit根本不会触发报错——它只在“尝试写新event但总空间超限时”才拦住，而卡住时IO线程还在持续追binlog、不断生成新relay log文件，旧的又删不掉，空间就指数级上涨。
关键判断依据是SHOW SLAVE STATUS\G里的Slave_SQL_Running和Seconds_Behind_Master：
-
Slave_SQL_Running: No且Seconds_Behind_Master: NULL→ SQL线程已退出，必须先查错因（比如DDL失败、唯一键冲突），不能只调参数 -
Seconds_Behind_Master持续增大 → 复制延迟严重，需优化SQL线程性能（如关闭innodb_lock_wait_timeout过短、检查大事务） -
Relay_Log_Space接近你设的relay_log_space_limit→ 确认是否真超限，用df -h /var/lib/mysql对比磁盘实际使用率
PURGE RELAY LOGS BEFORE和TO哪个更安全
PURGE RELAY LOGS TO更可控，BEFORE容易误判。因为BEFORE '2026-04-05 00:00:00'依赖MySQL服务器时区，且要求该时间点对应的所有relay log**已被SQL线程完全执行完毕**——但Exec_Master_Log_Pos只告诉你位置，不告诉你时间戳，得靠mysqlbinlog反查binlog才能确认，实操成本高。
TO命令直接比对文件编号，只要编号小于当前Relay_Log_File就安全：
- 先查：
SHOW SLAVE STATUS\G，记下Relay_Log_File: mysql-relay-bin.000123 - 选一个明显小的编号，比如
000110，执行：PURGE RELAY LOGS TO 'mysql-relay-bin.000110'; - 注意文件名必须完全一致：不能多空格、不能加
.index、不能写成mysql-relay-bin.000110.000001
调整后Relay_Log_Space不下降？
说明旧relay log还没被真正删除，常见于两种情况：
- SQL线程仍在运行，但刚purge完的那些文件其实还没执行到——
PURGE只是把索引里标记为“可删”，真正删要等SQL线程读完并确认无引用；此时Relay_Log_Space不变是正常的，等几分钟再查 - MySQL进程还持有已purge文件的句柄（
lsof | grep DELETE | grep relay可见），这时磁盘空间不释放，但inode已归还；唯一解法是重启mysqld（需评估业务影响）或等SQL线程自然推进后自动释放 - 检查
relay_log_purge是否真为ON：SELECT @@global.relay_log_purge;返回1才行；返回0说明配置没生效或被某些定制镜像覆盖
最易被忽略的一点：relay_log_space_limit只管relay log总大小，不管relay_log_index文件本身——这个索引文件虽小，但每新增一个relay log就追加一行，长期不维护也会撑满inode。所以清理后务必用df -i看inode使用率。
