21CTO 导读：本文作者遇到了服务器磁盘溢出的情况，结果是MySQL 二进制日志过多的原因。以下内容是解决方法全部。
我们目前正在开发一个 PHP（laravel）应用程序，该应用程序会对我们的 mysql 数据库进行大量临时写入，因为我们的模型需要这些数据。
几天前，我们用 Laravel Forge 搭建的测试服务器开始出现空间不足的问题。
首先，清理一切不需要的日志文件（请注意，我使用的是CentOS Stream）。
1. 清理大的 log 文件:
# find /var -name "*.log" \( \( -size +50M -mtime +7 \) -o -mtime +30 \) -exec truncate {} --size 0 \;
2. 清除YUM 缓存:
# yum clean all# rm -rf /var/tmp/yum-*
3. 清除 Orphan相关包:
4. WP CLI caches:
# rm -rf /root/.wp-cli/cache/*# rm -rf /home/*/.wp-cli/cache/*
5. Old kernels:
# (( $(rpm -E %{rhel}) >= 8 )) && dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)# (( $(rpm -E %{rhel}) <= 7 )) && package-cleanup --oldkernels --count=2
6. Composer caches:
# rm -rf /root/.composer/cache# rm -rf /home/*/.composer/cache
7. Core dumps:
# find -regex ".*/core\.[0-9]+$" -delete
8. error_log files (CPanel为例，根据你的Web 服务器重定位):
# find /home/*/public_html/ -name error_log -delete
9. NodeJs caches:
# rm -rf /root/.npm /home/*/.npm /root/.node-gyp /home/*/.node-gyp /tmp/npm-*
10. Mock caches:
# rm -rf /var/cache/mock/* /var/lib/mock/*
11. Generic program caches:
# rm -rf /home/*/.cache/*/* /root/.cache/*/*
我们通过以上检查了占用磁盘项，但释放效果并不大，项目文件夹本身并没问题，数据库大小也似乎没有异常。
我们一直在努力寻找问题所在，但始终找不到。后来我用 du 命令来检查文件夹大小：
这里显示该var/lib/mysql/文件夹大小超过了 15 GB。
我在这个文件夹中运行程序后，得到了以下结果：
$ sudo ls /var/lib/mysql -ltotal 9416464 … -rw-r — — — 1 mysql mysql 503 3月 21 09:10 binlog.000001 -rw-r — — — 1 mysql mysql 1073764606 3月 23 13:12 binlog.000002 -rw-r — — — 1 mysql mysql 1073811686 3月 25 10:09 binlog.000003 -rw-r — — — 1 mysql mysql 1073784664 3月 26 07:33 binlog.000004 -rw-r — — — 1 mysql mysql 1073759290 3月 26 15:48 binlog.000005 -rw-r — — — 1 mysql mysql 1073846533 3月30日 13:10 binlog.000006 -rw-r — — — 1 mysql mysql 1073774707 4月1日 08:08 binlog.000007 -rw-r — — — 1 mysql mysql 1074212971 4月1日 23:50 binlog.000008 -rw-r — — — 1 mysql mysql 1073771720 4月3日 06:37 binlog.000009 -rw-r — — — 1 mysql mysql 875431943 4月3日 10:07 binlog.000010 -rw-r — — — 1 mysql mysql 160 4月3日 06:37 binlog.index
出现这种情况的原因是，我们的服务器默认配置设置为创建日志，这些日志可以在 MySQL 集群中共享。在这种情况下，我们的 MySQL 实例被设置为主实例，它会保存这些日志并将其传输到从实例。
就我而言，我们没有任何从属数据库实例，因此保留它实际上没有意义。
禁用 MySQL 日志记录
首先，清除旧的二进制日志文件。
在安装 MySQL 后，它的默认配置为使用二进制日志，用于跟踪更改并准备将其保存到 MySQL 集群。大多数情况下我们并不需要这种配置，而且由于我们的应用程序会向数据库写入大量临时数据，这些日志可能会变得非常庞大。
如果已经创建了这些 MySQL 日志（因为您忘记禁用日志），我们通过以root用户身份登录 MySQL 控制台来重置它们：
然后使用以下 mysql 命令清除数据：
或者，如果不想删除所有记录，而只想删除较早的记录：
PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 2 DAY) + INTERVAL 0 SECOND;
禁用二进制日志记录
为确保将来不再发生这种情况，你可以禁用日志记录。
接下来，打开我的my.cnf文件：
sudo vim /etc/mysql/my.cnf
然后将以下行添加到文件中：
完成上述步骤后，再次重启MySQL服务器：
sudo service mysqld restart
警告：如果已将此配置添加到 MySQL 并重启了服务器，RESET MASTER则PURGE BINARY LOGS该命令将被忽略。请务必在将其添加到 mysql.cnf 文件之前清除日志，或者暂时将其删除，清除后再重新添加。
更好的解决方案
这个方案目前已经帮我们解决了服务器空间不足的问题，但更好的解决方案肯定是不要往 MySQL 里写入那么多数据，比如二进制型内容。MySQL 本来就不是用来处理这类数据的，以后我们可能会用别的数据库，不过作为临时方案，在我们有足够的时间进行重构之前，这个方案确实帮了我们很大的忙。
作者：风油精
这是一部浓缩的计算机科学发展史，一部有趣的科学家人物传记，一部绝佳的人生发展读物——《改变世界的程序员》正式上市，收获从现在开始↓Oracle 承诺开放 MySQL 治理体系，但社区要求给出硬性保障
MySQL 存在 20 年的 Bug #11472 终于修复了
Python 日志最佳实践指南
