![224fd5ddd2e273c4cc25a452976a8236.png](https://i-blog.csdnimg.cn/blog_migrate/b57c9038232c108ce04c41ff61b28380.jpeg)
作者 王志朋|美团点评DBA
曾在京东金融担任DBA,目前就职于美团点评,主要负责金融业务线数据库及基础组件数据库的运维。
MySQL Group Replication(以下简称MGR),于5.7.17版本正式GA,由Oracle官方出品,为MySQL的高可用方案注入了新血液。其一致性,以及不依赖外部组件实现的自动切换、多点写入,给DBA带来了不少期待。
一、背景
以MHA作为切换工具,CMDB管理元数据,结合中间件的高可用方案在MySQL生态中是比较常见的架构。在这个体系中,CMDB作为基础组件之一,不能再依赖这个架构实现自身的高可用,而需要一套自成体系的高可用架构保障。
![c732ead02307321bc005f1f5e0f24984.png](https://i-blog.csdnimg.cn/blog_migrate/0e412b67031e930499b824235c8ff855.jpeg)
2017年下半年开始,美团点评数据库计划全面升级上线5.7版本,也正是这个契机,基于MGR的CMDB高可用想法应运而生。
二、关于MGR
MGR是以Plugin的形式嵌入在MySQL实例中,插件内部实现了冲突检测、Paxos协议通信等。
![92016aadb92a99d47c58bc85e7889e3e.png](https://i-blog.csdnimg.cn/blog_migrate/f9e96bb4372bbaa6b45a7bed71ce39eb.jpeg)
可能有同学了解它与PXC很像,社区中关于二者的口水战也非常的热闹,具体二者的优劣与争端此处不表,但有一点值得说明,MGR集群当中,仍然是通过binlog实现节点同步的。这一点对DBA很友好,意味着我们可以很轻易的找回熟悉的主从的感觉(Still A MySQL)。
![aa066d1b5e02cd4bdb9e178494306172.png](https://i-blog.csdnimg.cn/blog_migrate/9e94a700cbb617a74f33fcc3c2332038.jpeg)
三、解决方案
MGR包括多主与单主两个模式,出于多主模式的一些已知问题以及实际业务场景的考虑,我们决定选择单主模式作为主要方案,即当主节点故障后,集群自动选举新的主节点,应用将写访问指向新的主节点。
![a44ff0bc3333a7ca1a5e9f5829a1c530.png](https://i-blog.csdnimg.cn/blog_migrate/e193e447ddb6b002229e1aecae443884.jpeg)
那么具体的解决方案还有哪些需要考虑呢?
- MGR的限制;
- 相关测试;
- 合理的参数。
1.MGR的限制
- 只支持InnoDB存储引擎;
- 必须有主键;
- binlog_format只支持ROW格式;
- 不支持save point(后修复);
- ……
官方给出了一些明确的要求及限制。针对这些限制我们要对线上要接入的数据库进行排查,调研可行性,规范其满足MGR的要求。包括收敛MyISAM存储引擎的表、无主键的表,应用逻辑中去除save point(新版本去掉此限制)等。
此外我们生产关心的问题,如网络抖动对MGR的影响、备份恢复工具可用性、Online-DDL可用性等,同样需要考虑在内。对此我们做了系统性的功能测试:
![a9d6ce40bafe8d00a80c2c425b6997d1.png](https://i-blog.csdnimg.cn/blog_migrate/21ff31687715e6e513281ca7d0bb7d43.jpeg)
同时在测试中也对MGR的行为有了一些新的认识,比如MyISAM引擎、无主键的表等MGR明确不支持的场景,都是以一种“乐观”的方式处理,即允许你创建、Alter,但不允许写入数据。
2.MGR的参数
同时在上面提到的测试中,我们也遇到了几个重要参数不同值的不同行为。比如group_replication_unreachable_majority_timeout这个参数,它真正的含义是MGR节点由ONLINE状态进入UNREACHABLE状态后(一般是由于网络抖动、节点异常等引起),等待相应的时间,如果仍保持UNREACHABLE,则将节点置为ERROR状态,即这个参数是UNREACHABLE状态的一个timeout,单位秒。
![7bd704e3906a16d7ffd82a2aceea04ea.png](https://i-blog.csdnimg.cn/blog_migrate/b0d297ced3aff013b01fd788583e00e8.jpeg)
(MGR节点的几个状态)
该参数默认值为0,含义是无timeout,即无限等待,这在实际的生产环境中,如发生网络的异常,是个不可接受结果。
以下是我们根据官方的文档,以及实践过程中的一些问题,总结的参数,可作为一个参考:
![ad0659cfbf4464701fd60da9c7f40f43.png](https://i-blog.csdnimg.cn/blog_migrate/1e49588b96b9e7ca805464640ca0f00d.jpeg)
3.最终架构
最后我落实了三机房三节点MGR集群,作为高可用方案主体,同时向下扩展了一套主从集群,作为不可挽回问题的灾备。毕竟MGR作为新生儿,可靠性还有待验证,相信不远的将来我们也有足够的信心放弃回滚到主从的方案。
![e192403753644c6d217e1c5ae60eb095.png](https://i-blog.csdnimg.cn/blog_migrate/4db660d6182ca74d092a3b9292c9c957.jpeg)
四、上线历程
美团点评从2018年以来,总共将三个系统迁移上线了MGR,包括流程系统、报表系统以及CMDB。
![eef060d8e7919514c8632905fdd47c97.png](https://i-blog.csdnimg.cn/blog_migrate/c9872da36ba8a3f4f4860a7e3865047f.jpeg)
五、典型问题
在几个集群上线的过程中,我们也积累了一些问题,其中典型的几个在这里简单回顾一下:
1.大事务
在报表系统上线后,集群出现了一点诡异的状况:在某些时间点,节点不定时会出现UNREACHABLE的状态,严重时直接导致集群选主切换,而在此期间,机房机器网络并没有什么异常。
![a8de62eddac8b82e7d98443604d0162f.png](https://i-blog.csdnimg.cn/blog_migrate/d73022e24f6771c034bbf77c50fba5c6.jpeg)
这个问题最初困扰了我们一段时间,通过对之前流程系统的对比,我们发现两个集群网卡的流量大小有些区别,且报表系统有比较明显的尖刺:
![bacbecb3ccddaeb505cce9c715de29ca.png](https://i-blog.csdnimg.cn/blog_migrate/84caf7c3de9261d5f6c7296d4566decf.jpeg)
从这个分析角度出发,我们查阅文档,发现有参数可以做相关的优化,即group_replication_compression_threshold,含义是事务超过相应大小则在传输前进行压缩处理。下图为参数调整后的对比,由1.5M减少到15K。实际场景中异常状态发生次数确实减少了,但没有根除。
![48c57d2fa928ca43f0b85dcd129c6209.png](https://i-blog.csdnimg.cn/blog_migrate/3786841ccf3e74d10a412d6ef8897f75.jpeg)
顺着这个思路我们做了一些测试,定位到了根本问题:大事务。
需要说明的是MGR的大事务有自己的“定义”,它的大事务与网络的传输时间有关,这就解释了为什么我们开启压缩后,节点异常状态次数减少的问题。最后我们通过限制事务的大小的方式,彻底解决了这个问题,同时也在业务逻辑上优化了大事务。以下是两个相关的参数:
![8df36ebd01b32c823dc5fae18cc35073.png](https://i-blog.csdnimg.cn/blog_migrate/904097fa82e5879cb9409699aad09f3f.jpeg)
2. 应用HANG死
第二个问题发生在一次节点下线演练的过程中,DBA开始演练操作后,开发同学突然反馈说后台Nginx由于请求积压,机器挂掉了。如下图Nginx可用率:
![69559f899db72390ae8c0a3e87b1d67e.png](https://i-blog.csdnimg.cn/blog_migrate/d40a4309da54ab10ce3c70b3882d99b8.jpeg)
此时我们在DBA的慢查询监控中发现一个峰值,时间点基本吻合。下图为慢查询监控:
![16114660550bc70bb9a40449d6d7f8f5.png](https://i-blog.csdnimg.cn/blog_migrate/a562c686abb303791fa038ce9c171e44.jpeg)
由此我们分析了这段时间的慢查询,发现这个SQL我们非常眼熟——MGR查询主节点的语句。正常这个SQL执行时间在毫秒级,故障当时执行了10s,而这个10s与stop group_replication这个操作的耗时基本吻合。
![0a7060ed875919623911d0c5fd4afc7d.png](https://i-blog.csdnimg.cn/blog_migrate/4a51c46973a9cc266a792dc3b7db22cc.jpeg)
据此我们做了相应的测试验证了猜测:在MGR节点START和STOP过程中,当前节点的replication_group_member视图的查询全部hang住。这也就是解释了Nginx后台请求堆积造成的宕机。在此之后,我们在程序中查询这个视图时加入了超时的逻辑,解决了这个问题。
3. 机房故障
第三个问题发生在一次实际的机房故障中:CMDB主节点所在机房网络带宽减半,导致CMDB的MGR集群和一套业务主从集群几乎同时发生了切换,MGR的切换时间大概在3s左右,业务基本无感知,只发生部分报错,但业务集群切换发现回填CMDB失败。
究其原因主要是由于切换的逻辑仍然沿用DNS的连接方式,导致切换发生,DNS同步重新指向,而切换的应用程序对DNS新地址的解析迟迟未效。
![cb4f00ddfb89814dbdfc1939b3c60fa1.png](https://i-blog.csdnimg.cn/blog_migrate/b657d6f58583cdea0b78fbd47585421a.jpeg)
通过这次故障,也促使我们将所有核心CMDB访问全部迁移到内部开发的Smart Client端上。
![5cfe72f632ea5fa9a65bbe78ff5243f2.png](https://i-blog.csdnimg.cn/blog_migrate/415a82fbaebabe552696aac3ef4bb58e.jpeg)
六、Smart Client
关于Smart Client,它是我们内部开发的一套Python连接API,是基于MySQLdb实现的一套MGR切换自动选主、读写分离的功能。对于熟悉Python访问MySQL的同学上手非常简单。
![9163c5fec955a4d255eb2aac082963f4.png](https://i-blog.csdnimg.cn/blog_migrate/b4decbe8e8cd22e9d0efef5f9f4f82c3.jpeg)
七、日常运维
关于MGR的日常运维,实际情况比较省心。
初始化除部分参数区别外,基本与主从集群差异不大。监控方面,我们除了加入系统和MySQL的基础监控外(对MGR兼容良好),还加入了MGR节点状态的监控,即非ONLINE状态的节点全为异常。同时会有同学问,延迟怎么监控?理论上MGR是个最终一致的集群,它内部没有延迟的概念,但我们可以通过监控待执行事务队列中数值,近似看做是一种延迟。
![debd2ccc36a948d02bfbeb5cc31feb06.png](https://i-blog.csdnimg.cn/blog_migrate/3ed40acbbfcea7c499afcd0b1c1514ab.jpeg)
下图为线上一个集群的“延迟”情况,纵坐标为事务个数:
![435c73891190d404fd0817b8eedb3e53.png](https://i-blog.csdnimg.cn/blog_migrate/acc0445caab5ef86c79f8c5c1772fbd7.jpeg)
同时还有主节点与其他节点的GTID_SET差值也可以作为一定参考。
八、写在最后
通过我们一系列的线上演练,甚至包括部分高峰期的演练,以及一段时间的运行状态观察,MGR确实是一个稳定、可靠的高可用架构。虽然对于写入密集型场景不是非常友好,但相信还是可以为DBA的高可用方案提供新的思路。
参考
- MGR的要求:
- https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html
- MGR的限制:
- https://dev.mysql.com/doc/refman/5.7/en/group-replication-limitations.html
- 参数配置:
- https://dev.mysql.com/doc/refman/5.7/en/group-replication-configuring-instances.html
- python工具包:Python MySQL Group Replication 使用
- 参考链接:https://km.sankuai.com/page/52289606
- 转自 美团点评基于MGR的CMDB高可用架构搭建之路 https://www.toutiao.com/i6602060886867706376/