使用MYSQL 的DBER们都对大事务和关于BINLOG 的 expire_log_days 或者更新的Binlog_expire_logs_seconds(MYSQL8)

中的管控BINLOG 的保留问题及管控或多或少都有一丝的不确定

问题

1  到底BINLOG 保留的天数和实际存储了多少BINLOG SIZE 有没有直接的联系

2  我设置了较短的expire_log_days 到底会不会还发生 binlog 暴涨造成的数据库DOWN机的问题

3  我怎么能保证就算有大事务和业务暴涨引起的BINLOG暴涨及时的保证业务的不停机的情况下，自动的先解决超出存储警戒线的BINLOG。

OK 如果你安装了官方版本的MYSQL，你就略过此篇文章，因为可能下面的方法不能奏效。如果你碰巧和我一样公司部署的MYSQL 都是 PERCONA 的版本，那你就来着了，下面的文字必然能帮到你点什么。

这个问题其实有有客户反映的，PERCONA 在相关的mysql 5.7.23 上已经打上了一个PATCH，可以进行除限制日期后的，日志SIZE的清除活动，这看上去没有什么但实际上是一个非常有用的功能。

我们来先看一下实际的情况

下面演示的机器是一台测试机，而测试机的BINLOG 增长是没有规律的，所以我可以在保存时间长度上尽量设置的短一些，但一般测试机的磁盘容量都不是很大，所以如果测试进行软件性能方面的测试，那就很容易将磁盘爆掉。

下面截图是目前的此时服务器的状况，日志大致在15G 左右，但如果我们希望日志仅仅保留 5G 就可以了我们怎么办

我们添加 binlog_space_limit = 5G

然后从启动MYSQL的服务器，OK 

看下图，在MYSQL SERVICE从启动后，再次查看BINLOG保留的数据量，你可以看到数据日志已经被自动删除了大半。

最近另外一个觉得自己提高的地方就是，原来大部分时间段的思路都是以一个DBER的想法去想软件开发，或者软件架构，而到新公司开发部门，并变换为数据库架构这快一年的时间里面，学到的蛮多，如何融合数据库和开发的思路去想问题。如以前认为软件的CHECKER 用户输入的数据的校验的功能一般应该放在前端，而发生用户误输入数据导致后端，乃至数据库产生字段类型与输入数据的类型不一致的时候，第一个想法就是 前端在做什么，有没有干活，在开发部门后扭转了我这样的思维，就算是前端将自己该做的工作都做了，但是找到前端的漏洞在浏览器里面做手脚，然后突破前端的检测，直接让错误的数据发送到后端的事情是很容易做到的，所以后端的数据CHECKER 是一定不能少了，这打破我原有的固有思维的模式，看来人在一个环境待久了，会有一些思维定式的问题，而长久活在自己的思维定式里面，会“缺氧的”。