MySQL从库relay-log过多耗尽inode的清理优化策略

MySQL从库relay-log过多导致inode耗尽怎么办？清理策略优化

在MySQL主从复制架构中，relay-log文件堆积过多，直接耗尽inode，往往比磁盘空间满更棘手。这本质上是文件系统“没号可分”了。遇到这种情况，必须立刻清理已执行完的relay log，但方法错了，后果更严重。比如，直接用rm命令删除单个文件，看似简单，实则埋雷。

为什么 rm -f *.relay-bin* 会让复制彻底崩溃

MySQL的复制机制，高度依赖relay_log_index文件（或在mysql.sla ve_relay_log_info表中）来记录SQL线程当前读取的relay log文件及位置。手动执行rm，粗暴地破坏了索引文件与实际物理文件之间的一致性。后果就是，重启MySQL服务后，SQL线程会一脸茫然，根本找不到该从哪里开始读取，直接报错Failed to open the relay log，或者更糟——跳过部分未应用的日志，导致主从数据出现不可逆的不一致。

还有一个更隐蔽的陷阱：即便用rm删除了文件，其inode被释放，但如果mysqld进程仍然持有着这个已删除文件的句柄（通过lsof | grep DELETE命令可以看到），那么磁盘空间实际上并不会被释放。然而，inode却已经归还给了系统。这正是为什么df -i显示inode耗尽，而df -h却显示磁盘空间还很充足的根本原因。

所以，几个关键操作必须避免：

• 别写个脚本定时去rm /var/lib/mysql/mysql-relay-bin.*，这是自毁长城。
• 也别在MySQL服务运行时，去移动或重命名relay log文件。
• 最后，务必确认参数relay_log_purge是ON（默认值），如果被设成了OFF，MySQL压根就不会自动清理任何relay log，堆积是必然的。

PURGE RELAY LOGS 必须配合 TO 或 BEFORE，不能裸用

知道要用PURGE RELAY LOGS命令是第一步，但用错了等于没用。裸执行PURGE RELAY LOGS（不带任何条件）是极其危险的操作，它会清空所有relay log文件，包括SQL线程正在读取的和下一个待读的。结果就是复制链路瞬间断裂，SQL线程直接中断。

安全的清理，只允许以下两种方式：

• 指定文件边界：PURGE RELAY LOGS TO 'mysqld-relay-bin.000245'; 这条命令会删除编号严格小于000245的所有文件（包含000244及之前的）。执行前，务必通过SHOW SLA VE STATUS\G确认当前的Relay_Log_File值大于等于000245。
• 指定时间边界：PURGE RELAY LOGS BEFORE '2026-04-05 00:00:00'; 这里的时间必须是MySQL服务器自身的时区，而非操作系统的时区。并且，要确保这个时间点之前的所有relay log都已经被SQL线程完全执行完毕（可以通过Exec_Master_Log_Pos是否已经越过该时间点对应的事务来判断）。

对于更复杂的级联复制环境，还可以加上AND MASTER_LOG_FILE = 'binlog.000888'这样的条件，避免误删了来自其他主库的relay log，操作起来更稳妥。

inode 耗尽时的紧急恢复步骤

当警报响起，df -i显示inode使用率100%，而df -h显示空间还有余量时，说明大量小尺寸的relay log文件已经把inode池占满了。这时候，需要按步骤紧急处理：

1. 首先，执行STOP SLA VE;，暂停复制，防止新的relay log文件继续生成，让情况雪上加霜。
2. 立刻查询SHOW SLA VE STATUS\G，准确记录下Relay_Master_Log_File和Exec_Master_Log_Pos这两个关键值。
3. 执行安全的清理命令，例如PURGE RELAY LOGS TO 'xxx';。这里的'xxx'需要选择一个明显小于当前Relay_Log_File编号的值，宁少勿多。
4. 清理完成后，执行START SLA VE;重启复制。
5. 密切观察Sla ve_SQL_Running_State的状态，看它是否顺利回到reading event from the relay log。如果启动失败，检查错误日志，如果出现relay log not found这类错误，说明刚才的purge操作可能删过头了，把SQL线程还需要用的日志也删了。这时，往往只能从备份恢复，或者考虑重建从库了。

长期防复发：限制总量 + 拆离路径 + 监控 inode

问题解决了，但治标更要治本。仅仅依赖relay_log_purge = ON这个默认参数是不够的，因为它只在SQL线程成功推进一个relay log后才会删除对应的文件。一旦SQL线程卡住——比如遇到一个耗时很长的DDL、表锁冲突，或者一个超大事务——relay log的生成和消费就会失衡，堆积如山只是时间问题。

因此，必须建立组合防御策略：

• 设置空间上限：通过参数relay_log_space_limit（例如设为4294967296，即4GB）来限制所有relay log文件占用的总磁盘空间。当达到这个阈值时，I/O线程会主动暂停接收主库的binlog，这相当于给了DBA一个宝贵的干预窗口。
• 路径隔离：将relay_log和relay_log_index的存储路径，通过配置指向一个独立的挂载点（例如/data/relaylog）。这样做的好处是，让relay log文件与数据文件（datadir）使用不同的inode池，避免互相影响。
• 监控inode使用率：监控脚本不能只看磁盘空间，必须把inode使用率也纳入监控。例如，定期检查df -i /data/relaylog | awk 'NR==2 {print $5}' | sed 's/%//'，当使用率超过80%时就触发告警。

说到底，真正麻烦的从来不是“怎么删”，而是“删完了，SQL线程还在卡着”。所以，每次执行完purge操作后，千万别掉以轻心。至少要紧盯Seconds_Behind_Master和Sla ve_SQL_Running_State五分钟以上，确认复制是真的在向前追赶，而不是卡在某个错误点上“假装正常”。