NodeId

唯一的節點 ID 用作所有叢集內部訊息的節點位址。對於資料節點，這是一個介於 1 到 144 之間的整數（含首尾）。叢集中的每個節點都必須有唯一的識別碼。

NodeId 是識別資料節點時唯一支援的參數名稱。

ExecuteOnComputer

這指的是在 [computer] 區段中為其中一個電腦設定的 Id。

此節點的節點 ID 只能提供給明確要求它的連線。要求「任何」節點 ID 的管理伺服器無法使用這個。當在同一主機上執行多個管理伺服器時可以使用此參數，且 HostName 不足以區分不同程序時。適用於測試用途。

HostName

指定此參數會定義資料節點將駐留的電腦的主機名稱。使用 HostName 指定 localhost 以外的主機名稱。

ServerPort

叢集中的每個節點都使用一個連接埠來連接其他節點。預設情況下，此連接埠會動態配置，以確保同一主機電腦上的兩個節點不會收到相同的連接埠號碼，因此通常不需要為此參數指定值。

但是，如果您需要在防火牆中開啟特定連接埠以允許資料節點與 API 節點（包括 SQL 節點）之間進行通訊，您可以在 config.ini 檔案的 [ndbd] 區段中（或者，如果您需要對多個資料節點執行此操作）[ndbd default] 區段中將此參數設定為所需的連接埠號碼，然後開啟具有該號碼的連接埠，以接收來自 SQL 節點、API 節點或兩者的連線。

TcpBind_INADDR_ANY

將此參數設定為 TRUE 或 1 會繫結 IP_ADDR_ANY，以便可以從任何位置建立連線（針對自動產生的連線）。預設值為 FALSE (0)。

NodeGroup

此參數可用於將資料節點指派給特定的節點群組。當叢集第一次啟動時，它是唯讀的，並且不能用於線上將資料節點重新指派給不同的節點群組。通常不希望在 config.ini 檔案的 [ndbd default] 區段中使用此參數，並且必須小心不要以無效的節點數指派給任何節點群組的方式將節點指派給節點群組。

LocationDomainId

LocationDomainId 採用介於 0 到 16 (含) 之間的整數值，其中 0 為預設值；使用 0 與不設定參數相同。

NoOfReplicas

此全域參數只能在 [ndbd default] 區段中設定，並定義叢集中儲存的每個資料表的分片複本數。此參數也指定節點群組的大小。節點群組是一組全部儲存相同資訊的節點。

節點群組是隱式形成的。第一個節點群組由具有最低節點 ID 的一組資料節點組成，下一個節點群組由下一組最低節點 ID 組成，依此類推。舉例來說，假設我們有 4 個資料節點，且 NoOfReplicas 設定為 2。這四個資料節點的節點 ID 分別為 2、3、4 和 5。那麼第一個節點群組由節點 2 和 3 組成，第二個節點群組由節點 4 和 5 組成。以這種方式配置叢集非常重要，即同一個節點群組中的節點不應放置在同一部電腦上，因為單一硬體故障會導致整個叢集失敗。

如果未提供節點 ID，資料節點的順序將是決定節點群組的因素。無論是否進行明確的指派，都可以在管理用戶端的 SHOW 命令輸出中檢視它們。

NoOfReplicas 的預設值為 2。這是大多數生產環境建議的值。也支援將此參數的值設定為 3 或 4。

叢集中的資料節點數必須能被此參數的值整除。例如，如果有兩個資料節點，則 NoOfReplicas 必須等於 1 或 2，因為 2/3 和 2/4 都會產生小數值；如果有四個資料節點，則 NoOfReplicas 必須等於 1、2 或 4。

DataDir

此參數指定放置追蹤檔、日誌檔、pid 檔和錯誤日誌的目錄。

預設值為資料節點處理程序的工作目錄。

FileSystemPath

此參數指定放置為中繼資料、REDO 日誌、UNDO 日誌 (用於磁碟資料表) 和資料檔建立的所有檔案的目錄。預設值為 DataDir 指定的目錄。

NDB Cluster 的建議目錄階層包含 /var/lib/mysql-cluster，在此目錄下建立節點檔案系統的目錄。此子目錄的名稱包含節點 ID。例如，如果節點 ID 為 2，則此子目錄命名為 ndb_2_fs。

BackupDataDir

此參數指定放置備份的目錄。

DataMemory

此參數定義可用於儲存資料庫記錄的空間量 (以位元組為單位)。此值指定的整個量會在記憶體中配置，因此機器有足夠的實體記憶體來容納它非常重要。

對於可變大小的資料表屬性，資料儲存在從 DataMemory 配置的個別資料頁面上。可變長度記錄使用固定大小的部分，並額外使用 4 個位元組來參照可變大小的部分。可變大小的部分有 2 個位元組的額外負擔，每個屬性額外使用 2 個位元組。

最大記錄大小為 30000 個位元組。

指定給 DataMemory 的資源用於儲存所有資料和索引。(配置為 IndexMemory 的任何記憶體都會自動新增至 DataMemory 使用的記憶體，以形成一個通用資源集區。)

配置頁面後，目前無法將其返回可用頁面集區，除非刪除資料表。(這也表示 DataMemory 頁面，一旦配置給指定的資料表，就不能由其他資料表使用。)執行資料節點復原也會壓縮分割區，因為所有記錄都會從其他活動節點插入到空的分割區中。

DataMemory 的預設值為 98MB。最小值為 1MB。沒有最大大小，但實際上，最大大小必須調整，以便在達到限制時，處理程序不會開始進行交換。此限制取決於機器上可用的實體 RAM 量，以及作業系統可以配置給任何一個處理程序的記憶體量。32 位元作業系統通常限制為每個處理程序 2-4GB；64 位元作業系統可以使用更多。對於大型資料庫，因此最好使用 64 位元作業系統。

IndexMemory

IndexMemory 參數已棄用（並可能在未來移除）；任何分配給 IndexMemory 的記憶體，現在會改為分配到與 DataMemory 相同的資源池。DataMemory 負責儲存資料和索引在記憶體中的所有資源。在 NDB 9.0 中，於叢集組態檔中使用 IndexMemory 會觸發管理伺服器的警告。

您可以使用以下公式來估計雜湊索引的大小：

  size  = ( (fragments * 32K) + (rows * 18) )
          * fragment_replicas

fragments 是分片的數量，fragment_replicas 是分片副本的數量（通常為 2），而 rows 是列的數量。如果一個表格有一百萬列、八個分片和兩個分片副本，則預期的索引記憶體使用量計算如下：

  ((8 * 32K) + (1000000 * 18)) * 2 = ((8 * 32768) + (1000000 * 18)) * 2
  = (262144 + 18000000) * 2
  = 18262144 * 2 = 36524288 bytes = ~35MB

排序索引的索引統計資料（啟用時）會儲存在 mysql.ndb_index_stat_sample 表格中。由於此表格具有雜湊索引，因此會增加索引記憶體的使用量。給定排序索引的列數上限可以計算如下：

  sample_size= key_size + ((key_attributes + 1) * 4)

  sample_rows = IndexStatSaveSize
                * ((0.01 * IndexStatSaveScale * log2(rows * sample_size)) + 1)
                / sample_size

在前面的公式中，key_size 是排序索引鍵的大小（以位元組為單位），key_attributes 是排序索引鍵中的屬性數量，而 rows 是基底表格中的列數。

假設表格 t1 有 100 萬列，並且在兩個四位元組整數上有名為 ix1 的排序索引。此外，假設 IndexStatSaveSize 和 IndexStatSaveScale 設定為其預設值（分別為 32K 和 100）。使用先前的 2 個公式，我們可以計算如下：

  sample_size = 8  + ((1 + 2) * 4) = 20 bytes

  sample_rows = 32K
                * ((0.01 * 100 * log2(1000000*20)) + 1)
                / 20
                = 32768 * ( (1 * ~16.811) +1) / 20
                = 32768 * ~17.811 / 20
                = ~29182 rows

因此，預期的索引記憶體使用量為 2 * 18 * 29182 = ~1050550 位元組。

此參數的最小值和預設值為 0（零）。

StringMemory

此參數決定為字串（例如表格名稱）分配多少記憶體，並且在 config.ini 檔案的 [ndbd] 或 [ndbd default] 區段中指定。介於 0 和 100（含）之間的值會被解讀為最大預設值的百分比，此預設值是根據多種因素計算得出，包括表格數量、最大表格名稱大小、 .FRM 檔案的最大大小、MaxNoOfTriggers、最大欄名稱大小以及最大預設欄值。

大於 100 的值會被解讀為位元組數。

預設值為 25，也就是預設最大值的 25%。

在大多數情況下，預設值應該足夠，但是當您有大量的 NDB 表格（1000 個或更多）時，可能會出現錯誤 773 字串記憶體不足，請修改 StringMemory 組態參數：永久錯誤：結構描述錯誤，在這種情況下，您應該增加此值。25（25%）並不過分，並且應該可以防止此錯誤在極端條件下再次發生。

MaxNoOfConcurrentTransactions

每個叢集資料節點都需要每個叢集中每個作用中交易的交易記錄。協調交易的任務會在所有資料節點之間分配。叢集中的交易記錄總數是任何給定節點中的交易數量乘以叢集中的節點數量。

交易記錄會分配給個別的 MySQL 伺服器。每個與 MySQL 伺服器的連線都需要至少一個交易記錄，以及每個由該連線存取的表格一個額外的交易物件。這表示叢集中交易總數的合理最小值可以表示為：

TotalNoOfConcurrentTransactions =
    (maximum number of tables accessed in any single transaction + 1)
    * number of SQL nodes

假設有 10 個使用叢集的 SQL 節點。一個涉及 10 個表格的單一聯結需要 11 個交易記錄；如果在一個交易中有 10 個這樣的聯結，則每個 MySQL 伺服器需要 10 * 11 = 110 個交易記錄，或者總共需要 110 * 10 = 1100 個交易記錄。可以預期每個資料節點處理 TotalNoOfConcurrentTransactions / 資料節點的數量。對於具有 4 個資料節點的 NDB 叢集，這表示在每個資料節點上將 MaxNoOfConcurrentTransactions 設定為 1100 / 4 = 275。此外，您應該透過確保單一節點群組可以容納所有平行交易來提供故障復原；換句話說，每個資料節點的 MaxNoOfConcurrentTransactions 足以涵蓋等於 TotalNoOfConcurrentTransactions / 節點群組數量的交易數量。如果此叢集具有單一節點群組，則應將 MaxNoOfConcurrentTransactions 設定為 1100（與整個叢集的平行交易總數相同）。

此外，每個交易至少涉及一個作業；因此，為 MaxNoOfConcurrentTransactions 設定的值應始終不大於 MaxNoOfConcurrentOperations 的值。

對於所有叢集資料節點，必須將此參數設定為相同的值。這是因為當資料節點失敗時，最舊的倖存節點會重新建立失敗節點中正在進行的所有交易的交易狀態。

可以使用滾動重新啟動來變更此值，但是叢集上的流量必須使得在進行此操作時，發生的交易數不超過舊層級和新層級中的較低者。

預設值為 4096。

MaxNoOfConcurrentOperations

根據交易的大小和數量調整此參數的值是個好主意。當執行僅涉及少量操作和記錄的交易時，此參數的預設值通常就足夠了。執行涉及大量記錄的大型交易通常需要您增加其值。

每個更新叢集資料的交易都會保留記錄，無論是在交易協調器中還是在執行實際更新的節點中。這些記錄包含尋找回滾 UNDO 記錄、鎖定佇列和其他用途所需的狀態資訊。

此參數的最小值應設定為交易中同時更新的記錄數除以叢集資料節點數。例如，在一個有四個資料節點的叢集中，預計使用交易處理一百萬個並行更新，您應該將此值設定為 1000000 / 4 = 250000。為了幫助提供針對故障的恢復能力，建議您將此參數設定為一個足夠高的值，以便允許單個資料節點處理其節點組的負載。換句話說，您應該將該值設定為等於 並行操作總數 / 節點組數量。（在只有一個節點組的情況下，這與整個叢集的並行操作總數相同。）

由於每個交易都至少涉及一個操作，MaxNoOfConcurrentOperations 的值應始終大於或等於 MaxNoOfConcurrentTransactions 的值。

設定鎖定的讀取查詢也會導致建立操作記錄。在個別節點內會分配一些額外的空間，以適應節點分佈不均的情況。

當查詢使用唯一雜湊索引時，每個交易中的記錄實際上會使用兩個操作記錄。第一個記錄代表索引表中的讀取，第二個記錄處理基表上的操作。

預設值為 32768。

此參數實際上處理兩個可以單獨配置的值。第一個指定要將多少操作記錄放置在交易協調器中。第二部分指定多少操作記錄應在本機資料庫中。

在一個八節點叢集上執行的大型交易需要在交易協調器中具有與交易中涉及的讀取、更新和刪除一樣多的操作記錄。但是，這些操作記錄分佈在所有八個節點上。因此，如果有必要為一個非常大的交易配置系統，最好單獨配置這兩部分。 MaxNoOfConcurrentOperations 始終用於計算節點交易協調器部分中的操作記錄數量。

了解操作記錄的記憶體需求也很重要。每個記錄消耗大約 1KB 的空間。

MaxNoOfLocalOperations

預設情況下，此參數的計算公式為 1.1 × MaxNoOfConcurrentOperations。這適用於許多同時交易的系統，但沒有一個交易非常大。如果需要一次處理一個非常大的交易，並且有很多節點，最好透過明確指定此參數來覆蓋預設值。

此參數已棄用，並會在未來的 NDB 叢集版本中移除。此外，此參數與 TransactionMemory 參數不相容；如果您嘗試在叢集組態檔 (config.ini) 中為這兩個參數設定值，管理伺服器將拒絕啟動。

MaxDMLOperationsPerTransaction

此參數限制交易的大小。如果交易需要的操作數量超過此數量，則會中止交易。

此參數的值不能超過為 MaxNoOfConcurrentOperations 設定的值。

MaxNoOfConcurrentIndexOperations

對於使用唯一雜湊索引的查詢，在查詢的執行階段會使用另一組臨時操作記錄。此參數設定該記錄池的大小。因此，只有在執行查詢的一部分時才會分配此記錄。一旦執行完這部分，就會釋放該記錄。處理中止和提交所需的狀態由正常操作記錄處理，其中池大小由參數 MaxNoOfConcurrentOperations 設定。

此參數的預設值為 8192。只有在使用唯一雜湊索引的極高並行性的罕見情況下，才需要增加此值。如果 DBA 確定叢集不需要高度的並行性，則可以使用較小的值並節省記憶體。

此參數已棄用，並會在未來的 NDB 叢集版本中移除。此外，此參數與 TransactionMemory 參數不相容；如果您嘗試在叢集組態檔 (config.ini) 中為這兩個參數設定值，管理伺服器將拒絕啟動。

MaxNoOfFiredTriggers

MaxNoOfFiredTriggers 的預設值為 4000，足以應付大多數情況。在某些情況下，如果 DBA 認為叢集中不需要高並行性，甚至可以降低此值。

當執行影響唯一雜湊索引的操作時，會建立記錄。在具有唯一雜湊索引的表中插入或刪除記錄，或更新屬於唯一雜湊索引一部分的列，會在索引表中觸發插入或刪除。產生的記錄用於表示此索引表操作，同時等待觸發該操作的原始操作完成。此操作是短期的，但在基表上包含一組唯一雜湊索引的許多並行寫入操作的情況下，仍然可能需要其池中存在大量記錄。

此參數已棄用，並會在未來的 NDB 叢集版本中移除。此外，此參數與 TransactionMemory 參數不相容；如果您嘗試在叢集組態檔 (config.ini) 中為這兩個參數設定值，管理伺服器將拒絕啟動。

TransactionBufferMemory

此參數影響的記憶體用於追蹤更新索引表和讀取唯一索引時觸發的操作。此記憶體用於儲存這些操作的索引鍵和欄位資訊。只有極少數情況下才需要將此參數的值從預設值更改。

TransactionBufferMemory 的預設值為 1MB。

正常的讀取和寫入操作使用類似的緩衝區，其使用時間更短。編譯時參數 ZATTRBUF_FILESIZE (位於 ndb/src/kernel/blocks/Dbtc/Dbtc.hpp 中) 設定為 4000 × 128 個位元組 (500KB)。類似的索引鍵資訊緩衝區 ZDATABUF_FILESIZE (也在 Dbtc.hpp 中) 包含 4000 × 16 = 62.5KB 的緩衝區空間。Dbtc 是處理交易協調的模組。

ReservedConcurrentIndexOperations

在一個資料節點上具有專用資源的同時索引操作的數量。

ReservedConcurrentOperations

在一個資料節點上的交易協調器中具有專用資源的同時操作的數量。

ReservedConcurrentScans

在一個資料節點上，具有專用資源的同時掃描數量。

ReservedConcurrentTransactions

在一個資料節點上，具有專用資源的同時交易數量。

ReservedFiredTriggers

在一個 ndbd (DB) 節點上，具有專用資源的觸發器數量。

ReservedLocalScans

在一個資料節點上，具有專用資源的同時片段掃描數量。

ReservedTransactionBufferMemory

分配給每個資料節點的金鑰和屬性資料的動態緩衝區空間（以位元組為單位）。

TransactionMemory

此參數決定在每個資料節點上為交易分配的記憶體（以位元組為單位）。交易記憶體的設定方式如下：

與 TransactionMemory 不相容的參數。以下參數不能與 TransactionMemory 同時使用，因此已棄用：

如果在叢集組態檔案 (config.ini) 中也設定了 TransactionMemory，則明確設定剛列出的任何參數會導致管理節點無法啟動。

有關 NDB 叢集資料節點中資源分配的更多資訊，請參閱 章節 25.4.3.13，“資料節點記憶體管理”。

BatchSizePerLocalScan

此參數用於計算用於處理同時掃描操作的鎖定記錄數。

已棄用。

BatchSizePerLocalScan 與 SQL 節點中定義的 BatchSize 密切相關。

LongMessageBuffer

這是一個內部緩衝區，用於在個別節點內和節點之間傳遞訊息。預設值為 64MB。

此參數很少需要從預設值進行變更。

MaxFKBuildBatchSize

用於建置外鍵的最大掃描批次大小。增加此參數設定的值可能會加速外鍵建置，但會對進行中的流量產生更大的影響。

MaxNoOfConcurrentScans

此參數用於控制可在叢集中執行的平行掃描數量。每個交易協調器可以處理為此參數定義的平行掃描數量。每個掃描查詢都是透過平行掃描所有分割區來執行的。每個分割區掃描都會在使用分割區所在的節點中使用掃描記錄，記錄的數量是此參數的值乘以節點數。叢集應能夠同時從叢集中的所有節點支援 MaxNoOfConcurrentScans 次掃描。

實際上會在兩種情況下執行掃描。第一種情況發生在沒有雜湊或排序索引來處理查詢時，在這種情況下，會透過執行完整表格掃描來執行查詢。第二種情況是在沒有雜湊索引來支援查詢但有排序索引時遇到。使用排序索引表示執行平行範圍掃描。順序僅保留在本地分割區上，因此必須在所有分割區上執行索引掃描。

MaxNoOfConcurrentScans 的預設值為 256。最大值為 500。

MaxNoOfLocalScans

如果許多掃描未完全平行化，則指定本機掃描記錄的數量。當未提供本機掃描記錄的數量時，將按此處顯示的方式計算

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

此參數已棄用，並會在未來的 NDB 叢集版本中移除。此外，此參數與 TransactionMemory 參數不相容；如果您嘗試在叢集組態檔 (config.ini) 中為這兩個參數設定值，管理伺服器將拒絕啟動。

MaxParallelCopyInstances

當剛啟動的節點與已擁有最新資料的節點同步時，此參數設定節點重新啟動或系統重新啟動的複製階段中使用的平行化，方法是從最新節點複製任何已變更的記錄。由於在這種情況下完全平行化可能會導致超載情況，因此 MaxParallelCopyInstances 提供了一種減少平行化的方法。此參數的預設值為 0。此值表示有效平行化等於剛啟動的節點中以及更新節點中的 LDM 執行個體數量。

MaxParallelScansPerFragment

可以設定允許平行掃描的最大數量（TUP 掃描和 TUX 掃描），然後它們才開始排隊以進行串列處理。您可以增加此值，以利用在平行執行大量掃描時的任何未使用的 CPU 並提高其效能。

MaxReorgBuildBatchSize

用於重新組織表格分割區的最大掃描批次大小。增加此參數設定的值可能會加速重新組織，但會對進行中的流量產生更大的影響。

MaxUIBuildBatchSize

用於建置唯一金鑰的最大掃描批次大小。增加此參數設定的值可能會加速此類建置，但會對進行中的流量產生更大的影響。

FragmentLogFileSize

設定此參數可讓您直接控制重做記錄檔的大小。當 NDB 叢集在高負載下執行且無法在嘗試開啟新的記錄檔之前足夠快地關閉片段記錄檔時，這會很有用（一次只能開啟 2 個片段記錄檔）；增加片段記錄檔的大小可讓叢集有更多時間才需要開啟每個新的片段記錄檔。此參數的預設值為 16M。

有關片段記錄檔的更多資訊，請參閱 NoOfFragmentLogFiles 的描述。

InitialNoOfOpenFiles

此參數設定為開啟檔案配置的內部執行緒的初始數量。

預設值為 27。

InitFragmentLogFiles

預設情況下，當資料節點執行初始啟動時，會以稀疏方式建立片段日誌檔 — 也就是說，根據使用的作業系統和檔案系統，不一定會將所有位元組都寫入磁碟。但是，可以使用此參數覆寫此行為，並強制寫入所有位元組，無論使用的平台和檔案系統類型為何。InitFragmentLogFiles 可以採用以下兩個值之一

根據您的作業系統和檔案系統，設定 InitFragmentLogFiles=FULL 可能有助於消除重做日誌寫入時的 I/O 錯誤。

EnablePartialLcp

當 true 時，啟用部分本機檢查點：這表示每個 LCP 只會記錄完整資料庫的一部分，加上自上次 LCP 以來任何包含已變更列的記錄；如果沒有任何列變更，則 LCP 只會更新 LCP 控制檔，而不會更新任何資料檔。

如果停用 EnablePartialLcp (false)，則每個 LCP 都只使用單一檔案並寫入完整檢查點；這需要最少的 LCP 磁碟空間，但會增加每個 LCP 的寫入負載。預設值為啟用 (true)。部分 LCP 使用的空間比例可透過 RecoveryWork 組態參數的設定修改。

如需有關完整和部分 LCP 使用的檔案和目錄的詳細資訊，請參閱 NDB 叢集資料節點檔案系統目錄。

將此參數設定為 false 也會停用調適型 LCP 控制機制使用的磁碟寫入速度計算。

LcpScanProgressTimeout

本機檢查點片段掃描監控程式會定期檢查在執行本機檢查點時執行的每個片段掃描中是否有任何進度，如果經過給定的時間後沒有任何進度，則會關閉節點。可以使用 LcpScanProgressTimeout 資料節點組態參數設定此間隔，此參數會設定本機檢查點可以停滯的最長時間，之後 LCP 片段掃描監控程式會關閉節點。

預設值為 60 秒（與先前的版本提供相容性）。將此參數設定為 0 會完全停用 LCP 片段掃描監控程式。

MaxNoOfOpenFiles

此參數設定要為開啟檔案配置的內部執行緒數上限。 任何需要變更此參數的情況都應回報為錯誤。

預設值為 0。但是，此參數可以設定的最小值為 20。

MaxNoOfSavedMessages

此參數設定錯誤日誌中寫入的最大錯誤數，以及在覆寫現有追蹤檔案之前保留的最大追蹤檔案數。追蹤檔案會在節點因任何原因當機時產生。

預設值為 25，這會將這些最大值設定為 25 個錯誤訊息和 25 個追蹤檔案。

MaxLCPStartDelay

在平行資料節點復原中，實際上只會平行複製和同步表格資料；字典和檢查點資訊等中繼資料的同步會以序列方式完成。此外，字典和檢查點資訊的復原無法與執行本機檢查點平行執行。這表示，當同時啟動或重新啟動許多資料節點時，資料節點可能會被迫等待執行本機檢查點，這可能會導致更長的節點復原時間。

可以強制延遲本機檢查點，以允許更多（可能全部）資料節點完成中繼資料同步；一旦每個資料節點的中繼資料同步完成，所有資料節點就可以平行復原表格資料，即使在執行本機檢查點時也是如此。若要強制執行此延遲，請設定 MaxLCPStartDelay，其決定叢集在資料節點繼續同步中繼資料時，可以等待開始本機檢查點的秒數。此參數應在 [ndbd default] config.ini 檔案的區段中設定，以便所有資料節點都相同。最大值為 600；預設值為 0。

NoOfFragmentLogFiles

此參數設定節點的 REDO 日誌檔數，因此也設定配置給 REDO 日誌的空間量。由於 REDO 日誌檔是以環狀方式組織，因此集合中的第一個和最後一個日誌檔（有時分別稱為「head」和「tail」日誌檔）不會碰在一起，這一點非常重要。當這些日誌檔太靠近時，由於沒有空間容納新的日誌記錄，節點會開始中止所有包含更新的交易。

只有在自插入該日誌記錄以來，完成兩個必要的本機檢查點後，才會移除 REDO 日誌記錄。檢查點頻率由本章其他地方討論的一組組態參數決定。

預設參數值為 16，依預設，這表示 16 組 4 個 16MB 檔案，總共 1024MB。可以使用 FragmentLogFileSize 參數設定個別日誌檔的大小。在需要大量更新的情況下，NoOfFragmentLogFiles 的值可能需要設定為高達 300 或甚至更高，才能為 REDO 日誌提供足夠的空間。

如果檢查點速度較慢，且資料庫的寫入次數過多，導致日誌檔已滿，且在不危及復原的情況下無法削減日誌尾端，則所有更新交易都會因內部錯誤碼 410 (Out of log file space temporarily) 而中止。此狀況會持續存在，直到檢查點完成且日誌尾端可以向前移動為止。

RecoveryWork

LCP 檔案的儲存額外負荷百分比。此參數只有在 EnablePartialLcp 為 true 時才生效，也就是說，只有在啟用部分本機檢查點時才會生效。較高的值表示

RecoveryWork 的較低值表示

例如，將 RecoveryWork 設定為 60 表示 LCP 的總大小約為要檢查點資料大小的 1 + 0.6 = 1.6 倍。這表示，與使用完整檢查點的重新啟動期間完成的工作相比，重新啟動的還原階段需要多執行 60% 的工作。（在重新啟動的其他階段中，這會得到更多補償，因此在使用部分 LCP 時，整體而言重新啟動仍然比使用完整 LCP 時更快。）為了不填滿重做日誌，必須以檢查點期間資料變更速率的 1 + (1 / RecoveryWork) 倍的速率寫入 — 因此，當 RecoveryWork = 60 時，必須以大約 1 + (1 / 0.6 ) = 2.67 倍的變更速率寫入。換句話說，如果以每秒 10 MB 的速度寫入變更，則檢查點需要以大約每秒 26.7 MB 的速度寫入。

設定 RecoveryWork = 40 表示只需要 1.4 倍的 LCP 總大小（因此還原階段所需的時間減少 10% 到 15%）。在這種情況下，檢查點寫入速率是變更速率的 3.5 倍。

NDB 原始碼發行版本包含一個模擬 LCP 的測試程式。可以在 storage/ndb/src/kernel/blocks/backup/ 中找到 lcp_simulator.cc。若要在 Unix 平台上編譯和執行它，請執行這裡顯示的命令

$> gcc lcp_simulator.cc
$> ./a.out

此程式除了 stdio.h 之外沒有任何相依性，而且不需要連線到 NDB 叢集或 MySQL 伺服器。依預設，它會模擬 300 個 LCP（三組 100 個 LCP，每個 LCP 依序由插入、更新和刪除組成），並回報每個 LCP 之後的大小。您可以透過變更原始碼中的 recovery_work、insert_work 和 delete_work 的值，然後重新編譯來變更模擬。如需更多資訊，請參閱程式的原始碼。

InsertRecoveryWork

用於插入列的 RecoveryWork 百分比。較高的值會增加本機檢查點期間的寫入次數，並減少 LCP 的總大小。較低的值會減少 LCP 期間的寫入次數，但會導致 LCP 使用更多空間，這意味著復原需要更長的時間。此參數僅在 EnablePartialLcp 為 true 時生效，也就是說，僅在啟用部分本機檢查點時才生效。

EnableRedoControl

啟用用於控制重做日誌使用量的自適應檢查點速度。

啟用時（預設值），EnableRedoControl 允許資料節點在將 LCP 寫入磁碟的速度方面具有更大的彈性。更具體來說，啟用此參數意味著可以使用更高的寫入速率，以便 LCP 可以更快完成並修剪重做日誌，從而減少復原時間和磁碟空間需求。此功能允許資料節點更好地利用現代固態儲存裝置和協定（例如使用非揮發性記憶體快遞（NVMe）的固態硬碟（SSD））提供的較高 I/O 速率和更大的頻寬。

當 NDB 部署在 I/O 或頻寬相對於使用固態技術的系統（例如使用傳統硬碟（HDD）的系統）受限的系統上時，EnableRedoControl 機制很容易導致 I/O 子系統飽和，從而增加資料節點輸入和輸出的等待時間。特別是，這可能會導致 NDB 磁碟資料表出現問題，這些資料表的表空間或日誌檔案群組與資料節點 LCP 和重做日誌檔案共用受限的 I/O 子系統；此類問題可能包括由於 GCP 停止錯誤導致的節點或叢集失敗。將 EnableRedoControl 設定為 false 以在此類情況下停用它。將 EnablePartialLcp 設定為 false 也會停用自適應計算。

MaxNoOfAttributes

此參數設定叢集中可以定義的建議最大屬性數；與 MaxNoOfTables 類似，它不打算作為硬上限。

（在較舊的 NDB 叢集版本中，此參數有時被視為某些操作的硬性限制。當建立的表多於可以複寫的表時，這會導致 NDB 叢集複寫出現問題，並且有時當可以建立多於 MaxNoOfAttributes 個屬性時（或在某些情況下不可能時）會導致混淆。）

預設值為 1000，最小值為 32。最大值為 4294967039。由於所有中繼資料都完全複寫在伺服器上，因此每個屬性每個節點會消耗約 200 位元組的儲存空間。

設定 MaxNoOfAttributes 時，務必事先為您將來可能執行的任何 ALTER TABLE 陳述式做好準備。這是因為在叢集表上執行 ALTER TABLE 期間，會使用原始表中屬性數的 3 倍，因此一個好的做法是允許此數量的兩倍。例如，如果具有最多屬性的 NDB 叢集表（greatest_number_of_attributes）具有 100 個屬性，則 MaxNoOfAttributes 值的良好起點為 6 * greatest_number_of_attributes = 600。

您還應該估計每個表的平均屬性數，並將其乘以 MaxNoOfTables。如果此值大於前一段中獲得的值，則應改用較大的值。

假設您可以順利建立所有想要的表，您還應該在設定參數後嘗試實際的 ALTER TABLE 來驗證此數字是否足夠。如果沒有成功，請將 MaxNoOfAttributes 增加另一個 MaxNoOfTables 的倍數並再次測試。

MaxNoOfTables

每個表和叢集中每個唯一的雜湊索引都會配置一個表物件。此參數設定整個叢集建議的最大表物件數；與 MaxNoOfAttributes 類似，它不打算作為硬上限。

（在較舊的 NDB 叢集版本中，此參數有時被視為某些操作的硬性限制。當建立的表多於可以複寫的表時，這會導致 NDB 叢集複寫出現問題，並且有時當可以建立多於 MaxNoOfTables 個表時（或在某些情況下不可能時）會導致混淆。）

對於具有 BLOB 資料類型的每個屬性，都會使用一個額外的表來儲存大部分 BLOB 資料。在定義表總數時，也必須考慮這些表。

此參數的預設值為 128。最小值為 8，最大值為 20320。每個表物件每個節點約消耗 20KB。

MaxNoOfOrderedIndexes

對於叢集中的每個排序索引，都會配置一個物件來描述正在索引的內容及其儲存區段。依預設，每個這樣定義的索引也會定義一個排序索引。每個唯一索引和主索引鍵都同時具有排序索引和雜湊索引。MaxNoOfOrderedIndexes 設定系統中任何時候可以使用的排序索引總數。

此參數的預設值為 128。每個索引物件每個節點約消耗 10KB 的資料。

MaxNoOfUniqueHashIndexes

對於每個不是主索引鍵的唯一索引，都會配置一個特殊表，將唯一索引鍵對應到被索引表的主索引鍵。依預設，也會為每個唯一索引定義一個排序索引。若要防止這種情況，您必須在定義唯一索引時指定 USING HASH 選項。

預設值為 64。每個索引每個節點約消耗 15KB。

MaxNoOfTriggers

每個唯一的雜湊索引都會配置內部更新、插入和刪除觸發器。（這表示為每個唯一的雜湊索引建立三個觸發器。）但是，排序索引只需要單個觸發器物件。備份也會為叢集中的每個普通表使用三個觸發器物件。

叢集之間的複寫也會使用內部觸發器。

此參數設定叢集中的最大觸發器物件數。

預設值為 768。

MaxNoOfSubscriptions

NDB 叢集中的每個 NDB 表格都需要 NDB 核心中的訂閱。對於某些 NDB API 應用程式，可能需要或希望變更此參數。但是，對於使用充當 SQL 節點的 MySQL 伺服器的正常使用情況，沒有任何需要這樣做的情況。

MaxNoOfSubscriptions 的預設值為 0，這被視為等於 MaxNoOfTables。每個訂閱會消耗 108 位元組。

MaxNoOfSubscribers

此參數僅在使用 NDB 叢集複寫時才相關。預設值為 0。它被視為 2 * MaxNoOfTables + 2 * [API 節點數]。每個 NDB 表格都有一個訂閱，用於兩個 MySQL 伺服器（一個充當複寫來源，另一個充當複本）。每個訂閱者使用 16 位元組的記憶體。

當使用循環複製、多來源複製，以及其他涉及超過 2 個 MySQL 伺服器的複製設定時，您應該將此參數增加到複製中包含的 mysqld 程序數量（這通常但不總是與叢集的數量相同）。例如，如果您有一個使用三個 NDB 叢集的循環複製設定，每個叢集都附加一個 mysqld，並且這些 mysqld 程序中的每一個都充當來源和複本，您應該將 MaxNoOfSubscribers 設定為等於 3 * MaxNoOfTables。

更多資訊，請參閱 第 25.7 節，「NDB 叢集複製」。

MaxNoOfConcurrentSubOperations

此參數設定叢集中所有 API 節點一次可以執行的操作數量上限。預設值 (256) 對於正常操作來說已經足夠，只有在有大量 API 節點同時執行大量操作時才需要調整。

CompressedLCP

將此參數設定為 1 會導致本機檢查點檔案被壓縮。使用的壓縮相當於 gzip --fast，並且可以節省資料節點上儲存未壓縮檢查點檔案所需空間的 50% 或更多。可以為個別資料節點或所有資料節點啟用壓縮的 LCP（透過在 config.ini 檔案的 [ndbd default] 區段中設定此參數）。

預設值為 0（已停用）。

CrashOnCorruptedTuple

當啟用此參數（預設值）時，每當資料節點遇到損壞的元組時，它會強制關閉。

Diskless

可以將 NDB 叢集表指定為無磁碟，這表示表不會檢查點到磁碟，並且不會發生任何記錄。此類表僅存在於主記憶體中。使用無磁碟表的後果是，這些表或表中的記錄都無法在崩潰後倖存。但是，當在無磁碟模式下運作時，可以在無磁碟電腦上執行 ndbd。

當啟用此功能時，NDB 叢集線上備份將被停用。此外，無法部分啟動叢集。

Diskless 預設為停用。

EncryptedFileSystem

加密 LCP 和表空間檔案，包括還原記錄和重做記錄。預設為停用 (0)；設定為 1 以啟用。

更多資訊，請參閱 第 25.6.14 節，「NDB 叢集的檔案系統加密」。

LateAlloc

在與管理伺服器建立連線後，為此資料節點配置記憶體。預設為啟用。

LockPagesInMainMemory

對於許多作業系統，包括 Solaris 和 Linux，可以將一個程序鎖定在記憶體中，從而避免任何與磁碟的交換。這可以用來幫助保證叢集的即時特性。

此參數採用整數值 0、1 或 2 中的一個，其作用如下清單所示

如果作業系統未配置為允許非特權使用者鎖定頁面，則使用此參數的資料節點程序可能必須以系統根使用者身分執行。（LockPagesInMainMemory 使用 mlockall 函式。從 Linux 核心 2.6.9 開始，非特權使用者可以鎖定記憶體，其限制由 max locked memory 決定。有關更多資訊，請參閱 ulimit -l 和 http://linux.die.net/man/2/mlock）。

ODirect

啟用此參數會導致 NDB 嘗試對 LCP、備份和重做記錄使用 O_DIRECT 寫入，這通常會降低 kswapd 和 CPU 使用率。當在 Linux 上使用 NDB 叢集時，如果您使用的是 2.6 或更新版本的核心，請啟用 ODirect。

ODirect 預設為停用。

ODirectSyncFlag

當啟用此參數時，會執行重做記錄寫入，使得每個完成的檔案系統寫入都被視為對 fsync 的呼叫。如果以下至少一個條件為 true，則會忽略此參數的設定

預設為停用。

RequireCertificate

如果此參數設定為 true，則資料節點會在 TLS 搜尋路徑中尋找金鑰和有效且最新的憑證，如果找不到它們，則無法啟動。

RequireTls

如果此參數設定為 true，則必須使用 TLS 對此資料節點的連線進行驗證。

RestartOnErrorInsert

此功能僅在建置偵錯版本時才可存取，在該版本中，可以作為測試的一部分在個別程式碼區塊的執行中插入錯誤。

預設情況下，此功能為停用狀態。

StopOnError

此參數指定當遇到錯誤條件時，資料節點程序應結束還是執行自動重新啟動。

此參數的預設值為 1；這表示，預設情況下，錯誤會導致資料節點程序停止。

當遇到錯誤且 StopOnError 為 0 時，資料節點程序會重新啟動。

MySQL Cluster Manager 的使用者應注意，當 StopOnError 等於 1 時，這會阻止 MySQL Cluster Manager 代理程式在執行自身的重新啟動和恢復後，重新啟動任何資料節點。請參閱在 Linux 上啟動和停止代理程式以取得更多資訊。

UseShm

啟用此資料節點和也在此主機上執行的 API 節點之間的共享記憶體連線。設定為 1 以啟用。

TimeBetweenWatchDogCheck

為了防止主執行緒在某個時間點陷入無限迴圈，「監看程式」執行緒會檢查主執行緒。此參數指定檢查之間的毫秒數。如果程序在三次檢查後仍保持相同狀態，監看程式執行緒會終止它。

可以輕鬆變更此參數以進行實驗或適應當地情況。它可以針對每個節點指定，儘管似乎沒有理由這樣做。

預設逾時時間為 6000 毫秒（6 秒）。

TimeBetweenWatchDogCheckInitial

這與 TimeBetweenWatchDogCheck 參數類似，但 TimeBetweenWatchDogCheckInitial 控制在記憶體配置期間，儲存節點在早期啟動階段內執行檢查之間經過的時間量。

預設逾時時間為 6000 毫秒（6 秒）。

StartPartialTimeout

此參數指定叢集在呼叫叢集初始化常式之前，等待所有資料節點啟動的時間長度。此逾時用於盡可能避免部分叢集啟動。

當執行叢集的初始啟動或初始重新啟動時，此參數會被覆寫。

預設值為 30000 毫秒（30 秒）。0 會停用逾時，在這種情況下，叢集只有在所有節點都可用時才能啟動。

StartPartitionedTimeout

如果叢集在等待 StartPartialTimeout 毫秒後已準備好啟動，但仍可能處於分割狀態，則叢集會等待直到此逾時也經過。如果 StartPartitionedTimeout 設定為 0，則叢集會無限期等待 (2³²−1 毫秒，或大約 49.71 天)。

當執行叢集的初始啟動或初始重新啟動時，此參數會被覆寫。

StartFailureTimeout

如果資料節點未在此參數指定的時間內完成其啟動順序，則節點啟動會失敗。將此參數設定為 0（預設值）表示不會套用資料節點逾時。

對於非零值，此參數以毫秒為單位測量。對於包含極大量資料的資料節點，應增加此參數。例如，在包含數 GB 資料的資料節點的情況下，可能需要長達 10-15 分鐘（即 600000 到 1000000 毫秒）的時間來執行節點重新啟動。

StartNoNodeGroupTimeout

當資料節點設定為 Nodegroup = 65536 時，會被視為未分配到任何節點群組。完成後，叢集會等待 StartNoNodegroupTimeout 毫秒，然後將這些節點視為已新增到傳遞給 --nowait-nodes 選項的清單中，並啟動。預設值為 15000（也就是管理伺服器等待 15 秒）。將此參數設定為 0 表示叢集會無限期等待。

StartNoNodegroupTimeout 對於叢集中的所有資料節點必須相同；因此，您應始終在 config.ini 檔案的 [ndbd default] 區段中設定它，而不是針對個別資料節點設定。

請參閱第 25.6.7 節，「線上新增 NDB 叢集資料節點」以取得更多資訊。

HeartbeatIntervalDbDb

發現失敗節點的主要方法之一是使用心跳訊號。此參數表示發送心跳訊號的頻率以及預期接收它們的頻率。心跳訊號無法停用。

連續錯過四個心跳間隔後，該節點會被宣告為已失效。因此，透過心跳機制發現失敗的最長時間是心跳間隔的五倍。

預設心跳間隔為 5000 毫秒（5 秒）。此參數不得大幅變更，且不應在節點之間差異過大。如果一個節點使用 5000 毫秒，而監看它的節點使用 1000 毫秒，顯然該節點會很快被宣告為失效。此參數可以在線上軟體升級期間變更，但只能以小增量變更。

另請參閱網路通訊和延遲，以及 ConnectCheckIntervalDelay 組態參數的說明。

HeartbeatIntervalDbApi

每個資料節點都會向每個 MySQL 伺服器（SQL 節點）發送心跳訊號，以確保其保持連線。如果 MySQL 伺服器未及時發送心跳訊號，則會宣告其「失效」，在這種情況下，所有正在進行的交易都會完成，並且會釋放所有資源。在先前 MySQL 執行個體啟動的所有活動完成之前，SQL 節點無法重新連線。此判定的三心跳標準與針對 HeartbeatIntervalDbDb 描述的相同。

預設間隔為 1500 毫秒（1.5 秒）。此間隔可以在個別資料節點之間變更，因為每個資料節點都會獨立於所有其他資料節點監看連線到它的 MySQL 伺服器。

如需更多資訊，請參閱網路通訊和延遲。

HeartbeatOrder

資料節點以循環方式互相發送心跳訊號，每個資料節點都會監看前一個節點。如果給定的資料節點未偵測到心跳訊號，則此節點會宣告循環中的前一個資料節點「失效」（也就是說，叢集無法再存取）。資料節點失效的判斷是全域性的；換句話說，一旦宣告資料節點失效，叢集中的所有節點都會將其視為失效。

與其他節點對之間的心跳訊號相比，不同主機上的資料節點之間的心跳訊號可能會太慢（例如，由於心跳間隔非常短或暫時連線問題），以至於即使節點仍然可以作為叢集的一部分運作，也會宣告資料節點失效。

在這種情況下，資料節點之間傳輸心跳訊號的順序可能會影響是否宣告特定資料節點失效。如果發生不必要的宣告，這可能會導致不必要地遺失節點群組，進而導致叢集失敗。

考慮一個在 2 個主機電腦 host1 和 host2 上執行 4 個資料節點 A、B、C 和 D 的設定，這些資料節點組成 2 個節點群組，如下表所示

假設心跳訊號以 A->B->C->D->A 的順序傳輸。在這種情況下，主機之間遺失的心跳訊號會導致節點 B 宣告節點 A 失效，節點 C 宣告節點 B 失效。這會導致節點群組 0 遺失，因此叢集會失敗。另一方面，如果傳輸順序為 A->B->D->C->A（且所有其他條件保持與先前所述相同），則遺失的心跳訊號會導致節點 A 和 D 被宣告為失效；在這種情況下，每個節點群組都有一個倖存的節點，並且叢集可以存活。

HeartbeatOrder 組態參數使心跳訊號傳輸的順序可由使用者設定。 HeartbeatOrder 的預設值為零；允許在所有資料節點上使用預設值會導致心跳訊號傳輸的順序由 NDB 決定。如果使用此參數，則必須將叢集中每個資料節點都設定為非零值（最大值為 65535），並且每個資料節點的值必須是唯一的；這會導致心跳訊號按照其 HeartbeatOrder 值從最低到最高的順序（然後直接從具有最高 HeartbeatOrder 的資料節點到具有最低值的資料節點，以完成循環）從一個資料節點到另一個資料節點進行傳輸。這些值不必連續。例如，若要在先前概述的情境中強制執行心跳訊號傳輸順序 A->B->D->C->A，您可以設定 HeartbeatOrder 值，如下所示

若要使用此參數變更執行中 NDB Cluster 的心跳傳輸順序，您必須先在全域組態 (config.ini) 檔案 (或多個檔案) 中，為叢集中每個資料節點設定 HeartbeatOrder。若要使變更生效，您必須執行下列其中一項操作

您可以使用 DUMP 908 來觀察資料節點日誌中此參數的效果。

ConnectCheckIntervalDelay

此參數啟用資料節點之間的連線檢查，如果其中一個節點在最多 HeartbeatIntervalDbDb 毫秒的 5 個間隔內未通過心跳檢查。

如果此資料節點在 ConnectCheckIntervalDelay 毫秒的間隔內仍無法回應，則會被視為可疑，並在兩個這樣的間隔後被視為死亡。這在已知有延遲問題的設定中可能很有用。

此參數的預設值為 0 (停用)。

TimeBetweenLocalCheckpoints

此參數是個例外，它並非指定在開始新的本機檢查點之前要等待的時間；而是用來確保在更新相對較少的叢集中不會執行本機檢查點。在大多數具有高更新率的叢集中，很可能會在前一個本機檢查點完成後立即啟動新的本機檢查點。

會加上自前一個本機檢查點開始以來執行的所有寫入操作的大小。此參數也是例外，因為它指定為 4 位元組字組數量的以 2 為底的對數，因此預設值 20 表示 4MB (4 × 2²⁰) 的寫入操作，21 表示 8MB，依此類推，直到最大值 31，相當於 8GB 的寫入操作。

會將叢集中所有寫入操作加總。將 TimeBetweenLocalCheckpoints 設定為 6 或更少，表示本機檢查點會連續執行，不會暫停，與叢集的工作負載無關。

TimeBetweenGlobalCheckpoints

當交易提交時，會在鏡像資料的所有節點上的主記憶體中提交。但是，交易日誌記錄不會作為提交的一部分刷新到磁碟。這種行為背後的理由是，在至少兩個獨立主機上安全地提交交易應符合合理的持久性標準。

確保即使是最壞的情況（叢集完全崩潰）也能正確處理也很重要。為了保證發生這種情況，在給定間隔內發生的所有交易都會放入全域檢查點中，這可以被認為是一組已提交的交易，這些交易已刷新到磁碟。換句話說，作為提交過程的一部分，交易會被放置在全域檢查點群組中。稍後，此群組的日誌記錄會被刷新到磁碟，然後整個交易群組會安全地提交到叢集中所有電腦上的磁碟。

我們建議當您使用固態硬碟（尤其是使用 NVMe 的硬碟）搭配 Disk Data 資料表時，減少此值。在這種情況下，您還應該確保將 MaxDiskDataLatency 設定為適當的等級。

此參數定義全域檢查點之間的間隔。預設值為 2000 毫秒。

TimeBetweenGlobalCheckpointsTimeout

此參數定義全域檢查點之間的最小逾時。預設值為 120000 毫秒。

TimeBetweenEpochs

此參數定義 NDB Cluster 複寫的同步處理週期之間的間隔。預設值為 100 毫秒。

TimeBetweenEpochs 是 「微型 GCP」 實作的一部分，可用於改善 NDB Cluster 複寫的效能。

TimeBetweenEpochsTimeout

此參數定義 NDB Cluster 複寫的同步處理週期的逾時。如果節點在由此參數決定的時間內未能參與全域檢查點，則會關閉該節點。預設值為 0；換句話說，逾時已停用。

TimeBetweenEpochsTimeout 是 「微型 GCP」 實作的一部分，可用於改善 NDB Cluster 複寫的效能。

當 GCP 儲存時間超過 1 分鐘或 GCP 提交時間超過 10 秒時，此參數的目前值和警告會寫入叢集日誌。

將此參數設定為零的效果是停用因儲存逾時、提交逾時或兩者而導致的 GCP 停止。此參數的最大可能值為 256000 毫秒。

MaxBufferedEpochs

訂閱節點可以延遲的未處理週期數量。超過此數量會導致延遲的訂閱者斷線。

預設值 100 足夠用於大多數正常操作。如果訂閱節點的延遲足以導致斷線，通常是由於程序或執行緒的網路或排程問題所致。（在極少數情況下，問題可能是由於 NDB 用戶端中的錯誤所致。）當週期較長時，可能需要將值設定為低於預設值。

斷線可防止用戶端問題影響資料節點服務、耗盡記憶體來緩衝資料，並最終關閉。相反地，斷線只會影響用戶端（例如，二進位日誌中的間隙事件），迫使用戶端重新連線或重新啟動程序。

MaxBufferedEpochBytes

此節點為緩衝週期所配置的位元組總數。

TimeBetweenInactiveTransactionAbortCheck

逾時處理是藉由在每個交易的計時器上，以由此參數指定的每個間隔檢查一次來執行的。因此，如果此參數設定為 1000 毫秒，則每個交易會每秒檢查一次逾時。

預設值為 1000 毫秒 (1 秒)。

TransactionInactiveTimeout

此參數指出在交易中的操作之間允許經過的最長時間，超過此時間，交易就會中止。

此參數的預設值為 4G（也是最大值）。對於需要確保沒有交易會長時間保持鎖定的即時資料庫，此參數應設定為相對較小的值。將其設定為 0 表示應用程式永遠不會逾時。單位為毫秒。

TransactionDeadlockDetectionTimeout

當節點執行涉及交易的查詢時，節點會等待叢集中的其他節點回應，然後再繼續。此參數設定交易可以在資料節點中執行的時間量，也就是交易協調器等待參與交易的每個資料節點執行要求的時間。

無法回應的原因可能為下列任一項

此逾時參數指出交易協調器等待另一個節點執行查詢的時間長度，之後才會中止交易，這對於節點失敗處理和死結偵測都很重要。

預設逾時值為 1200 毫秒 (1.2 秒)。

此參數的最小值為 50 毫秒。

DiskSyncSize

這是將資料刷新到本機檢查點檔案之前要儲存的最大位元組數。這樣做是為了防止寫入緩衝，這可能會嚴重阻礙效能。此參數不打算取代 TimeBetweenLocalCheckpoints。

預設值為 4M (4 MB)。

MaxDiskWriteSpeed

設定在此 NDB Cluster 中未發生重新啟動（由此資料節點或任何其他資料節點）時，本機檢查點和備份操作每秒寫入磁碟的最大速率（以位元組為單位）。

若要設定此資料節點重新啟動時允許的磁碟寫入最大速率，請使用 MaxDiskWriteSpeedOwnRestart。若要設定在其他資料節點重新啟動時允許的磁碟寫入最大速率，請使用 MaxDiskWriteSpeedOtherNodeRestart。所有 LCP 和備份操作磁碟寫入的最小速度可以透過設定 MinDiskWriteSpeed 來調整。

MaxDiskWriteSpeedOtherNodeRestart

設定當此 NDB Cluster 中的一個或多個資料節點重新啟動時（不包括此節點），本機檢查點和備份操作每秒寫入磁碟的最大速率（以位元組為單位）。

若要設定此資料節點重新啟動時允許的最大磁碟寫入速率，請使用 MaxDiskWriteSpeedOwnRestart。若要設定叢集中任何資料節點皆未重新啟動時允許的最大磁碟寫入速率，請使用 MaxDiskWriteSpeed。所有 LCP 和備份操作的最小磁碟寫入速度可透過設定 MinDiskWriteSpeed 來調整。

MaxDiskWriteSpeedOwnRestart

設定此資料節點重新啟動時，本機檢查點和備份操作寫入磁碟的最大速率，單位為每秒位元組。

若要設定其他資料節點重新啟動時允許的最大磁碟寫入速率，請使用 MaxDiskWriteSpeedOtherNodeRestart。若要設定叢集中任何資料節點皆未重新啟動時允許的最大磁碟寫入速率，請使用 MaxDiskWriteSpeed。所有 LCP 和備份操作的最小磁碟寫入速度可透過設定 MinDiskWriteSpeed 來調整。

MinDiskWriteSpeed

設定本機檢查點和備份操作寫入磁碟的最小速率，單位為每秒位元組。

在各種情況下，LCP 和備份允許的最大磁碟寫入速率可使用參數 MaxDiskWriteSpeed、MaxDiskWriteSpeedOwnRestart 和 MaxDiskWriteSpeedOtherNodeRestart 進行調整。如需更多資訊，請參閱這些參數的描述。

ArbitrationTimeout

此參數指定資料節點等待仲裁器對仲裁訊息回應的時間長度。如果超過此時間，則假設網路已分割。

預設值為 7500 毫秒 (7.5 秒)。

Arbitration

Arbitration 參數可選擇仲裁方案，對應此參數的 3 個可能值之一。

RestartSubscriberConnectTimeout

此參數決定資料節點等待訂閱 API 節點連線的時間。一旦此逾時時間到期，任何「遺失」的 API 節點都會與叢集斷開連線。若要停用此逾時時間，請將 RestartSubscriberConnectTimeout 設定為 0。

雖然此參數以毫秒為單位指定，但逾時時間本身會解析為下一個最接近的整秒。

KeepAliveSendInterval

您可以透過設定此參數來啟用並控制在資料節點之間傳送的保持連線訊號之間的間隔。 KeepAliveSendInterval 的預設值為 60000 毫秒 (一分鐘)；將其設定為 0 會停用保持連線訊號。介於 1 到 10 (含) 之間的值會被視為 10。

在監視並斷開閒置 TCP 連線的環境中，此參數可能很有用，在叢集閒置時可能會造成不必要的資料節點故障。

UndoIndexBuffer

此參數先前設定還原索引緩衝區的大小，但在目前版本的 NDB Cluster 中沒有任何作用。

在叢集設定檔中使用此參數會引發棄用警告；您應該預期它會在未來的 NDB Cluster 版本中移除。

UndoDataBuffer

此參數先前設定還原資料緩衝區的大小，但在目前版本的 NDB Cluster 中沒有任何作用。

在叢集設定檔中使用此參數會引發棄用警告；您應該預期它會在未來的 NDB Cluster 版本中移除。

RedoBuffer

所有更新活動也都需要記錄。REDO 記錄可讓您在系統重新啟動時重播這些更新。NDB 復原演算法會使用資料的「模糊」檢查點，以及 UNDO 記錄，然後套用 REDO 記錄來重播直到還原點的所有變更。

RedoBuffer 設定寫入 REDO 記錄的緩衝區大小。預設值為 32MB；最小值為 1MB。

如果此緩衝區太小，則 NDB 儲存引擎會發出錯誤碼 1221 (REDO 記錄緩衝區過載)。因此，如果您嘗試在叢集組態的線上變更中減少 RedoBuffer 的值，您應該小心處理。

ndbmtd 會為每個 LDM 執行緒配置個別的緩衝區 (請參閱 ThreadConfig)。例如，使用 4 個 LDM 執行緒時，ndbmtd 資料節點實際上具有 4 個緩衝區，並為每個緩衝區配置 RedoBuffer 個位元組，總共為 4 * RedoBuffer 個位元組。

EventLogBufferSize

控制資料節點內用於 NDB 記錄事件的循環緩衝區大小。

LogLevelStartup

在程序啟動期間產生的事件的報告層級。

預設層級為 1。

LogLevelShutdown

在節點正常關閉時產生的事件的報告層級。

預設層級為 0。

LogLevelStatistic

統計事件的報告層級，例如主要索引鍵讀取次數、更新次數、插入次數、與緩衝區使用相關的資訊等等。

預設層級為 0。

LogLevelCheckpoint

本機和全域檢查點產生的事件的報告層級。

預設層級為 0。

LogLevelNodeRestart

在節點重新啟動期間產生的事件的報告層級。

預設層級為 0。

LogLevelConnection

叢集節點之間連線產生的事件的報告層級。

預設層級為 0。

LogLevelError

此參數設定叢集整體產生的錯誤和警告事件的回報層級。這些錯誤不會導致任何節點故障，但仍認為值得回報。

預設層級為 0。

LogLevelCongestion

此參數設定因壅塞而產生的事件回報層級。這些錯誤不會導致節點故障，但仍認為值得回報。

預設層級為 0。

LogLevelInfo

此參數設定關於叢集一般狀態的資訊事件的回報層級。

預設層級為 0。

MemReportFrequency

此參數控制資料節點記憶體用量報告記錄在叢集日誌中的頻率；它是一個整數值，表示報告之間的秒數。

每個資料節點的資料記憶體和索引記憶體使用量都會以百分比和 DataMemory 的 32 KB 頁面數記錄，如 config.ini 檔案中所設定。例如，如果 DataMemory 等於 100 MB，且給定資料節點使用 50 MB 作為資料記憶體儲存，則叢集日誌中的對應行可能如下所示

2006-12-24 01:18:16 [MgmSrvr] INFO -- Node 2: Data usage is 50%(1280 32K pages of total 2560)

MemReportFrequency 不是必要參數。如果使用，則可在 config.ini 的 [ndbd default] 區段中為所有叢集資料節點設定，也可以在組態檔案的對應 [ndbd] 區段中為個別資料節點設定或覆寫。最小值（也是預設值）為 0，在這種情況下，只有當記憶體使用量達到特定百分比（80%、90% 和 100%）時，才會記錄記憶體報告，如 第 25.6.3.2 節「NDB 叢集日誌事件」中統計事件的討論所述。

StartupStatusReportFrequency

當使用 --initial 啟動資料節點時，它會在啟動階段 4（請參閱第 25.6.4 節「NDB 叢集啟動階段摘要」）期間初始化 redo 記錄檔。當為 NoOfFragmentLogFiles、FragmentLogFileSize 或兩者設定非常大的值時，此初始化可能需要很長時間。您可以透過 StartupStatusReportFrequency 組態參數，強制定期記錄此程序的進度報告。在這種情況下，進度會在叢集日誌中報告，包括已初始化的檔案數量和空間量，如下所示

2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 1: Local redo log file initialization status:
#Total files: 80, Completed: 60
#Total MBytes: 20480, Completed: 15557
2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 2: Local redo log file initialization status:
#Total files: 80, Completed: 60
#Total MBytes: 20480, Completed: 15570

這些報告會在啟動階段 4 期間每 StartupStatusReportFrequency 秒記錄一次。如果 StartupStatusReportFrequency 為 0（預設值），則只有在 redo 記錄檔初始化程序的開始和完成時，才會將報告寫入叢集日誌。

DictTrace

可以使用 DictTrace，來記錄透過建立和刪除表格產生的事件追蹤。此參數僅在偵錯 NDB 核心程式碼時有用。DictTrace 採用整數值。0 是預設值，表示不執行任何記錄；1 啟用追蹤記錄，2 啟用額外 DBDICT 偵錯輸出。

WatchdogImmediateKill

您可以透過啟用 WatchdogImmediateKill 資料節點組態參數，使執行緒在發生看門狗問題時立即終止。此參數應僅在偵錯或疑難排解時使用，以取得報告執行停止瞬間所發生情況的追蹤檔。

BackupDataBufferSize

在建立備份時，有兩個緩衝區用於將資料傳送至磁碟。備份資料緩衝區用於填入掃描節點表格所記錄的資料。一旦此緩衝區填滿至指定為 BackupWriteSize 的層級，頁面就會傳送至磁碟。在將資料刷新至磁碟時，備份程序可以繼續填滿此緩衝區，直到用完空間。當發生這種情況時，備份程序會暫停掃描，並等待某些磁碟寫入完成以釋放記憶體，以便繼續掃描。

此參數的預設值為 16MB。最小值為 512K。

BackupDiskWriteSpeedPct

BackupDiskWriteSpeedPct 僅在備份為單執行緒時適用；由於 NDB 9.0 支援多執行緒備份，因此通常不需要調整此參數，在多執行緒情況下此參數無效。以下討論專門針對單執行緒備份。

在正常操作期間，資料節點會嘗試最大化用於本機檢查點和備份的磁碟寫入速度，同時保持在 MinDiskWriteSpeed 和 MaxDiskWriteSpeed 設定的範圍內。磁碟寫入節流會為每個 LDM 執行緒提供總預算的相等份額。這允許並行的 LCP 在不超過磁碟 I/O 預算的情況下發生。由於備份僅由一個 LDM 執行緒執行，這有效地導致預算削減，從而導致備份完成時間更長，並且 - 如果變更率足夠高 - 當備份記錄緩衝區填滿率高於可實現的寫入率時，備份無法完成。

這個問題可以透過使用 BackupDiskWriteSpeedPct 組態參數來解決，該參數的值範圍為 0-90（含），它被解讀為節點最大寫入速率預算的百分比，該預算在將剩餘預算分配給 LDM 執行緒以用於 LCP 之前保留。執行備份的 LDM 執行緒會收到備份的整個寫入速率預算，以及其（減少的）本機檢查點寫入速率預算的份額。

此參數的預設值為 50（解讀為 50%）。

BackupLogBufferSize

備份記錄緩衝區的作用類似於備份資料緩衝區，不同之處在於它用於產生備份執行期間所做所有表格寫入的記錄。寫入這些頁面的原則與備份資料緩衝區相同，不同之處在於當備份記錄緩衝區沒有更多空間時，備份會失敗。因此，備份記錄緩衝區的大小必須足夠大，以處理備份期間寫入活動所造成的負載。請參閱第 25.6.8.3 節「NDB 叢集備份組態」。

此參數的預設值應足以應付大多數應用程式。事實上，備份失敗更有可能是因磁碟寫入速度不足所致，而不是備份記錄緩衝區已滿。如果未針對應用程式造成的寫入負載組態磁碟子系統，則叢集不太可能執行所需的操作。

最好以處理器成為瓶頸，而不是磁碟或網路連線的方式組態叢集節點。

此參數的預設值為 16MB。

BackupMemory

此參數已過時，可能會在未來版本的 NDB 叢集中移除。為此參數做的任何設定都會被忽略。

BackupReportFrequency

此參數控制在備份期間，管理用戶端發出備份狀態報告的頻率，以及將此類報告寫入叢集日誌的頻率（前提是叢集事件記錄組態允許，請參閱記錄和檢查點）。BackupReportFrequency 表示備份狀態報告之間的秒數。

預設值為 0。

BackupWriteSize

此參數指定備份記錄和備份資料緩衝區寫入磁碟的訊息預設大小。

此參數的預設值為 256KB。

BackupMaxWriteSize

此參數指定備份記錄和備份資料緩衝區寫入磁碟的訊息最大大小。

此參數的預設值為 1MB。

CompressedBackup

啟用此參數會壓縮備份檔案。使用的壓縮相當於 gzip --fast，而且可以節省資料節點上儲存未壓縮備份檔案所需空間的 50% 或更多。可以為個別資料節點啟用壓縮備份，或者為所有資料節點啟用壓縮備份（透過在 config.ini 檔案的 [ndbd default] 區段中設定此參數）。

預設值為 0（已停用）。

RequireEncryptedBackup

如果設定為 1，則備份必須加密。雖然可以為每個資料節點個別設定此參數，但建議您在 config.ini 全域組態檔案的 [ndbd default] 區段中設定。如需執行加密備份的詳細資訊，請參閱第 25.6.8.2 節「使用 NDB 叢集管理用戶端建立備份」。

BackupDataBufferSize >= BackupWriteSize + 188KB

BackupLogBufferSize >= BackupWriteSize + 16KB

BackupMaxWriteSize >= BackupWriteSize

BuildIndexThreads

此參數決定在系統或節點啟動期間重建排序索引時，以及執行 ndb_restore --rebuild-indexes 時，要建立的執行緒數量。僅當每個資料節點的表格有多個片段時才支援此參數（例如，當 COMMENT="NDB_TABLE=PARTITION_BALANCE=FOR_RA_BY_LDM_X_2" 與 CREATE TABLE 一起使用時）。

將此參數設定為 0（預設值）會停用多執行緒建立排序索引。

使用 ndbd 或 ndbmtd 時，支援此參數。

您可以將 TwoPassInitialNodeRestartCopy 資料節點組態參數設定為 TRUE，以在資料節點初始重新啟動期間啟用多執行緒建立。

LockExecuteThreadToCPU

與 ndbd 一起使用時，此參數（現在是字串）指定指派給處理 NDBCLUSTER 執行緒的 CPU ID。與 ndbmtd 一起使用時，此參數的值是以逗號分隔的 CPU ID 清單，這些 CPU ID 指派給處理執行緒。清單中的每個 CPU ID 都應該是介於 0 到 65535（含）之間的整數。

指定的 ID 數量應符合由 MaxNoOfExecutionThreads 決定的執行緒數量。但是，當使用此參數時，無法保證執行緒會以任何給定的順序指派給 CPU。您可以使用 ThreadConfig 來獲得更精細的控制。

LockExecuteThreadToCPU 沒有預設值。

LockMaintThreadsToCPU

此參數指定指派給處理 NDBCLUSTER 維護執行緒的 CPU ID。

此參數的值是介於 0 到 65535（含）之間的整數。沒有預設值。

Numa

此參數決定非統一記憶體存取 (NUMA) 是由作業系統還是資料節點程序控制，無論資料節點是使用 ndbd 還是 ndbmtd。依預設，NDB 會嘗試在主機作業系統提供 NUMA 支援的任何資料節點上使用交錯的 NUMA 記憶體配置原則。

設定 Numa = 0 表示資料節點程序本身不嘗試設定記憶體配置原則，並允許此行為由作業系統決定，作業系統可以進一步由單獨的 numactl 工具引導。也就是說，Numa = 0 會產生系統預設行為，該行為可以透過 numactl 自訂。對於許多 Linux 系統，系統預設行為是在配置時將套接字本地記憶體配置給任何給定的程序。當使用 ndbmtd 時，這可能會產生問題；這是因為 nbdmtd 會在啟動時配置所有記憶體，導致不平衡，進而為不同的套接字提供不同的存取速度，尤其是在鎖定主記憶體中的頁面時。

設定 Numa = 1 表示資料節點程序使用 libnuma 來要求交錯的記憶體配置。（這也可以在作業系統層級上使用 numactl 手動完成。）實際上，使用交錯配置會告知資料節點程序忽略非統一記憶體存取，但不嘗試利用快速本地記憶體；相反地，資料節點程序會嘗試避免因慢速遠端記憶體而造成的不平衡。如果不需要交錯配置，請將 Numa 設定為 0，以便在作業系統層級上決定所需的行為。

只有在可使用 libnuma.so 的 Linux 系統上，才支援 Numa 組態參數。

RealtimeScheduler

將此參數設定為 1 會啟用資料節點執行緒的即時排程。

預設值為 0（停用排程）。

SchedulerExecutionTimer

此參數指定在將執行緒傳送出去之前，執行緒在排程器中執行的時間（以微秒為單位）。將其設定為 0 會盡量縮短回應時間；若要達到更高的輸送量，您可以增加該值，但代價是較長的回應時間。

預設值為 50 微秒，我們的測試顯示，這可以在高負載情況下稍微增加輸送量，而不會嚴重延遲要求。

SchedulerResponsiveness

設定 NDB 排程器中速度與輸送量之間的平衡。此參數採用一個整數，其值介於 0 到 10（含）之間，預設值為 5。較高的值相對於輸送量提供更好的回應時間。較低的值會增加輸送量，但代價是較長的回應時間。

SchedulerSpinTimer

此參數指定在執行緒休眠之前，執行緒在排程器中執行的時間（以微秒為單位）。

SpinMethod

此參數提供一個簡單的介面來控制資料節點上的適應性旋轉，四個可能的值為旋轉參數值提供預設值，如下列清單所示

由 SpinMethod 修改的旋轉參數如下列清單所述

在缺乏可用旋轉指令的平台上，例如 PowerPC 和某些 SPARC 平台，在所有情況下旋轉時間都設定為 0，並且會忽略 SpinMethod 的 StaticSpinning 以外的值。

TwoPassInitialNodeRestartCopy

透過將此組態參數設定為 true (預設值)，可以啟用多執行緒建置排序索引，以供資料節點初始重新啟動時使用。這會啟用在節點初始重新啟動期間進行的雙步驟資料複製。

您還必須將 BuildIndexThreads 設定為非零值。

AutomaticThreadConfig

設定為 1 時，會啟用自動執行緒組態，該組態會採用資料節點可用的 CPU 數量，並考量 taskset、numactl、虛擬機器、Docker 和其他控制哪些 CPU 可供特定應用程式使用的方式所設定的任何限制 (在 Windows 平台上，自動執行緒組態會使用所有在線的 CPU)；或者，您可以將 NumCPUs 設定為所需的 CPU 數量 (最多 1024 個，這是自動執行緒組態可處理的最大 CPU 數量)。任何 ThreadConfig 和 MaxNoOfExecutionThreads 設定都會被忽略。此外，啟用此參數會自動停用 ClassicFragmentation。

ClassicFragmentation

啟用時 (設定為 true)，NDB 會在 LDM 之間分配分段，使得每個節點的預設分割區數量等於每個資料節點的本機資料管理員 (LDM) 執行緒的最小數量。

對於新的叢集，在首次設定叢集時，最好將 ClassicFragmentation 設定為 false；這樣做會導致每個節點的分割區數量等於 PartitionsPerNode 的值，確保所有分割區均勻分散在所有 LDM 之間。

此參數和 AutomaticThreadConfig 互斥；啟用 AutomaticThreadConfig 會自動停用 ClassicFragmentation。

EnableMultithreadedBackup

啟用多執行緒備份。如果每個資料節點至少有 2 個 LDM，則所有 LDM 執行緒都會參與備份，該備份是使用每個 LDM 執行緒一個子目錄建立的，並且每個子目錄都包含 .ctl、.Data 和 .log 備份檔案。

對於 ndbmtd，此參數通常已啟用 (設定為 1)。若要強制使用單執行緒備份，以便使用舊版本的 ndb_restore 輕鬆還原，請將此參數設定為 0 來停用多執行緒備份。必須針對叢集中的每個資料節點執行此動作。

如需更多資訊，請參閱第 25.6.8.5 節「使用平行資料節點進行 NDB 備份」以及從平行備份還原。

MaxNoOfExecutionThreads

此參數直接控制 ndbmtd 使用的執行緒數量，最多為 72 個。雖然此參數是在 config.ini 檔案的 [ndbd] 或 [ndbd default] 區段中設定，但它是 ndbmtd 獨有的，不適用於 ndbd。

啟用 AutomaticThreadConfig 會導致此參數的任何設定遭到忽略。

設定 MaxNoOfExecutionThreads 會為每種類型設定執行緒數量，具體取決於檔案 storage/ndb/src/common/mt_thr_config.cpp 中的矩陣。下表顯示 MaxNoOfExecutionThreads 的可能值所對應的這些執行緒數量。

一律有一個 SUMA (複製) 執行緒。

NoOfFragmentLogParts 應設定為等於 ndbmtd 使用的 LDM 執行緒數量，如本參數的設定所決定。此比例不應大於 4:1；特別不允許這種情況下的組態。

LDM 執行緒的數量也決定未明確分割的 NDB 表格所使用的分割區數量；這是 LDM 執行緒的數量乘以叢集中資料節點的數量。(如果資料節點上使用 ndbd 而不是 ndbmtd，則永遠只有一個 LDM 執行緒；在這種情況下，自動建立的分割區數量等於資料節點的數量。如需更多資訊，請參閱第 25.2.2 節「NDB 叢集節點、節點群組、分段複本和分割區」。

如果磁碟頁面緩衝區不夠大，在使用超過預設 LDM 執行緒數量的情況下為磁碟資料表格新增大型表空間可能會導致資源和 CPU 使用問題；如需更多資訊，請參閱 DiskPageBufferMemory 組態參數的說明。

執行緒類型將在本節稍後說明 (請參閱 ThreadConfig)。

如果將此參數設定在允許的值範圍之外，管理伺服器會在啟動時中止，並顯示錯誤訊息 錯誤行 number: 參數 MaxNoOfExecutionThreads 的值 value 無效。

對於 MaxNoOfExecutionThreads，NDB 會在內部將值 0 或 1 四捨五入為 2，因此 2 被視為此參數的預設值和最小值。

MaxNoOfExecutionThreads 通常旨在設定為等於可用的 CPU 執行緒數量，並配置每種執行緒類型適合一般工作負載的執行緒數量。它不會將特定執行緒指派給指定的 CPU。若要變更提供的設定，或將執行緒繫結至 CPU，您應改為使用 ThreadConfig，這可讓您將每個執行緒直接配置給所需的類型、CPU 或兩者。

多執行緒資料節點程序至少會產生此處列出的執行緒

對於 MaxNoOfExecutionThreads 值為 8 或更少，不會建立 TC 執行緒，而是由主要執行緒執行 TC 處理。

變更 LDM 執行緒的數量通常需要重新啟動系統，無論是使用此參數還是 ThreadConfig 進行變更，但是，如果滿足以下兩個條件，則可以使用節點初始重新啟動 (NI) 來生效變更

MaxSendDelay

此參數可用於讓資料節點在將資料傳送至 API 節點之前暫時等待；在以下段落中描述的某些情況下，這可以更有效率地傳送大量資料並提高整體輸送量。

當有大量 API 節點處於飽和點或接近飽和點時，MaxSendDelay 相當有用，這可能會導致效能不斷增加和降低。當資料節點能夠相對快速地將結果傳送回 API 節點時，會發生這種情況，因為需要處理許多小型封包，與大型封包相比，處理每個位元組可能需要更長的時間，因而減慢 API 節點的速度；稍後，資料節點會再次開始傳送更大的封包。

為了處理此類情況，您可以將 MaxSendDelay 設定為非零值，這有助於確保不會太快將回應傳送回 API 節點。這樣做之後，當沒有其他競爭流量時，會立即傳送回應，但當有競爭流量時，設定 MaxSendDelay 會導致資料節點等待足夠長的時間，以確保它們傳送較大的封包。實際上，這會在傳送程序中引入人工瓶頸，而實際上可以顯著提高輸送量。

NoOfFragmentLogParts

設定屬於此 ndbmtd 的重做記錄的記錄檔群組數量。此參數的值應設定為等於 ndbmtd 使用的 LDM 執行緒數量，如 MaxNoOfExecutionThreads 的設定所決定。不允許使用每個 LDM 超過 4 個重做記錄部分的組態。

如需更多資訊，請參閱 MaxNoOfExecutionThreads 的說明。

NumCPUs

設定自動執行緒組態僅使用指定數量的 CPU。如果未啟用 AutomaticThreadConfig，則此設定無效。

PartitionsPerNode

設定在建立新的 NDB 資料表時，每個節點上使用的分割區數量。當本地資料管理器 (LDM) 的數量增加時，這可以避免將資料表分割成過多的分割區。

雖然可以在不同的資料節點上將此參數設定為不同的值，並且這樣做沒有已知的問題，但這也可能沒有任何優勢；因此，建議僅在全球 config.ini 檔案的 [ndbd default] 區段中為所有資料節點設定一次。

如果啟用了 ClassicFragmentation，則會忽略此參數的任何設定。(請記住，啟用 AutomaticThreadConfig 會停用 ClassicFragmentation。)

ThreadConfig

此參數與 ndbmtd 一起使用，將不同類型的執行緒分配給不同的 CPU。其值為一個字串，格式具有以下語法

ThreadConfig := entry[,entry[,...]]

entry := type={param[,param[,...]]}

type := ldm | query | recover | main | recv | send | rep | io | tc | watchdog | idxbld

param := count=number
  | cpubind=cpu_list
  | cpuset=cpu_list
  | spintime=number
  | realtime={0|1}
  | nosend={0|1}
  | thread_prio={0..10}
  | cpubind_exclusive=cpu_list
  | cpuset_exclusive=cpu_list

括住參數列表的大括號 ({...}) 是必需的，即使列表中只有一個參數。

param (參數) 指定以下任何或全部資訊

不同平台的 thread_prio 設定和效果。thread_prio 的實作在 Linux/FreeBSD、Solaris 和 Windows 之間有所不同。在以下列表中，我們將依次討論其在這些平台上的影響

type 屬性代表 NDB 執行緒類型。支援的執行緒類型以及每個執行緒允許的 count 值範圍在以下列表中提供

變更 ThreadConfig 通常需要系統初始重新啟動，但在某些情況下可以放寬此要求。

在任何其他情況下，都需要系統初始重新啟動才能變更此參數。

NDB 可以透過以下兩個準則來區分執行緒類型：

簡單範例

# Example 1.

ThreadConfig=ldm={count=2,cpubind=1,2},main={cpubind=12},rep={cpubind=11}

# Example 2.

Threadconfig=main={cpubind=0},ldm={count=4,cpubind=1,2,5,6},io={cpubind=3}

在為資料節點主機配置執行緒使用時，通常最好保留一個或多個 CPU 數量，供作業系統和其他任務使用。因此，對於具有 24 個 CPU 的主機，您可能想要使用 20 個 CPU 執行緒（保留 4 個供其他用途），其中 8 個 LDM 執行緒、4 個 TC 執行緒（LDM 執行緒數量的一半）、3 個傳送執行緒、3 個接收執行緒，以及每個用於結構描述管理、非同步複製和 I/O 操作的 1 個執行緒。（這幾乎與 MaxNoOfExecutionThreads 設定為 20 時所使用的執行緒分配相同。）以下 ThreadConfig 設定會執行這些指派，此外還會將所有這些執行緒繫結到特定的 CPU：

ThreadConfig=ldm{count=8,cpubind=1,2,3,4,5,6,7,8},main={cpubind=9},io={cpubind=9}, \
rep={cpubind=10},tc{count=4,cpubind=11,12,13,14},recv={count=3,cpubind=15,16,17}, \
send{count=3,cpubind=18,19,20}

在大多數情況下，應該可以將主（結構描述管理）執行緒和 I/O 執行緒繫結到同一個 CPU，就像我們在剛剛顯示的範例中所做的那樣。

以下範例整合了使用 cpuset 和 cpubind 定義的 CPU 群組，以及執行緒優先順序的使用。

ThreadConfig=ldm={count=4,cpuset=0-3,thread_prio=8,spintime=200}, \
ldm={count=4,cpubind=4-7,thread_prio=8,spintime=200}, \
tc={count=4,cpuset=8-9,thread_prio=6},send={count=2,thread_prio=10,cpubind=10-11}, \
main={count=1,cpubind=10},rep={count=1,cpubind=11}

在本例中，我們建立兩個 LDM 群組；第一個使用 cpubind，第二個使用 cpuset。thread_prio 和 spintime 設定為每個群組的相同值。這表示總共有 8 個 LDM 執行緒。（您應該確保 NoOfFragmentLogParts 也設定為 8。）這 4 個 TC 執行緒只使用 2 個 CPU；當使用 cpuset 時，可以指定比群組中執行緒數量少的 CPU。（對於 cpubind 則不然。）傳送執行緒使用 2 個執行緒，使用 cpubind 將這些執行緒繫結到 CPU 10 和 11。主執行緒和 rep 執行緒可以重複使用這些 CPU。

此範例說明如何在具有超執行緒的 24 個 CPU 主機上設定 ThreadConfig 和 NoOfFragmentLogParts，讓 CPU 10、11、22 和 23 可用於作業系統功能和中斷。

NoOfFragmentLogParts=10
ThreadConfig=ldm={count=10,cpubind=0-4,12-16,thread_prio=9,spintime=200}, \
tc={count=4,cpuset=6-7,18-19,thread_prio=8},send={count=1,cpuset=8}, \
recv={count=1,cpuset=20},main={count=1,cpuset=9,21},rep={count=1,cpuset=9,21}, \
io={count=1,cpuset=9,21,thread_prio=8},watchdog={count=1,cpuset=9,21,thread_prio=9}

接下來的幾個範例包含 idxbld 的設定。其中前兩個範例示範了為 idxbld 定義的 CPU 集如何與為其他（永久性）執行緒類型指定的 CPU 集重疊，第一個使用 cpuset，第二個使用 cpubind。

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8},idxbld={cpuset=1-8}

ThreadConfig=main,ldm={count=1,cpubind=1},idxbld={count=1,cpubind=1}

下一個範例為 I/O 執行緒指定 CPU，但不為索引建立執行緒指定。

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8}

由於剛才顯示的 ThreadConfig 設定將執行緒鎖定到編號為 1 到 8 的 8 個核心，因此它與此處顯示的設定相同：

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8},idxbld={cpuset=1,2,3,4,5,6,7,8}

為了利用使用 ThreadConfig 所提供的增強穩定性，必須確保 CPU 已隔離，並且不受中斷的影響，也不會由作業系統排程執行其他任務。在許多 Linux 系統上，您可以透過在 /etc/sysconfig/irqbalance 中將 IRQBALANCE_BANNED_CPUS 設定為 0xFFFFF0，以及在 grub.conf 中使用 isolcpus 開機選項來執行此操作。如需特定資訊，請參閱您的作業系統或平台文件。

DiskPageBufferEntries

這是要配置的頁面項目（頁面參考）數量。它在 DiskPageBufferMemory 中指定為 32K 頁面的數量。預設值足以應付大多數情況，但如果您在使用磁碟資料表格時遇到非常大的交易問題，可能需要增加此參數的值。每個頁面項目約需 100 個位元組。

DiskPageBufferMemory

這會決定用於快取磁碟上頁面的空間大小（以位元組為單位），並在 config.ini 檔案的 [ndbd] 或 [ndbd default] 區段中設定。

如果 DiskPageBufferMemory 的值設定太低，且在 ThreadConfig 中使用超過預設數量的 LDM 執行緒（例如 {ldm=6...}），則在嘗試將大型（例如 500G）資料檔案新增至以磁碟為基礎的 NDB 表格時，可能會出現問題，在此過程中，該流程會佔用其中一個 CPU 核心，且耗時無限期。

這是因為，在將資料檔案加入表空間的過程中，範圍頁面會被鎖定在額外的 PGMAN 工作執行緒的記憶體中，以便快速存取中繼資料。當加入大型檔案時，此工作執行緒的記憶體不足以處理所有資料檔案的中繼資料。在這種情況下，您應該增加 DiskPageBufferMemory，或加入較小的表空間檔案。您可能還需要調整 DiskPageBufferEntries。

您可以查詢 ndbinfo.diskpagebuffer 資料表，以協助判斷是否應該增加此參數的值，以減少不必要的磁碟搜尋。請參閱 第 25.6.17.31 節，「ndbinfo diskpagebuffer 資料表」，以取得更多資訊。

SharedGlobalMemory

此參數決定用於日誌緩衝區、磁碟操作（例如頁面請求和等待佇列），以及表空間、日誌檔案群組、UNDO 檔案和資料檔案的中繼資料的記憶體量。共用全域記憶體池也提供記憶體，用於滿足與 CREATE LOGFILE GROUP 和 ALTER LOGFILE GROUP 陳述式一起使用的 UNDO_BUFFER_SIZE 選項的記憶體需求，包括此選項在 InitialLogFileGroup 資料節點組態參數的設定中隱含的任何預設值。SharedGlobalMemory 可以在 config.ini 組態檔案的 [ndbd] 或 [ndbd default] 區段中設定，並且以位元組為單位測量。

預設值為 128M。

DiskIOThreadPool

此參數決定用於磁碟資料檔案存取的不受限執行緒數。在引入 DiskIOThreadPool 之前，每個磁碟資料檔案都會產生一個執行緒，這可能會導致效能問題，尤其是在使用非常大的資料檔案時。透過 DiskIOThreadPool，您可以（例如）使用多個並行工作的執行緒來存取單個大型資料檔案。

此參數僅適用於磁碟資料 I/O 執行緒。

此參數的最佳值取決於您的硬體和組態，並且包括以下因素

此參數的預設值為 2。

磁碟資料檔案系統參數。 以下清單中的參數可讓您在特定目錄中放置 NDB Cluster 磁碟資料檔案，而無需使用符號連結。

如需更多資訊，請參閱 第 25.6.11.1 節，「NDB Cluster 磁碟資料物件」。

磁碟資料物件建立參數。 接下来的兩個參數可讓您在第一次啟動叢集時，無需使用 SQL 陳述式，即可建立磁碟資料日誌檔案群組、表空間或兩者。