最近发现服务器硬盘占用持续上升，而且增长偏快。环境是 Debian 10.5 + AMH 面板 + MySQL 8（mysql-generic-8.0），最终定位到 **MySQL 二进制日志（binlog）**在持续写入并占用空间。本文记录完整排查与解决流程。
现象
- df -h 显示根分区占用在增长（虽未满，但趋势异常）
- du 分析目录后发现 /home 占用较大
- 进一步排查发现 MySQL 目录下存在不断变大的 binlog.* 或 mysql-bin.* 文件
一、定位是哪个目录在增长
先确认哪个挂载点在涨：
df -h
df -i然后用 du 分层定位大目录（不跨文件系统）：
du -x -h --max-depth=1 / | sort -h这次结果显示 /home 是占用大头，于是继续下钻并找最近变大的大文件：
find /home/usrdata -xdev -type f -mtime -7 -size +50M -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' 2>/dev/null | sort -nr | head -50输出里直接命中 MySQL 的 binlog 文件（如 binlog.000001、binlog.000002 等）。
二、确认 MySQL 正在写 Binlog
在 phpMyAdmin 里通过 SQL 确认 binlog 状态：
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'log_bin_basename';
SHOW MASTER STATUS;
SHOW BINARY LOGS;关键点：
- log_bin = ON 说明 binlog 开着
- log_bin_basename 能确认 binlog 前缀（例如 /home/usrdata/mysql-generic-8.0/binlog）
- SHOW MASTER STATUS 的 File 表示当前正在写的 binlog 文件
三、踩坑记录：不要用 rm 直接删正在被 MySQL 管理的 binlog
这次过程中曾经用 rm 直接删除 binlog.000001~000005，导致后续在 phpMyAdmin 执行 purge 报错：
- File ‘./binlog.000005’ not found (OS errno 2)
原因是：MySQL 仍保存着 binlog 的索引与状态，但实际文件已被手动删除，导致状态与磁盘不一致。
正确做法应该优先使用：
PURGE BINARY LOGS ...或用更彻底的方式重建状态（见下文）。
四、最终解决方案：永久关闭 Binlog + 重置状态 + 清理残留文件
对于单机 WordPress（不做主从复制、也不依赖 binlog 做点时间恢复），最省心的方案是永久关闭 binlog。
1）在 AMH 配置中强制关闭 binlog
进入 AMH → MySQL → 编辑配置，在 [mysqld] 段加入：
disable_log_bin保存后重启 MySQL。
2）验证已关闭
phpMyAdmin 执行：
SHOW VARIABLES LIKE 'log_bin';确认返回 OFF。
3）重建/清空 binlog 状态（修复“删文件导致索引错乱”）
在 phpMyAdmin 执行：
RESET MASTER;此时 binlog 的索引、状态会被重置，避免后续再出现“引用不存在文件”的报错。
4）删除残留的大 binlog 文件（此时可以 rm）
因为 log_bin=OFF 且已 RESET MASTER，MySQL 不再写也不再依赖这些文件，可以安全删除历史残留（例如 mysql-bin.000001 很大）：
cd /home/usrdata/mysql-generic-8.0/
ls -lh | egrep "mysql-bin|binlog"
rm -f mysql-bin.000001 mysql-bin.000002
rm -f binlog.* 2>/dev/null
df -h五、结果
- MySQL binlog 不再生成，硬盘占用增长停止
- 清理残留文件后释放了数百 MB 空间
- MySQL 状态恢复一致，不再出现 “binlog not found” 类报错
补充建议
- 如果你确实需要 binlog（主从复制/点时间恢复），不要关闭；应设置自动过期，例如：
SET PERSIST binlog_expire_logs_seconds=259200;- （保留 3 天，按需调整）
