ndb_apply_status 用於記錄已從來源複寫到複本的操作。如果複本上不存在 ndb_apply_status 資料表，ndb_restore 會重新建立此資料表。

與 ndb_binlog_index 的情況不同，此資料表中的資料並非特定於 (複本) 叢集中的任何一個 SQL 節點，因此 ndb_apply_status 可以使用 NDBCLUSTER 儲存引擎，如下所示

CREATE TABLE `ndb_apply_status` (
    `server_id`   INT(10) UNSIGNED NOT NULL,
    `epoch`       BIGINT(20) UNSIGNED NOT NULL,
    `log_name`    VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
    `start_pos`   BIGINT(20) UNSIGNED NOT NULL,
    `end_pos`     BIGINT(20) UNSIGNED NOT NULL,
    PRIMARY KEY (`server_id`) USING HASH
) ENGINE=NDBCLUSTER DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

ndb_apply_status 資料表僅在複本上填入，這表示在來源上，此資料表永遠不會包含任何列；因此，不需要在那裡配置任何 DataMemory 給 ndb_apply_status。

由於此資料表是從來源上的資料填入的，因此應允許複寫；任何無意中阻止複本更新 ndb_apply_status 或阻止來源寫入二進位記錄檔的複寫篩選或二進位記錄篩選規則，都可能會阻止叢集之間的複寫正常運作。如需更多有關此類篩選規則可能產生的問題資訊，請參閱 NDB 叢集之間複寫的複寫和二進位記錄篩選規則。

可以刪除此資料表，但不建議這麼做。刪除此資料表會將所有 SQL 節點設為唯讀模式；NDB 會偵測到此資料表已刪除，並重新建立，之後就可以再次執行更新。刪除和重新建立 ndb_apply_status 會在二進位記錄檔中建立間隙事件；間隙事件會導致複本 SQL 節點停止套用來自來源的變更，直到重新啟動複寫通道為止。

此資料表的 epoch 資料欄中的 0 表示來源為 NDB 以外的儲存引擎的交易。

ndb_apply_status 用於記錄已從上游來源複寫並套用至複本叢集的 epoch 交易。此資訊會擷取在 NDB 線上備份中，但 (依設計) 不會由 ndb_restore 還原。在某些情況下，還原此資訊以便在新設定中使用可能會很有幫助；您可以透過使用 --with-apply-status 選項叫用 ndb_restore 來達成此目的。如需更多資訊，請參閱選項的描述。

NDB 叢集複寫使用 ndb_binlog_index 資料表來儲存二進位記錄檔的索引資料。由於此資料表是每個 MySQL 伺服器的本機資料表，且未參與叢集，因此使用 InnoDB 儲存引擎。這表示必須在參與來源叢集的每個 mysqld 上分別建立此資料表。(二進位記錄檔本身包含來自叢集中所有 MySQL 伺服器的更新。) 此資料表的定義如下

CREATE TABLE `ndb_binlog_index` (
    `Position` BIGINT(20) UNSIGNED NOT NULL,
    `File` VARCHAR(255) NOT NULL,
    `epoch` BIGINT(20) UNSIGNED NOT NULL,
    `inserts` INT(10) UNSIGNED NOT NULL,
    `updates` INT(10) UNSIGNED NOT NULL,
    `deletes` INT(10) UNSIGNED NOT NULL,
    `schemaops` INT(10) UNSIGNED NOT NULL,
    `orig_server_id` INT(10) UNSIGNED NOT NULL,
    `orig_epoch` BIGINT(20) UNSIGNED NOT NULL,
    `gci` INT(10) UNSIGNED NOT NULL,
    `next_position` bigint(20) unsigned NOT NULL,
    `next_file` varchar(255) NOT NULL,
    PRIMARY KEY (`epoch`,`orig_server_id`,`orig_epoch`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

ndb_binlog_index 表的大小取決於每個二進制日誌檔案的週期數和二進制日誌檔案的數量。每個二進制日誌檔案的週期數通常取決於每個週期產生的二進制日誌數量和二進制日誌檔案的大小，較小的週期會導致每個檔案有更多週期。您應該注意到，即使 --ndb-log-empty-epochs 選項為 OFF 時，空的週期也會產生對 ndb_binlog_index 表的插入操作，這表示每個檔案的條目數量取決於該檔案的使用時間長度；此關係可以用這裡顯示的公式表示

[number of epochs per file] = [time spent per file] / TimeBetweenEpochs

忙碌的 NDB Cluster 會定期寫入二進制日誌，並且可能比閒置的叢集更快輪換二進制日誌檔案。這表示啟用 --ndb-log-empty-epochs=ON 的「閒置」NDB Cluster 實際上可能比有大量活動的叢集擁有更高的每個檔案 ndb_binlog_index 行數。

當使用 --ndb-log-orig 選項啟動 mysqld 時，orig_server_id 和 orig_epoch 欄分別儲存事件發生的伺服器 ID 以及事件在原始伺服器上發生的週期，這在採用多個來源的 NDB Cluster 複寫設定中非常有用。用於在多來源設定中尋找最接近複本上已應用最高週期的二進制日誌位置的 SELECT 語句（請參閱 章節 25.7.10，「NDB Cluster 複寫：雙向和循環複寫」）使用這兩個未編入索引的欄位。這可能會在嘗試故障轉移時導致效能問題，因為查詢必須執行表掃描，尤其是在來源使用 --ndb-log-empty-epochs=ON 執行的情況下。您可以透過將索引新增至這些欄位來改善多來源故障轉移時間，如下所示

ALTER TABLE mysql.ndb_binlog_index
    ADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch);

從單一來源複寫到單一複本時，新增此索引沒有任何好處，因為在這種情況下，用於取得二進制日誌位置的查詢不會使用 orig_server_id 或 orig_epoch。

如需更多有關使用 next_position 和 next_file 欄位的資訊，請參閱 章節 25.7.8，「使用 NDB Cluster 複寫實作故障轉移」。

下圖顯示 NDB Cluster 複寫來源伺服器、其二進制日誌注入器執行緒和 mysql.ndb_binlog_index 表的關係。

圖 25.13 複寫來源叢集

ndb_replication 表用於控制二進制日誌和衝突解決，並針對每個表執行。此表中的每一列都對應於正在複寫的表，決定如何記錄對該表的變更，如果指定了衝突解決函數，則決定如何解決該表的衝突。

與 ndb_apply_status 和 ndb_replication 表不同，ndb_replication 表必須使用此處顯示的 SQL 語句手動建立

CREATE TABLE mysql.ndb_replication  (
    db VARBINARY(63),
    table_name VARBINARY(63),
    server_id INT UNSIGNED,
    binlog_type INT UNSIGNED,
    conflict_fn VARBINARY(128),
    PRIMARY KEY USING HASH (db, table_name, server_id)
)   ENGINE=NDB
PARTITION BY KEY(db,table_name);

此表的欄位會列在這裡，並附有說明

若要使用 NDB 複寫啟用衝突解決，必須在應該解決衝突的 SQL 節點上建立並填入此表，其中包含控制資訊。根據要採用的衝突解決類型和方法，這可能是來源、複本或兩者伺服器。在複本也可以在本地變更資料的簡單來源-複本設定中，這通常是複本。在更複雜的複寫方案（例如雙向複寫）中，這通常是所有相關來源。如需更多資訊，請參閱 章節 25.7.12，「NDB Cluster 複寫衝突解決」。

ndb_replication 表允許在衝突解決範圍之外針對二進制日誌進行表級控制，在這種情況下，conflict_fn 會指定為 NULL，而其餘欄位值則是用於控制指定表或符合萬用字元運算式的一組表的二進制日誌。透過為 binlog_type 欄位設定正確的值，您可以使指定表或數個表的記錄使用所需的二進制日誌格式，或完全停用二進制日誌。此欄位的可能值及其說明顯示在下表中

數個 binlog_type 值等同於 mysqld 記錄選項 --ndb-log-updated-only、--ndb-log-update-as-write 和 --ndb-log-update-minimal 的各種組合，如下表所示

透過將資料列插入 ndb_replication 資料表，並使用適當的 db、table_name 和 binlog_type 欄位值，可以針對不同的資料表設定不同的二進制日誌格式。設定二進制日誌格式時，應使用上表所示的內部整數值。以下兩個陳述式將資料表 test.a 的二進制日誌設定為記錄完整資料列（值為 3），並將資料表 test.b 的二進制日誌設定為僅記錄更新（值為 2）：

# Table test.a: Log full rows
INSERT INTO mysql.ndb_replication VALUES("test", "a", 0, 3, NULL);

# Table test.b: log updates only
INSERT INTO mysql.ndb_replication VALUES("test", "b", 0, 2, NULL);

若要停用一個或多個資料表的記錄，請使用 binlog_type 的值 1，如下所示：

# Disable binary logging for table test.t1
INSERT INTO mysql.ndb_replication VALUES("test", "t1", 0, 1, NULL);

# Disable binary logging for any table in 'test' whose name begins with 't'
INSERT INTO mysql.ndb_replication VALUES("test", "t%", 0, 1, NULL);

停用特定資料表的記錄等同於設定 sql_log_bin = 0，只是它會個別套用至一個或多個資料表。如果 SQL 節點沒有針對特定資料表執行二進制日誌記錄，則不會將這些資料表的資料列變更事件傳送給它。這表示它並非接收所有變更然後丟棄部分變更，而是未訂閱這些變更。

停用記錄在許多情況下都很有用，包括以下列出的原因：

使用萬用字元比對。為了避免需要在複寫設定中針對資料庫、資料表和 SQL 節點的每個組合都在 ndb_replication 資料表中插入資料列，NDB 支援在此資料表的 db、table_name 和 server_id 欄位上進行萬用字元比對。在 db 和 table_name 中使用的資料庫和資料表名稱可能包含以下一或多個萬用字元：

（這些是 MySQL LIKE 運算子支援的相同萬用字元。）

server_id 欄位支援使用 0 作為萬用字元，等同於 _（比對任何字元）。這已在先前顯示的範例中使用。

ndb_replication 資料表中的指定資料列可以使用萬用字元，比對資料庫名稱、資料表名稱和伺服器 ID 的任意組合。如果資料表中有多個潛在的比對，則會選擇最佳比對，如下表所示，其中 W 代表萬用字元比對，E 代表完全比對，Quality 欄位中的值越高，比對效果越好

因此，完全比對資料庫名稱、資料表名稱和伺服器 ID 會被視為最佳（最強），而最弱（最差）的比對是所有三個欄位都使用萬用字元比對。選擇要套用的規則時，僅考慮比對的強度；資料列在資料表中出現的順序對此判斷沒有影響。

記錄完整或部分資料列。 根據 mysqld 的 --ndb-log-updated-only 選項設定，記錄資料列有兩種基本方法：

通常，僅記錄已更新的欄位就足夠且更有效率；但是，如果您需要記錄完整資料列，可以將 --ndb-log-updated-only 設定為 0 或 OFF 來達成。

將變更的資料記錄為更新。 MySQL 伺服器的 --ndb-log-update-as-write 選項設定決定記錄是否在有或沒有「之前」影像的情況下執行。

由於更新和刪除作業的衝突解決是在 MySQL 伺服器的更新處理常式中完成，因此必須控制複寫來源執行的記錄，使更新是更新而不是寫入；也就是說，使更新被視為現有資料列的變更，而不是寫入新的資料列，即使這些資料列會取代現有的資料列。

預設會開啟此選項；換句話說，更新會被視為寫入。也就是說，預設會將更新以二進制日誌中的 write_row 事件寫入，而不是 update_row 事件。

若要停用此選項，請使用 --ndb-log-update-as-write=0 或 --ndb-log-update-as-write=OFF 啟動來源 mysqld。當從 NDB 資料表複寫到使用不同儲存引擎的資料表時，必須執行此操作；請參閱從 NDB 複寫到其他儲存引擎，以及從 NDB 複寫到非交易式儲存引擎，以取得更多資訊。