NodeId

唯一的節點 ID 會用作所有叢集內部訊息的節點位址。對於資料節點，這是一個 1 到 144 (含) 範圍內的整數。叢集中的每個節點都必須具有唯一的識別碼。

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

ExecuteOnComputer

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

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

HostName

指定此參數可定義資料節點所在的電腦主機名稱。使用 HostName 指定 localhost 以外的主機名稱。

ServerPort

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

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

TcpBind_INADDR_ANY

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

NodeGroup

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

NodeGroup 參數主要用於將新節點群組新增至執行中的 NDB 叢集，而無需執行滾動重新啟動。為此，您應該將其設定為 65536 (最大值)。您不需要為所有叢集資料節點設定 NodeGroup 值，只需要設定稍後將啟動並新增至叢集作為新節點群組的那些節點即可。如需更多資訊，請參閱 第 25.6.7.3 節，「線上新增 NDB 叢集資料節點：詳細範例」。

LocationDomainId

將資料節點指派給雲端中的特定可用性網域（也稱為可用性區域）。透過告知 NDB 哪些節點位於哪個可用性網域，可以在雲端環境中透過以下方式提高效能：

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 叢集的建議目錄階層包括 /var/lib/mysql-cluster，在其下會建立節點檔案系統的目錄。此子目錄的名稱包含節點 ID。例如，如果節點 ID 為 2，則此子目錄命名為 ndb_2_fs。

BackupDataDir

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

DataMemory

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

由 DataMemory 配置的記憶體用於儲存實際記錄和索引。每個記錄有 16 位元組的額外負荷；每個記錄也會產生額外的數量，因為它儲存在具有 128 位元組頁面額外負荷的 32KB 頁面中（請參閱下文）。由於每個記錄僅儲存在一個頁面中，因此每個頁面也會浪費少量空間。

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

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

指派給 DataMemory 的資源用於儲存所有資料和索引。（任何配置為 IndexMemory 的記憶體都會自動新增到 DataMemory 使用的記憶體中，以形成一個共用的資源集區。）

由 DataMemory 配置的記憶體空間由 32KB 的頁面組成，這些頁面會配置給表格片段。每個表格通常會分割成與叢集中資料節點數量相同的片段數量。因此，對於每個節點，都有與 NoOfReplicas 中設定的相同的片段數量。

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

DataMemory 記憶體空間也包含 UNDO 資訊：對於每個更新，會在 DataMemory 中配置未修改記錄的複本。在排序的表格索引中，也有每個複本的參考。只有在更新唯一索引欄時，才會更新唯一雜湊索引，在這種情況下，會在索引表格中插入一個新項目，並在提交時刪除舊項目。因此，還需要配置足夠的記憶體來處理使用叢集的應用程式所執行的最大交易。無論如何，執行一些大型交易與使用許多較小的交易相比，並沒有任何優勢，原因如下：

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

IndexMemory

IndexMemory 參數已棄用（並可能在未來移除）；任何分配給 IndexMemory 的記憶體，都會改為分配到與 DataMemory 相同的記憶體池，而 DataMemory 完全負責儲存資料和索引所需的全部記憶體資源。在 NDB 8.4 中，在叢集設定檔中使用 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 萬列，並且在兩個 4 位元組整數上具有名為 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

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

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

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

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

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

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

預設值為 32768。

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

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

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

MaxNoOfLocalOperations

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

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

MaxDMLOperationsPerTransaction

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

此參數的值不能超過為 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 記錄之後，直到完成兩個需要的本機檢查點，才會移除 REDO 記錄。檢查點頻率由本章其他地方討論的自己的一組組態參數決定。

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

如果檢查點速度緩慢，而且資料庫寫入次數太多，導致記錄檔已滿，且無法在不損害復原的情況下削減記錄尾部，則所有更新交易都會因內部錯誤代碼 410（暫時沒有記錄檔空間）而中止。此條件會持續存在，直到檢查點完成且可以向前移動記錄尾部為止。

RecoveryWork

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

RecoveryWork 的值較低表示

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

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

NDB 來源發行版本包含用於模擬 LCP 的測試程式。lcp_simulator.cc 可以在 storage/ndb/src/kernel/blocks/backup/ 中找到。若要在 Unix 平台上編譯並執行它，請執行此處顯示的命令

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

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

InsertRecoveryWork

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

EnableRedoControl

啟用自適應檢查點速度以控制 redo 記錄使用量。

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

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

MaxNoOfAttributes

此參數設定叢集中可以定義的屬性建議最大數量；就像 MaxNoOfTables 一樣，它並非旨在作為硬性上限。

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

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

在設定 MaxNoOfAttributes 時，請務必事先準備好任何您未來可能需要執行的 ALTER TABLE 陳述式。這是因為在叢集表格上執行 ALTER TABLE 時，會使用原始表格中屬性數量的 3 倍，而一個好的做法是允許兩倍的屬性數量。例如，如果具有最多屬性 (greatest_number_of_attributes) 的 NDB 叢集表格有 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 應用程式，可能需要或希望變更此參數。但是，對於使用 MySQL 伺服器作為 SQL 節點的正常使用情況，則不需要這麼做。

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，其作用如下列所示：

如果作業系統未配置為允許非特權使用者鎖定頁面，則使用此參數的資料節點程序可能必須以系統 root 身分執行。( 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 Cluster 時，如果您使用的是 2.6 或更高版本的核心，請啟用 ODirect。

ODirect 預設為停用。

ODirectSyncFlag

啟用此參數後，執行重做記錄寫入時，會將每個完成的檔案系統寫入處理為對 fsync 的呼叫。如果至少符合下列其中一個條件，則會忽略此參數的設定：

預設為停用。

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 Cluster 資料節點〉。

HeartbeatIntervalDbDb

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

在連續錯過四個心跳間隔後，節點會被宣告為已死。因此，通過心跳機制發現故障的最大時間為心跳間隔的五倍。

預設心跳間隔為 5000 毫秒 (5 秒)。此參數不得大幅變更，並且在節點之間不應有很大差異。如果一個節點使用 5000 毫秒，而監視它的節點使用 1000 毫秒，則顯然該節點會很快被宣告為已死。可以在線上軟體升級期間變更此參數，但只能少量遞增。

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

HeartbeatIntervalDbApi

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

預設間隔為 1500 毫秒（1.5 秒）。此間隔在各個資料節點之間可能會有所不同，因為每個資料節點都會獨立於所有其他資料節點監看與其連線的 MySQL 伺服器。

有關更多資訊，請參閱 網路通訊和延遲。

HeartbeatOrder

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

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

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

考慮一個設定，其中有 4 個資料節點 A、B、C 和 D 在 2 個主機電腦 host1 和 host2 上執行，並且這些資料節點構成 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 值，如下所示

C

3

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

完整關閉並重新啟動整個叢集。

連續 2 次對叢集進行輪流重新啟動。 所有節點必須在兩個輪流重新啟動中，都以相同的順序重新啟動。

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

ConnectCheckIntervalDelay

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

此參數的預設值為 0（停用）。

TimeBetweenLocalCheckpoints

以 2 為底的對數表示的 4 位元組字組數

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

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

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

TimeBetweenGlobalCheckpoints

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

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

當您搭配使用固態硬碟（特別是採用 NVMe 的固態硬碟）與「磁碟資料」表時，建議您降低此值。在這種情況下，您也應確保將 MaxDiskDataLatency 設定為適當的層級。

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

TimeBetweenGlobalCheckpointsTimeout

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

TimeBetweenEpochs

此參數定義 NDB 叢集複製的同步週期之間的間隔。預設值為 100 毫秒。

TimeBetweenEpochs 是「微 GCP」實作的一部分，可用於提升 NDB 叢集複製的效能。

TimeBetweenEpochsTimeout

MaxBufferedEpochs

訂閱節點可以落後未處理 epoch 的數量。超過此數量會導致落後的訂閱者斷線。

預設值 100 對於大多數正常操作來說已足夠。如果訂閱節點確實落後到足以導致斷線，通常是因為網路或排程問題，與程序或執行緒有關。（在極少數情況下，問題可能是 NDB 客戶端中的錯誤所導致）。當 epoch 時間較長時，可能需要將該值設定為低於預設值。

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

MaxBufferedEpochBytes

此節點分配用於緩衝 epoch 的總位元組數。

TimeBetweenInactiveTransactionAbortCheck

逾時處理是透過針對每個交易，按照此參數指定的間隔檢查計時器來執行。因此，如果此參數設定為 1000 毫秒，則每個交易每秒檢查一次逾時。

預設值為 1000 毫秒（1 秒）。

TransactionInactiveTimeout

此參數表示在同一交易中的操作之間允許經過的最長時間，超過此時間交易將中止。

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

TransactionDeadlockDetectionTimeout

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

無法回應的原因可能如下：

此逾時參數表示交易協調器在中止交易之前等待另一個節點執行查詢的時間，這對於節點故障處理和死鎖偵測都很重要。

預設逾時值為 1200 毫秒（1.2 秒）。

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

DiskSyncSize

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

預設值為 4M（4 百萬位元組）。

MaxDiskWriteSpeed

設定在此 NDB 叢集中沒有重新啟動（由該資料節點或任何其他資料節點）的情況下，本機檢查點和備份操作寫入磁碟的最大速率，以每秒位元組數表示。

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

MaxDiskWriteSpeedOtherNodeRestart

設定在此 NDB 叢集中一個或多個資料節點（而非此節點）重新啟動時，本機檢查點和備份操作寫入磁碟的最大速率，以每秒位元組數表示。

如要設定此資料節點重新啟動時允許的最大磁碟寫入速率，請使用 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

您可以透過設定此參數來啟用和控制資料節點之間傳送的 Keep-Alive 訊號之間的時間間隔。KeepAliveSendInterval 的預設值為 60000 毫秒（一分鐘）；將其設定為 0 會停用 Keep-Alive 訊號。1 到 10（含 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 Cluster 日誌事件」中統計事件的討論中所述。

StartupStatusReportFrequency

當使用 --initial 啟動資料節點時，它會在「啟動階段 4」（請參閱 第 25.6.4 節「NDB Cluster 啟動階段摘要」）期間初始化 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 8.4 支援多執行緒備份，因此通常不需要調整此參數，它在多執行緒情況下無效。以下討論專門針對單執行緒備份。

在正常操作期間，資料節點會嘗試最大化用於本地檢查點和備份的磁碟寫入速度，同時保持在 MinDiskWriteSpeed 和 MaxDiskWriteSpeed 所設定的界限內。磁碟寫入節流會讓每個 LDM 執行緒均分總預算。這允許並行 LCP 在不超出磁碟 I/O 預算的情況下進行。由於備份僅由一個 LDM 執行緒執行，這實際上導致了預算削減，導致備份完成時間更長，並且 — 如果變更速率足夠高 — 在備份日誌緩衝區填滿速率高於可實現的寫入速率時，無法完成備份。

可以使用 BackupDiskWriteSpeedPct 組態參數來解決此問題，該參數的值範圍為 0-90（含），其被解釋為節點的最大寫入速率預算的百分比，該百分比會在 LCP 的 LDM 執行緒之間共享剩餘預算之前被保留。執行備份的 LDM 執行緒將獲得用於備份的整個寫入速率預算，加上其（減少的）用於本地檢查點的寫入速率預算份額。

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

BackupLogBufferSize

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

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

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

此參數的預設值為 16MB。

BackupMemory

此參數已過時，並可能在未來版本的 NDB Cluster 中移除。對其進行的任何設定都會被忽略。

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 Cluster 管理用戶端建立備份」。

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 備份檔案。

此參數通常為啟用狀態（設定為 1），用於 ndbmtd。若要強制執行單執行緒備份，以便使用較舊版本的 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 處理會改由主要執行緒執行。

無論是使用此參數還是 ThreadConfig 變更，變更 LDM 執行緒的數量通常都需要重新啟動系統，但是，如果滿足以下兩個條件，則可以使用節點初始重新啟動（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 設定為每個群組的相同值。這表示總共有八個 LDM 執行緒。（您應確保 NoOfFragmentLogParts 也設定為 8。）四個 TC 執行緒僅使用兩個 CPU；當使用 cpuset 時，可以指定少於群組中執行緒數量的 CPU。（cpubind 並非如此。）傳送執行緒使用兩個執行緒，使用 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，但未為索引建置執行緒指定 CPU

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

由於剛剛顯示的 ThreadConfig 設定將執行緒鎖定到編號為 1 到 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 陳述式。