Contents
网易杭研总结：数据库高可用技术之道（8）
转载来源： https://zhuanlan.zhihu.com/p/91488488
数据库作为IT系统中最关键的服务之一，其可用性一直是系统设计中的重点考虑因素。同时，由于数据库有数据有状态的天性，数据库高可用有其天然的复杂性和难点，云原生架构下尤其如此，是一个值得深入探讨的课题。本系列文章将基于网易杭州研究院的研究与实践，解析数据库高可用技术要点，梳理主流数据库方案，为数据库技术建设规划提供参考。
本文由作者授权网易云发布，未经许可，请勿转载！
作者：倪山三，网易杭州研究院运维工程师
Catalog
-
- Prologue
-
- 数据库高可用技术要点
-
- 1.1. 冗余设计 — 数据冗余方案
- 1.2. 冗余设计 — 冗余数据间的一致性
- 1.3. 冗余设计 — 实例冗余
- 1.4. 故障切换 — 服务角色
- 1.5. 故障切换 — 故障感知与应对
- 1.6. 故障切换 — 业务连接切换
-
- 主流数据库方案概览
-
- 2.1. 主流数据库高可用功能概览
- 2.2. MySQL数据库高可用功能概览
接上文：
2.2. MySQL高可用功能概览
最后来具体看一下我们最常用的MySQL数据库.
2.2.1. 传统MySQL高可用架构
如果使用最原始的MHA+VIP方案, 那么按照我们的评分标准得到如下分值:
图54, 传统MySQL高可用架构, 最大的问题就是松散集群, 无内部通信, 无角色, 无切换策略, 除了主从数据冗余外, 其他所有功能都需要外部实现.
这个成绩算不上好. 最显著的短板在于无角色和VIP漂移方案可能存在的切换成功率与脑裂风险. 因此针对MySQL高可用的增强主要是在故障发现与业务连接切换能力这两方面. 集群防脑裂, 故障发现和切换可靠性, 应用连接切换方案, 三大技术点都有缺乏必要设计.
MySQL不在功能里做这些保障那就意味着这些功能必须由外部框架来实现, 这也是为啥针对MySQL的各类“中间件”如此繁多的重要原因. 外部实现需要根据各种不同的环境开发不同的功能, 结果就是各个公司, 各个环境运用Oracle, Redis, MongoDB这些自身高可用功能相对完善的数据库使用的架构大同小异, 但是到了MySQL这里就会有各种各样差异很大的设计. 举个例子, 各种云计算平台针对MySQL高可用的设计实现方式上就有很大差比, 例如AWS是DRBD冗余+域名切换, 阿里云则是主从日志复制+代理切换, 而我们自己的网易私有云则是日志复制+VIP漂移…
在MySQL高可用各种功能缺失中最致命的实际上失效节点如何隔离读写, 要根据不同的环境做具体设计, 但是总体上来讲非常难以实现, 这使得传统MySQL各种高可用架构不同程度都存在脑裂风险.
2.2.2. 基于MGR的MySQL高可用架构
图55, MySQL MGR架构, 一次性解决了MySQL高可用功能中的大部分痛点, 是非常有价值的技术方案.
MySQL作为多数互联网公司最重要的OLTP数据库产品, 其高可用功能缺失的问题实际上也得到了各方面的重视. 目前我们能看到的最重要的一个技术方向就是在5.7引入的MGR（MySQL Group Replication）集群功能, MGR架构终于在多个互备的MySQL服务间建立起了内部通信管道和paxos协议组, 通过数据写入时paxos协议机制替换原本半同步的数据一致性保障, 可靠性更好, 同时内部通信也允许MySQL实现了集群自动角色选举和切换, 以及失效节点的自我隔离, 一次性内置实现了数据一致性, 脑裂, 故障感知和角色切换等功能, 是对MySQL高可用体系的革命性改进.
但是该方案也有一些无可奈何的不足, 例如依然依赖binlog, binlog复制该有的问题MGR依然会有. 然后paxos组提交对业务大事务有一定限制等. 但是最重要的不足我认为依然没有给出一个六大技术点中如何解决业务连接切换问题的成熟方案.
图56, 也是第二次出现的图, MGR需要通过跟随应用侧部署代理服务实现业务连接高可用切换, 该方案普适性有一定局限.
官方给出的一种可行方案时在应用侧部署和应用服务器绑定的代理服务来兼容数据库服务端的高可用切换功能, 一方面官方的代理服务功能和可靠性方面存在较多问题, 另一方面在分布式服务中非常流行的客户端驱动兼容高可用集群切换的功能并没有被官方采纳.
不论如何, MGR改造将是今年下半年开始我们网易数据库服务体系中最重要的一项技术改进, 为了解决线上运用最广的MySQL数据库当前各种痛点和风险, 我们必须加快MGR落地的速度. 相关内容我们后续继续探讨.
相关阅读推荐：
发表回复