MySQL 高可用基础教程之二高可用架构方案介绍

发表于 阅读次数： 评论数： 本文字数： 8.9k 阅读时长 ≈ 8 分钟

大纲

概述

高可用架构方案分类

高可用方案保证数据强一致性使用说明描述
主从复制否支持单主只适用于对可用性和数据一致性要求较低的业务场景。
MMM 否支持单主基本淘汰了，在一致性和高并发稳定性等方面有些问题。
MHA 否支持单主有少数开发者还在用，但也有些问题，也是趋于淘汰的 MySQL 主从高可用方案。
MGR 是支持单主 / 多主基于 MySQL 官方从 5.7.17 版本开始引入的组复制技术。
MySQL Cluster 是支持多主 MySQL 官方提供的一种分布式数据库解决方案，只支持 NDB 引擎。
Galera Cluster 是支持多主引领时代的主从复制高可用技术。
Galera Cluster for MySQL 是支持多主 MySQL 对 Galera Cluster 的实现。
MariaDB Galera Cluster (MGC) 是支持多主 MariaDB 对 Galera Cluster 的实现。
Percona XtraDB Cluster (PXC) 是支持多主 Percona 对 Galera Cluster 的实现，目前业界使用 PXC 的会多一些。
MySQL InnoDB Cluster 是支持单主 / 多主 MySQL 官方推出的一套完整高可用性解决方案。

主从复制

主从之间一般使用异步复制，这意味无法保证数据的一致性，对于数据一致性要求比较高的业务场景是不适用的（如金融、银行业务）。

整体架构

优缺点

  • 优点

    • 架构简单，维护起来比较方便。

  • 缺点

    • 无法保证数据的一致性。
    • 主库宕机后，整个系统都无法写入数据。
    • Proxy 存在单点问题，建议使用 Keepalived + HAProxy 实现数据库中间件的负载均衡。

MMM

MMM（Master-Master Replication Manager）是一套支持 MySQL 双主故障切换和双主日常管理的脚本程序，可以实现 MySQL 数据库的高可用性和负载均衡。MMM 基于 Perl 语言开发，主要用于监控和管理 MySQL Master-Master（双主） 复制，可以说是 MySQL 主主复制的管理器。虽然叫做双主复制，但在业务上同一时刻只能有一个主库进行数据的写入，另一台主备库会提供部分读服务，以加速在主主切换时主备库的预热。另外，主备库会在主库失效时，进行主备切换和故障转移。可以说 MMM 这套脚本程序一方面实现了主备切换的功能，另一方面其内部附加的工具脚本也可以实现多个 Slave 节点的读负载均衡。简而言之，MMM 是一套基于 MySQL 主从复制的高可用性解决方案，通过使用双主复制架构、自动故障检测与切换机制、故障恢复机制，实现了 MySQL 数据库的高可用性和数据同步。

注意

MMM 方案基本淘汰了，在生产环境中不建议使用。

整体架构

  • MMM 架构包括三大组件：监控器（Monitor）、代理（Agent）和 MySQL 实例。
  • 在 MMM 中是通过一个 VIP（虚拟 IP）的机制来保证集群的高可用。在整个 MySQL 集群中，在主节点会提供一个 VIP 地址来提供数据读写服务，当出现故障的时候，VIP 就会从原来的主节点切换到其他节点，由其他节点提供服务。
  • VIP（虚拟 IP）是基于 ARP 协议，因此所有节点必须处于同一局域网。

工作原理

  • 工作原理：MMM 采用了一种双主复制架构，其中有两个 MySQL 主服务器（Master1 和 Master2），它们之间通过 MySQL 的复制功能进行数据同步。在这种架构中，应用程序可以同时连接到 Master1 和 Master2，从而实现读写负载的分担和高可用性。
  • 主从复制：MMM 利用 MySQL 的主从复制机制，将一个 MySQL 主服务器（Master1）作为主节点，另一个 MySQL 主服务器（Master2）作为从节点。主节点接收写操作并将其复制到从节点，从而保持数据的同步。当主节点发生故障时，从节点可以自动接管主节点的角色，确保数据库的高可用性。
  • 自动故障检测与切换：MMM 具有自动检测主节点故障的能力。它通过监控主节点的心跳以及与从节点的复制延迟来确定主节点是否正常工作。如果主节点发生故障或延迟过高，MMM 会自动将从节点切换为主节点，并将所有写操作重定向到新的主节点。
  • 故障恢复：当主节点恢复正常工作后，MMM 可以自动将其重新加入复制拓扑，并将其配置为从节点。这样，当前的主节点（之前的从节点）会将数据同步到恢复的主节点，以确保数据的一致性。

特别注意

使用 MMM 可以有效地提高 MySQL 数据库的可用性和性能。特别注意的是，MMM 并不能解决所有的高可用问题，例如网络分区和数据一致性等问题。

优缺点

  • 优点

    • 高可用性：MMM 通过自动故障检测和故障转移机制，可以快速将一个从节点提升为新的主节点，从而实现数据库的高可用性，减少系统的停机时间。
    • 负载均衡：MMM 可以根据节点的负载情况，将读操作分发到不同的节点上，从而实现负载均衡，提高系统的整体性能。
    • 简单易用：MMM 提供了一些管理工具，可以方便地进行节点的添加、删除和配置修改等操作，使得系统的管理和维护变得简单易用。
    • VIP 支持：默认提供了读写 VIP（虚拟 IP）的支持。

  • 缺点：

    • 无法完全保证数据一致性：由于 MMM 默认采用了 MySQL 的异步复制机制，主节点和从节点之间的同步存在一定的延迟，可能会导致数据的不一致。在某些场景下，需要额外的措施来确保数据的一致性。
    • 单点故障：虽然 MMM 可以自动进行故障转移，但在故障转移过程中，可能会存在一段时间的数据库不可用。如果 MMM 本身发生故障，可能会导致整个系统的不可用。
    • 配置复杂性：MMM 的配置相对复杂，需要对 MySQL 的复制机制和 MMM 的工作原理有一定的了解。在配置过程中，需要注意各个节点的配置一致性和正确性。
    • 故障切换会丢事务：出现故障切换时，容易丢失事务，建议主从库采用半同步复制方式解决，减少出问题的概率。
    • 不支持 GTID：MMM 不支持基于 GTID 的复制，只支持基于日志点的复制。
    • 社区不活跃：目前 MMM 开源社区已经缺少维护者。

MHA

MHA（Master High Availability）是一种用于 MySQL 数据库的高可用性架构。它的设计目标是确保在主数据库发生故障时，能够快速自动地将备库（Slave）提升为新的主库，以保证系统的连续性和可用性。MHA 专门用于监控主库的状态，当发现 Master 节点发生故障的时候，会自动提升其中拥有最新数据的 Slave 节点成为新的 Master 节点；在此期间，MHA 会通过其他从节点获取额外的信息来避免数据一致性问题。MHA 还提供了一种在线切换 Master-Slave 节点的功能，可以根据需要进行切换。MHA 可在 30 秒内实现故障转移，同时最大程度确保数据一致性。

注意

  • MHA 方案比较适合旧版本的 MySQL，即小于 5.7.17 的版本，如 5.5、5.6 等。
  • MySQL 官方从 5.7.17 版本开始提供了组复制技术，因此版本号大于 5.7.17 的 MySQL，建议采用 MGR（MySQL Group Replication）或者其他高可用方案。

整体架构

  • MHA 由两部分组成，分别是 MHA Manager（管理节点）和 MHA Node（数据节点）。
  • MHA Manager 可以单独部署在一台独立的机器上管理单个或多个 Master-Slave 集群，也可以部署在一台 Slave 节点上。MHA Node 运行在每台 MySQL 服务器上。
  • Slave 节点是 MySQL 数据库的备库，负责同步主库的数据。MHA 会通过与 Slave 节点建立 SSH 连接，实时监测备库的状态。
  • Master 节点是 MySQL 数据库的主库，负责处理所有的写操作和读操作。MHA 会通过与 Master 节点建立 SSH 连接，实时监测主库的状态。
  • Manager 节点是 MHA 的核心组件，负责监控主库的状态并自动执行故障切换操作。它通过与 MySQL 主库和备库建立 SSH 连接，实时监测集群中的 Master 节点；当 Master 节点出现故障时，它可以自动将拥有最新数据的 Slave 节点提升为新的 Master 节点，然后将所有其他的 Slave 节点重新指向新的 Master 节点。

MHA 可以扩展为多主多从的集群架构，如下图所示

工作原理

目前 MHA 主要支持一主多从的架构，要搭建 MHA，则必须保证在一个 MySQL 复制集群中最少有三台数据库服务器，一主二从，即一台 Master 节点，一台充当备用 Master 节点，另外一台充当 Slave 节点，因为至少需要三台服务器。

工作流程

MHA 架构的工作流程如下：

  • 从宕机崩溃的 Master 中保存二进制日志事件（binlog events）
  • 识别最新更新的 Slave 节点
  • 应用差异的中继日志（relay log）到其他 Slave 节点
  • 应用从 Master 保存的二进制日志事件（binlog events）
  • 提升其中一个 Slave 节点为新 Master 节点
  • 让其他的 Slave 节点连接新的 Master 节点进行复制

自动故障切换

在 MHA 自动故障切换的过程中，MHA 会尝试从宕机的主服务器上最大限度的保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，主服务器硬件故障或无法通过 SSH 访问，导致 MHA 无法保存二进制日志，只进行故障转移而丢失了最新的数据。使用从 MySQL 5.5 开始支持的半同步复制，可以大大降低数据丢失的风险。值得一提的是，MHA 很适合与半同步复制机制结合起来使用。如果只有一个 Slave 节点已经接收到了最新的二进制日志，MHA 可以将最新的二进制日志应用于其他所有的 Slave 节点上，因此可以保证所有节点的数据一致性。

优缺点

  • 优点：

    • 自动故障切换：MHA 能够自动检测主库的故障，并快速将备库提升为新的主库，减少了手动干预的需要，提高了系统的可用性。
    • 实时监测：MHA 通过与 Master 节点和 Slave 节点建立 SSH 连接，实时监测它们的状态，能够及时发现故障并采取相应的措施。
    • 简化配置：MHA 提供了简单易用的配置文件，可以轻松地配置主库和备库的信息，减少了配置的复杂性。
    • 高可扩展性：MHA 支持多个备库，可以根据需求灵活地扩展系统的容量和性能。
    • 支持 GTID 与日志点：支持基于 GTID 的复制模式，在进行故障转移时更不易产生数据丢失，同时还支持基于日志点的复制。
    • 支持监控多个集群：同一个监控节点可以监控多个集群。

  • 缺点：

    • 配置复杂性：尽管 MHA 提供了简化的配置文件，但对于不熟悉 MHA 的用户来说，配置仍然可能是一项复杂的任务。特别是在涉及多个主库和备库的复杂环境中，配置可能变得更加困难。
    • 依赖 SSH 连接：MHA 通过 SSH 连接与主库和备库进行通信和监控。这意味着在配置和使用 MHA 时，必须确保 SSH 连接的可用性和稳定性，否则可能会导致 MHA 无法正常工作。由于需要基于 SSH 免认证配置，存在一定的安全隐患。
    • 故障切换过程中的数据同步延迟：在故障切换期间，MHA 需要将备库提升为新的主库，并重新配置其他备库作为新的从库。这个过程可能需要一些时间，导致在切换期间存在一定的数据同步延迟，这可能会对某些应用程序的数据一致性产生影响。
    • 依赖 MySQL 复制功能：MHA 依赖 MySQL 的半同步复制方式来实现数据的同步和复制。如果 MySQL 的复制功能出现问题，可能会导致 MHA 无法正常工作或数据同步不完整。
    • 需要额外的硬件资源：为了实现高可用性，MHA 需要至少一个备库来作为冗余备份。这意味着需要额外的硬件资源来支持备库的运行和数据复制，增加了系统的成本和复杂性。
    • 只监控 Master 节点：MHA 启动后只会对主数据库进行监控，并不关注 Slave 节点的运行状态，这可能会导致 Master 节点挂掉后切换到无效的 Slave 节点，从而导致系统崩溃。
    • 需要配置 VIP：MHA 需要编写脚本或利用第三方工具来实现 VIP（虚拟 IP）的配置。
    • 存在脑裂的问题：可能会因网络分区导致脑裂问题的发生。

特别注意

MHA 并不是万能的解决方案，它适用于大多数的 MySQL 数据库场景，但在特定的情况下可能需要根据实际需求进行定制化的配置和调整。此外，为了确保 MHA 的正常运行，还需要进行定期的监控和维护工作，以保证系统的稳定性和可靠性。

MGR

MGR（MySQL Group Replication）是 MySQL 官方在 5.7.17 版本引进的一个数据库高可用解决方案，以插件形式提供，用于实现 MySQL 数据库的主从复制和自动故障切换。MGR 基于 MySQL 的 InnoDB 存储引擎和 Group Replication 插件实现，引入组复制主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。值得一提的是，MGR 支持单主模式与多主模式，多主模式支持多点写入，MySQL 官方推荐使用单主模式。

  • MGR 架构的核心组件

    • Group Replication 组件：Group Replication 是 MySQL 官方提供的插件，用于实现多主复制和自动故障切换。它基于 Paxos 协议，通过在集群中的成员之间进行通信和协调，实现数据的同步和一致性。
    • Primary 节点：Primary 节点是 MGR 集群中的主节点，负责处理所有的写操作和读操作。Primary 节点接收来自应用程序的写请求，并将数据复制到其他节点（Secondary 节点）上。
    • Secondary 节点：Secondary 节点是 MGR 集群中的从节点，负责复制 Primary 节点上的数据。Secondary 节点通过与 Primary 节点进行通信，接收并应用 Primary 节点上的写操作，以保持数据的一致性。

  • MGR 架构的工作流程

    • 初始化集群：在 MGR 架构中，首先需要选择一个节点作为初始 Primary 节点，并将其配置为 Group Replication 组件的成员。然后，其他节点可以加入到集群中，并通过与 Primary 节点进行通信，获取数据并成为 Secondary 节点。
    • 数据同步：一旦集群初始化完成，Primary 节点开始接收来自应用程序的写请求，并将数据复制到其他节点上。Secondary 节点通过与 Primary 节点进行通信，接收并应用 Primary 节点上的写操作，以保持数据的一致性。
    • 自动故障切换：如果 Primary 节点发生故障，Group Replication 组件会自动选择一个 Secondary 节点作为新的 Primary 节点，并将其他节点重新配置为新的 Secondary 节点。这个过程是自动的，无需人工干预。

整体架构

工作原理

  • MGR 由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。
  • MGR 基于分布式 Paxos 协议，实现组复制，保证数据的强一致性，自带故障检测和自动选主功能。
  • MGR 基于 ROW 格式的二进制日志文件和 GTID 特性。

优缺点

  • 优点

    • 自动故障切换：MGR 能够自动检测 Primary 节点的故障，并快速将一个 Secondary 节点提升为新的 Primary 节点，实现自动故障切换，提高了系统的可用性。只要有 N / 2 + 1 节点可用，集群就可用。
    • 保证数据的强一致性：MGR 使用 Paxos 协议来保证数据的强一致性。在写操作提交之前，集群中的成员会达成一致，确保数据在所有节点上的复制是一致的。
    • 简化配置和管理：MGR 提供了简单易用的配置选项和管理工具，使得集群的配置和管理变得更加简单和方便。
    • 高可扩展性：MGR 支持多主复制，可以根据需求灵活地扩展系统的容量和性能。
    • 支持多主模式，但目前该技术还不是很成熟
      • 多主模式下，客户端可以随机向 MySQL 节点写入数据。
      • 单主模式下，MGR 集群会选出 Primary 节点负责写请求，Primary 和 Secondary 节点都可以进行读请求的处理。

  • 缺点

    • 网络稳定性：MGR 对网络的稳定性要求较高，因为节点之间需要进行频繁的通信和数据同步。如果网络不稳定，可能会导致数据同步延迟或节点之间的通信故障。
    • 数据冲突：由于 MGR 支持多主复制，如果应用程序在不同的节点上同时进行写操作，可能会导致数据冲突和一致性问题。因此，需要在应用程序层面进行合理的设计和处理。
    • 配置复杂性：尽管 MGR 提供了简化的配置选项和管理工具，但对于不熟悉 MGR 的用户来说，配置仍然可能是一项复杂的任务。特别是在涉及多个节点和复杂环境中，配置可能变得更加困难。
    • 存在较多限制：
      • 仅支持 Innodb 储存引擎，且储存引擎的版本必须一致。
      • 所有节点的 MySQL 版本必须一致，否则无法添加到 MGR 中。
      • 不支持异构的 MySQL 节点，也就是说，所有 MySQL 节点的操作系统和版本必须一致。
      • 只能在 GTID 模式下使用。
      • Binlog 的日志格式必须为 ROW 格式。
      • 每个表都必须有主键，在进行事务冲突检测时需要利用主键值进行对比。
      • RP 和普通复制 Binlog 校验不能共存，需设置 --binlog-checksum=none。
      • 不支持 gap lock（间隙锁），隔离级别需设置为 read_committed。
      • 不支持对表进行锁操作（如 lock table、unlock table）。
      • 不支持在不同的 MGR 节点上，对同一个表分别执行 DML 和 DDL，可能会造成数据丢失或节点报错退出。
      • DDL 语句不支持原子性，不能检测冲突，执行后需自行校验是否一致。
      • 多主模式下不支持使用外键，但单主模式下支持使用外键。
      • 不支持 serializable（串行） 隔离级别。
      • 不支持复制过滤（Replication Filters）设置。
      • 最多支持 9 个节点，超过 9 个节点无法加入组。

  • 适用场景

    • 要求数据强一致性的业务场景
    • 希望对数据库的写服务提供高可用保障，但又不想安装第三方软件

提示

在使用 MGR 之前，建议进行充分的测试和评估，以确保它能够满足系统的可用性和性能要求，并根据具体的应用场景和需求进行适当的配置和调整。

MySQL Cluster

MySQL Cluster （又叫 MySQL NDB Cluster）是 MySQL 官方开源的一种分布式数据库解决方案，旨在提供高可用性、可扩展性和实时性能。它基于 NDB（Network DataBase）存储引擎，使用多台服务器组成一个集群，提供数据的分片和复制，以实现高可用性和自动的读写负载均衡。值得一的是，MySQL Cluster 兼容 ACID 事务，不存在单点故障，支持自动水平扩容，可以保证数据的强一致性。

注意

由于 MySQL Cluster 的使用和配置都比较复杂，该方案在国内并没有被大规模使用。

整体架构

  • MySQL Cluster 架构的核心组件
    • Management 节点：Management 节点是 MySQL Cluster 的控制节点，负责集群的管理和配置。它负责监控集群中的各个节点，并协调数据的分片和复制。
    • Data 节点：Data 节点是 MySQL Cluster 的数据节点，负责存储和处理数据。每个 Data 节点都运行 NDB 存储引擎，数据被分片存储在不同的 Data 节点上，以实现数据的分布和负载均衡。
    • SQL 节点：SQL 节点是 MySQL Cluster 的查询节点，负责处理应用程序的查询请求。SQL 节点接收来自应用程序的 SQL 查询，并将查询分发到适当的 Data 节点上进行处理。

工作原理

工作流程

MySQL Cluster 架构的工作流程如下：

  • 集群初始化：在 MySQL Cluster 中，首先需要配置和启动 Management 节点，然后配置和启动 Data 节点和 SQL 节点。Management 节点负责监控和管理集群中的各个节点。
  • 数据分片和复制：一旦集群初始化完成，Management 节点会根据配置的规则将数据分片存储在不同的 Data 节点上。数据的复制和同步由 MySQL Cluster 自动处理，以保证数据的一致性和可用性。
  • 查询处理：当应用程序发送查询请求时，SQL 节点接收并解析查询，并将查询分发到适当的 Data 节点上进行处理。Data 节点返回查询结果给 SQL 节点，然后 SQL 节点将结果返回给应用程序。

优缺点

  • 优点

    • 高可用性：MySQL Cluster 通过数据的分片和复制，以及自动故障检测和恢复机制，实现了高可用性。即使某个节点发生故障，集群仍然可以继续提供服务。
    • 可扩展性：MySQL Cluster 支持水平扩展，可以通过增加 Data 节点来扩展存储容量和处理能力。同时，由于数据的分片和负载均衡，可以实现更好的性能和吞吐量。
    • 实时性能：MySQL Cluster 的设计目标之一是提供实时性能。通过将数据存储在内存中，并使用并行处理和分布式计算，可以实现较低的延迟和更高的吞吐量。
    • 数据的强一致性：MySQL Cluster 使用多副本复制和同步机制，以保证数据的强一致性。即使在节点故障或网络分区的情况下，数据仍然可以保持一致。

  • 缺点：

    • 配置复杂性：MySQL Cluster 的配置相对复杂，需要考虑数据分片、复制和负载均衡等因素。对于不熟悉 MySQL Cluster 的用户来说，配置可能是一项具有挑战性的任务。
    • 内存需求：由于 MySQL Cluster 将数据存储在内存中，因此对内存的需求较高，需要根据数据量和性能需求来配置足够的内存资源。
    • 存储引擎需求：MySQL Cluster 需要使用 NDB 存储引擎，与 MySQL 常用引擎（如 Innodb 引擎）存在一定的差异。
    • 网络稳定性：MySQL Cluster 对网络的稳定性要求较高，因为节点之间需要进行频繁的通信和数据同步。如果网络不稳定，可能会导致数据同步延迟或节点之间的通信故障。
    • 重启时间长：重启的时候，数据节点将数据加载到内存需要很长时间。
    • 备份和恢复：MySQL Cluster 对数据备份和恢复并不友好。
    • 节点数需求：搭建 MySQL Cluster 时，要求至少有三个服务器节点。
    • 存在较多限制：如不支持外键，数据行不能超过 8K（不包括 BLOB 和 TEXT 中的数据）等。

提示

在使用 MySQL Cluster 之前，建议进行充分的测试和评估，以确保它能够满足系统的可用性、性能和扩展性要求，并根据具体的应用场景和需求进行适当的配置和调整。

参考资料