mysql 8.0.32 磁盘爆满，清理从库日志

1、问题现象

mysql 8.0.32 从库磁盘爆满。
mysql 一主一从，使用binlog同步的。

查看磁盘上哪些文件占用了磁盘空间：

确认哪些文件占用较大

du-ah/ --max-depth=1|sort-hrdu-ah/var/lib/ --max-depth=1|sort-hr

2、问题原因

原因是从库的log_slave_updates: 开启了，并且binlog_expire_logs_seconds参数配置为永不过期。导致磁盘占用翻倍：因为开启这个参数后，主库过来的每一次数据变更，从库除了写入中继日志（Relay Log）用于回放，还会额外写入从库自己的binlog文件，会占用额外的磁盘空间和I/O资源。

清理规则：这些从库自己的 binlog.0000xx 文件，过期时间同样受 binlog_expire_logs_seconds 参数控制（默认30天）。你需要确保这个值设置合理，否则从库磁盘也可能被写满。本例中核心原因是因为binlog_expire_logs_seconds参数配置为永不过期，导致从库自己的 binlog.0000xx 文件永不清理，一直积累下去越来越多最终导致磁盘爆满。

在 MySQL 8.0.32 中，这两个参数的默认值都是 开启 (ON) 状态。
log_bin (二进制日志): 默认开启 (ON)
log_slave_updates: 默认开启 (ON)

log_bin (二进制日志) 详解：
从 MySQL 8.0 开始，二进制日志功能默认就是开启的。除非你在启动时显式地指定了 --skip-log-bin 或 --disable-log-bin 选项，否则该功能就是启用的。

如果你在配置文件中没有提供 --log-bin 选项，MySQL 会使用 binlog 作为默认的日志文件基础名

log_slave_updates 详解
这个参数控制从库 (Replica) 在回放主库传来的变更后，是否将这些变更也写入自己的二进制日志 (binlog) 中
版本差异：在 MySQL 5.7 及更早版本中，该参数默认为 OFF
MySQL 8.0 起：默认值已更改为 ON。但需要注意的是，log_slave_updates 生效的前提是 log_bin 本身必须是开启状态

为什么log_slave_updates默认是开启的呢？
log_slave_updates 默认开启 这个设置让从库能把从主库同步过来的数据，再次写入自己的 binlog。

这么设计主要是为了支持“级联复制”，即这个从库未来可以作为“二级主库”，再同步给其他从库。对于只需要一主一从的场景，这个功能确实用不上。

3、解决方法

从库执行mysql -uroot -p登录数据库
– 查看当前有哪些 binlog 文件

SHOWBINARYLOGS;

发现有几百个binlog文件，共占用了几十G磁盘空间。

因为是生产环境，不能贸然改动数据库配置参数。因此只清理了从库自己的 binlog.0000xx 文件。
从库执行：

cd/var/lib/mysql

ls -lhrt 查看binlog.xxxxxx 一共有多大 。(判断如果清理能腾出来多大空间)

清理前先备份从库 至关重要：

备份从库整个数据目录/var/lib/mysql
切换到root用户

cp-r/var/lib/mysql /path/to/备份磁盘

清理前查看关键数据表的行数，记录关键数据表行数。

selectcount(*)fromtablecrucial1;selectcount(*)fromtablecrucial2;selectcount(*)fromtablecrucial3;

清理前确认从库上主从同步状态正常：
确保从库已经应用了所有从主库同步过来的数据。执行 SHOW REPLICA STATUS\G，重点看 Replica_IO_Running: Yes 和 Replica_SQL_Running: Yes，以及 Seconds_Behind_Source: 0（或很小的数值）。确认同步正常后，再执行清理。
从库执行

mysql-uroot-p

showslavestatus\G

清理从库的binlog文件
– 示例：保留最后一个文件（如 binlog.000567），删除它之前的所有文件。
binlog.000567是SHOW BINARY LOGS; 查询返回的最后一个文件。
清理从库的binlog：

mysql-uroot-p

PURGEBINARYLOGSTO'binlog.000567';

清理后查看关键数据表的行数，确保关键数据表行数没有发生变化。

selectcount(*)fromtablecrucial1;selectcount(*)fromtablecrucial2;selectcount(*)fromtablecrucial3;