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

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

大纲

概述

高可用架构方案分类

高可用方案保证数据强一致性使用说明描述
主从复制否支持单主只适用于对可用性和数据一致性要求较低的业务场景。
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 官方推出的一套完整高可用性解决方案。

Galera Cluster

Galera Cluster 是由 Codership 开源的一套基于同步多主复制的 MySQL 集群解决方案。目前 Galera Cluster 有三种版本（实现方案），分别是 Galera Cluster for MySQL、MariaDB Galera Cluster (MGC) 及 Percona Xtradb Cluster (PXC)。Galera Cluster 使用 Galera Replication 插件，通过在多个 MySQL 节点之间同步数据来实现高可用性和负载均衡。其本身具有 Multi-Master (多主) 特性，支持多点写入（所有节点都可以同时读写数据库），Galera Cluster 中每个实例都是对等的，互为主从。当客户端读写数据的时候，可以选择任一 MySQL 实例，对于读操作，每个实例读取到的数据都是相同的。对于写操作，当数据写入某一节点后，集群会将其同步到其它节点。这种架构不共享任何数据，是一种高冗余架构。

如何选择版本？

建议采用 Percona XtraDB Cluster，因为技术比较成熟，而且国内很多企业在生产线上用的更多一些。

版本区别

Galera Cluster for MySQL、MariaDB Galera Cluster (MGC) 与 Percona Xtradb Cluster (PXC) 三者的区别如下：

  • 版本不同

    • 三者使用的 Galera Cluster 版本不同，因此在功能和性能上存在一些的差异。

  • 发行版不同：

    • MariaDB Galera Cluster 是由 MariaDB 基金会开发的，支持 MariaDB 数据库。
    • Percona XtraDB Cluster 是由 Percona 公司开发的，支持 Percona Server 数据库。
    • Galera Cluster for MySQL 是由 Codership 公司开发的，支持 MySQL 和 Percona Server 数据库。

  • 功能不同：

    • Percona XtraDB Cluster 提供了一些额外的功能，例如在线扩容、在线更改节点角色等。
    • MariaDB Galera Cluster 支持 Galera Cluster for MySQL 的所有功能，包括多主写入、并行复制、自动故障检测和恢复等。

  • 许可证不同：

    • MariaDB Galera Cluster 使用 LGPLv2.1 许可证。
    • Galera Cluster for MySQL 和 Percona XtraDB Cluster 都使用 GPLv2 许可证。

MariaDB 与 Percona Server 的关系

MariaDB 数据库是由原 MySQL 创始人开发，Percona Server 数据库由 Percona 公司开发（使用 XtraDB 存储引擎），两者都是从 MySQL 衍生出来的数据库分支。

整体架构

  • Galera Cluster 的核心组件
    • Galera Replication 插件：Galera Replication 是一个基于同步复制的插件，用于实现数据的多主复制和一致性。它使用了多主复制协议，确保在集群中的所有节点之间的数据同步和一致性。
    • Primary Component：Primary Component 是 Galera Cluster 中的主组件，负责处理所有的写操作和读操作。Primary Component 接收来自应用程序的写请求，并将数据复制到其他节点（Secondary Component）上。
    • Secondary Component：Secondary Component 是 Galera Cluster 中的从组件，负责复制 Primary Component 上的数据。Secondary Component 通过与 Primary Component 进行通信，接收并应用 Primary Component 上的写操作，以保持数据的一致性。

工作原理

工作流程

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

优缺点

  • 优点
    • 高可用性：Galera Cluster 通过数据的多主复制和自动故障切换，支持自动添加和剔除节点，实现了高可用性。即使某个节点发生故障，集群仍然可以继续提供服务。
    • 数据强一致性：Galera Cluster 使用多主复制协议，确保在集群中的所有节点之间的数据同步和一致性。在写操作提交之前，集群中的成员会达成一致，确保数据在所有节点上的复制是一致的。
    • 简化配置和管理：Galera Cluster 提供了简单易用的配置选项和管理工具，使得集群的配置和管理变得更加简单和方便。
    • 可扩展性：Galera Cluster 支持水平扩展，可以通过增加节点来扩展存储容量和处理能力。同时，由于数据的多主复制和负载均衡，可以实现更好的性能和吞吐量。
    • 拥有成熟的社区：Galera Cluster 拥有成熟的社区，国内有互联网公司在大规模使用。
    • 使用体验一致：用户可以直接连接 Galera Cluster 集群，使用感受上与 MySQL 完全一致。
    • 同步复制：Galera Cluster 使用了同步复制，且支持真正的并行复制（行级）。
  • 缺点
    • 网络稳定性：Galera Cluster 对网络的稳定性要求较高，因为节点之间需要进行频繁的通信和数据同步。如果网络不稳定，可能会导致数据同步延迟或节点之间的通信故障。
    • 写冲突：由于 Galera Cluster 支持多主复制，如果应用程序在不同的节点上同时进行写操作，可能会导致写冲突和一致性问题。因此，需要在应用程序层面进行合理的设计和处理。
    • 配置复杂性：尽管 Galera Cluster 提供了简化的配置选项和管理工具，但对于不熟悉 Galera Cluster 的用户来说，配置可能是一项具有挑战性的任务。
    • 需要安装补丁：使用 Galera Cluster 时，需要提前为原生 MySQL 节点安装 Wsrep 补丁。
    • 节点数需求：搭建 Galera Cluster 时，要求至少有三个服务器节点，且多节点写入开销大。
    • 使用限制
      • 不支持 GTID（全局事务标识符）。
      • 不支持异步复制，所有节点必须同步复制。
      • 不支持全局临时表，因为它们不能被复制。
      • 不支持使用外键，因为这会导致复制延迟和性能问题。
      • 不支持 DDL 语句的自动化复制，需要手动在每个节点上执行。
      • 不支持非确定性函数，因为它们在不同节点上的结果可能不同。
      • 不支持存储过程和函数的自动化复制，需要手动在每个节点上创建。
      • 只支持使用 InnoDB 存储引擎，不支持 MyISAM、NDB 存储引擎。

提示

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

Percona XtraDB Cluster

Percona XtraDB Cluster（PXC）由 Percona 公司开发，是一个基于 Galera Cluster 实现的高可用性和高性能的 MySQL 集群解决方案。它是由 Percona 开发的，建立在 Galera Replication 插件之上，提供了多主复制和数据同步的功能。

PXC 的兼容性

  • 最小化的迁移（可以非常方便地从现有系统迁移到 PXC）。
  • 快速地回退版本（无锁化、非常容易地恢复到非 PXC 系统）。
  • 完全兼容已有的系统（InnoDB 存储引擎，优化器执行计划，完全相同的优化思路）。

PXC 的使用限制

  • 仅支持 InnoDB 存储引擎，而 MySQL 自带的系统库（如 mysql）里面有些表是使用 MyISAM 存储引擎，因此不能直接对系统库的表进行 DML 操作，比如 INSERT INTO mysql.user，但使用 CREATE USER 是没有问题的，它也是正确的使用方式。
  • 不允许大事务的产生（否则的话后果很严重），允许的最大事务大小由 wsrep_max_ws_rows 和 wsrep_max_ws_size 变量定义，LOAD DATA INFILE 方式处理每 10000 行提交一次，对于大的事务将被分解众多小型事务。
  • 对于写密集型应用需要控制单个节点的大小，单个节点的数据越大，新加节点如果采用自动添加，则可能会产生很大抖动（添加节点建议提前使用备份或者备份 + Binlog 进行数据同步，尽量减少抖动）。
  • 集群高负载时应避免执行 ALTER TABLE、IMPORT、EXPORT 等操作，因为如果这些操作未在所有节点上同步执行，可能会导致节点不一致。
  • 在多主模式中不支持 LOCK TABLES 以及 UNLOCK TABLES 锁定功能，如 GET_LOCK ()，RELEASE_LOCK () 等也不被支持。
  • 硬件配置短板限制，即整个集群的写吞吐量受最弱节点的限制，因此所有 PXC 节点的硬件配置要一致。如果一个节点变慢，整个集群会跟着变慢。
  • 需要尽可能地控制 PXC 集群的规模，节点越多，数据同步速度越慢。
  • 查询日志不能定向到表，即如果启用查询日志记录，则必须将日志转发到文件，而不能转发到表。
  • enforce_storage_engine=InnoDB 与 wsrep_replicate_myisam=OFF（默认） 不兼容。
  • binlog_rows_query_log_events 变量不受支持。
  • 由于可能的提交回滚，XA 事务不受支持。
  • InnoDB 的虚假更改功能不受支持。
  • 最小的集群大小是 3 个节点。
  • 不能解决热点更新问题。

Replication 与 PXC 对比

方案介绍

  • Replication 方案（主从复制）
    • 速度快，但仅能保证弱一致性，适用于保存价值不高的数据，比如日志、帖子、新闻等。
    • 采用 Master-Slave 架构，在 Master 写入会同步到 Slave，能从 Slave 读出，但在 Slave 写入无法同步到 Master。
    • 采用异步复制，Master 写入成功就向客户端返回成功，但是同步 Slave 可能失败，会造成无法从 Slave 读出的结果。

  • Percona XtraDB Cluster（PXC）方案
    • 速度慢，但能保证强一致性，适用于保存价值较高的数据，比如订单、客户、支付数据等。
    • 数据同步是双向的，在任一节点写入数据，都会同步到其他所有节点，在任何节点上都能同时读写。
    • 采用同步复制，向任一节点写入数据，只有所有节点都同步成功后，才会向客户端返回成功。事务在所有节点要么同时提交，要么不提交。

对比说明

对比总结

  • 数据一致性对比

    • Replication 一般采用异步复制，无法保证数据的强一致性。
    • PXC 采用同步复制，事务在所有集群节点要么都提交，要么都不提交，可以保证数据的强一致性。

  • 写入性能对比

    • Replication 写入速度快，但是不能保证数据的强一致性。
    • PXC 可以保证数据的强一致性，但写入速度慢（所有节点都可以同时读写）。
    • PXC 和 Replication 都只实现了数据的同步，并没有提供数据切分（分片）的的功能。

  • 两者的区别总结

    • PXC 集群的所有节点都是可读可写，但 Replication 的从节点不能写入，因为主从同步是单向的，无法从 Slave 节点向 Master 节点同步。
    • PXC 的同步机制是同步进行的，这也是它能保证数据强一致性的根本原因，Replication 的同步机制是异步进行的，如果从节点停止同步，依然可以向主节点插入数据，且正确返回给客户端，造成主从节点的数据不一致。
    • PXC 是牺牲性能来保证数据的一致性，Replication 在性能上是高于 PXC 的，所以两者的使用场景是不一样的。
      • Replication 适用于存储普通数据，能够容忍数据丢失，例如：购物车、用户行为日志等。
      • PXC 适用于存储重要数据，要求保证数据的强一致性，例如：订单信息、支付信息、用户信息等。

PXC 高性能高可用部署方案

PXC 集群高可用架构部署

PXC 集群高性能架构部署

PXC 集群混合架构部署

MySQL InnoDB Cluster

MySQL InnoDB Cluster 是 MySQL 官方推出的一套完整高可用性解决方案。

整体架构

  • MySQL InnoDB Cluster 的核心组件
    • MySQL Group Replication：简称 MGR，是 MySQL 的主从同步高可用方案，包括数据同步及角色选举。
    • MySQL Router：业务流量的统一入口，支持对 MGR 的主从角色判断，可以配置不同的端口分别对外提供读写服务，实现读写分离等功能。
    • MySQL Shell：MySQL InnoDB Cluster 的管理工具，用来创建和管理集群。

参考资料