NDB 8.4 中的 NDB 複製支援使用通用的 MySQL 伺服器多執行緒套用程式機制 (MTA)，這允許在副本上平行套用獨立的二進位日誌交易，從而提高峰值複製輸送量。

需求

MySQL 伺服器 MTA 實作會將個別二進位日誌交易的處理委派給工作執行緒集區（其大小可設定），並協調工作執行緒以確保尊重二進位日誌中編碼的交易相依性，並在需要時維持提交順序（請參閱第 19.2.3 節「複製執行緒」）。若要將此功能與 NDB Cluster 搭配使用，必須將副本設定為使用多個工作執行緒。若要執行此動作，請設定 replica_parallel_workers 以控制副本上的工作執行緒數目。預設值為 4。

MTA 設定：來源

如果在來源 mysqld 上設定，replica_parallel_type 必須為 LOGICAL_CLOCK（預設值）。

此外，建議您將用於追蹤來源上二進位日誌交易寫入集的記憶體量 (binlog_transaction_dependency_history_size) 設定為 E * P，其中 E 是平均時間間隔大小（以每個時間間隔的作業數表示），而 P 是預期的最大平行度。請參閱寫入集追蹤記憶體使用量以取得更多資訊。

MTA 設定：副本

用於 NDB MTA 的副本 mysqld 設定要求 replica_parallel_workers 大於 1。首次啟用 MTA 時，建議的起始值為 4，這是預設值。

此外，replica_preserve_commit_order 必須為 ON。這也是預設值。

交易相依性和寫入集處理

交易相依性是透過分析每個交易的寫入集來偵測的，也就是交易寫入的一組列（表格、索引鍵值）。如果兩個交易修改相同的列，則會視為相依，且必須依序（換句話說，循序）套用，以避免死結或不正確的結果。如果表格具有次要唯一索引鍵，這些值也會新增至交易的寫入集，以偵測因不同交易影響相同唯一索引鍵值而產生的交易相依性案例，因此需要排序。在無法有效判斷相依性的情況下，mysqld 會為了安全考量，回復將交易視為相依。

交易相依性是由來源 mysqld 編碼在二進位日誌中。相依性是使用稱為「邏輯時鐘」的配置，在 ANONYMOUS_GTID 事件中編碼的。（請參閱第 19.1.4.1 節「複製模式概念」。）

MySQL (和 NDB Cluster) 使用的寫入集實作使用基於雜湊的衝突偵測，該衝突偵測基於比對相關表格和索引值的 64 位元列雜湊。這會可靠地偵測到何時看到相同的索引鍵兩次，但如果不同的表格和索引值雜湊到相同的 64 位元值，則也會產生誤判；這可能會導致人為相依性，進而減少可用的平行度。

下列任何一種情況都會強制執行交易相依性

MySQL MTA 實作會嘗試平行套用獨立的二進位日誌交易。NDB 會在一個二進位日誌交易中記錄在時間間隔 (TimeBetweenEpochs，預設值為 100 毫秒) 中提交的所有使用者交易中發生的所有變更，這稱為時間間隔交易。因此，若要讓兩個連續時間間隔交易獨立，且有可能平行套用，則必須在兩個時間間隔中皆未修改任何列。如果在兩個時間間隔中皆修改任何單列，則它們會相依，並會循序套用，這可能會限制可用的可利用平行度。

時間間隔交易會根據在來源叢集中於時間間隔內修改的一組列，但不包括傳達時間間隔中繼資料的產生的 mysql.ndb_apply_status WRITE_ROW 事件，視為獨立。這避免了每個時間間隔交易顯然地相依於先前時間間隔，但也確實要求以保留的提交順序在副本上套用 binlog。這也表示具有寫入集相依性的 NDB 二進位日誌不適合由使用不同 MySQL 儲存引擎的副本資料庫使用。

可能可以或希望修改應用程式交易行為，以避免在短時間內對相同列重複修改的模式，以增加可利用的套用平行度。

寫入集追蹤記憶體使用量

可以使用 binlog_transaction_dependency_history_size 伺服器系統變數來設定用於追蹤二進位日誌交易寫入集的記憶體量，其預設值為 25000 個列雜湊。

如果平均二進位日誌交易修改 N 個列，則為了能夠識別高達 P 的平行度層級的獨立 (可平行處理) 交易，我們需要 binlog_transaction_dependency_history_size 至少為 N * P。(最大值為 1000000。)

歷史記錄的有限大小導致可可靠判定的最大相依性長度有限，進而限制了可表達的平行處理能力。任何在歷史記錄中找不到的資料列，都可能依賴於從歷史記錄中清除的最後一筆交易。

寫入集歷史記錄的運作方式並非像最後 N 筆交易的滑動視窗；而是一個有限的緩衝區，允許完全填滿，然後在其滿載時完全捨棄其內容。這表示歷史記錄的大小會隨著時間呈現鋸齒狀模式，因此最大可偵測相依性長度也會隨著時間呈現鋸齒狀模式，使得獨立的交易如果其處理之間寫入集歷史記錄緩衝區已重置，仍可能被標記為相依。

在此方案中，二進制日誌檔案中的每筆交易都會使用 sequence_number (1, 2, 3, ...) 進行註解，並註解其所依賴的最近一筆二進制日誌交易的序號，我們稱之為 last_committed。

在給定的二進制日誌檔案中，第一筆交易的 sequence_number 為 1，而 last_committed 為 0。

如果二進制日誌交易依賴於其直接前一筆交易，則其應用會序列化。如果相依性是更早的交易，則有可能與先前的獨立交易平行應用該交易。

可以使用 mysqlbinlog 查看 ANONYMOUS_GTID 事件的內容，包括 sequence_number 和 last_committed（以及交易相依性）。

來源端產生的 ANONYMOUS_GTID 事件會與包含大量 BEGIN、 TABLE_MAP*、WRITE_ROW*、UPDATE_ROW*、DELETE_ROW* 和 COMMIT 事件的壓縮交易酬載分開處理，允許在解壓縮之前判斷相依性。這表示複本協調器執行緒可以將交易酬載解壓縮委派給工作執行緒，在複本上提供獨立交易的自動平行解壓縮。

已知限制

次要唯一資料行。 具有次要唯一資料行（即主要索引鍵以外的唯一索引鍵）的資料表，會將所有資料行傳送到來源端，以便偵測與唯一索引鍵相關的衝突。

如果目前的二進制記錄模式不包含所有資料行，而僅包含已變更的資料行（--ndb-log-updated-only=OFF、--ndb-log-update-minimal=ON、--ndb-log-update-as-write=OFF），則這可能會增加從資料節點傳送到 SQL 節點的資料量。

影響取決於此類資料表中資料列的修改（更新或刪除）速率，以及未實際修改的資料行中的資料量。

將 NDB 複寫到 InnoDB。 NDB 二進制日誌注入器交易相依性追蹤會刻意忽略由產生的 mysql.ndb_apply_status 中繼資料事件所建立的交易間相依性，這些事件會作為複本應用程式上週期性交易認可的一部分單獨處理。對於複寫到 InnoDB，沒有特殊的處理方式；當使用 InnoDB 多執行緒應用程式來取用 NDB MTA 二進制日誌時，可能會導致效能降低或其他問題。