NodeId

唯一节点 ID 用作所有集群内部消息的节点地址。对于数据节点，这是一个介于 1 到 144 之间的整数。集群中的每个节点都必须具有唯一的标识符。

NodeId 是识别数据节点时唯一支持的参数名称。

ExecuteOnComputer

这指的是为 [computer] 部分中定义的一台计算机设置的 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 个字节的开销；由于每条记录都存储在一个 32KB 的页面中，并带有 128 字节的页面开销（见下文），因此每条记录都会产生额外的开销。由于每条记录仅存储在一个页面中，因此每个页面也会浪费少量空间。

对于可变大小的表属性，数据存储在单独的数据页面上，这些数据页面从 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

片段 是片段的数量，片段副本 是片段副本的数量（通常为 2），行 是行的数量。如果一个表有一百万行、八个片段和两个片段副本，则预期的索引内存使用量计算如下所示

  ((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

在前面的公式中，键大小 是有序索引键的大小（以字节为单位），键属性 是有序索引键中的属性数量，行 是基表中的行数。

假设表 t1 有一百万行，并且在两个四字节整数上有一个名为 ix1 的有序索引。此外，假设 IndexStatSaveSize 和 IndexStatSaveScale 设置为其默认值（分别为 32K 和 100）。使用前面的两个公式，我们可以计算如下

  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 Cluster，这意味着在每个数据节点上将 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 Cluster 版本中删除。此外，此参数与 TransactionMemory 参数不兼容；如果您尝试在集群配置文件 (config.ini) 中为这两个参数设置值，则管理服务器将拒绝启动。

MaxDMLOperationsPerTransaction

此参数限制事务的大小。如果事务需要超过此数量的 DML 操作，则该事务将中止。

此参数的值不能超过为 MaxNoOfConcurrentOperations 设置的值。

MaxNoOfConcurrentIndexOperations

对于使用唯一哈希索引的查询，在查询的执行阶段会使用另一组临时的操作记录。此参数设置该记录池的大小。因此，此记录仅在执行查询的一部分时分配。一旦执行了这一部分，就会释放该记录。处理中止和提交所需的状态由普通操作记录处理，其中池大小由参数 MaxNoOfConcurrentOperations 设置。

此参数的默认值为 8192。只有在使用唯一哈希索引的极端高并行情况下才需要增加此值。如果 DBA 确定集群不需要高度并行性，则可以使用较小的值并节省内存。

此参数已弃用，并将在未来的 NDB Cluster 版本中删除。此外，此参数与 TransactionMemory 参数不兼容；如果您尝试在集群配置文件 (config.ini) 中为这两个参数设置值，则管理服务器将拒绝启动。

MaxNoOfFiredTriggers

MaxNoOfFiredTriggers 的默认值为 4000，足以满足大多数情况。在某些情况下，如果 DBA 确定集群中不需要并行性，则甚至可以减少此值。

当执行的操作影响唯一哈希索引时，会创建一个记录。在具有唯一哈希索引的表中插入或删除记录或更新作为唯一哈希索引一部分的列会在索引表中触发插入或删除。生成的记录用于表示此索引表操作，同时等待触发它的原始操作完成。此操作是短暂的，但在包含一组唯一哈希索引的基本表上进行多次并行写入操作的情况下，其池中仍然需要大量记录。

此参数已弃用，并将在未来的 NDB Cluster 版本中删除。此外，此参数与 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 Cluster 数据节点中资源分配的更多信息，请参阅第 25.4.3.13 节“数据节点内存管理”。

BatchSizePerLocalScan

此参数用于计算用于处理并发扫描操作的锁记录数。

已弃用。

BatchSizePerLocalScan 与 SQL 节点中定义的 BatchSize 有很强的联系。

LongMessageBuffer

这是一个内部缓冲区，用于在单个节点内以及节点之间传递消息。默认值为 64MB。

此参数很少需要更改默认值。

MaxFKBuildBatchSize

用于构建外键的最大扫描批大小。增加为此参数设置的值可能会加快外键构建的速度，但会对正在进行的流量产生更大的影响。

MaxNoOfConcurrentScans

此参数用于控制可以在集群中执行的并行扫描数。每个事务协调器都可以处理为此参数定义的并行扫描数。每个扫描查询都通过并行扫描所有分区来执行。每个分区扫描在分区所在的节点中使用一个扫描记录，记录数是此参数的值乘以节点数。集群应该能够承受来自集群中所有节点的 MaxNoOfConcurrentScans 个并发扫描。

实际上，在两种情况下执行扫描。第一种情况发生在没有哈希索引或有序索引来处理查询时，在这种情况下，查询是通过执行全表扫描来执行的。第二种情况是在没有哈希索引来支持查询但有有序索引时遇到的。使用有序索引意味着执行并行范围扫描。顺序仅保留在本地分区上，因此有必要对所有分区执行索引扫描。

MaxNoOfConcurrentScans 的默认值为 256。最大值为 500。

MaxNoOfLocalScans

如果许多扫描未完全并行化，则指定本地扫描记录数。如果未提供本地扫描记录数，则按此处所示进行计算

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

此参数已弃用，并将在未来的 NDB Cluster 版本中删除。此外，此参数与 TransactionMemory 参数不兼容；如果您尝试在集群配置文件 (config.ini) 中为这两个参数设置值，则管理服务器将拒绝启动。

MaxParallelCopyInstances

此参数设置在节点重启或系统重启的复制阶段使用的并行度，此时，当前正在启动的节点通过将已更新的节点中的任何更改的记录复制到已启动的节点来与已具有当前数据的节点同步。因为在这种情况下完全并行可能会导致过载情况，所以 MaxParallelCopyInstances 提供了一种减少并行度的方法。此参数的默认值为 0。此值意味着有效并行度等于刚启动的节点和正在更新它的节点中的 LDM 实例数。

MaxParallelScansPerFragment

可以配置在并行扫描（TUP 扫描和 TUX 扫描）开始排队进行串行处理之前允许的最大数量。您可以增加此值，以便在执行大量并行扫描时利用任何未使用的 CPU，并提高其性能。

MaxReorgBuildBatchSize

用于重新组织表分区时使用的最大扫描批处理大小。增加为此参数设置的值可以加快重新组织的速度，但代价是对正在进行的流量产生更大的影响。

MaxUIBuildBatchSize

用于构建唯一键时使用的最大扫描批处理大小。增加为此参数设置的值可以加快此类构建的速度，但代价是对正在进行的流量产生更大的影响。

FragmentLogFileSize

设置此参数后，您可以直接控制重做日志文件的大小。这在 NDB Cluster 在高负载下运行且无法在尝试打开新文件之前足够快地关闭片段日志文件时非常有用（一次只能打开 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，它确定集群在数据节点继续同步元数据时可以等待开始本地检查点的秒数。应在 config.ini 文件的 [ndbd default] 部分中设置此参数，以便所有数据节点都相同。最大值为 600；默认值为 0。

NoOfFragmentLogFiles

此参数设置节点的 REDO 日志文件数，从而设置分配给 REDO 日志记录的空间量。由于 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 倍。这意味着与使用完整检查点的重启相比，在使用部分 LCP 的重启的恢复阶段需要多 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 的测试程序。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 后报告其大小。您可以通过更改源代码中 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 Disk Data 表出现问题，这些表的表空间或日志文件组与数据节点 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

对于不是主键的每个唯一索引，都会分配一个特殊表，用于将唯一键映射到索引表的primaryKey。默认情况下，还会为每个唯一索引定义一个有序索引。要防止这种情况，您必须在定义唯一索引时指定 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 集群时，如果使用的是 2.6 或更高版本的内核，请启用 ODirect。

默认情况下，ODirect 被禁用。

ODirectSyncFlag

启用此参数后，将执行重做日志写入，以便将每个完成的文件系统写入作为对 fsync 的调用来处理。如果满足以下至少一个条件，则忽略此参数的设置：

默认情况下禁用。

RequireCertificate

如果此参数设置为 true，则数据节点会在 TLS 搜索路径中查找密钥和有效且最新的证书，如果找不到则无法启动。

RequireTls

如果此参数设置为 true，则必须使用 TLS 对与此数据节点的连接进行身份验证。

RestartOnErrorInsert

仅在构建调试版本时才能访问此功能，在调试版本中，可以将错误插入到各个代码块的执行中作为测试的一部分。

默认情况下，此功能被禁用。

StopOnError

此参数指定在遇到错误情况时数据节点进程是应退出还是执行自动重启。

此参数的默认值为 1；这意味着默认情况下，错误会导致数据节点进程停止。

当遇到错误且 StopOnError 为 0 时，数据节点进程将重新启动。

MySQL 集群管理器用户应注意，当 StopOnError 等于 1 时，这会阻止 MySQL 集群管理器代理在其执行自己的重启和恢复后重启任何数据节点。有关更多信息，请参见 在 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

数据节点以循环方式相互发送心跳，其中每个数据节点监视前一个数据节点。如果给定数据节点未检测到心跳，则该节点会将循环中的前一个数据节点声明为“失效”（即集群无法再访问该数据节点）。数据节点失效的确定是在全局范围内完成的；换句话说，一旦数据节点被声明为失效，则集群中的所有节点都会将其视为失效。

与其他数据节点对之间的心跳相比，位于不同主机上的数据节点之间的心跳可能会过慢（例如，由于心跳间隔非常短或暂时连接问题），以至于即使数据节点仍然可以作为集群的一部分正常运行，也会被声明为失效。

在这种情况下，数据节点之间传输心跳的顺序可能会影响特定数据节点是否被声明为失效。如果不必要地进行此声明，则可能导致不必要地丢失节点组，从而导致集群故障。

假设在一个设置中，有 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 值

要使用此参数更改正在运行的 NDB 集群中的心跳传输顺序，必须首先在全局配置文件（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 的固态硬盘）与磁盘数据表一起使用时，应减少此值。在这种情况下，您还应该确保 MaxDiskDataLatency 设置为适当的级别。

此参数定义全局检查点之间的时间间隔。默认值为 2000 毫秒。

TimeBetweenGlobalCheckpointsTimeout

此参数定义全局检查点之间的最小超时时间。默认值为 120000 毫秒。

TimeBetweenEpochs

此参数定义 NDB 集群复制的同步周期之间的间隔。默认值为 100 毫秒。

TimeBetweenEpochs 是 “微型 GCP” 实现的一部分，可用于提高 NDB 集群复制的性能。

TimeBetweenEpochsTimeout

此参数定义 NDB 集群复制的同步周期的超时时间。如果节点未能在由此参数确定的时间内参与全局检查点，则该节点将关闭。默认值为 0；换句话说，超时被禁用。

TimeBetweenEpochsTimeout 是 “微型 GCP” 实现的一部分，可用于提高 NDB 集群复制的性能。

每当 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 兆字节）。

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 之间（含）的值将被视为 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

此参数控制数据节点内存使用情况报告在集群日志中记录的频率；它是一个整数值，表示报告之间的秒数。

每个数据节点的数据内存和索引内存使用情况都记录为 config.ini 文件中设置的 DataMemory 的百分比和 32 KB 页数。例如，如果 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 集群启动阶段摘要”）。如果为 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（默认值），则仅在重做日志文件初始化过程开始和完成时才会将报告写入集群日志。

DictTrace

可以使用 DictTrace 导致记录由创建和删除表生成的事件的跟踪。此参数仅在调试 NDB 内核代码时有用。DictTrace 接受一个整数值。0 是默认值，表示不执行日志记录；1 启用跟踪日志记录，2 启用其他 DBDICT 调试输出的日志记录。

WatchdogImmediateKill

通过启用 WatchdogImmediateKill 数据节点配置参数，您可以使线程在发生 watchdog 问题时立即终止。此参数应该仅在调试或故障排除时使用，以获取报告执行停止时究竟发生情况的跟踪文件。

BackupDataBufferSize

在创建备份时，有两个缓冲区用于将数据发送到磁盘。备份数据缓冲区用于填充通过扫描节点表记录的数据。一旦此缓冲区已填充到指定为 BackupWriteSize 的级别，页面就会被发送到磁盘。在将数据刷新到磁盘时，备份过程可以继续填充此缓冲区，直到其空间耗尽。发生这种情况时，备份过程会暂停扫描，并等待某些磁盘写入完成以释放内存，以便扫描可以继续。

此参数的默认值为 16MB。最小值为 512KB。

BackupDiskWriteSpeedPct

BackupDiskWriteSpeedPct 仅在备份是单线程时适用；由于 NDB 8.4 支持多线程备份，因此通常不需要调整此参数，在多线程情况下它不起作用。以下讨论特定于单线程备份。

在正常操作期间，数据节点会尝试最大限度地提高用于本地检查点和备份的磁盘写入速度，同时保持在 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 时重建有序索引时要创建的线程数。只有当每个数据节点的表有多个片段时（例如，在 CREATE TABLE 中使用 COMMENT="NDB_TABLE=PARTITION_BALANCE=FOR_RA_BY_LDM_X_2" 时），才支持此参数。

将此参数设置为 0（默认值）将禁用有序索引的多线程构建。

使用 ndbd 或 ndbmtd 时，支持此参数。

您可以通过将 TwoPassInitialNodeRestartCopy 数据节点配置参数设置为 TRUE，在数据节点初始重启期间启用多线程构建。

LockExecuteThreadToCPU

与 ndbd 一起使用时，此参数（现在是字符串）指定分配给处理 NDBCLUSTER 执行线程的 CPU 的 ID。与 ndbmtd 一起使用时，此参数的值是分配给处理执行线程的 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，以便可以在操作系统级别确定所需的行为。

Numa 配置参数仅在可以使用 libnuma.so 的 Linux 系统上受支持。

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 不适用这种情况。）发送线程使用两个线程，并使用 cpubind 将这些线程绑定到 CPU 10 和 11。主线程和复制线程可以重用这些 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 的 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] 部分中设置。

如果在 ThreadConfig 中使用比默认 LDM 线程数更多的线程（例如 {ldm=6...}）的情况下，将 DiskPageBufferMemory 的值设置得太低，则在尝试将大型（例如 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 群集磁盘数据文件放置在特定目录中，而无需使用符号链接。

有关更多信息，请参见 “第 25.6.11.1 节“NDB Cluster 磁盘数据对象””。

磁盘数据对象创建参数。 以下两个参数允许您在首次启动集群时创建磁盘数据日志文件组、表空间或两者，而无需使用 SQL 语句。