在MySQL官方的不断努力下，已经推出了一系列基于MySQL复制的高可用解决方案，如主从半同步复制、InnoDBReplicaSet、组复制（MGR)、InnoDBCluster和最新的InnoDBClusterSet。本文将为读者介绍各种方案的优缺点，以及适用场景。在介绍各种解决方案之前，读者必须先了解MySQL的复制功能。几乎所有的MySQL高可用解决方案都是基于MySQL复制的。MySQL的复制功能（以前叫MasterSlave复制，现在改为SourceReplica复制）。MySQL可以生成二进制日志（binlog）。当MySQL启用此功能时，MySQL服务器产生的所有事件都可以记录在日志中。MySQL的复制功能将binlog传输到另一台服务器（可以称为从服务器，Slave或Replica，发送binlog的服务器称为master服务器）。收到服务器的binlog后，对日志记录进行处理Application，以达到两台服务器数据一致的目的，从而实现了复制。主从复制原理如下图所示：方案1-MMMMMM（Multi-MasterReplicationManager）是一组灵活的脚本，用于监控/故障转移和管理MySQL主从复制配置（任何时候只有一个）节点是可写的）。MMM主要用于以下2种场景：双节点：在两个节点的master-master设置中，MMM使用5个IP，每个节点只有一个永久IP，2个读取IP（只读）和1个写入IP（更新）。后三个IP根据节点可用性在节点之间切换。通常（没有复制失败，没有复制延迟等）主服务器有2个IP（读和写），备用-1个IP（读）。如果发生故障，写入和读取角色都会迁移到工作节点。两台主服务器，一台或多台从服务器：这种场景下写IP只能在两台主服务器之间切换，读IP可以在主从之间切换。通过MMM方案，用户可以实现服务器故障转移，从而实现MySQL的高可用。MMM的主要功能由三个脚本提供：mmm_mond负责监控daemon进程并决定是否移除节点（mmm_mond进行心跳检测，如果检测失败则将写入IP切换到另一台master服务器）mmm_agentd它是运行在mysql服务器上的代理守护进程，mmm_control通过命令行管理mmm_mond进程。优点：可用性高，扩展性好，故障自动切换，主从同步，同时只提供一次数据库写操作，保证数据一致性。当主服务器出现故障时，另一台主服务器立即接管，其他从服务器可以自动切换，无需人工干预。缺点：监控节点是单点故障。并且对主机数量有要求，至少三个节点。如果需要实现读写分离，还需要在前端编写一个读写分离程序。在读写非常繁忙的业务系统下性能不是很稳定，可能会出现复制延迟、切换失败等问题。MMM方案不太适合数据安全要求高，读写繁忙的环境。解决方案2-MHAMHA（MasterHighAvailability）由前MySQL团队（Sun时代）的YoshinoriMatsunobu开发。可以实现故障转移和主从提升功能。在MySQL故障转移过程中，MHA可以在0~30秒内自动完成数据库的故障转移操作，并且在故障转移过程中，MHA可以最大程度保证数据的一致性，从而实现真正的高可用。感。MHA由两部分组成：MHAManager（管理节点）和MHANode（数据节点）。管理节点可以部署在独立的服务器上管理多个主从集群，也可以部署在从服务器上。数据节点运行在每个MySQL服务器上。管理节点会定时检测集群中的主服务器。当主服务器出现故障时，它可以自动将拥有最新数据的从服务器提升为新的主服务器，然后将所有其他从服务器重定向到新的主服务器。整个故障转移过程对应用程序是完全透明的。MHA的优点是可以非常快速的完成故障转移和提升从服务器的作用，不会在主服务崩溃时造成数据不一致，用户不需要修改当前的MySQL设置，也不会有性能损失，适用于任何存储引擎。MHA曾经很火，但是随着MySQL官方高可用方案的不断推出，笔者已经意识到MHA解决的问题已经逐渐被官方方案所取代。因此，从MySQL8.0开始，笔者不再开发维护MHA。加一条华丽的分割线方案三——MySQLInnoDBReplicaSetMySQLInnoDBReplicaSet集成了MySQL相关技术，用户可以通过MySQLShell部署和管理MySQL主从复制。InnoDBReplicaSet由至少两个MySQL服务器实例组成，提供熟悉的MySQL主从复制功能，如读横向扩展、数据安全等。MySQLInnoDBReplicaSet基于异步主从复制，因此适用于用户对高可用性要求不高的环境。用户可以通过MySQLShell快速搭建和管理主从复制，避免了搭建主从复制时的大量手动操作。InnoDBReplicaSet的架构如下图所示：解决方案4-GroupReplicationGroupReplication是一个MySQL服务器插件，可以创建一个弹性、高可用和容错的复制拓扑。组复制基于“Paxos”协议（“Mencius”）实现，支持多点写入，具有冲突检测和解决机制，可以让一个应用写入的数据在同组所有服务器上保持一致。内置组复制模块，支持跨平台分布式恢复，通过内置故障转移机制实现容错。组复制插件的架构如下图所示：组复制允许用户从现有的主从复制升级到组复制，保证了一个高可用的MySQL服务分布在多个实例之间，无需人工干预来实现容错。GroupReplication确保数据库服务的连续可用性，但不提供用于故障转移或负载平衡的内置方法。为了实现自动故障转移和负载均衡，用户可以使用中间件来实现。解决方案5—MySQLInnoDBClusterMySQLInnoDBCluster是一个用于完整部署和管理MySQL的高可用性解决方案。它集成了MySQL的多项技术，弥补了组复制的不足，提供了具有自动故障转移功能和自动配置的中间件。等待是不够的。InnoDBCluster至少需要三个MySQL服务器实例，并提供高可用性和可扩展性。InnoDBCluster包括以下组件：MySQLShell：用于MySQL的高级客户端、管理工具和代码编辑器。MySQLServerandGroupReplication：启用一组MySQL实例以提供高可用性。InnoDBCluster提供了一种替代手动配置的方法，一种易于使用的编程方式来处理组复制。MySQLRouter：一个轻量级的中间件，在应用程序和多个MySQL实例之间提供负载平衡和透明的连接路由。InnoDBCluster的整体架构如下图所示：场景6—MySQLInnoDBClusterSetMySQLInnoDBClusterSet通过将主InnoDBCluster与其他位置（例如，不同数据中心）的一个或多个副本链接起来，为InnoDBCluster部署提供容灾。能力。InnoDBClusterSet使用专用的ClusterSet复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心崩溃或网络连接丢失而变得不可用，用户可以激活副本集群以恢复服务可用性。InnoDBClusterSet的整体架构如下图所示：InnoDBClusterSet优先考虑可用性而非一致性，以最大化系统的容灾能力。正常的复制延迟或网络分区可能意味着在主集群遇到问题时，部分或所有副本集群与主集群不完全一致。在这些场景中，如果触发紧急故障转移，任何未复制或发送的交易都有丢失的风险，并且只能由用户手动恢复和协调，不能保证在紧急故障转移时数据将得到保留.如果用户不能容忍故障转移时事务或数据丢失，InnoDBClusterSet不能作为系统解决方案，可以考虑跨多个数据中心部署的InnoDBCluster和成员服务器。
