MySQL :: MySQL 9.0 參考手冊 :: 25.7.10 NDB Cluster 複寫：雙向與環狀複寫

版本 9.0

8.4 目前
8.0
5.7

8.0 日文

MySQL 9.0 參考手冊 / ... / NDB 叢集複製：雙向和環狀複製

25.7.10 NDB 叢集複製：雙向和環狀複製

NDB 叢集可用於兩個叢集之間的雙向複製，以及任意數量的叢集之間的環狀複製。

環狀複製範例。 在接下來的幾個段落中，我們考慮一個涉及三個 NDB 叢集的複製設定範例，編號為 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 叢集環狀複製

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 叢集環狀複製

在這種情況下，每個叢集中使用不同的 SQL 節點作為複製來源和複本。您不能啟用系統變數 log_replica_updates來啟動任何 SQL 節點。這種 NDB 叢集的環狀複製方案（其中複製線（再次由圖表中的彎曲箭頭表示）是不連續的）應該是可行的，但應該注意的是，它尚未經過徹底測試，因此仍應被視為實驗性的。

使用 NDB 原生備份和還原來初始化複本叢集。 設定環狀複製時，可以使用管理用戶端 START BACKUP 命令在一個 NDB 叢集上建立備份，然後使用 ndb_restore 將此備份套用在另一個 NDB 叢集上，藉此初始化複本叢集。這不會在第二個 NDB 叢集的 SQL 節點（作為複本）上自動建立二進位日誌；為了導致建立二進位日誌，您必須在該 SQL 節點上發出 SHOW TABLES 陳述式；這應該在執行 START REPLICA 之前完成。這是一個已知問題。

多來源容錯移轉範例。 在本節中，我們討論具有伺服器 ID 1、2 和 3 的三個 NDB 叢集的多來源 NDB 叢集複製設定中的容錯移轉。在此情境中，叢集 1 複製到叢集 2 和 3；叢集 2 也複製到叢集 3。此關係如下所示

圖 25.16：具有 3 個來源的 NDB 叢集多來源複製

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 叢集可能對不同的複製通道使用不同的 SQL 節點。這種情況如下所示

圖 25.17：具有 MySQL 伺服器的 NDB 叢集多來源複製

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 叢集之間的複製是異步的，因此無法保證叢集 3 直接來自叢集 1 的更新比透過叢集 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 叢集複製綱要和表格」。

手動將 @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 叢集複製實作容錯移轉」。