MySQL 官方提供了多种高可用部署方案，从最基础的主从复制到组复制再到 InnoDB Cluster 等等。本篇文章以 MySQL 8.0 版本为准，介绍下不同高可用方案架构原理及使用场景。

MySQL Replication

MySQL Replication（MySQL 复制）是一种用来实现数据从一个 MySQL 服务器（主库）复制到一个或多个 MySQL 服务器（从库）的机制。它通常用于提高数据的可用性、性能以及容灾能力。Replication 提供了异步复制的能力，使得主从数据库在不完全同步的情况下仍能工作，这非常适合于读写分离、备份、负载均衡等场景。

MySQL Replication 的工作原理

MySQL Replication 的基本流程如下：

  1. 主库（Master）记录更改：当主库上发生写操作（如 INSERT、UPDATE、DELETE）时，主库会将这些更改记录到二进制日志（binlog） 中。二进制日志是所有数据修改的日志文件。
  2. 从库（Slave）读取二进制日志：从库通过I/O线程连接到主库，并请求从主库读取二进制日志。这些日志文件被复制到从库并存储为中继日志（relay log）。
  3. 从库应用更改：从库的SQL线程会读取中继日志，将这些日志中的数据修改应用到从库上，最终保持从库与主库的数据同步。

MySQL Replication 的模式

  1. 异步复制（Asynchronous Replication）：主库不等待从库确认复制完成即返回给客户端。这种模式性能高，但可能会造成主从数据短暂不一致。[默认]
  2. 半同步复制（Semi-Synchronous Replication）：主库在执行写操作时，等待至少一个从库确认数据已经复制，但不等待所有从库完成复制。这种模式比全同步复制性能好，但也提高了一定的一致性。
  3. 全同步复制（Fully Synchronous Replication）：主库等待所有从库都确认复制成功后，才将操作结果返回给客户端。尽管这种模式下数据一致性最好，但由于性能开销大，使用较少。

优势

  • 数据备份：通过复制机制，可以将数据同步到从库，用于备份和灾难恢复。
  • 负载均衡：主库处理写操作，从库处理读操作，能显著减少主库压力。
  • 高可用性：当主库发生故障时，可以快速切换到从库，确保业务不中断。

适用场景：

  • 读密集型应用：在需要高读取性能的场景下，读写分离架构可以有效提升性能。
  • 数据备份和容灾：用作数据实时备份和故障恢复的场景。
  • 业务分布：适合对高可用要求不高的业务，允许丢数据及同步延迟。

MySQL Group Replication

MySQL Group Replication（MGR） 是 MySQL 5.7 之后引入的高可用性和高扩展性解决方案。它基于原生 MySQL 复制技术，并结合了分布式共识协议 Paxos，确保集群中的多个节点能保持数据的一致性。MGR 提供了两种运行模式：单主模式 和 多主模式。在组复制中，集群至少需要 3 个节点来保证数据一致性和容错能力。

主要特点：

  1. 高一致性：通过 Paxos 协议，MGR 能够确保多个节点之间的数据是一致的。即使某些节点发生故障，系统也能自动检测和恢复，并保持数据同步。
  2. 高容错性：组复制具备自动故障检测与恢复功能，集群能够自动剔除故障节点，保证系统的连续可用性。
  3. 高扩展性：MGR 支持动态扩展，允许你在不停止集群的情况下添加或删除节点，且能够自动将数据同步到新加入的节点。
  4. 灵活的主从模式：
    • 单主模式：集群中只有一个节点负责写操作，其他节点只提供读操作。这种模式通常用于高可用场景，写请求集中到一个节点，其他节点分担读请求。
    • 多主模式：多个节点同时可以进行读写操作，适合多区域数据中心或高并发写操作的场景。

MGR 的工作原理：

  1. 主节点（Primary Node）：处理写入操作，并通过组复制协议将更改传播到其他节点。
  2. 从节点（Secondary Nodes）：接收来自主节点的写操作并应用它们，保持数据一致。
  3. 自动选主：当主节点发生故障时，MGR 自动选举新的主节点，确保服务不中断。
  4. 故障恢复：失效的节点可以在恢复后重新加入集群，并自动同步缺失的数据。

工作流程：

  • 事务提交过程：主节点上的事务提交时，通过 Paxos 共识协议将事务分发给其他节点，确保集群中所有节点的一致性。
  • 冲突检测：多主模式下，如果多个节点同时执行写操作，MGR 会通过事务冲突检测机制来确保数据一致性。

适用场景：

  • 高可用性需求：适用于需要高可用性和数据强一致性的场景。
  • 分布式系统：适用于需要分布式数据处理和高吞吐量的应用。
  • 自动化管理：适用于希望通过自动化工具简化管理和运维的企业。

MySQL Group Replication 和 MySQL Replication 的对比：

特性 MySQL Replication MySQL Group Replication
架构 主从架构（Master-Slave） 多主架构（Multi-Master）或单主模式
复制类型 异步或半同步 同步（基于 Paxos 协议）
一致性 最终一致性（Eventual Consistency） 强一致性（Strong Consistency）
故障切换（Failover） 需要手动故障切换或使用工具 自动故障切换，集群可自动选择新主节点
主节点数量 单一主节点 可有多个主节点（Multi-Primary 模式）
事务处理 支持单主事务 支持分布式事务，强一致性
写操作 只有主节点可写 多主节点均可写（Multi-Primary）
冲突检测 无内置冲突检测机制 内置冲突检测和处理机制
数据同步 通过二进制日志（Binlog）进行复制 基于组复制协议，使用事务提交同步
扩展性 需要手动配置、添加节点 自动发现并添加节点，节点加入集群即被识别
适用场景 单主节点写入，多从节点读 高可用、高一致性场景，支持多主写入
集群成员的通信协议 基于 TCP/IP 复制 使用 Paxos 协议确保分布式一致性
读写分离 支持读写分离（主写，从读） 支持但在多主模式下可以避免
冲突处理 依赖应用层处理 内置冲突检测机制（避免数据冲突）
数据丢失风险 有可能数据丢失（半同步可降低风险） 更低的数据丢失风险（同步复制）

MySQL InnoDB Cluster

MySQL InnoDB Cluster 是 MySQL 官方提供的一种原生高可用性和高可扩展性解决方案。它通过使用 Group Replication 来实现数据的自动复制和高可用性。并结合 MySQL Shell 及 MySQL Router ，提供了更全面的高可用解决方案，包括自动安装、配置、管理和监控 MySQL 集群的能力。架构示意图如下：

image-20241010200115615

InnoDB Cluster 集群内部基于 MySQL 组复制构建，提供自动成员管理，容错，自动故障转移动能等。利用 MySQL Shell 提供的 AdminAPI 功能来管理和配置 InnoDB Cluster。利用 MySQL Router 提供路由功能， 将客户端应用程序透明地连接到服务器实例，如果服务器实例发生意外故障，集群会自动重新配置。

主要特性：

  • 自动故障转移：在主节点出现故障时，系统可以自动将读写请求切换到可用的从节点，确保服务的连续性。
  • 强一致性：利用 Group Replication 确保所有节点的数据一致性。
  • 读写分离：支持读写分离，提高系统的读性能。
  • 简化管理：通过 MySQL Shell 和 AdminAPI 进行自动化管理，简化集群的部署和运维。

适用场景：

  • 适用于需要高可用性、高一致性和高读性能的应用场景，推荐使用 MySQL 8.0 的高版本进行部署。

MySQL InnoDB Cluster 在 MySQL Group Replication 的基础上增加了高可用性管理和自动化配置，提供了更简化的部署、监控和故障恢复功能，适合生产环境中的完整高可用解决方案。

MySQL InnoDB ClusterSet

MySQL InnoDB ClusterSet 是对 MySQL InnoDB Cluster 的扩展，支持跨数据中心的多集群部署，提供更强的地理分布容灾能力，而 InnoDB Cluster 主要针对单数据中心的高可用性。

image-20241010200409022

MySQL InnoDB ClusterSet 在 MySQL InnoDB Cluster 的基础上增加了跨多个集群的地理分布容灾和多集群管理能力，使其适用于跨数据中心的高可用性和容灾场景。

MySQL InnoDB ClusterSet 通过在不同地理区域部署多个 InnoDB Clusters，并使用异步复制在集群间传输数据，配合自动故障切换和全局路由，实现跨集群的高可用性和容灾能力，同时集中管理多个集群，确保业务在跨地域故障时快速恢复。

MySQL InnoDB ReplicaSet

MySQL InnoDB ReplicaSet 是基于传统主从复制架构的高可用性方案，只是集成了 MySQL Shell 及 MySQL Router 进行配置及管理。InnoDB ReplicaSet 不提供 InnoDB Cluster 提供的所有功能，例如自动故障转移或多主模式。但是它确实支持以类似方式配置、添加和删除实例等功能。在主节点不可用的情况下，需要使用 AdminAPI 手动触发故障转移。

主要特性：

  • 主从复制：基于异步复制技术，将数据从主节点复制到一个或多个从节点。
  • 手动故障转移：在主节点故障时需要手动进行故障转移。
  • 易于管理：架构相对简单，配置和管理较为方便。

适用场景：

  • 适用于中小型企业的业务系统、开发和测试环境等不需要复杂高可用性和自动故障转移的场景。

总结

总结1：

特性 MySQL Replication MySQL Group Replication MySQL InnoDB Cluster MySQL InnoDB ClusterSet MySQL InnoDB ReplicaSet
高可用性 通过多个从服务器提高 自动故障转移 自动故障转移、自动路由 跨地域高可用和容灾 手动故障转移
数据一致性 最终一致性（异步/半同步复制制） 强一致性（分布式协议） 强一致性（Group Replication） 各集群内强一致性，集群间异步一致性 最终一致性（异步复制制）
优点 简单易用，维护简易 高一致性，支持多主模式，自动故障恢复 自动化管理，强一致性，自动故障转移 跨地域高可用，自动故障转移 简单易用，读写分离，MySQL Shell 支持
缺点 最终一致性，手动故障转移，扩展性有限 配置复杂，仅支持 InnoDB 表，网络需求高 资源需求高，网络要求高，维护复杂 资源需求最高，有一定的学习曲线，维护成本 手动故障转移，一致性问题
适用场景 大规模读扩展，非关键业务数据备份，低成本解决方案 高一致性需求，自动故障恢复，小到中型集群 高一致性，高可用性，高读写性能需求场景 大型企业级应用，跨地域高可用和容灾需求 简单的高可用性和读写分离需求场景

总结2：

  • 对于小型应用，可以使用 主从复制 或 MHA。
  • 对于高一致性和高可用性要求的应用，推荐使用 MySQL Group Replication 或 MySQL InnoDB Cluster。
  • 对于跨地域容灾需求，可以使用 MySQL InnoDB ClusterSet。

补充：MHA（Master High Availability）

  • 基本原理：MHA 是一个开源的 MySQL 高可用解决方案，能在主库故障时自动从从库中选出一个新的主库，并将其切换为主库，减少故障恢复时间。
  • **底层原理：**MHA（Master High Availability） 的底层原理是通过监控 MySQL 主库状态，自动检测故障并在主库宕机时进行快速主从切换，选举延迟最小的从库作为新主库。同时，MHA 在故障转移时通过收集并应用主库的 binlog（从未同步的事务日志），最大限度地减少数据丢失，确保数据一致性。整个过程由 MHA Manager 进行控制和协调，无需手动干预。
  • 优点：自动故障转移，数据丢失量少（通常只丢失未复制的少量事务）。
  • 缺点：切换过程需要手动配置；实现有一定复杂性，依赖 SSH 管理集群。
  • 适用场景：需要高可用性、自动故障转移的中大型企业应用。

部分参考：

介绍几种 MySQL 官方高可用方案

技术分享 | MySQL InnoDB Cluster Set 介绍