死磕数据库系列（二十三）：MySQL 高可用方案选型解析

2023-03-16 00:00:00 数据 节点 服务器 复制 主从


今天我将详细的为大家介绍 MySQL 数据库高可用技术常见的几种方案选型解析相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发支持一波！！！

高可用是数据库永恒的话题，高可用方案也是受数据库爱好者关注的重点技术之一。在MySQL二十多年的发展历程中，针对MySQL的高可用方案百花齐放，各具特色，这也是这款开源数据库能让人着迷的地方。例如，早些年的MMM、MHA等等。

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

MySQL 的各种高可用方案，大多是基于以下几种基础来部署的：

  • 基于主从复制；
  • 基于Galera协议；
  • 基于NDB引擎；
  • 基于中间件/proxy；
  • 基于共享存储；
  • 基于主机高可用；

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

主从或主主 + Keepalive

主从或主主 + Keepalived 算是历史比较悠久的 MySQL 高可用方案，常见架构如下：其大致原理是：在主实例的 Keepalived 中，增加监测本机 MySQL 是否存活的脚本，如果监测 MySQL 挂了，就会重启 Keepalived，从而使 VIP 飘到从实例。

优点
  • 部署简单。
  • 只有两个节点，没有主实例宕机后选主的问题。
缺点
  • 级联复制或者一主多从在切换之后，其他从实例需要重新配置连接新主。
  • 云环境使用不了。

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进行开发和维护。

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

PXC

PXC（Percona XtraDB Cluster）是一个完全开源的 MySQL 高可用解决方案。它将 Percona Server、Percona XtraBackup 与 Galera 库集成在一起，以实现多主复制的 MySQL 集群。常见架构图如下：

优点
  • 去中心：任何节点宕机，集群都可以继续运行而不会丢失任何数据。
  • 每个节点都可以写入数据并自动同步到其他节点。
  • 数据写入需要集群所有节点验证通过才会提交，保证了数据的强一致性。
缺点
  • 只支持 InnoDB 引擎。
  • 木桶效应：集群吞吐量取决于性能差的节点。
  • 增加节点时，必须从现有节点之一复制完整的数据集。

MySQL InnoDB ReplicaSet

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

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

组复制 MGR

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

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

优点
  • 基本无延迟，延迟比异步的小很多
  • 支持多写模式，但是目前还不是很成熟
  • 数据的强一致性，可以保证数据事务不丢失
缺点
  • 仅支持innodb，且每个表必须提供主键。
  • 只能用在GTID模式下，且日志格式为row格式。
适用的业务场景
  • 对主从延迟比较敏感
  • 希望对对写服务提供高可用，又不想安装第三方软件
  • 数据强一致的场景

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以及跨多个数据中心部署的成员服务器。

来源：blog.csdn.net/n88Lpo/article/details/127116041 blog.csdn.net/huanglu0314/article/details/124909230



相关文章