摘要：在系统运维中，磁盘空间耗尽是最高优先级的告警之一。本文详细记录了一次由MySQL Binlog配置不当引发的生产环境服务器磁盘空间100%告警的完整排查、应急处理及根源解决过程，并对该事件进行了复盘与反思，旨在沉淀经验，防范未来可能出现的同类问题。
一、问题现象：深夜的磁盘告警
2023年3月16日凌晨，监控系统发出紧急告警，提示“3.140的迅捷预警”服务器根分区磁盘使用率达到100%。磁盘空间耗尽通常意味着应用无法写入日志、生成临时文件，甚至可能导致服务完全宕机，必须立即处理。
二、应急排查与定位过程
接到告警后，我立即登录服务器，开始进行排查。
步骤一：确认磁盘使用情况
首先，使用df -h 命令确认磁盘的总体使用情况。
[root@server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 50G 0G 100% /
...
命令输出证实了告警信息，根分区的可用空间为0，使用率已达100%。
步骤二：定位大文件目录
接下来，需要快速定位是哪个目录或文件占用了大量空间。我从根目录开始，使用du -sh * 命令逐层排查。
[root@server /]# du -sh *
...
45G /var
...
经过几轮排查，很快定位到/var目录占用了约45G空间，是主要的“嫌疑犯”。继续深入/var/lib/mysql 目录，最终发现了问题所在。
[root@server /var/lib/mysql]# ls -lh
total 45G
-rw-r----- 1 mysql mysql 17G Mar 16 02:30 mysql-bin.000001
-rw-r----- 1 mysql mysql 15G Mar 16 02:30 mysql-bin.000002
-rw-r----- 1 mysql mysql 13G Mar 16 02:30 mysql-bin.000003
...
大量的mysql-bin.xxxxx 文件，即MySQL的二进制日志（Binary Log），累计占用了数十GB的空间，这显然是异常的。
三、根源分析
Binlog是MySQL用于记录所有数据更改操作（DML）的日志，主要用于主从复制和数据恢复。在正常配置下，MySQL应该有自动清理过期Binlog的机制，避免其无限增长。当前的状况表明，这个机制很可能失效或未被正确配置。
为了验证猜想，我登录了MySQL数据库，查询相关的系统变量。
mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
查询结果显示expire_logs_days的值为0。这个参数用于设置Binlog的自动过期天数，值为0意味着永不过期。至此，问题的根源已经非常清晰：由于MySQL的Binlog过期策略未被设置，导致日志文件长期累积，最终耗尽了服务器的磁盘空间。
注：在较新的MySQL版本中，expire_logs_days已被废弃，推荐使用binlog_expire_logs_seconds。
四、解决方案与实施
定位到根源后，解决方案分为两步：紧急恢复和永久修复。
1. 紧急处理：手动清理Binlog，恢复服务
为了尽快释放磁盘空间，让业务恢复正常，需要手动清理掉一部分最旧的Binlog文件。
首先，查看当前的Binlog文件列表：
mysql> show binary logs;
然后，执行PURGE 命令。为了安全起见，我选择保留最近几天的日志，删除了较早的文件。
-- 删除 'mysql-bin.000005' 之前的所有日志文件
mysql> PURGE BINARY LOGS TO 'mysql-bin.000005';
执行完毕后，再次使用df -h 检查，磁盘空间被成功释放，应用服务恢复正常。
2. 永久修复：配置Binlog自动过期策略
为了从根本上解决问题，必须配置Binlog的自动清理策略。
我通过set global 命令在线修改了配置，设置Binlog的保留周期为7天（根据业务备份策略，7天是安全且合理的周期）。
-- 设置binlog保留7天（单位为秒：60*60*24*7）
mysql> set global binlog_expire_logs_seconds=604800;
mysql> flush logs; -- 执行flush logs会让新配置生效并滚动生成一个新的日志文件
为了防止数据库重启导致配置丢失，最稳妥的方式是将其写入MySQL的配置文件my.cnf 中，并重启MySQL服务。
[mysqld]
...
binlog_expire_logs_seconds = 604800
...
完成以上配置后，问题得到了彻底解决。
五、总结与反思
本次线上问题虽然处理过程不算复杂，但暴露出的问题值得深思：
标准化的重要性：任何服务的部署都应依赖一份经过验证的、标准化的配置清单（Checklist）。“默认配置”往往是线上事故的温床。此次事件的核心原因就是部署时遗漏了对
expire_logs_days或binlog_expire_logs_seconds的配置。监控需有深度：对服务器的监控不应只停留在CPU、内存、磁盘使用率等宏观指标上。针对MySQL这类核心服务，应增加更细粒度的监控项，例如对Binlog文件总大小、主从延迟等进行专项监控，从而在问题发生初期就能预警，而不是等到磁盘被完全占满后才被动响应。
基础知识是基石：快速定位和解决问题的能力，源于对系统和应用底层原理的扎实理解。对Linux常用命令的熟练使用和对MySQL Binlog机制的了解是本次能够快速处理问题的关键。