死磕数据库系列(二十三):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



相关文章