可以使用 NDB 集群在两个集群之间进行双向复制，也可以在任意数量的集群之间进行环形复制。It is possible to use NDB Cluster for bidirectional replication between two clusters, as well as for circular replication between any number of clusters.

循环复制示例。 在接下来的几段中，我们将考虑一个包含三个编号为 1、2 和 3 的 NDB 集群的复制设置示例，其中集群 1 作为集群 2 的复制源，集群 2 作为集群 3 的复制源，集群 3 作为集群 1 的复制源。每个集群都有两个 SQL 节点，SQL 节点 A 和 B 属于集群 1，SQL 节点 C 和 D 属于集群 2，SQL 节点 E 和 F 属于集群 3。Circular replication example.  In the next few paragraphs we consider the example of a replication setup involving three NDB Clusters numbered 1, 2, and 3, in which Cluster 1 acts as the replication source for Cluster 2, Cluster 2 acts as the source for Cluster 3, and Cluster 3 acts as the source for Cluster 1. Each cluster has two SQL nodes, with SQL nodes A and B belonging to Cluster 1, SQL nodes C and D belonging to Cluster 2, and SQL nodes E and F belonging to Cluster 3.

只要满足以下条件，就支持使用这些集群进行循环复制：Circular replication using these clusters is supported as long as the following conditions are met:

这种类型的循环复制设置如下图所示：This type of circular replication setup is shown in the following diagram:

图 25.14 所有源为副本的 NDB 集群循环复制Figure 25.14 NDB Cluster Circular Replication with All Sources As Replicas

在这种情况下，集群 1 的 SQL 节点 A 会复制到集群 2 的 SQL 节点 C；SQL 节点 C 复制到集群 3 的 SQL 节点 E；SQL 节点 E 复制到 SQL 节点 A。换句话说，复制线路（如图中弯箭头所示）直接连接了所有作为复制源和副本的 SQL 节点。In this scenario, SQL node A in Cluster 1 replicates to SQL node C in Cluster 2; SQL node C replicates to SQL node E in Cluster 3; SQL node E replicates to SQL node A. In other words, the replication line (indicated by the curved arrows in the diagram) directly connects all SQL nodes used as replication sources and replicas.

也可以设置循环复制，使得并非所有源 SQL 节点都是副本，如下所示：It is also possible to set up circular replication in such a way that not all source SQL nodes are also replicas, as shown here:

图 25.15 NDB 集群循环复制（并非所有源都是副本）Figure 25.15 NDB Cluster Circular Replication Where Not All Sources Are Replicas

在这种情况下，每个集群中的不同 SQL 节点被用作复制源和副本。您 不得 启动任何 SQL 节点，同时启用系统变量 log_replica_updates。这种针对 NDB Cluster 的循环复制方案，其中复制线路（在图中再次由曲线箭头表示）是不连续的，应当是可行的，但需要注意的是，它尚未经过彻底测试，因此仍应视为实验性功能。In this case, different SQL nodes in each cluster are used as replication sources and replicas. You must not start any of the SQL nodes with the system variable log_replica_updates enabled. This type of circular replication scheme for NDB Cluster, in which the line of replication (again indicated by the curved arrows in the diagram) is discontinuous, should be possible, but it should be noted that it has not yet been thoroughly tested and must therefore still be considered experimental.

使用原生 NDB 备份和恢复初始化副本集群。 在设置循环复制时，可以通过在一个 NDB 集群上使用管理客户端的 START BACKUP 命令创建备份，然后使用 ndb_restore 将此备份应用到另一个 NDB 集群，从而初始化副本集群。这不会自动在作为副本的第二个 NDB 集群的 SQL 节点上创建二进制日志；为了生成二进制日志，必须在该 SQL 节点上执行 SHOW TABLES 语句；这应在运行 START REPLICA 之前完成。这是一个已知问题。Using NDB-native backup and restore to initialize a replica cluster.  When setting up circular replication, it is possible to initialize the replica cluster by using the management client START BACKUP command on one NDB Cluster to create a backup and then applying this backup on another NDB Cluster using ndb_restore. This does not automatically create binary logs on the second NDB Cluster's SQL node acting as the replica; in order to cause the binary logs to be created, you must issue a SHOW TABLES statement on that SQL node; this should be done prior to running START REPLICA. This is a known issue.

多源故障切换示例。 本节中，我们讨论在多源 NDB 集群复制设置中进行故障切换的情况，该设置包含三个 NDB 集群，其服务器 ID 分别为 1、2 和 3。在此方案中，集群 1 复制到集群 2 和 3；集群 2 也复制到集群 3。此关系如下所示：Multi-source failover example.  In this section, we discuss failover in a multi-source NDB Cluster replication setup with three NDB Clusters having server IDs 1, 2, and 3. In this scenario, Cluster 1 replicates to Clusters 2 and 3; Cluster 2 also replicates to Cluster 3. This relationship is shown here:

图 25.16 具有 3 个源的 NDB 集群多源复制Figure 25.16 NDB Cluster Multi-Source Replication With 3 Sources

换句话说，数据通过两条不同的路线从集群 1 复制到集群 3：直接复制，以及通过集群 2 复制。In other words, data replicates from Cluster 1 to Cluster 3 through 2 different routes: directly, and by way of Cluster 2.

并非所有参与多源复制的 MySQL 服务器都必须同时充当源和副本，且给定的 NDB 集群可能会针对不同的复制通道使用不同的 SQL 节点。此情况如下所示：Not all MySQL servers taking part in multi-source replication must act as both source and replica, and a given NDB Cluster might use different SQL nodes for different replication channels. Such a case is shown here:

图 25.17 NDB 集群多源复制，带 MySQL 服务器Figure 25.17 NDB Cluster Multi-Source Replication, With MySQL Servers

作为副本运行的 MySQL 服务器必须启用系统变量 log_replica_updates。前面的图表还显示了哪些 mysqld 进程需要此选项。MySQL servers acting as replicas must be run with the system variable log_replica_updates enabled. Which mysqld processes require this option is also shown in the preceding diagram.

当其中一个复制集群发生故障时，就需要进行故障切换。在此示例中，我们考虑集群 1 停止服务的情况，因此集群 3 将失去来自集群 1 的 2 个更新源。由于 NDB 集群之间的复制是异步的，因此无法保证集群 3 直接来自集群 1 的更新比通过集群 2 接收到的更新更新。你可以通过确保集群 3 跟上集群 2 关于来自集群 1 的更新来处理此情况。在 MySQL 服务器方面，这意味着你需要将 MySQL 服务器 C 上所有未完成的更新复制到服务器 F。The need for failover arises when one of the replicating clusters goes down. In this example, we consider the case where Cluster 1 is lost to service, and so Cluster 3 loses 2 sources of updates from Cluster 1. Because replication between NDB Clusters is asynchronous, there is no guarantee that Cluster 3's updates originating directly from Cluster 1 are more recent than those received through Cluster 2. You can handle this by ensuring that Cluster 3 catches up to Cluster 2 with regard to updates from Cluster 1. In terms of MySQL servers, this means that you need to replicate any outstanding updates from MySQL server C to server F.

在服务器 C 上，执行以下查询：On server C, perform the following queries:

mysqlC> SELECT @latest:=MAX(epoch)
     ->     FROM mysql.ndb_apply_status
     ->     WHERE server_id=1;

mysqlC> SELECT
     ->     @file:=SUBSTRING_INDEX(File, '/', -1),
     ->     @pos:=Position
     ->     FROM mysql.ndb_binlog_index
     ->     WHERE orig_epoch >= @latest
     ->     AND orig_server_id = 1
     ->     ORDER BY epoch ASC LIMIT 1;

手动将 @file 和 @pos 的值从服务器 C 复制到服务器 F（或让您的应用程序执行等效操作）。然后，在服务器 F 上执行以下 CHANGE REPLICATION SOURCE TO 语句：Copy over the values for @file and @pos manually from server C to server F (or have your application perform the equivalent). Then, on server F, execute the following CHANGE REPLICATION SOURCE TO statement:

mysqlF> CHANGE REPLICATION SOURCE TO
     ->     SOURCE_HOST = 'serverC'
     ->     SOURCE_LOG_FILE='@file',
     ->     SOURCE_LOG_POS=@pos;

一旦完成此操作，您可以在 MySQL 服务器 F 上发出 START REPLICA 语句；这将使来自服务器 B 的任何缺失更新被复制到服务器 F。Once this has been done, you can issue a START REPLICA statement on MySQL server F; this causes any missing updates originating from server B to be replicated to server F.

CHANGE REPLICATION SOURCE TO 语句还支持一个 IGNORE_SERVER_IDS 选项，该选项接受逗号分隔的服务器 ID 列表，并使来自相应服务器的事件被忽略。有关此语句的更多信息，请参阅文档，以及 第 15.7.7.35 节，“SHOW REPLICA STATUS 语句”。有关此选项如何与 ndb_log_apply_status 变量交互的信息，请参阅 第 25.7.8 节，“使用 NDB 集群复制实现故障转移”。The CHANGE REPLICATION SOURCE TO statement also supports an IGNORE_SERVER_IDS option which takes a comma-separated list of server IDs and causes events originating from the corresponding servers to be ignored. See the documentation for this statement for more information, as well as Section 15.7.7.35, “SHOW REPLICA STATUS Statement”. For information about how this option interacts with the ndb_log_apply_status variable, see Section 25.7.8, “Implementing Failover with NDB Cluster Replication”.