MySQL binlog 为何会导致磁盘爆满
binlog(二进制日志)用于记录数据库所有的变更操作,是数据恢复与主从复制的重要依据。在高写入业务场景下,若未及时清理,binlog 文件将持续累积,最终占满磁盘,导致数据库无法正常写入甚至崩溃。
官方自动清理机制
MySQL 提供了自动清理参数来控制 binlog 的保留时间:
- expire_logs_days:设置 binlog 保留天数,超过后自动删除,适用于 MySQL 5.7 及更早版本。
- binlog_expire_logs_seconds:以秒为单位精确控制 binlog 过期时间,从 MySQL 8.0 开始支持,替代了 expire_logs_days。
可通过动态参数调整当前会话,但需同时写入配置文件(如 my.cnf)以在重启后仍然生效。例如:
SET GLOBAL binlog_expire_logs_seconds = 604800;
注意:不同 MySQL 版本对参数的默认值和废弃状态有差异,配置前请查阅对应版本文档。
手动清理与定时任务
除自动清理外,还可使用 SQL 命令手动删除指定 binlog 文件:
- 删除某个文件之前的所有日志:PURGE BINARY LOGS TO 'mysql-bin.000010';
- 删除某个时间点之前的所有日志:PURGE BINARY LOGS BEFORE '2025-01-01 00:00:00';
建议通过系统的 cron 或计划任务定期执行清理脚本。脚本中可先检查当前磁盘使用率,只有超过阈值时才执行 PURGE,同时将执行结果写入日志,方便溯源与告警。
最佳实践与注意事项
- 根据业务恢复需求和磁盘容量,合理设置 binlog 保留周期,通常建议 7 至 15 天。
- 在主从复制架构中,清理前必须确认所有从库已经拉取并重放对应 binlog,否则会导致主从同步中断。
- 持续监控 binlog 增长速率和磁盘占用,建议在磁盘使用率到达 80% 前触发告警。
- 定期测试基于 binlog 的数据恢复流程,避免因清理策略造成数据恢复盲区。
- 对于长期需要归档的 binlog,可将日志实时同步到外部存储,兼顾数据库磁盘空间和合规审计需求。
结语
通过配置 binlog 过期参数、定期执行 PURGE 任务并辅以磁盘监控,可以避免 binlog 持续增长导致的磁盘爆满问题。DBA 应根据实际业务负载和容灾要求,制定并验证可持续运行的清理机制,确保 MySQL 服务稳定可靠。