MySQL Binlog日志文件增长过快磁盘告警解决方案

当磁盘告警响起，很多人的第一反应就是检查 binlog。但别急着删除文件——务必先确认位置，再执行清理操作。在 MySQL 8.0 及以上版本中，expire_logs_days 参数已被废弃，必须使用 binlog_expire_logs_seconds（例如设置为 604800 秒）。如果两个参数同时存在，旧的配置可能引发冲突或失效。核心原则：先查看主从同步位置，再使用 PURGE 指令，切勿直接 rm 删除 binlog 文件。

确认 binlog 是否真的在快速增长，以及谁是真正的元凶

磁盘空间耗尽不一定就是 binlog 导致的。就在 2026 年 4 月，曾有一个案例中 slow_query_log 单独增长到了 397 GB。先彻底排查日志占用的空间：

• 使用 du -sh /var/lib/mysql/*.log /var/log/mysql/*.log 扫描各个日志文件的大小，重点关注 mysql-bin.*、slow-query.log、error.log。
• 执行 SHOW VARIABLES LIKE 'log_bin'; 确认 binlog 是否已开启——返回 ON 才算启用。
• 运行 SHOW BINARY LOGS; 查看当前 binlog 文件总数和总大小。如果单个 mysql-bin.000xxx 超过 1 GB，并且文件数量持续增加，基本可以确定是 binlog 导致的问题。
• 别忘了检查 general_log 是否被误开启：SHOW VARIABLES LIKE 'general_log'; ——这个日志会记录每一条 SQL，不使用时应务必关闭。

紧急释放空间：PURGE 前必须核对主从同步位置

直接 rm mysql-bin.000042 会导致主从同步中断，从库会报错 Got fatal error 1236。安全清理的前提是确认所有从库都已经读取完待删除的日志：

• 在主库执行 SHOW MASTER STATUS;，记录下 File 字段（例如 mysql-bin.000042）。
• 逐一登录每个从库，执行 SHOW SLAVE STATUS\G，重点查看 Relay_Master_Log_File 和 Exec_Master_Log_Pos。
• 找出所有从库中 Relay_Master_Log_File 序号最小的那个（例如 mysql-bin.000035），这就是安全边界——你最多只能执行 PURGE TO 'mysql-bin.000036';。
• 执行清理命令：PURGE BINARY LOGS TO 'mysql-bin.000036'; 或 PURGE BINARY LOGS BEFORE '2026-06-02 00:00:00';（时间格式必须为 Y-m-d H:i:s）。

防止反复爆满：MySQL 8.0+ 必须配置 binlog_expire_logs_seconds

从 MySQL 8.0 开始，expire_logs_days 已经废弃，默认值为 0（永不清除），即使设置了也可能不生效。仅使用 SET GLOBAL 是临时生效的，重启后就会丢失。

• 进入配置文件（如 /etc/my.cnf 或宝塔路径 /www/server/mysql/etc/my.cnf），在 [mysqld] 段添加：

binlog_expire_logs_seconds = 604800
expire_logs_days = 0

• 保存后重启服务：systemctl restart mysqld。
• 验证配置是否生效：SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; ——返回的值必须是你设置的秒数（如 604800），不能是 0 或空。
• 建议同时添加 max_binlog_size = 100M，防止单个 binlog 文件过大而拖慢 PURGE 效率。

源头控量：别只盯着清理，还要压缩生成量

自动清理只是兜底措施，真正治本的方法是减少 binlog 本身的体积。

• 查看当前 binlog 格式：SHOW VARIABLES LIKE 'binlog_format'; ——如果是 ROW 或 MIXED，在高频更新场景下，体积可能是 STATEMENT 的 10 倍以上。
• 如果业务允许（无非确定性函数如 NOW()、RAND()），可以改用 STATEMENT：SET GLOBAL binlog_format = 'STATEMENT';，并写入 my.cnf 永久生效。
• 检查应用层是否存在低效操作：例如用循环逐条 INSERT 代替批量 INSERT ... VALUES (...), (...)，这种写法会成倍放大 binlog 事件数。
• 对大表执行全量更新或删除前，评估是否可以分批执行并加限流措施，避免单次操作生成超大的 binlog 文件。

最容易被忽略的一点是：配置已修改、PURGE 也已执行，但磁盘空间却没有释放——这通常是因为旧日志文件的句柄仍被 mysqld 进程占用。此时需要执行 FLUSH LOGS; 强制切换新的 binlog 文件，旧文件才能被彻底释放。