本文介绍了近几年美团点评MySQL数据库高可用架构的演进过程，以及我们基于开源所做的一些创新技术。同时也与业界其他方案进行了全面的对比，了解业界在高可用方面的进展以及我们未来的一些规划和展望。MMM在2015年之前，美团点评（大众点评方面）长期使用MMM（Master-MasterreplicationmanagerforMySQL）来实现数据库的高可用。因此，我们积累了很多经验，也踩了很多坑。可以说MMM对公司数据库的快速发展起到了很大的作用。MMM的架构如下：如上图所示，整个MySQL集群对外提供一个写VIP（VirtualIP）和N（N>=1）个读VIP服务。每个MySQL节点都部署了一个Agent（mmm-agent），mmm-agent和mmm-manager保持通信状态，定期向mmm-manager（这里称为heartbeat）报告当前MySQL节点的生存状态。当mmm-manager连续多次接收不到mmm-agent的心跳消息时，就会切换。mmm-manager处理异常分两种情况：异常是一个slave节点，mmm-manager会尝试移除slave节点的读VIP，并将读VIP漂移到其他存活的节点，通过这种方式实现高可用图书馆。例外是主节点。如果当时节点没有完全挂掉，只是响应超时，尝试给DeadMaster加全局锁（flushtableswithreadlock），从slave中选出一个候选master节点作为新的master节点节点。,完成数据。数据完成后，移除死主的写VIP，尝试加入新的主节点。补充其他存活节点的数据，重新挂载到新的主节点上。主库故障后，整个集群的状态变化如下：mmm-manager检测到master1故障，完成数据后，将写VIP漂移到master2，应用写操作在新节点上继续。但是MMM架构存在以下问题：VIP数量过多，管理困难（曾经有一个1master6slave的集群，一共7个VIP）。在某些情况下，集群中的大部分VIP会同时丢失，很难区分之前在该节点上使用了哪个VIP。mmm-agent过于敏感，容易导致VIP流失。同时由于mmm-agent本身不具备高可用，一旦挂掉，会导致mmm-manager误判，误认为MySQL节点异常。有一个mmm-manager的单点。一旦因为某种原因挂掉，整个集群就会失去高可用性。VIP需要使用ARP协议，跨网段、跨机房的高可用基本不可能实现，保障能力有限。同时MMM是谷歌技术团队开发的老牌高可用产品。行业内用的不多，社区也不活跃。谷歌长期不再维护MMM的代码分支。我们在使用过程中发现了大量的bug，我们对其中的一些进行了修改并提交给了开源社区。MHA就是针对这个的。从2015年开始，美团点评改进了MySQL高可用架构，更新为MHA，很大程度上解决了MMM之前遇到的各种问题。MHA（MySQLMasterHighAvailability）是Facebook工程师YoshinoriMatsunobu开发的一款MySQL高可用软件。从名字可以看出，MHA只负责MySQL主库的高可用。当主库出现故障时，MHA会选择一个数据最接近原主库的候选主节点（这里只有一个从节点，所以从节点就是候选主节点）作为新的主节点，并补上和之前DeadMasterBinlog的区别。数据完成后，写入VIP并漂移至新主库。整个MHA的架构如下（为简单起见，只描述一主一从）：这里我们对MHA做了一些优化，避免了一些脑裂问题。比如DB服务器上行交换机跳动，导致主库无法访问，被管理节点判断为故障，触发MHA切换，VIP漂移到新的主库。然后恢复开关，可以访问主库，但是由于主库没有去掉VIP，导致两台机器同时有VIP，导致脑裂。我们在MHAManager中加入了对同一机架上其他物理机的检测，通过比较更多的信息来判断是网络故障还是单机故障。MHA+Zebra(DAL)斑马（Zebra）是美团点评基础架构团队开发的一款Java数据库访问中间件。是美团点评内部使用的基于c3p0封装的动态数据源，包括读写分离、分库分表、SQL流控等非常强大的功能，配合MHA成为重要的部分MySQL数据库的高可用。一环。MHA+Zebra合作的整体结构如下：以主库故障为例，处理逻辑有以下两种方式：MHA切换完成后，会主动向Zebra监控器发送消息，Zebramonitor会更新ZooKeeper的配置，更新主库的配置。配置的读取流量标记为离线。Zebramonitor每隔一段时间（10s~40s）检测集群中节点的健康状态。一旦发现某个节点出现问题，会及时刷新ZooKeeper中的配置，将该节点标记为离线。一旦节点变更完成，客户端检测到节点发生变更，会立即使用新的配置重新建立连接，而旧的连接会逐渐关闭。整个集群的failover流程如下（只描述Zebramonitor主动检测，第一次MHA通知请自行脑补^_^）。由于切换过程仍然依赖VIP漂移，只能在同一网段或同一二层交换机上进行，无法实现跨网段或跨机房的高可用。为了解决这个问题，我们对MHA进行了二次开发，去掉了MHA添加VIP的操作，并通知Zebramonitor在切换后重新调整节点的读写信息（调整Write为新master的真实IP，并设置DeadMaster读取流量移除）。整个切换完全去VIP，跨网段，甚至跨机房切换，彻底解决了之前高可用局限在同一网段的问题。上面的切换过程变成下图：但是这种方式的MHA管理节点是单点的，在出现网络故障或者机器宕机的情况下还是有风险的。同时，由于Master和Slave之间基于Binlog的异步复制，当主库机器宕机或主库不可访问时，可能会在MHA切换过程中造成数据丢失。另外，当主从延迟过大时，也会给数据补全操作带来额外的时间开销。除了Proxy的Zebra中间件，美团点评还有一套基于Proxy的中间件，配合MHA使用。当MHA切换时，主动通知Proxy调整读写流量。与Zebra相比，Proxy更加灵活，也可以覆盖非Java应用场景。缺点是多了一层接入链路，相应的ResponseTime和故障率也会有一定程度的增加。未来架构设想MHA架构中还存在以下两个问题：管理节点单点MySQL异步复制数据丢失为此，我们对部分核心业务采用Semi-Sync，可以保证数据不丢失在95%以上的场景中（仍有一些极端情况无法保证数据的强一致性）。此外，高可用性使用分布式代理。一个节点失效后，通过一定的选举协议选出一个新的Master，从而解决了MHAManager的单点问题。针对上述问题，我们研究了一些业内领先的做法，现简要介绍如下。主从同步数据丢失针对主从同步数据丢失，一种方式是创建一个BinlogServer，模拟Slave接受Binlog日志，主库每次都需要收到BinlogServer的ACK响应数据被写入。写入成功。BinlogServer可以部署在就近的物理节点上，从而保证每次数据写入都能快速落地到BinlogServer上。发生故障时，只需要从BinlogServer中拉取数据即可，保证数据不会丢失。分布式Agent高可用针对MHA管理节点的单点问题，一种方法是在MySQL数据库集群的每个节点上部署Agent。当发生故障时，每个Agent参与选举投票，选出一个合适的Slave作为新的master。library，防止仅通过Manager切换，去除MHA单点。整个架构如下图所示：MGB结合上述中间件高可用的方式在一定程度上解决了之前的问题，但是Agent和BinlogServer是新引入的风险。额外的开销。有没有办法在不丢失数据的情况下删除BinlogServer和Agent？答案当然是肯定的。近年来，分布式协议Raft和Paxos在MySQL社区非常流行。社区还推出了基于Paxos的MGR版本的MySQL。通过Paxos将一致性和切换过程下推到数据库，对上层屏蔽切换细节。架构如下（以MGR的单主为例）：当数据库出现故障时，MySQL会进行内部切换。切换完成后，将topo结构推送给Zebra监控器，Zebra监控器会相应改变读写流量。但是这种架构和BinlogServer一样存在回复确认的问题，即主库数据每次写入，大部分节点都需要回复ACK，才认为写入成功，存在一定的响应时间开销。同时，每个MGR集群必须要求奇数个节点（大于1）。导致以前只需要一主一从两台机器，现在至少需要三台，造成了一定的资源浪费。但无论如何，MGR的出现无疑是MySQL数据库的又一次伟大创新。结束语本文介绍了美团点评MySQL数据库高可用架构从MMM到MHA+Zebra、MHA+Proxy的演进过程，同时也介绍了业界的一些高可用实践。近年来，数据库的发展突飞猛进。数据库的高可用设计没有完美的解决方案，只有不断的突破和创新。我们一直在这条路上探索更好的设计和更完美的解决方案。
