relay_log写满磁盘会导致SQL_THREAD立即退出、复制中断，必须停线程并迁移路径；expire_logs_days对relay_log无效，因其仅控制主库binlog，从库relay_log依赖relay_log_purge=ON和SQL_THREAD推进位置自动清理。
relay_log 写满磁盘不是“延迟高”，是 SQL_THREAD 立即退出、复制彻底中断——必须停线程 + 迁路径，不能只删文件或调 expire_logs_days。
为什么 expire_logs_days 对 relay_log 完全无效
expire_logs_days 只控制主库的 binlog，而从库的 relay_log 有自己的清理逻辑：它依赖 relay_log_purge = ON（默认开启）和 SQL_THREAD 推进位置来自动删除旧文件。一旦 SQL_THREAD 卡住（比如遇到大事务、DDL 锁、表损坏），relay_log 就停止被 purge，文件持续堆积。更致命的是，默认和 datadir 共用同一分区，主库写入不停 + 从库消费不动 → 磁盘瞬间打满。
紧急止血：手动清理前必须停 SQL_THREAD
不先停线程就删文件，极大概率导致复制错位或启动失败。操作顺序不能错：
-
STOP SLAVE SQL_THREAD;—— 只停 SQL 线程，保留 IO 线程继续拉取 binlog（避免主库新事件丢失） - 查当前正在用的 relay log：
SHOW SLAVE STATUS\G中看Relay_Log_File和Relay_Log_Pos - 进
datadir目录，ls -lt mysql-relay-bin.*排序，只删比Relay_Log_File编号更小的旧文件（例如当前是mysql-relay-bin.000012，可删.000001到.000011） - 绝对不要删
mysql-relay-bin.index，也别碰正在写的那个Relay_Log_File -
START SLAVE SQL_THREAD;后观察Slave_SQL_Running是否恢复为Yes
根治方案：把 relay_log 和 relay_log_index 迁到独立挂载点
这是唯一长期可靠的方式。迁移不是改配置重启那么简单，MySQL 启动时会校验索引文件路径，顺序或权限错一步就会拒绝启动：
-
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 文件过去，MySQL 启动时会自动初始化新索引并从正确位置开始写入。
