作者： zimuxia-PingCAP 原文来源：https://tidb.net/blog/8352bedb

背景

Multi-master replication 是数据库复制的一种方法，它将数据存储于一组服务器，并允许该组服务器的任何成员对数据进行查询或更新。此解决方案的系统会将每个成员所做的数据修改传播到副本组的其余成员，并解决不同成员进行的并发更改之间可能出现的任何冲突。

方案

Singe-master

此方案中一般是主从的架构，即 Master 负责写操作的负载，也就是说一切写的操作都在 Master 上进行，而读的操作则分摊到 Slave 上进行。

此方案在一般情况下拥有的优势有：可以读写分离，例如，分析应用程序可以从 Slave 读取，而不会影响主站；在整个数据库备份时，对 Master 的影响相对较小。缺点是主要包括：在发生故障的情况下，需要将 Slave 转成 Master；当 Master 发生故障时，可能丢失数据；转换主从节点后，可能需要应用端重启。

Multi-Master

此方案的优势是可以分摊写入流量；自动且基本上无开销的故障转移，从而提高可用性；方便地域的用户就近访问。缺点是大多数多主复制系统只是松散一致的，此外随着所涉及的节点数量的增加和所需等待时间的减少，诸如配置、解决冲突之类的问题可能变得复杂。

Aurora

在多主集群中，所有数据库实例都具有读写功能。数据存储在一个高度可靠且自动增长的共享存储卷中。与单主集群核心差异在于数据库实例的数量和类型。在多主集群中，有 N 个读写节点。目前，N 的最大值为 2。

使用低延迟和低滞后 Aurora 复制连接多主集群节点。多主集群使用全对等复制。每个 Writer 均会将其更改复制到所有其他 Writer。

副本同步方法：

如果提出更改的 Writer 节点收到了一定数量的存储节点（会存储全量数据）的肯定确认，则它将执行两件事。首先，它在存储层中提交更改，从而导致每个存储节点都提交更改。然后，它使用低延迟的 peer-to-peer 复制协议将更改记录复制到群集中的每个其他 Writer 节点。这些 Writer 节点在收到更改信息后将更改应用于它们的内存中缓存。

下图说明了在写程序节点故障和随后的恢复时，应用程序层进行的连接重新分配如何提供连续的数据库可用性。图 1 显示了已建立与 Writer 1 和 Writer 2 的数据库连接的应用程序。图 2 显示了 Writer 1 的故障，将其从群集中删除。该应用程序重新建立（移动）发生故障的 Writer 1 到 Writer 2 的连接。图 3 显示 Writer 1 已修复并恢复联机。该应用程序将已移动到 Writer 2 的连接移回 Writer 1。

                             图 1

                             图 2

                             图 3

Aurora 多主集群的以下优势：

• 多主集群进一步提高了 Aurora 的高可用性。可以重新启动读写数据库实例，而不会导致集群中的其他数据库实例重新启动。当读写数据库实例变得不可用时，没有故障转移过程和相关的延迟。

• 多主集群非常适合分片应用程序或多租户应用程序。在管理数据时，可以避免复杂的重新分片操作。您可能能够使用较少数量的集群或数据库实例来合并分片应用程序。

• Aurora 会立即检测写冲突，而不是在事务提交时这样做。

Aurora 多主集群不足包括它不保证强一致读。此外，此方案对 SQL 会有一些限制，例如：多主集群不能包含任何具有全文搜索 (FTS) 索引的表，当表正在进行 DDL 时，无法对该表进行写入，无法在多主集群上使用 SERIALIZABLE 事务隔离级别等。

MySQL NDB Cluster

NDB 群集是一项使无共享系统中的内存数据库得以群集的技术。无共享架构使系统可以使用非常便宜的硬件，并且对硬件或软件的特定要求最少。NDB 群集被设计为没有任何单点故障。在没有共享的系统中，每个组件都应具有自己的内存和磁盘，并且不建议或不支持使用共享存储机制，例如网络共享，网络文件系统和 SAN。

NDB Cluster 将标准 MySQL 服务器与称为内存的集群存储引擎 NDB 集成在一起。它是一种内存存储引擎，提供高可用性和数据持久性功能。

此类群集节点共有三种类型:

管理节点：这种类型的节点的作用是管理 NDB 群集中的其他节点，执行诸如提供配置数据，启动和停止节点以及运行备份之类的功能。由于此节点类型管理其他节点的配置，因此应首先启动此类型的节点，然后再启动任何其他节点。

数据节点：这种类型的节点存储集群数据。数据节点的数量是副本的数量乘以片段的数量。例如，对于两个副本（每个副本都有两个片段），您需要四个数据节点。一个副本足以存储数据，但不提供冗余。

SQL 节点：这是访问群集数据的节点。

NDB 群集内的自动同步复制，使用 MySQL 复制在 NDB 群集之间进行异步复制（不支持同步复制）。此方案有两种循环复制：多个 NDB 群集之间进行循环复制，NDB 群集循环复制并非所有 Master 都是 Slave。

循环复制示例。 在接下来的几段中，我们将考虑复制设置的示例，其中涉及三个编号为 1，2 和 3 的 NDB 群集，其中群集 1 充当群集 2 的复制主服务器，群集 2 充当群集 3 的主服务器和群集 3 充当集群 1 的主节点。每个集群具有两个 SQL 节点，其中 SQL 节点 A 和 B 属于集群 1，SQL 节点 C 和 D 属于集群 2，SQL 节点 E 和 F 属于集群 3。

如上图所示方案中，群集 1 中的 SQL 节点 A 复制到群集 2 中的 SQL 节点 C; SQL 节点 C 复制到集群 3 中的 SQL 节点 E; SQL 节点 E 复制到 SQL 节点 A。

如上面图所示情况下，每个群集中的不同 SQL 节点将用作复制主服务器和从服务器。

NDB Cluster 案优点包括：快速自动故障转移；灵活的分布式架构，无单点故障；可扩展性，支持在线容量扩展等。缺点有：有很多限制，例如：事务隔离级别只支持 Read Committed；部署，管理，配置非常复杂；备份和恢复不方便等。

Percona XtraDB Cluster

PXC 基于 Galera 协议的高可用方案。Galera 是 Codership 提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。

此方案中的每个节点都包含完整的数据副本，即节点的数据完全对等。PXC 中使用乐观锁，以避免在每个节点获取锁以及网路开销。在写入节点上，事务在提交之前与单点的 Innodb 一样。到达提交点时，向集群其他节点（galera 库完成）广播并等待各节点验证结果。如果所有节点都返回成功，则提交，否则回滚。它保证了整个集群所有数据的强一致性。

此方案的优势如下：

• 当执行一个查询时，在本地节点上执行。因为所有数据都在本地，无需远程访问。

• 无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作。

此方案的缺点包括：其一，加入新节点必须从现有节点之一复制完整数据集，所以新加节点开销比较大。其二，整个群集的写吞吐量受限制于最弱节点，即如果一个节点变得缓慢，则整个群集会缓慢。此外，不能用作有效的写扩展解决方案。