mysql 8.0.32 磁盘爆满清理从库日志1、问题现象2、问题原因3、解决方法1、问题现象mysql 8.0.32 从库磁盘爆满。mysql 一主一从使用binlog同步的。查看磁盘上哪些文件占用了磁盘空间确认哪些文件占用较大du-ah/ --max-depth1|sort-hrdu-ah/var/lib/ --max-depth1|sort-hr2、问题原因原因是从库的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 及更早版本中该参数默认为 OFFMySQL 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/mysqlls -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-pshowslavestatus\G清理从库的binlog文件– 示例保留最后一个文件如 binlog.000567删除它之前的所有文件。binlog.000567是SHOW BINARY LOGS; 查询返回的最后一个文件。清理从库的binlogmysql-uroot-pPURGEBINARYLOGSTObinlog.000567;清理后查看关键数据表的行数确保关键数据表行数没有发生变化。selectcount(*)fromtablecrucial1;selectcount(*)fromtablecrucial2;selectcount(*)fromtablecrucial3;
)
