可以使用 NDB 集群进行双向复制和环形复制。

环形复制示例。 下面，我们考虑一个涉及三个 NDB 集群（编号 1、2 和 3）的复制设置，Cluster 1 作为 Cluster 2 的复制源，Cluster 2 作为 Cluster 3 的复制源，Cluster 3 作为 Cluster 1 的复制源。每个集群都有两个 SQL 节点，SQL 节点 A 和 B 属于 Cluster 1，SQL 节点 C 和 D 属于 Cluster 2，SQL 节点 E 和 F 属于 Cluster 3。

只要满足以下条件，环形复制就支持这些集群：

这种环形复制设置如以下图所示：

在这种情况下，SQL 节点 A 在 Cluster 1 复制到 SQL 节点 C 在 Cluster 2；SQL 节点 C 复制到 SQL 节点 E 在 Cluster 3；SQL 节点 E 复制到 SQL 节点 A。在其他 words，复制线（图中的弯曲箭头）直接连接所有 SQL 节点，用于作为复制源和副本。

也可以设置环形复制，使得不所有源 SQL 节点都是副本，如下所示：

在这种情况下，每个集群中的不同 SQL 节点用于复制源和副本。您 不能 启动任何 SQL 节点时启用系统变量 log_replica_updates。这种 NDB 集群环形复制方案，复制线（图中的弯曲箭头）是断开的，尚未经过彻底测试，因此仍然是实验性的。

使用 NDB 本机备份和还原来初始化副本集群。  设置环形复制时，可以使用管理客户端 START BACKUP 命令在一个 NDB 集群上创建备份，然后在另一个 NDB 集群上应用该备份使用 ndb_restore。这不会自动在第二个 NDB 集群的 SQL 节点上创建二进制日志；为了创建二进制日志，必须在该 SQL 节点上发出 SHOW TABLES 语句；这应该在运行 START REPLICA 之前完成。这是一个已知的问题。

多源失效转移示例。  在本节中，我们讨论了多源 NDB 集群复制设置中的失效转移，具有服务器 ID 1、2 和 3 的三个 NDB 集群。在这种情况下，Cluster 1 复制到 Cluster 2 和 Cluster 3；Cluster 2 也复制到 Cluster 3。这种关系如下所示：

换言之，数据从 Cluster 1 复制到 Cluster 3 通过 2 个不同的路由：直接和通过 Cluster 2。

并不是所有参与多源复制的 MySQL 服务器都必须同时作为源和副本，一个 NDB 集群可能使用不同的 SQL 节点 для不同的复制通道。这种情况如下所示：

作为副本的 MySQL 服务器必须运行时启用系统变量 log_replica_updates。哪些 mysqld 进程需要这个选项也显示在前面的图中。

当一个复制集群崩溃时，需要故障转移。在这个例子中，我们考虑 Cluster 1 不可用，Cluster 3 将失去来自 Cluster 1 的 2 个更新源。由于 NDB 集群之间的复制是异步的，因此无法保证 Cluster 3 直接来自 Cluster 1 的更新比通过 Cluster 2 收到的更新更新。你可以通过确保 Cluster 3赶上 Cluster 2 的更新来处理这个问题。在 MySQL 服务器方面，这意味着你需要从服务器 C 复制任何未完成的更新到服务器 F。

在服务器 C 上，执行以下查询：

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;

手动从服务器 C 复制 @file 和 @pos 的值到服务器 F（或让应用程序执行等效操作）。然后，在服务器 F 上执行以下 CHANGE REPLICATION SOURCE TO 语句：

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

完成后，你可以在 MySQL 服务器 F 上发出 START REPLICA 语句；这将导致来自服务器 B 的任何缺失更新被复制到服务器 F。

该 CHANGE REPLICATION SOURCE TO 语句还支持一个 IGNORE_SERVER_IDS 选项，该选项采用逗号分隔的服务器 ID 列表，并导致来自相应服务器的事件被忽略。请参阅该语句的文档，以获取更多信息，以及 第 15.7.7.37 节，“SHOW REPLICA STATUS 语句”。关于该选项如何与 ndb_log_apply_status 变量交互，请参阅 第 25.7.8 节，“使用 NDB 集群复制实现故障转移”。