Java资源分享网 - 专业的Java学习网站 学Java,上Java资源分享网
行业案例:美团MySQL集群从MMM到MHA+Zebra以及MHA+Proxy的演进 PDF 下载
匿名网友发布于:2024-11-10 11:22:06
(侵权举报)
(假如点击没反应,多刷新两次就OK!)

行业案例:美团MySQL集群从MMM到MHA+Zebra以及MHA+Proxy的演进  PDF 下载 图1

 

 

资料内容:

 

本文介绍最近几年美团点评MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些 创新。同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划 和展望。

MMM

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

MMM的架构如下。

如上所示,整个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,并尝试加到新的主节点上。 将其它存活的节点进行数据补齐,并重新挂载在新的主节点上。 主库发生故障后,整个集群状态变化如下: