美团点评数据库高可用架构的演进与设想

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

MMM

在2015年之前,美团点评(点评侧)长期使用MMM(Master-Master replication manager for MySQL)做数据库高可用,积累了比较多的经验,也踩了不少坑,可以说MMM在公司数据库高速发展过程中起到了很大的作用。

MMM的架构如下:

06184c862f1b91ceb99017cfd1a2f7ac6e596c7d

如上所示,整个MySQL集群提供1个写VIP    (Virtual IP)和N(N>=1)个读VIP提供对外服务。每个MySQL节点均部署有一个Agent(mmm-agent),mmm-agent和mmm-manager保持通信状态,定期向mmm-manager上报当前MySQL节点的存活情况(这里称之为心跳)。当mmm-manager连续多次无法收到mmm-agent的心跳消息时,会进行切换操作。

mmm-manager分两种情况处理出现的异常:

1.出现异常的是从节点
  • mmm-manager会尝试摘掉该从节点的读VIP,并将该读VIP漂移到其它存活的节点上,通过这种方式实现从库的高可用。
2.出现异常的是主节点
  • 如果当时节点还没完全挂,只是响应超时。则尝试将Dead Master加上全局锁(flush tables with read lock)。
  • 在从节点中选择一个候选主节点作为新的主节点,进行数据补齐。
  • 数据补齐之后,摘掉Dead Master的写VIP,并尝试加到新的主节点上。
  • 将其它存活的节点进行数据补齐,并重新挂载在新的主节点上。

主库发生故障后,整个集群状态变化如下:

05c0026367fe822aec648aaeeb7fc6118f2c4d6a

mmm-manager检测到master1发生了故障,对数据进行补齐之后,将写VIP漂移到了master2上,应用写操作在新的节点上继续进行。

然而,MMM架构存在如下问题:

  • VIP的数量过多,管理困难(曾经有一个集群是1主6从,共计7个VIP)。某些情况下会导致集群大部分VIP同时丢失,很难分清节点上之前使用的是哪个VIP。
  • mmm-agent过度敏感,容易导致VIP丢失。同时mmm-agent自身由于没有高可用,一旦挂掉,会造成mmm-manager误判,误认为MySQL节点异常。
  • mmm-manager存在单点,一旦由于某些原因挂掉,整个集群就失去了高可用。
  • VIP需要使用ARP协议,跨网段、跨机房的高可用基本无法实现,保障能力有限。

同时,MMM是Google技术团队开发的一款比较老的高可用产品,在业内使用的并不多,社区也不活跃,Google很早就不再维护MMM的代码分支。我们在使用过程中发现大量Bug,部分Bug我们做了修改,并提交到开源社区,有兴趣的同学可以参考这里。

MHA

针对于此,从2015年开始,美团点评对MySQL高可用架构进行了改进,全部更新为MHA,很大程度上解决了之前MMM遇到的各种问题。

MHA(MySQL Master High Availability)是由Facebook工程师Yoshinori Matsunobu开发的一款MySQL高可用软件。从名字就可以看出,MHA只负责MySQL主库的高可用。主库发生故障时,MHA会选择一个数据最接近原主库的候选主节点(这里只有一个从节点,所以该从节点即为候选主节点)作为新的主节点,并补齐和之前Dead Master 差异的Binlog。数据补齐之后,即将写VIP漂移到新主库上。

整个MHA的架构如下(为简单起见,只描述一主一从):

b1a13bced5d4636c057a1a72de4e9f04ee07e65f

这里我们对MHA做了一些优化,避免一些脑裂问题。

比如DB服务器的上联交换机出现了抖动,导致主库无法访问,被管理节点判定为故障,触发MHA切换,VIP被漂到了新主库上。随后交换机恢复,主库可被访问,但由于VIP并没有从主库上摘除,因此2台机器同时拥有VIP,会产生脑裂。我们对MHA Manager加入了相同机架上其他物理机的探测,通过对比更多的信息来判断是网络故障还是单机故障。

MHA+Zebra(DAL)

Zebra(斑马)是美团点评基础架构团队开发的一个Java数据库访问中间件,是在c3p0基础上包装的美团点评内部使用的动态数据源,包括读写分离、分库分表、SQL流控等非常强的功能。它和MHA配合,成为了MySQL数据库高可用的重要一环。如下是MHA+Zebra配合的整体架构:

9df4015b001ed968799fbcd12e8265edb194bf3d

还是以主库发生故障为例,处理逻辑有如下两种方式:

  • 当MHA切换完成之后,主动发送消息给Zebra monitor,Zebra monitor更新ZooKeeper的配置,将主库上配置的读流量标记为下线状态。
  • Zebra monitor每隔一段时间(10s ~ 40s)检测集群中节点的健康状况,一旦发现某个节点出现了问题,及时刷新ZooKeeper中的配置,将该节点标记为下线。

一旦节点变更完成,客户端监听到节点发生了变更,会立即使用新的配置重建连接,而老的连接会逐步关闭。整个集群故障切换的过程如下(仅描述Zebra monitor主动探测的情况,第一种MHA通知请自行脑补^_^)。

e460cd0310bb7d18b32ea8a47bbfde9f7f689be3

由于该切换过程还是借助于VIP漂移,导致只能在同网段或者说同个二层交换机下进行,无法做到跨网段或者跨机房的高可用。为解决这个问题,我们对MHA进行了二次开发,将MHA添加VIP的操作去掉,切换完之后通知Zebra monitor去重新调整节点的读写信息(将Write调整为new master的实IP,将Dead Master的读流量摘除),整个切换就完全去VIP化,做到跨网段、甚至跨机房切换,彻底解决之前高可用仅局限于同网段的问题。上述切换过程就变成了如下图:

1adb8cae1380a23763f96ea340b1995be560c5c4

然而,这种方式中的MHA管理节点是单点,在网络故障或者机器宕机情况下依然存在风险。同时,由于Master-Slave之间是基于Binlog的异步复制,也就导致了主库机器宕机或者主库无法访问时,MHA切换过程中可能导致数据丢失。

另外,当Master-Slave延迟太大时,也会给数据补齐这一操作带来额外的时间开销。

Proxy

除了Zebra中间件,美团点评还有一套基于Proxy的中间件,和MHA一起配合使用。当MHA切换后,主动通知Proxy来进行读写流量调整,Proxy相比Zebra更加灵活,同时也能覆盖非Java应用场景。缺点就是访问链路多了一层,对应的Response Time和故障率也有一定增加。有兴趣的同学们可以自行前往GitHub查询详细文档。

未来架构设想

上文提到的MHA架构依然存在如下两个问题:

  • 管理节点单点。
  • MySQL异步复制中的数据丢失。

针对于此,我们在部分核心业务上使用Semi-Sync,可以保证95%以上场景下数据不丢失(依然存在一些极端情况下无法保障数据的强一致性)。另外,高可用使用分布式的Agent,在某个节点发生故障后,通过一定的选举协议来选择新的Master,从而解决了MHA Manager的单点问题。

针对上述问题,我们研究了业界的一些领先的做法,简单描述如下。

主从同步数据丢失

针对主从同步的数据丢失,一种做法是创建一个Binlog Server,该Server模拟Slave接受Binlog日志,主库每次的数据写入都需要接收到Binlog Server的ACK应答,才认为写入成功。Binlog Server可以部署在就近的物理节点上,从而保证每次数据写入都能快速落地到Binlog Server。在发生故障时,只需要从Binlog Server拉取数据即可保证数据不丢失。

分布式Agent高可用

针对MHA管理节点单点问题,一种做法是让MySQL数据库集群中每个节点部署Agent,发生故障时每个Agent均参与选举投票,选举出合适的Slave作为新的主库,防止只通过Manager来切换,去除MHA单点。整个架构如下图所示。

cbc81a690f26aac380cd2ebf6783d2a62ae2d825

MGB结合中间件高可用

上述方式某种程度上解决了之前的问题,但是Agent和Binlog Server却是新引入的风险,同时Binlog Server的存在,也带来了响应时间上的额外开销。有没有一种方式,能够去除Binlog Server和Agent,又能保证数据不丢失呢 ?答案当然是有的。

最近几年,MySQL社区关于分布式协议Raft和Paxos非常火,社区也推出了基于Paxos的MGR版本的MySQL,通过Paxos将一致性和切换过程下推到数据库内部,向上层屏蔽了切换细节。架构如下(以MGR的single-primary为例)。

514749db56f078f9832fa0cffa4f9367bdfd2610

当数据库发生故障时,MySQL内部自己进行切换。切换完成后将topo结构推送给Zebra monitor,Zebra monitor进行相应的读写流量变更。不过,该架构存在与Binlog Server同样的需要回复确认问题,就是每次主库数据写入,都需要大多数节点回复ACK,该次写入才算成功,存在一定的响应时间开销。同时,每个MGR集群必须需要奇数个数(大于1)的节点,导致原先只需要一主一从两台机器,现在需要至少三台,带来一定的资源浪费。但不管怎么说,MGR的出现是无疑是MySQL数据库又一次伟大的创新。

总结

本文介绍了美团点评MySQL数据库高可用架构从MMM到MHA+Zebra以及MHA+Proxy的演进历程,同时也介绍了业界一些高可用的做法。数据库最近几年发展突飞猛进,数据库的高可用设计上没有完美的方案,只有不断的突破和创新,我们也一直在这条路上探索更加优秀的设计与更加完美的方案。


原文发布时间为:2017-11-20

本文作者:金龙

本文来自云栖社区合作伙伴“数据和云”,了解相关信息可以关注“数据和云”微信公众号

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
16天前
|
存储 关系型数据库 分布式数据库
|
1天前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
26天前
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
218 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
9天前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
6月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
513 3
Mysql高可用架构方案
|
21天前
|
存储 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:高可用-无感切换篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,单位成本仅0.8元人民币。PolarDB通过VotingDisk实现秒级故障切换,RPO=0,提供高可用性。PolarDB还推出国产轻量版,兼具高性能与低成本,满足多样化需求。
|
3月前
|
人工智能 JavaScript 安全
【01】Java+若依+vue.js技术栈实现钱包积分管理系统项目-商业级电玩城积分系统商业项目实战-需求改为思维导图-设计数据库-确定基础架构和设计-优雅草卓伊凡商业项目实战
【01】Java+若依+vue.js技术栈实现钱包积分管理系统项目-商业级电玩城积分系统商业项目实战-需求改为思维导图-设计数据库-确定基础架构和设计-优雅草卓伊凡商业项目实战
148 13
【01】Java+若依+vue.js技术栈实现钱包积分管理系统项目-商业级电玩城积分系统商业项目实战-需求改为思维导图-设计数据库-确定基础架构和设计-优雅草卓伊凡商业项目实战
|
3月前
|
监控 关系型数据库 MySQL
云数据库:从零到一,构建高可用MySQL集群
在互联网时代,数据成为企业核心资产,传统单机数据库难以满足高并发、高可用需求。云数据库通过弹性扩展、分布式架构等优势解决了这些问题,但也面临数据安全和性能优化挑战。本文介绍了如何从零开始构建高可用MySQL集群,涵盖选择云服务提供商、创建实例、配置高可用架构、数据备份恢复及性能优化等内容,并通过电商平台案例展示了具体应用。
|
2月前
|
存储 SQL 并行计算
【赵渝强老师】达梦数据库MPP集群的架构
达梦数据库提供大规模并行处理(MPP)架构,以低成本实现高性能并行计算,满足海量数据存储和复杂查询需求。DM MPP采用完全对等无共享体系,消除主节点瓶颈,通过多节点并行执行提升性能。其执行流程包括主EP生成计划、分发任务、各EP并行处理及结果汇总返回。为确保高可用性,建议结合数据守护部署。
|
8月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等