//
维护过程中积累的一点经验
//
昨天是上班以来第一次夜间深夜维护,之前维护都是凌晨五点或者晚上十一二点,凌晨3点维护对我来说还是有挑战的,尤其是睡眠不好的我,所以昨天睡得比较早,睡了两三个小时起来维护,整个过程还是比较顺利的,就是突出一个累字,在这里,真的是为公司的老员工竖起大拇指,一次维护,让我理解了一个人的责任心到底可以有多强!比你优秀的人,还比你努力,咋整,接着学呗~
今天在回西安的火车上,画图不方便,就简单总结这两天维护的缘由吧,因为线上的集群采用的是MyCAT+MHA+consul的高可用架构,所以维护的过程中的具体步骤比较多,需要注意的点也比较多,整个维护的起因是由于MySQL的一个bug引起的内存跳跃式增长,例如你只分配了2个G的buffer pool,但是实际MySQL在运行的过程中,内存的利用率会出现跳跃式增长,造成系统发生内存报警,具体可以参看percona的官方回复:
https://jira.percona.com/browse/PS-3734
这个bug本质是由于performance_schema引起的,维护的核心思路就是关闭performanct_schema,但是关闭这个特性需要重启数据库(至少目前没有发现其他的在线关闭Performance schema特性的方法),而线上的环境的buffer_pool有12G大小,如果直接重启,那么MySQL需要将buffer_pool中的脏页刷新回磁盘,时间可能比较长,程序段无法接受这么长的时间。
于是我们处理的思路如下:
1、关闭主从复制模式中从库的performance_schema特性
2、通过将主从模式的M-S架构,切换成M-M双主架构的方法
3、MyCat分片配置从consul域名模式切换成IP模式,并且将原来的slave节点作为新的master节点
4、M-M双主模式切换回M-S主从模式,此时,MyCat连接的主节点已经发生对调,通过双主的状态作为桥梁,master和slave进行切换
5、在原来的master上关闭Performance_schema特性,并重启生效。
当然,中间的细节还有很多,但是大体的思路就是上面这样的。
在这个过程中,还有一个细节需要注意,就是如果一个MySQL服务器的buffer pool设置的过大,那么我们关闭重启的时间可能会很长,因为要刷新buffer pool中的脏页,如果这个时间超过1分钟,那么基本上业务是不会接受的,但是在MySQL中提供了这样一个参数,可以让我们把这个动作前置,参数名称是:innodb_max_dirty_pages_pct,我们可以使用set global variables的方法临时设置这个参数的值为0,那么久意味着动态的慢慢主动将buffer pool中的脏页刷回磁盘,而不是通过关闭MySQL被动刷新,这个参数的默认值是75,也就是说,最大的脏页最多可以占用buffer_pool中75%空间。我们可以通过查看show engine innodb status命令中的modified db pages,等到这个值很小的时候,我们就可以关闭数据库了,这个时候关闭数据库的速度就会很快。
关于这个参数,详细信息可以参看官方文档:https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct
关于PS特性为什么会引起内存激增的现象,这个可能还需要研究,目前没有一个好的解释,或者说有,但是我还没有找到答案,这个问题后续有时间在研究吧。如果你对于这个问题,有不同的见解,还请留言互动