迁移后binlog暴增主因是清理策略失效：mysql 8.0.11+必须配置binlog_expire_logs_seconds并验证生效，同时核对所有从库relay_master_log_file确定安全下限，再purge清理旧日志，否则24小时内磁盘可能打满。
迁移后 binlog 突然暴增，基本就是自动清理策略失效了——不是没配，就是配了但没生效，或者配错参数被 MySQL 忽略。必须立刻查、立刻调、立刻 purge，否则 24 小时内磁盘大概率打满。
先确认 binlog 是否真在涨，以及是否开着
别凭感觉，连上 MySQL 执行三句：
-
SHOW VARIABLES LIKE 'log_bin';—— 返回ON才说明 binlog 确实启用；如果OFF，那磁盘满跟 binlog 无关 -
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';—— MySQL 8.0.11+ 必须看这个，值为0或空表示完全不清理 -
SHOW BINARY LOGS;—— 数一数文件数量，把File_size列加起来，超 5GB 就得动手
MySQL 8.0+ 必须用 binlog_expire_logs_seconds，expire_logs_days 已失效
很多迁移实例沿用了旧配置，expire_logs_days = 0 还留着，而 binlog_expire_logs_seconds 没设——这等于没开清理。官方从 8.0.11 起已明确弃用 expire_logs_days，设了也不生效。
- 临时生效（仅当前会话）：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7 天），同时清掉旧参数：SET GLOBAL expire_logs_days = 0; - 永久生效：编辑
/www/server/mysql/etc/my.cnf（宝塔路径）或/etc/my.cnf，在[mysqld]段末尾加两行：binlog_expire_logs_seconds = 604800<br>expire_logs_days = 0
- 重启后必须验证：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';返回值必须是你设的秒数，否则配置没加载成功
手动 PURGE BINARY LOGS 前，必须核对所有从库位置
配置生效只管“未来”的日志，已堆积的旧日志不会自动删。但直接 PURGE 又可能断主从——删掉从库还没读的日志，Slave_IO_Running 立刻变 No，报错 Got fatal error 1236。
- 在每台从库执行：
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File（注意不是Master_Log_File） - 找出所有从库中序号最小的那个文件名，比如
mysql-bin.000135，这就是安全下限——你最多只能执行：PURGE BINARY LOGS TO 'mysql-bin.000136'; - 如果某台从库延迟严重（
Seconds_Behind_Master > 3600），就更保守些，比如保留到mysql-bin.000134后再操作
清理完空间没释放？大概率是文件句柄还挂着
PURGE 成功后 df -h 没变化，不是命令失败，而是 Linux 内核仍持有已删除文件的句柄。
- 运行：
lsof | grep deleted | grep mysql-bin，如果看到一堆mysql-bin.* deleted，就坐实了这个问题 - 最稳妥解法：
FLUSH BINARY LOGS;（触发轮转），或直接重启 MySQL 服务 - 绝对不要用
rm直接删文件——MySQL 进程还在写，du统计它，df不认它，空间就是不回来
真正容易被忽略的是：迁移后往往漏掉从库状态检查，只在主库上 purge，结果一台从库落后两天，删掉它正等着读的日志，复制当场中断。安全边界永远由“最慢的那台从库”决定，不是由时间或文件数量拍脑袋定的。
