行业案例：美团MySQL集群从MMM到MHA+Zebra以及MHA+Proxy的演进.pdfVIP

本文介绍最近几年美团点评MySQL数据库高可用架构的演进过程，以及我们在开源技术基础上做的一些

创新。同时，也和业界其它方案进行综合对比，了解业界在高可用方面的进展，和未来我们的一些规划

和展望。

MMM

在2015年之前，美团点评（点评侧）长期使用MMM（Master-Masterreplicationmanagerfor

MySQL）做数据库高可用，积累了比较多的经验，也踩了不少坑，可以说MMM在公司数据库高速发展

过程中起到了很大的作用。

MMM的架构如下。

如上所示，整个MySQL集群提供1个写VIP（VirtualIP）和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.出现异常的是主节点

如果当时节点还没完全挂，只是响应超时。则尝试将DeadMaster加上全局锁（flushtables

withreadlock）。

在从节点中选择一个候选主节点作为新的主节点，进行数据补齐。

数据补齐之后，摘掉DeadMaster的写VIP，并尝试加到新的主节点上。

将其它存活的节点进行数据补齐，并重新挂载在新的主节点上。

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

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我们做了修

改，并提交到开源社区，有兴趣的同学可以参考这里(/cenalulu/mysql-mmm)。

MHA

针对于此，从2015年开始，美团点评对MySQL高可用架构进行了改进，全部更新为MHA，很大程度上

解决了之前MMM遇到的各种问题。

MHA（MySQLMasterHighAvailability）是由Facebook工程师YoshinoriMatsunobu(https://www.p

/live/mysql-conference-2014/users/yoshinori-matsunobu)开发的一款MySQL高可用软

件。从名字就可以看出，MHA只负责MySQL主库的高可用。主库发生故障时，MHA会选择一个数据最

接近原主库的候选主节点（这里只有一个从节点，所以该从节点即为候选主节点）作为新的主节点，并

补齐和之前DeadMaster差异的Binlog。数据补齐之后，即将写VIP漂移到新主库上。

整个MHA的架构如下（为简单起见，只描述一主一从）：

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

比如DB服务器的上联交换机出现了抖动，导致主库无法访问，被管理节点判定为故障，触发MHA切