​维护过程中积累的一点经验

//

维护过程中积累的一点经验

//

昨天是上班以来第一次夜间深夜维护，之前维护都是凌晨五点或者晚上十一二点，凌晨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特性为什么会引起内存激增的现象，这个可能还需要研究，目前没有一个好的解释，或者说有，但是我还没有找到答案，这个问题后续有时间在研究吧。如果你对于这个问题，有不同的见解，还请留言互动