MySQL8.0 binlog不清理导致使用磁盘空间过大问题

一、详细问题截图：

mysqlbinlog不清理截图如下

二、报错原因（分析过程）：

1、查看日志保留时间发现是8天.
show variables like ‘%binlog_expire_logs_seconds%’;

2、查看主备同步状态正常且没有延时。

show slave status\G

3、查看binlog日志生成大小限制为500M

show variables like ‘%max_binlog_size%’;

同时查看binlog日志大小发现没有超过500m的。

ls -lh /var/lib/mysql/archive/

4、查看3.20的时候刚好是平台下发备份的时间点（怀疑是备份引起的）。
查看官方网站发现有bug

https://bugs.mysql.com/bug.php?id=104785

5、根据如上情况分析
官方文档提示，当对MySQL实例发出LOCK INSTANCE FOR BACKUP语句期间，PURGE BINARY LOGS是不允许的，因为它会从服务器中删除文件(删除binlog文件)，违反了备份锁(backup lock)的规则。从MySQL 8.0.28开始，这个是不允许的。

因为Xtrabackup备份时，它会执行FLUSH NO_WRITE_TO_BINLOG BINARY LOGS命令，它会轮换二进制日志(rotate the binlog)，这实质上将创建一个新的二进制日志，而在 轮换二进制日志时，就会触发PURGE BINARY LOGS,而由于当前MySQL版本为MySQL 8.0.35，在MySQL进行Xtrabackup时，由于LOCK INSTANCE FOR BACKUP锁，导致PURGE BINARY LOGS是不允许的。

官方描述如下：

PURGE BINARY LOGS should not be issued while a LOCK INSTANCE FOR BACKUP statement is in effect for the instance, because it contravenes the rules of the backup lock by removing files from the server. From MySQL 8.0.28, this is disallowed.

官网连接如下：

https://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html

6、触发binlog清理的条件
清理过期binlog的原理机制：即使我们设置了系统变量binlog_expire_logs_seconds，不是说一旦binlog的创建时间超过了系统变的binlog_expire_logs_seconds的阈值，就会立即触发MySQL的相关线程去清理过期的binlog。清理过期的binlog，一般发生在MySQL启动时或刷新二进制日志时进行（flush logs）和binlog满max_binlog_size设定的值后新生成binlog时。

Binary log files are automatically removed after the server’s binary log expiration period. Removal of the files can take place at startup and when the binary log is flushed.

官方文档连接如下：

https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html

查看binlog保留大小发现

由于这个系统一天产生的binlog小于500m(可以从上面的binlog的输出信息看出，例如，binlog的大小，binlog的创建时间)，也就是说，一天24小时内，MySQL的binlog不会由于binlog过大而触发binlog的切换，也就是说只有Xtrabackup时才触发了binlog的切换，而又由于限制问题，导致过期的binlog不能被清理，久而久之，过期的binlog一直不能清理导致空间使用越来越多。

解决方法：
方案1可在线操作

方案2需停机操作

临时解决方案：

1.手动执行flush log;
2.调整max_binlog_size大小为一天生成的日志量。