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

需求

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

MTA組態：來源

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

此外，建議您將來源上用於追蹤二進位日誌交易寫入集的記憶體量 (binlog_transaction_dependency_history_size) 設定為 E * P，其中 E 是平均 epoch 大小（以每個 epoch 的操作數表示），而 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 叢集）所採用的寫入集實作使用基於雜湊的衝突偵測，其基於比對相關資料表和索引值的 64 位元列雜湊。這可以可靠地偵測到何時看到相同的索引鍵兩次，但如果不同的資料表和索引值雜湊成相同的 64 位元值，也可能會產生誤判；這可能會導致人為的相依性，進而降低可用的平行處理度。

下列任何情況都會強制產生交易相依性

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

Epoch 交易會根據來源叢集中在 epoch 中修改的列集，而被視為獨立，但不包括傳達 epoch 中繼資料的產生的 mysql.ndb_apply_status WRITE_ROW 事件。這會避免每個 epoch 交易都簡單地相依於前一個 epoch，但也要求在保留提交順序的情況下將 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 中繼資料事件所建立的交易間相依性，這些相依性會在副本應用程式上作為 epoch 交易提交的一部分單獨處理。對於複製到 InnoDB，沒有特殊處理；當使用 InnoDB 多執行緒應用程式來取用 NDB MTA 二進制日誌時，這可能會導致效能降低或其他問題。