MySQL binlog 占满磁盘？一次紧急清理笔记

MySQL binlog 占满磁盘？一次紧急清理笔记

凌晨 2 点 17 分，手机突然疯狂震动——监控系统报警：生产环境 MySQL 服务器磁盘使用率 98%！作为团队里唯一醒着的人，我不得不顶着困意爬起来处理这个突如其来的状况。今天就把这次惊心动魄的排障经历完整记录下来。

一、问题现象：磁盘空间去哪了？

登录服务器后，我首先用 df -h 确认了磁盘情况：

1

接着用 du -sh * 排查大文件，发现 /var/lib/mysql 目录占用了 42G！进一步检查发现是 binlog 文件爆炸式增长：

1

短短 2 小时就生成了 2 个 1.1G 的 binlog，这明显不正常。

二、紧急处理：先止血再治病

在业务高峰期直接清理 binlog 风险太大，我采取了分步方案：

1. 临时扩容：联系运维紧急挂载 100G 临时磁盘，缓解燃眉之急
2. 暂停同步：临时关闭从库同步避免连锁反应
3. 安全清理：使用 PURGE BINARY LOGS TO 'mysql-bin.000340' 保留最近 2 天的日志

清理后磁盘使用率降至 65%，系统暂时恢复稳定。

三、根因分析：谁在疯狂写日志？

通过 SHOW MASTER STATUS 查看写入位置，结合 mysqlbinlog 工具分析内容：

1

发现大量 UPDATE user_log SET status=1 WHERE id BETWEEN x AND y 语句——原来是新上线的批量状态更新功能没有分批处理，单次操作更新了 50 万条记录！

四、彻底解决方案

次日与开发团队讨论后，我们实施了以下改进：

• 优化批处理：将大事务拆分为每次处理 1000 条的小事务
• 调整 binlog 配置：

  1

• 增加监控：对 binlog 增长速率设置告警阈值

五、经验总结

这次事故让我深刻认识到：

1. MySQL 的默认配置不一定适合生产环境
2. 批量操作必须考虑对日志系统的影响
3. 磁盘监控不能只看使用量，还要关注增长速度

最后分享一个实用命令：SHOW BINARY LOGS 可以快速查看所有 binlog 文件及大小，建议加入日常巡检清单。

你有遇到过类似的坑吗？欢迎在评论区分享你的故事~