MySQL :: MySQL 8.4 参考手册 :: 25.7.10 NDB Cluster 复制：双向和循环复制

版本 8.4

8.0 日语

MySQL 8.4 参考手册 / ... / NDB Cluster 复制：双向和循环复制

25.7.10 NDB Cluster 复制：双向和循环复制

可以使用 NDB Cluster 在两个集群之间进行双向复制，以及在任意数量的集群之间进行循环复制。

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

只要满足以下条件，就可以支持使用这些集群进行循环复制。

所有源和副本上的 SQL 节点都相同。
所有充当源和副本的 SQL 节点都使用启用系统变量 log_replica_updates 的方式启动。

以下图表显示了这种类型的循环复制设置。

图 25.14 所有源都是副本的 NDB Cluster 循环复制

Some content is described in the surrounding text. The diagram shows three clusters, each with two nodes. Arrows connecting SQL nodes in different clusters illustrate that all sources are also replicas.

在这种情况下，集群 1 中的 SQL 节点 A 复制到集群 2 中的 SQL 节点 C；SQL 节点 C 复制到集群 3 中的 SQL 节点 E；SQL 节点 E 复制到 SQL 节点 A。换句话说，复制线（在图表中用曲线箭头表示）直接连接所有用作复制源和副本的 SQL 节点。

还可以以以下方式设置循环复制，即并非所有源 SQL 节点都是副本，如下所示。

图 25.15 并非所有源都是副本的 NDB Cluster 循环复制

在这种情况下，每个集群中不同的 SQL 节点用作复制源和副本。您必须不要使用启用系统变量 log_replica_updates 的方式启动任何 SQL 节点。对于 NDB Cluster 来说，这种类型的循环复制方案（其中复制线（在图表中再次用曲线箭头表示）是不连续的）应该是可能的，但请注意，它尚未经过充分测试，因此仍然应该被视为实验性的。

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

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

图 25.16 具有 3 个源的 NDB Cluster 多源复制

Multi-source NDB Cluster replication setup with three NDB Clusters having server IDs 1, 2, and 3; Cluster 1 replicates to Clusters 2 and 3; Cluster 2 also replicates to Cluster 3.

换句话说，数据通过 2 个不同的路由从集群 1 复制到集群 3：直接复制和通过集群 2 复制。

并非所有参与多源复制的 MySQL 服务器都必须充当源和副本，并且给定的 NDB Cluster 可能会针对不同的复制通道使用不同的 SQL 节点。这种情况如下所示。

图 25.17 NDB Cluster 多源复制，带有 MySQL 服务器

Concepts are described in the surrounding text. Shows three nodes: SQL node A in Cluster 1 replicates to SQL node F in Cluster 3; SQL node B in Cluster 1 replicates to SQL node C in Cluster 2; SQL node E in Cluster 3 replicates to SQL node G in Cluster 3. SQL nodes A and B in cluster 1 have --log-replica-updates=0; SQL nodes C in Cluster 2, and SQL nodes F and G in Cluster 3 have --log-replica-updates=1; and SQL nodes D and E in Cluster 2 have --log-replica-updates=0.

充当副本的 MySQL 服务器必须使用启用系统变量 log_replica_updates 的方式运行。哪些 mysqld 进程需要此选项也显示在前面的图表中。

注意

使用系统变量 log_replica_updates 对没有作为副本运行的服务器没有影响。

当其中一个复制集群停止工作时，就会出现故障转移的必要性。在本例中，我们考虑集群 1 停止服务的情况，因此集群 3 丢失了来自集群 1 的 2 个更新源。由于 NDB Cluster 之间的复制是异步的，因此无法保证来自集群 1 的集群 3 的更新比通过集群 2 收到的更新更最新。您可以通过确保集群 3 在来自集群 1 的更新方面赶上集群 2 来处理此问题。在 MySQL 服务器方面，这意味着您需要将来自 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;

注意

您可以通过向 ndb_binlog_index 表添加适当的索引来提高此查询的性能，从而可能显着加快故障转移时间。有关更多信息，请参见第 25.7.4 节，“NDB Cluster 复制架构和表”。

将 @file 和 @pos 的值从服务器 C 手动复制到服务器 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.34 节，“SHOW REPLICA STATUS 语句”。有关此选项如何与 ndb_log_apply_status 变量交互的信息，请参见第 25.7.8 节，“使用 NDB Cluster 复制实施故障转移”。

PREV HOME UP NEXT