MySQL Linux服务器快照克隆引起的binlog日志无法正常删除导致文件系统满

      最近，一个mysql数据库Linux服务器文件系统空间满，查看是binlog消耗绝大部分空间；经了解mysql数据库每天进行全备并删除1天前binlog日志；然而，2022.11.15日开始的binlog均没删除，后续了解到linux服务器被快照克隆，查看mysql错误日志发现2022.11.15日志提示shutdown normal，负责人反馈直接重启操作系统未关闭mysql。由此，猜测克隆时的binlog日志被损坏，mysql识别不到binlog日志，后续的binlog日志无法删除积累直到文件系统空间满。后续处理，2022.12.2当天将2022.11.28之前的binlog移动到其他文件系统，重启mysql时日志提示找不到被移走的binlog日志，使用purge命令指定删除7天前和2022.11.28 00：00：00的日志清理失败，最后purge特定binlog前的日志成功。

      一、问题现象

     文件系统满，mysql无法启动，system-lv_*对应的文件系统为故障文件系统，这里看到的是已经紧急扩了300G，处理故障时可用空间只有48MB。

 

     二、问题分析

    根据经验可能是Mysql binlog日志占用过多空间，查看binlog保留时间为0，此是可疑点。

询问运维人员反馈该mysql备份策略为每天全备并删除一天的binlog日志

 

 

备份软件备份任务提示均是成功的

 

然而，2022-12-02之前的binlog直到2022-11-15的都存在，这里只显示部分，根据统计一天的binlog有近60G，积累了18天的binlog有一个TB。到这里，备份软件是有问题的，binlog实际没有删除仍然提示成功并且没有预警。

     后续问题分析，经沟通，该mysql服务器在2022-11-15做过快照克隆，操作直接shutdow -h now关闭主机，mysql 错误日志提示shutdown normal并提示mysqld被force关闭。

     到此，猜测数据库被异常关闭binlog损坏导致binlog无法正常删除。

     三、问题处理

 将部分日志移动到/home/mysqlbinlog文件夹下，重启mysql提示被移走的binlog找不到

只能将日志移动回来，指定日期purge清理binlog日志，命令提示成功，好奇清理消耗没有时间消耗，binlog并没有从文件系统删除。

 

指定删除7天前的binlog进行purge清理，命令提示成功，好奇清理消耗没有时间消耗，binlog并没有从文件系统删除。

 

指定特定的binlog方式purge之前的所有binlog日志，命令提示成功，清理操作有时间消耗，文件系统释放成功

再次执行清理2022-11-30之前的binlog日志，能够成功清理，好奇清理消耗有了时间消耗

清理完binlog日志后，重启mysql正常

​   四、总结

    mysql及其附属主机维护，主机关闭前一定要正常将mysql关闭掉；

    mysql开启binlog时一定要设置expire_logs_days参数；

    备份软件需要改进，不能只凭purge命令返回结果就任务操作执行完成成功，还需要实际判断文件系统空间用量释放情况。