必须立刻清理已执行完的relay log，因rm -f .relay-bin会破坏relay_log_index一致性，导致sql线程找不到起始位置而复制崩溃；且rm后若mysqld仍持有已删文件句柄，inode释放但磁盘空间不释放，加剧inode耗尽问题。
relay-log 文件过多直接耗尽 inode，不是磁盘空间满，而是文件系统“没号可分”——必须立刻清理已执行完的 relay log，且不能靠 rm 删除单个文件。
为什么 rm -f *.relay-bin* 会让复制彻底崩溃
MySQL 依赖 relay_log_index 文件（或 mysql.slave_relay_log_info 表）记录当前读到哪个 relay log、位置在哪。手动 rm 会破坏该索引与实际文件的一致性，导致重启后 SQL 线程找不到起始位置，报错：Failed to open the relay log 或直接跳过部分日志，主从数据不一致。
更隐蔽的风险是：rm 后文件 inode 虽被释放，但若 mysqld 进程仍持有旧文件句柄（lsof | grep DELETE 可见），磁盘空间不释放，inode 却已归还——这正是 inode 耗尽却 df 显示空间充足的原因。
- 别用脚本定时
rm /var/lib/mysql/mysql-relay-bin.* - 别在未停库时移动或重命名 relay log 文件
- 确认
relay_log_purge = ON（默认值），否则 MySQL 根本不会自动删任何 relay log
PURGE RELAY LOGS 必须配合 TO 或 BEFORE，不能裸用
裸执行 PURGE RELAY LOGS 会清空所有 relay log（包括正在读和下一个待读的），SQL 线程立即中断，复制断裂。安全清理只允许两种方式：
-
PURGE RELAY LOGS TO 'mysqld-relay-bin.000245';—— 删除编号严格小于000245的所有文件（含000244）；执行前务必确认Relay_Log_File当前值 ≥000245（SHOW SLAVE STATUS\G查） -
PURGE RELAY LOGS BEFORE '2026-04-05 00:00:00';—— 时间必须是 MySQL 服务器时区（非系统时区），且该时间点对应的所有 relay log 必须已被 SQL 线程完全执行（看Exec_Master_Log_Pos是否已越过该时间点对应事务）
加 AND MASTER_LOG_FILE = 'binlog.000888' 更稳妥，避免级联复制中误删其他主库来源的日志。
inode 耗尽时的紧急恢复步骤
当 df -i 显示 inode 使用率 100%，但 df -h 空间尚有余量，说明大量小 relay log 文件占满 inode。此时：
- 先
STOP SLAVE;，防止新 relay log 继续生成 - 查
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File和Exec_Master_Log_Pos - 执行
PURGE RELAY LOGS TO 'xxx';（选一个明显小于当前Relay_Log_File编号的值） - 再
START SLAVE;，观察Slave_SQL_Running_State是否回到reading event from the relay log - 若失败，检查错误日志是否有
relay log not found，说明 purge 过头，需从备份恢复或重建从库
长期防复发：限制总量 + 拆离路径 + 监控 inode
仅靠 relay_log_purge = ON 不够——它只在 SQL 线程推进后才删，一旦线程卡住（如遇到 DDL、锁冲突、大事务），relay log 就堆积如山。必须组合防御：
- 设
relay_log_space_limit = 4294967296（4GB），I/O 线程会在达到阈值时主动暂停，给 DBA 干预窗口 - 把
relay_log和relay_log_index移到独立挂载点（如/data/relaylog），避免和datadir共享 inode 池 - 监控脚本必须同时检查
df -i /data/relaylog | awk 'NR==2 {print $5}' | sed 's/%//'，超过 80% 就告警
真正麻烦的从来不是“怎么删”，而是“删完 SQL 线程还在卡”。每次 purge 后，盯着 Seconds_Behind_Master 和 Slave_SQL_Running_State 至少 5 分钟，确认它真在往前跑，不是卡在某个报错上假装正常。
