Percona server of Mysql 特异功能 与多角度思考

使用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 是一定不能少了,这打破我原有的固有思维的模式,看来人在一个环境待久了,会有一些思维定式的问题,而长久活在自己的思维定式里面,会“缺氧的”。

本文分享自微信公众号 - AustinDatabases(AustinDatabases)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券