磁盘满导致relay log截断需先确认Last_SQL_Error含“OS error code 28”或“Relay log read failure”，且Seconds_Behind_Master为NULL、Slave_SQL_Running为No、Relay_Log_Pos停滞；expire_logs_days对其无效，必须停SQL_THREAD后清理旧文件或迁移relay_log路径至独立挂载点。
relay log 截断不是“日志满了就自动轮转”，而是磁盘写满后 MySQL 写入失败、文件损坏、SQL 线程直接退出——必须停复制、清旧文件（谨慎）、迁移路径，否则重启也起不来。
怎么确认是磁盘满导致 relay log 截断
看到 Last_SQL_Error 里有 OS error code 28: No space left on device 或 Relay log read failure，同时 Seconds_Behind_Master 变成 NULL、Slave_SQL_Running 是 No，且 Relay_Log_Pos 停滞不动，基本就是磁盘打满触发的截断。注意：expire_logs_days 对 relay log 完全无效，它只靠 relay_log_purge=ON 和 SQL 线程消费进度清理；一旦线程卡住，文件就堆死在 datadir 里。
紧急止血：只删安全的 relay log 文件
仅当 Slave_SQL_Running: Yes 且 Seconds_Behind_Master 很小（比如 < 60 秒）时，才可手动清理旧文件：
- 先执行
STOP SLAVE SQL_THREAD;，防止新事件继续写入 - 从
SHOW SLAVE STATUS\G中记下当前Relay_Log_File（如mysql-relay-bin.000123） - 进
datadir目录，用ls -lt mysql-relay-bin.*排序，把编号比Relay_Log_File小的所有文件（如.000120、.000121、.000122）全部rm—— 切勿删正在用的那个，也别碰mysql-relay-bin.index - 再执行
START SLAVE SQL_THREAD;，观察是否恢复；若仍报错或卡住，说明已有损坏，需走迁移流程
根治方案：把 relay_log 搬到独立挂载点
这是唯一长期可靠的方式，但操作顺序不能错：
-
STOP SLAVE;，并确认Seconds_Behind_Master = 0或已追平 - 记下
Relay_Master_Log_File和Exec_Master_Log_Pos（后续验证一致性用） - 新建目录（如
/data/relaylog），属主设为mysql，权限750；不要拷旧文件过去 - 在
my.cnf的[mysqld]段添加两行：relay_log = /data/relaylog/mysql-relay-bin，relay_log_index = /data/relaylog/mysql-relay-bin.index - 重启
mysqld，启动成功后立刻START SLAVE;，再用SHOW SLAVE STATUS\G确认两个线程都为Yes
为什么不能直接删完重启
因为 relay log 不是缓存，而是未执行事件的中间载体。删掉后 START SLAVE，IO 线程不会自动重建有效中继日志，反而会因 Relay_Log_Pos 指向非法偏移而卡死，报错 Failed to open the relay log。更危险的是：有人顺手去删 ibdata1 或 ib_logfile*，前者删了等于删库，后者删了 MySQL 启动直接失败。
