迁移后binlog暴涨主因是清理策略失效：mysql 8.0.11+需检查binlog_expire_logs_seconds是否设值且binlog_expire_logs_auto_purge为on，同时确认主从延迟避免误删，再通过purge手动清理并配置my.cnf永久生效。
迁移后 binlog 突然暴涨，大概率是新实例沿用了旧配置（expire_logs_days = 0 或 binlog_expire_logs_seconds 未设），或迁移过程跳过了日志清理环节。必须立刻干预，否则几天内磁盘就可能打满。
确认当前 binlog 清理策略是否生效
别猜，直接查 MySQL 内部状态：
-
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';—— MySQL 8.0.11+ 必须看这个，expire_logs_days已弃用且可能返回空或 0 -
SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge';—— 必须为ON，否则即使设了过期时间也不会自动删 -
SHOW BINARY LOGS;—— 数一数有多少个文件，File_size列加起来是否远超预期（比如 >5GB）
如果 binlog_expire_logs_seconds 是 0 或空值，说明清理完全没启用；如果是 2592000（30 天）但文件堆积严重，要检查是否主从延迟导致旧日志不敢删（见下一条）。
主从环境必须先核对 Relay_Master_Log_File
迁移后若保留了从库角色，盲目 purge 会中断复制。关键不是“最老的 binlog 文件名”，而是从库当前读到的位置：
- 在从库执行：
SHOW SLAVE STATUS\G - 找到
Relay_Master_Log_File字段值，例如mysql-bin.000156 - 你要保留的日志至少得包含这个文件——即
PURGE BINARY LOGS TO 'mysql-bin.000157';才安全 - 如果
Seconds_Behind_Master很大（比如 >3600），说明从库落后很多，此时 purge 范围要更保守，甚至先等同步追上
注意：RESET MASTER 在有从库时绝对禁用，它会清空所有 binlog 并重置序列号，直接导致从库 IO 线程报错 Got fatal error 1236。
立即释放空间：PURGE + 配置双管齐下
临时 purge 解燃眉之急，永久配置防复发：
- 先手动清理（进 MySQL）：
PURGE BINARY LOGS BEFORE '2026-04-25 00:00:00';（选一个明显早于当前时间、又晚于从库Relay_Master_Log_File时间点） - 编辑配置文件：
/www/server/mysql/etc/my.cnf（宝塔路径）或/etc/my.cnf（标准路径），在[mysqld]段添加：binlog_expire_logs_seconds = 604800（7 天）max_binlog_size = 100M（防单个文件过大） - 重启服务：
systemctl restart mysqld或用宝塔面板操作 - 验证：
mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"确认值已更新
执行完 PURGE 后，df -h 可能不立刻显示空间释放——这是 Linux 文件句柄未关闭的正常现象，lsof | grep 'deleted' 能看到残留句柄，等 MySQL 下次 FLUSH BINARY LOGS（比如重启或主从切换）就会真正回收。
为什么设了 binlog_expire_logs_seconds 还不自动删
常见三个盲区：
- 参数写在了错误的配置节，比如放在
[client]或[mysql]下，必须在[mysqld]段才生效 - MySQL 版本低于 8.0.11 却用了
binlog_expire_logs_seconds，该参数不识别，需改用expire_logs_days - 磁盘空间本身已 100%，MySQL 自动清理逻辑会静默失败（不报错），必须先人工
PURGE腾出一点空间再重启服务
最易被忽略的是：迁移后没检查 binlog_expire_logs_auto_purge 是否为 ON。这个开关默认开启，但某些定制镜像或手动编译版本可能关掉它——没有它，过期参数形同虚设。
