值得关注的MySQL高可用方案

值得关注的MySQL高可用方案

随着MySQL官方的不断发力，在基于MySQL复制的基础上，推出了一系列的高可用方案，例如，主从半同步复制、InnoDB ReplicaSet、组复制（MGR）、InnoDB Cluster，及目前最新的InnoDB ClusterSet。

在这一篇文章里，将向各位读者介绍各种方案的优缺点，及适用场景。在介绍各种方案之前，读者首先必须了解MySQL复制功能，MySQL的高可用方案几乎全部是基于MySQL复制实现的。

MySQL的复制功能（之前叫做Master Slave replication，现在改为 Source Replica replication）。MySQL能够产生一个二进制日志（binlog），当MySQL开启该功能后，能够将MySQL服务器所产生的全部事件记录在日志内。MySQL的复制功能将binlog传递到另外一台服务器（可以将其称之为从服务器，Slave或者Replica，发送binlog的服务器称之为主服务器），从服务器接受到binlog后，将日志记录的事件进行应用，以此达到两台服务器数据一致的目的，因此，实现了复制。主从复制的原理如下图所示：

方案一——MMM

MMM(Multi-Master Replication Manager)是一组灵活的脚本，用于执行 MySQL 主-主复制配置的监视/故障转移和管理（任何时候只有一个节点可写）。

MMM多用于以下2种场景：

两个节点：

在两个节点的主-主设置中，MMM使用了五个IP，每个节点只有一个永久IP，2个读取IP(只读)和1个写入IP(更新)。后面三个IP根据节点可用性在节点之间切换。

正常情况下(没有复制失败，没有复制延迟等)主服务器有2个IP(读取和写入)，备用服务器- 1个IP(读取)。在发生故障时，- 写入和读取角色都会迁移到工作节点。

两个主服务器，一个或多个从服务器：

在这个场景中，写入IP只能在两台主服务器之间进行切换，读取IP可以在主从之间切换。通过MMM方案用户能实现服务器的故障转移，从而实现MySQL的高可用。

MMM的主要功能由三个脚本提供: mmm_mond 负责监控工作的守护进程，决定是否将节点进行移除(mmm_mond进行心跳检测，如果检测到失败，则将写入IP切换到另外一台主服务器) mmm_agentd 是运行在mysql服务器上的代理守护进程，mmm_control 通过命令行管理mmm_mond进程。

优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。当主服务器发生故障后，另一个主服务器立即接管，其他的从服务器能自动切换，不用人工干预。

缺点：监控节点会发生单点故障。并且对主机的数量有要求，至少三个节点。如果需要实现读写分离,还需要在前端编写读写分离程序。在读写非常繁忙的业务系统下表现不是很 稳定，可能会出现复制延时、切换失效等问题。MMM方案并不太适应于对数据安全性要求很高，并且读、写繁忙的环境中。

方案二——MHA

MHA（Master High Availability）由原MySQL团队（Sun时代）的Yoshinori Matsunobu开发。可以实现故障切换和主从提升功能。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。管理节点可以单独部署在一台独立的服务器上管理多个主从集群，也可以部署在一台 从服务器上。数据节点运行在每台 MySQL 服务器上。管理节点会定时探测集群中的 主服务器，当 主服务器出现故障时，它可以自动将具有最新数据的从服务器提升为新的主服务器，然后将所有其他的从服务器重新指向新的主服务器。整个故障转移过程对应用程序完全透明。

MHA的优势在于可以非常快速地完成故障转移及提升从服务器角色、主服务崩溃时不会导致数据不一致、用户无需修改当前 MySQL 设置、不会产生性能损失，并且适用于任何存储引擎。

MHA曾经非常流行，但随着MySQL官方的高可用方案不断推出，作者已经意识到，曾经MHA所解决的问题，已经逐渐被官方的解决方案所代替，因此，从MySQL8.0开始，作者已经不在对MHA进行开发和维护。

加入一条华丽丽的分割线

mysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysqlmysql

以下介绍的方案均为来自MySQL团队的方案，包括，InnoDB ReplicaSet、组复制（MySQL Group Replication MGR）、InnoDB Cluster，及InnoDB ClusterSet。

方案三——MySQL InnoDB ReplicaSet

MySQL InnoDB ReplicaSet整合了MySQL相关技术，用户能够通过MySQL Shell部署和管理 MySQL主从复制。InnoDB ReplicaSet至少由两台MySQL服务器实例组成，并提供用户熟知的MySQL主从复制功能，例如，读取横向扩展和数据安全性。

MySQL InnoDB ReplicaSet基于异步的主从复制实现，因此适用于用户对高可用性要求不高的环境，用户可以通过MySQL Shell快速搭建及管理主从复制，避免了搭建主从复制时，大量的手动操作。 InnoDB ReplicaSet的架构如下图所示：

方案四——组复制

组复制是一个MySQL服务器插件，可以创建具有弹性、高可用性和容错的复制拓扑。组复制基于“Paxos”协议（“Mencius”）实现，支持多点写入，具有冲突检测和解决机制，它允许应用程序写入的数据在同一组内的所有服务器上保持一致。组复制内置的模块支持跨平台的分布式恢复，并通过内置的故障转移机制实现了容错。组复制插件的架构如下图所示：

组复制允许用户从现有的主从复制升级到组复制，可以确保一个高可用的MySQL服务分布在多个实例中，无需人工干预来实现容错。

组复制能够确保数据库服务连续可用，但没有提供内置方法进行故障转移或负载均衡。为了实现自动化的故障转移和负载均衡，用户可以使用中间件来实现。

方案五——MySQL InnoDB Cluster

MySQL InnoDB Cluster是一套完整部署和管理MySQL的高可用性解决方案，其整合了MySQL的多项技术，以弥补组复制无法提供具有自动化故障转移功能的中间件，无法自动配置等不足。InnoDB Cluster需要至少三台MySQL服务器实例组成，并且提供高可用性和扩展功能。

InnoDB Cluster包括如下组件：

MySQL Shell：MySQL的高级客户端、管理工具和代码编辑器。MySQL服务器和组复制：使一组MySQL实例能够提供高可用性。InnoDB Cluster提供了一种替代手动配置，易于使用的编程方式来处理组复制。MySQL Router：一种轻量级的中间件，提供负载均衡功能，并可在应用程序和多台MySQL实例之间提供透明的连接路由。

InnoDB Cluster的整体架构如下图所示：

方案六——MySQL InnoDB ClusterSet

MySQL InnoDB ClusterSet 通过将主要的InnoDB Cluster与其他位置（例如，不同数据中心）的一个或多个副本链接，为 InnoDB Cluster 部署提供容灾能力。InnoDB ClusterSet 使用专门的ClusterSet 复制通道，自动管理从主要集群到副本集群的复制。如果主要集群因数据中心损毁或网络连接丢失变得无法使用，用户可以激活副本集群以恢复服务的可用性。InnoDB ClusterSet的整体架构如下图所示：

InnoDB ClusterSet优先考虑可用性而不是一致性，以最大限度地提高系统的容灾能力。正常的复制延迟或网络分区可能意味着在主要集群遇到问题时，部分或全部副本集群与主要集群不完全一致。在这些场景中，如果触发紧急故障转移，任何未复制或发送的事务都有丢失的风险，并且只能由用户进行手动恢复和协调，无法保证在发生紧急故障转移时会保留数据。

如果用户无法容忍故障转移期间事务或数据丢失，则不能使用InnoDB ClusterSet作为系统的解决方案，可以考虑使用一个InnoDB Cluster以及跨多个数据中心部署的成员服务器。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。