NodeId

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

NodeId是唯一支持的参数名称，用于标识数据节点。

ExecuteOnComputer

这指的是在[computer]部分中定义的计算机的Id。

该节点的节点ID只能分配给明确请求它的连接。管理服务器请求“任何”节点ID不能使用该节点ID。该参数可用于在同一主机上运行多个管理服务器时，并且HostName不足以区分进程。旨在用于测试。

HostName

指定该参数定义了数据节点所在的计算机的主机名。使用HostName指定其他主机名，而不是localhost。

ServerPort

每个集群节点使用一个端口连接到其他节点。默认情况下，该端口是动态分配的，以确保同一主机计算机上的两个节点不接收相同的端口号，因此通常不需要指定该参数的值。

然而，如果您需要在防火墙中打开特定端口，以便从SQL节点或API节点到数据节点的通信，您可以在[ndbd]部分或[ndbd default]部分的config.ini文件中设置该参数的值，然后打开具有该号码的端口以接受来自SQL节点或API节点的入站连接。

TcpBind_INADDR_ANY

将该参数设置为TRUE或1以绑定IP_ADDR_ANY，以便从任何地方（对于自动生成的连接）建立连接。默认值为FALSE（0）。

NodeGroup

该参数可以将数据节点分配给特定的节点组。它仅在集群第一次启动时读取，并且不能在线重新分配数据节点到不同的节点组中。通常不建议在 [ndbd default] 部分的 config.ini 文件中使用该参数，并且必须小心地避免将节点分配给节点组，以免将无效的节点数分配给任何节点组。

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。

数据目录

该参数指定了跟踪文件、日志文件、PID 文件和错误日志的目录。

默认是数据节点进程的工作目录。

文件系统路径

该参数指定了元数据、REDO 日志、UNDO 日志（对于磁盘数据表）和数据文件的目录。默认是由数据目录指定的目录。

推荐的目录层次结构为 NDB 集群包括/var/lib/mysql-cluster，在其中创建一个节点文件系统的目录。该子目录的名称包含节点 ID。例如，如果节点 ID 是 2，则该子目录名为ndb_2_fs。

备份数据目录

该参数指定了备份的目录。

数据内存

该参数定义了用于存储数据库记录的空间（以字节为单位）。该值指定的整个金额将在内存中分配，因此机器必须具有足够的物理内存来容纳它。

由DataMemory分配的内存用于存储实际记录和索引。每个记录都有 16 字节的开销；每个记录还会因为存储在 32KB 页上而产生 128 字节的开销（见下文）。每页还会因为记录存储在一个页上而产生少量的浪费。

对于可变大小的表属性，数据存储在从DataMemory分配的单独数据页上。可变长度记录使用固定大小的部分，额外增加 4 字节来引用可变大小的部分。可变大小的部分还有 2 字节的开销加上每个属性的 2 字节。

最大记录大小为 30000 字节。

分配给 DataMemory 的资源用于存储所有数据和索引。（任何配置为 IndexMemory 的内存都会自动添加到 DataMemory 使用的内存中，以形成一个共同的资源池。）

由DataMemory分配的内存空间由 32KB 页组成，这些页被分配给表碎片。每个表通常被分区为与集群中的数据节点相同的数量。因此，对于每个节点，都有与NoOfReplicas 设置的相同数量的碎片。

一旦一页被分配，就不能将其返回到空闲页池中，除非删除表。（这也意味着DataMemory 页，一旦分配给某个表，就不能被其他表使用。）执行数据节点恢复也会压缩分区，因为所有记录都被插入到其他 live 节点的空白分区中。

DataMemory 内存空间还包含 UNDO 信息：对于每个更新，unaltered 记录的副本将被分配在 DataMemory 中。还有一个引用每个副本的有序表索引。唯一哈希索引只有在唯一索引列被更新时才会被更新，在提交时旧条目将被删除。因此，也需要分配足够的内存来处理应用程序使用集群时的最大事务。在任何情况下，执行少量大事务与执行许多小事务没有优势，因为：

默认的 DataMemory 值为 98MB。最小值为 1MB。没有最大大小，但实际上最大大小必须根据机器上的物理 RAM 量和操作系统对每个进程的内存承诺来确定。32 位操作系统通常限制为每个进程 2-4GB；64 位操作系统可以使用更多。对于大型数据库，可能更喜欢使用 64 位操作系统出于这个原因。

IndexMemory

IndexMemory 参数已弃用（并将在未来删除）；分配给 IndexMemory 的任何内存都将被分配到与DataMemory相同的池中，该池负责存储数据和索引所需的所有资源。在 NDB 8.3 中，在集群配置文件中使用 IndexMemory 将触发管理服务器的警告。

您可以使用以下公式来估算哈希索引的大小：

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

fragments 是碎片的数量，fragment_replicas 是碎片副本的数量（通常为 2），rows 是行的数量。如果一个表有100万行，八个碎片和两个碎片副本，那么预期的索引内存使用情况可以按照以下方式计算：

  ((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，分别）。使用前两个公式，我们可以按照以下方式计算：

  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 或更多）时，可能会出现 Error 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服务器需要110个事务记录，或者总共需要1100个事务记录。每个数据节点可以处理TotalNoOfConcurrentTransactions / 数据节点数的记录。对于具有4个数据节点的NDB Cluster，可以将每个数据节点的MaxNoOfConcurrentTransactions设置为1100 / 4 = 275。此外，还需要为故障恢复提供保障，确保单个节点组可以处理所有并发事务；换言之，每个数据节点的MaxNoOfConcurrentTransactions应该足以涵盖等于TotalNoOfConcurrentTransactions / 节点组数的交易数量。如果该集群只有一个节点组，那么MaxNoOfConcurrentTransactions应该设置为1100（与整个集群的并发事务数量相同）。

此外，每个事务至少涉及一个操作；因此，设置的MaxNoOfConcurrentTransactions值应该始终小于或等于MaxNoOfConcurrentOperations的值。

该参数必须对所有集群数据节点设置相同的值。这是因为，当数据节点失败时， oldest 生存节点将重新创建失败节点中的所有事务状态。

可以使用滚动重新启动更改该值，但是在此过程中，集群上的流量必须足以确保不超过旧值和新值之间的交易数量。

默认值为4096。

MaxNoOfConcurrentOperations

根据事务的大小和数量调整该参数的值是一个好主意。当执行仅涉及少量操作和记录的事务时，默认值通常足够。当执行涉及许多记录的大型事务时，通常需要增加该值。

对于每个更新集群数据的事务，会在事务协调器和执行实际更新的节点中保留记录。这些记录包含用于回滚、锁定队列和其他目的的状态信息。

该参数的最小值应该设置为同时更新记录的数量，除以集群数据节点的数量。例如，在具有四个数据节点的集群中，预计处理一百万个并发更新的事务，应该将该值设置为1000000 / 4 = 250000。为了提供对故障的弹性，建议将该值设置为足以使单个数据节点处理其节点组的负载的值。在单个节点组的情况下，这等于整个集群的并发操作数量。

因为每个事务至少涉及一个操作，因此MaxNoOfConcurrentOperations的值应该始终大于或等于MaxNoOfConcurrentTransactions的值。

锁定的读取查询也会创建操作记录。在每个节点中分配了一些额外的空间，以便处理节点之间的不均匀分布的情况。

当查询使用唯一哈希索引时，实际上使用了两个操作记录，每个记录在事务中使用一个记录代表索引表中的读取，另一个记录处理基本表上的操作。

默认值为32768。

该参数实际上处理了两个可以单独配置的值。第一个指定了事务协调器中的操作记录数量，第二个指定了数据库中的操作记录数量。

执行非常大的事务需要在事务协调器中记录操作记录的数量，相当于事务中涉及的读取、更新和删除操作的数量。然而，这些操作记录分布在八个节点上。因此，如果需要配置系统以处理一个非常大的事务，那么将两个部分分开配置是一个好主意。MaxNoOfConcurrentOperations始终用于计算事务协调器部分的操作记录数量。

此外，了解操作记录的内存要求也很重要。这些记录每个大约消耗1KB。

MaxNoOfLocalOperations

默认情况下，该参数计算为 1.1 × MaxNoOfConcurrentOperations。这适合具有许多同时事务的系统，其中没有任何一个事务非常大。如果需要处理一个非常大的事务，并且有许多节点，那么覆盖默认值并明确指定该参数是一个好主意。

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

MaxDMLOperationsPerTransaction

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

该参数的值不能超过MaxNoOfConcurrentOperations的值。

MaxNoOfConcurrentIndexOperations

对于使用唯一哈希索引的查询，执行阶段还使用另一个临时操作记录池。该参数设置该记录池的大小。因此，该记录仅在执行查询的一部分时分配，一旦该部分执行完毕，该记录将被释放。abort 和 commit 的状态处理由正常操作记录处理，其中池大小由参数 MaxNoOfConcurrentOperations 设置。

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

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

触发的最大数量

默认值为触发的最大数量是4000，这对于大多数情况已经足够。如果DBA确信集群中的并行性需求不高，可以降低该值。

当执行影响唯一哈希索引的操作时，会创建一条记录。插入或删除表中的记录，或者更新唯一哈希索引中的列，会触发插入或删除索引表中的记录。结果记录用于表示该索引表操作，直到原始操作完成。该操作非常短暂，但可能需要大量记录池来处理许多并行写操作的情况。

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

事务缓冲区内存

该参数影响的内存用于跟踪更新索引表和读取唯一索引时的操作。该内存用于存储这些操作的键和列信息。只有在非常少的情况下需要从默认值中更改该参数。

默认值为事务缓冲区内存是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）中明确设置任何上述参数时，管理节点将无法启动。

有关 NDB 集群数据节点中的资源分配，请参阅 第 25.4.3.13 节，“数据节点内存管理”。

BatchSizePerLocalScan

该参数用于计算并发扫描操作所需的锁记录数。

已弃用。

BatchSizePerLocalScan 与BatchSize在 SQL 节点中的定义存在强烈的关联。

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

设置这个参数可以直接控制 redo 日志文件的大小。这在 NDB 集群在高负载下操作时非常有用，无法快速关闭 fragment 日志文件之前尝试打开新文件（只有 2 个 fragment 日志文件可以同时打开）；增加 fragment 日志文件的大小可以给集群更多时间在尝试打开每个新 fragment 日志文件之前。

有关 fragment 日志文件的更多信息，请参阅 NoOfFragmentLogFiles 的描述。

InitialNoOfOpenFiles

这个参数设置内部线程的初始数量，以便打开文件。

默认值是 27。

InitFragmentLogFiles

默认情况下，fragment 日志文件是在数据节点的初始启动时稀疏创建的——也就是说，取决于操作系统和文件系统的类型，不是所有字节都被写入磁盘。但是，可以通过这个参数强制写入所有字节，忽略平台和文件系统类型。InitFragmentLogFiles 可以取以下两个值：

根据您的操作系统和文件系统，设置 InitFragmentLogFiles=FULL 可能有助于消除 redo 日志的 I/O 错误。

EnablePartialLcp

当 true 时，启用部分本地检查点：这意味着每个 LCP 记录仅记录完整数据库的一部分，另外记录自上一个 LCP 以来更改的行；如果没有行被更改，则 LCP 只更新 LCP 控制文件，不更新任何数据文件。

如果 EnablePartialLcp 被禁用 (false），每个 LCP 都使用单个文件并写入完整检查点；这需要最少的磁盘空间用于 LCP，但增加了每个 LCP 的写入负载。默认值为启用 (true)。partial LCP 使用的空间比例可以通过 RecoveryWork 配置参数修改。

有关完整和部分 LCP 使用的文件和目录的更多信息，请参阅 NDB 集群数据节点文件系统目录。

将该参数设置为 false 也禁用了自适应 LCP 控制机制中使用的磁盘写入速度计算。

LcpScanProgressTimeout

本地检查点碎片扫描监视器定期检查每个碎片扫描的进度，如果在给定的时间内没有进度，将关闭节点。该间隔可以使用 LcpScanProgressTimeout 数据节点配置参数设置，设置本地检查点可以被阻塞的最大时间之前监视器关闭节点。

默认值为 60 秒（与之前的版本兼容）。将该参数设置为 0 将禁用 LCP 碎片扫描监视器。

MaxNoOfOpenFiles

该参数设置了内部线程的上限，以便打开文件。任何需要更改该参数的情况都应报告为 bug。

默认值为 0。但是，该参数的最小值为 20。

MaxNoOfSavedMessages

该参数设置错误日志中的最大错误数目，以及在覆盖现有文件之前保留的跟踪文件的最大数目。跟踪文件是在节点崩溃时生成的。

默认值为 25，设置这些最大值为 25 个错误消息和 25 个跟踪文件。

MaxLCPStartDelay

在并行数据节点恢复中，只有表数据实际上是并行复制和同步的；元数据如词典和检查点信息的同步是串行进行的。此外，词典和检查点信息的恢复不能与执行本地检查点同时执行。这意味着，当同时启动或重新启动多个数据节点时，数据节点可能需要等待本地检查点的执行，这可能会导致节点恢复时间延长。

可以强制延迟本地检查点，以允许更多（可能是所有）数据节点完成元数据同步；一旦每个数据节点的元数据同步完成，所有数据节点都可以并行恢复表数据，即使本地检查点正在执行。要强制这种延迟，设置MaxLCPStartDelay，它确定集群可以等待开始本地检查点的秒数，而数据节点继续同步元数据。该参数应该在[ndbd default]部分的config.ini文件中设置，以便所有数据节点都相同。最大值为600，默认为0。

NoOfFragmentLogFiles

该参数设置节点的 REDO 日志文件数目，从而确定了 REDO 日志记录的空间分配。因为 REDO 日志文件是环形组织的，因此非常重要的是，第一个和最后一个日志文件（有时称为“头”和“尾”日志文件）不应该太接近。当它们太接近时，节点将开始中止所有包含更新的事务，因为没有足够的空间来记录新的日志记录。

一个 REDO 日志记录不会被删除，直到两个本地检查点都已完成，因为该日志记录被插入。检查点频率由其自己的配置参数确定，该参数在本章节的其他地方讨论。

默认参数值为 16，这意味着 16 个 4MB 的文件，总共 1024MB。单个日志文件的大小可以使用FragmentLogFileSize参数配置。在需要大量更新的场景中，NoOfFragmentLogFiles的值可能需要设置为 300 或更高，以提供足够的空间来记录 REDO 日志。

如果检查点速度慢，数据库写入很多，日志文件已满，日志尾部不能被截断以免危及恢复，所有更新事务将被中止，内部错误代码为 410（日志文件空间暂时不足）。这种情况将持续下去，直到检查点完成，日志尾部可以被移动。

RecoveryWork

LCP 文件的存储开销百分比。该参数只有在EnablePartialLcp为 true 时才生效，即只有在启用部分本地检查点时才生效。较高的值意味着：

较低的 RecoveryWork 值意味着：

例如，将 RecoveryWork 设置为 60 意味着 LCP 的总大小约为 1 + 0.6 = 1.6 倍于要 checkpoint 的数据大小。这意味着在恢复阶段，需要比使用完整 checkpoint 时多 60% 的工作。（这在其他阶段被补偿，以至于使用部分 LCP 的重启速度仍然比使用完整 LCP 快。）为了不填充 redo 日志，需要以 1 + (1 / RecoveryWork) 倍的速率写入数据变化率—因此，当 RecoveryWork = 60 时，需要以大约 1 + (1 / 0.6) = 2.67 倍的速率写入数据变化率。换言之，如果数据变化率为 10 MByte 每秒，那么 checkpoint 需要以大约 26.7 MByte 每秒的速率写入。

将 RecoveryWork 设置为 40 意味着只需要 1.4 倍的 LCP 大小（因此恢复阶段的时间缩短了 10% 到 15%）。在这种情况下，checkpoint 的写入速率是数据变化率的 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 的大小。您可以通过更改源代码中的 recovery_work、insert_work 和 delete_work 的值，并重新编译来改变模拟结果。有关更多信息，请参阅程序的源代码。

InsertRecoveryWork

插入行的 RecoveryWork 的百分比。较高的值增加了本地 checkpoint 期间的写入次数，并减少了 LCP 的总大小。较低的值减少了 LCP 期间的写入次数，但结果是 LCP 需要更多的空间，从而使恢复时间更长。当 EnablePartialLcp 为 true 时，这个参数才生效，也就是说，只有在启用部分本地 checkpoint 时才生效。

EnableRedoControl

启用自适应 checkpoint 速度以控制 redo 日志使用。

启用时（默认情况），EnableRedoControl 允许数据节点更灵活地控制写入 LCP 到磁盘的速率。更具体地说，启用该参数意味着数据节点可以使用更高的写入速率，以便更快地完成 LCP 并截断 redo 日志，从而减少恢复时间和磁盘空间需求。这项功能允许数据节点更好地利用现代固态存储设备和协议（如固态驱动器（SSD）使用非易失性存储器表达（NVMe））提供的更高 I/O 率和带宽。

当 NDB 部署在 I/O 或带宽受限的系统上时，例如使用传统硬盘（HDD）的系统，EnableRedoControl 机制可能会导致 I/O 子系统饱和，增加数据节点的输入和输出等待时间。特别是，这可能会导致 NDB Disk Data 表的表空间或日志文件组与数据节点 LCP 和 redo 日志文件共享受限的 I/O 子系统时出现问题，包括节点或集群故障由于 GCP 停止错误。在这种情况下，设置 EnableRedoControl 为 false 以禁用它。设置 EnablePartialLcp 为 false 也会禁用自适应计算。

MaxNoOfAttributes

该参数设置了集群中定义的最大属性数量的建议值；与 MaxNoOfTables 类似，不是硬性上限。

(在旧版本的 NDB 集群中，该参数有时被视为某些操作的硬性限制。这导致了 NDB 集群复制的问题，当时可能创建了比 MaxNoOfAttributes 更多的表，并且有时会在某些情况下导致混淆。)

默认值为 1000， 最小可能值为 32。最大值为 4294967039。每个属性在每个节点上消耗大约 200 字节的存储空间，因为所有元数据都在服务器上完全复制。

在设置 MaxNoOfAttributes 时，需要提前为将来的 ALTER TABLE 语句做好准备。这是因为在执行 ALTER TABLE 语句时，需要使用三倍于原始表的属性数量，并且是一个良好的实践是允许双倍这个数量。例如，如果 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 应用程序，可能需要或需要更改此参数。但是，对于使用 MySQL 服务器作为 SQL 节点的正常用法，不需要这样做。

默认值为 MaxNoOfSubscriptions 是 0，它被视为等于 MaxNoOfTables。每个订阅消耗 108 字节。

MaxNoOfSubscribers

只有在使用 NDB 集群复制时，这个参数才有趣。默认值为 0。它被视为 2 * MaxNoOfTables + 2 * [API 节点数]。每个订阅者使用 16 字节的内存。

在使用环形复制、多源复制和其他涉及多个 MySQL 服务器的复制设置时，您应该将其设置为参与复制的 mysqld 进程的数量（这通常，但不总是，等于集群的数量）。例如，如果您有一个环形复制设置，使用三个 NDB 集群，每个集群都有一个 mysqld 附加到每个集群，并且每个 mysqld 进程既是源又是副本，您应该将 MaxNoOfSubscribers 设置为 3 * MaxNoOfTables。

有关更多信息，请参阅 第 25.7 节，“NDB 集群复制”。

MaxNoOfConcurrentSubOperations

该参数设置了集群中所有 API 节点可以同时执行的操作数量上限。默认值（256）足以满足正常操作，可能只需要在有许多 API 节点同时执行大量操作的情况下进行调整。

CompressedLCP

将此参数设置为 1 可以使本地检查点文件被压缩。使用的压缩算法相当于 gzip --fast，可以节省 50% 或更多的数据节点存储未压缩检查点文件所需的空间。压缩 LCP 可以为单个数据节点或所有数据节点（通过在 [ndbd default] 部分的 config.ini 文件中设置此参数）启用。

默认值是 0（禁用）。

CrashOnCorruptedTuple

当启用此参数（默认情况）时，它将强制数据节点在遇到损坏的元组时关闭。

Diskless

可以将 NDB 集群表指定为 diskless，这意味着表不会被 checkpoint 到磁盘，也不会进行日志记录。这些表仅存在于主内存中。使用 diskless 表的结果是，表和表中的记录都不会在崩溃时幸存。但是，当操作在 diskless 模式下时，可以在没有磁盘的计算机上运行 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 尝试使用 O_DIRECT 写入 LCP、备份和 redo 日志，通常降低 kswapd 和 CPU 使用率。当在 Linux 上使用 NDB 集群时，如果您使用的是 2.6 或更高版本的内核，请启用 ODirect。

ODirect 默认情况下是禁用的。

ODirectSyncFlag

当启用该参数时，redo 日志写入将被执行，以便每个完成的文件系统写入都被视为对 fsync 的调用。如果至少满足以下条件之一，则忽略该参数的设置：

默认情况下禁用。

需要证书

如果该参数设置为 true，数据节点将在 TLS 搜索路径中查找密钥和有效的当前证书，并且如果找不到它们则无法启动。

需要 TLS

如果该参数设置为 true，连接到该数据节点必须使用 TLS 进行身份验证。

重启OnErrorInsert

该功能仅在调试版本中可用，用于在单个代码块的执行过程中插入错误作为测试的一部分。

该功能默认情况下是禁用的。

停止OnError

该参数指定了数据节点进程在遇到错误条件时是否应该退出或自动重启。

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

当错误发生并且 StopOnError 等于 0 时，数据节点进程将被重启。

MySQL 集群管理器用户请注意，当 StopOnError 等于 1 时，这将阻止 MySQL 集群管理器代理在重启和恢复后重启任何数据节点。请参阅 在 Linux 上启动和停止代理，以获取更多信息。

使用共享内存

启用在同一主机上运行的数据节点和 API 节点之间的共享内存连接。将其设置为 1 以启用。

WatchDog 检查间隔

为了防止主线程在某个点上陷入无限循环，一个“看门狗”线程检查主线程。这参数指定了检查之间的毫秒数。如果进程在三次检查后仍然保持相同状态，则看门狗线程将终止它。

该参数可以轻松地更改以进行实验或适应本地条件。可以在每个节点上单独指定，但似乎没有太多理由这样做。

默认超时是6000毫秒（6秒）。

观察狗检查初始间隔

这与观察狗检查间隔参数相似，除了观察狗检查初始间隔控制存储节点在早期启动阶段内存分配期间执行检查的时间间隔。

默认超时是6000毫秒（6秒）。

部分启动超时

该参数指定集群等待所有数据节点启动的时间，以避免部分集群启动。

该参数在执行集群的初始启动或初始重启时被覆盖。

默认值是30000毫秒（30秒）。 0禁用超时，在这种情况下，集群可能只有在所有节点可用时启动。

分区启动超时

如果集群在等待部分启动超时毫秒后仍然处于分区状态，集群将等待直到该超时也经过。如果分区启动超时设置为0，集群将无限期等待（2³²−1 ms，约49.71天）。

该参数在执行集群的初始启动或初始重启时被覆盖。

启动失败超时

如果数据节点在指定的时间内未完成启动序列，该节点启动将失败。将该参数设置为0（默认值）意味着不应用数据节点超时。

对于非零值，该参数以毫秒为单位。对于包含大量数据的数据节点，例如几十GB的数据，可能需要10-15分钟（即600000到1000000毫秒）来重启节点。

无节点组启动超时

当数据节点配置了Nodegroup = 65536时，被视为未分配到任何节点组。当这样做时，集群等待StartNoNodegroupTimeout毫秒，然后将这些节点视为添加到传递给--nowait-nodes选项的列表中，并启动。默认值为15000(即管理服务器等待15秒)。将该参数设置为0意味着集群无限期等待。

StartNoNodegroupTimeout必须对于集群中的所有数据节点相同；因此，您应该总是在[ndbd default]部分的config.ini文件中设置它，而不是为单个数据节点。

请参阅第 25.6.7 节，“在线添加 NDB 集群数据节点”，以获取更多信息。

HeartbeatIntervalDbDb

发现失败节点的一种主要方法是通过心跳信号的使用。该参数指定心跳信号的发送频率和接收频率。心跳信号不能被禁用。

在四个心跳间隔中未收到心跳信号后，节点将被宣布死亡。因此，通过心跳机制发现失败的最大时间是五倍的心跳间隔。

默认的心跳间隔为 5000 毫秒（5 秒）。该参数不得剧烈变化，并且不得在节点之间有很大差异。如果一个节点使用 5000 毫秒，而监视它的节点使用 1000 毫秒，那么节点将很快被宣布死亡。该参数可以在在线软件升级期间更改，但只能以小增量进行。

另请参阅网络通信和延迟，以及ConnectCheckIntervalDelay配置参数的描述。

HeartbeatIntervalDbApi

每个数据节点将心跳信号发送到每个 MySQL 服务器（SQL 节点），以确保保持联系。如果 MySQL 服务器未在时间内发送心跳信号，则将其宣布为“死亡”，在这种情况下，所有正在进行的事务将被完成，所有资源将被释放。SQL 节点无法重新连接，直到之前的 MySQL 实例启动的所有活动完成。该参数的三个心跳标准与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使心跳传输的顺序可以由用户配置。该参数的默认值为零；在所有数据节点上使用默认值将导致心跳传输的顺序由NDB确定。如果使用该参数，必须将其设置为非零值（最大65535）对于集群中的每个数据节点，并且该值必须是唯一的；这将导致心跳传输从数据节点到数据节点按照它们的HeartbeatOrder值从低到高（然后直接从具有最高HeartbeatOrder值的数据节点到具有最低值的数据节点，以完成圆圈）。这些值不需要是连续的。例如，要强制心跳传输顺序A->B->D->C->A，在之前的场景中，可以将HeartbeatOrder值设置如下：

要使用该参数更改心跳传输顺序在运行的NDB集群中，必须首先在全局配置文件（config.ini）中设置HeartbeatOrder值对于集群中的每个数据节点。要使更改生效，必须执行以下操作：

可以使用DUMP 908观察该参数在数据节点日志中的效果。

ConnectCheckIntervalDelay

该参数启用数据节点之间的连接检查，在一个数据节点失败心跳检查后5个间隔的HeartbeatIntervalDbDb毫秒内。

如果该数据节点进一步在ConnectCheckIntervalDelay毫秒内未响应，将被视为可疑，并在两个这样的间隔后被视为死亡。这在具有已知延迟问题的设置中可能很有用。

该参数的默认值为0（禁用）。

本地检查点之间的时间

该参数是一个例外，它不指定等待新本地检查点的时间，而是用于确保在更新率较低的集群中不执行本地检查点。在大多数具有高更新率的集群中，新的本地检查点将立即启动。

自上一个本地检查点开始以来执行的所有写操作的大小将被添加。该参数也异常，因为它是以 4 字节单词的基 2 对数指定的，因此默认值 20 表示 4MB（4 × 2²⁰）的写操作，21 将表示 8MB，以此类推，直到最大值 31，相当于 8GB 的写操作。

集群中的所有写操作将被添加在一起。将 本地检查点之间的时间 设置为 6 或更少意味着本地检查点将连续执行，不间断，独立于集群的工作负载。

全局检查点之间的时间

当事务提交时，它将在所有镜像数据的节点上提交到主内存中。但是，事务日志记录不会作为提交的一部分刷新到磁盘上。这种行为背后的原因是，至少在两个自治主机上安全地提交事务应该满足合理的持久性标准。

还需要确保，即使在最坏的情况下——集群完全崩溃——也能正确地处理。在这种情况下，所有在给定间隔内发生的事务将被放入全局检查点中，可以认为是一个已提交事务的集合，该集合已经刷新到磁盘上。换言之，在提交过程中，事务将被放入全局检查点组。稍后，该组的日志记录将被刷新到磁盘，然后整个事务组将被安全地提交到磁盘上所有集群计算机上。

我们建议，如果您使用固态磁盘（特别是使用 NVMe 的磁盘）和 Disk Data 表，那么您应该减少该值。在这种情况下，您还应该确保 MaxDiskDataLatency 设置为合适的级别。

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

全局检查点超时时间

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

Epoch 之间的时间

该参数定义了 NDB 集群复制的同步 epoch 之间的间隔。默认值为 100 毫秒。

Epoch 之间的时间 是 NDB 集群复制中“微型 GCP”实现的一部分，可以用来改善 NDB 集群复制的性能。

时间之间的Epoch超时

该参数定义了NDB集群复制的同步Epoch超时。如果节点在该参数确定的时间内未能参与全局检查点，则节点将被关闭。默认值为0，即超时被禁用。

时间之间的Epoch超时是NDB集群复制中“微GCP”实现的一部分，可以用于改善NDB集群复制的性能。

每当GCP保存时间超过1分钟或GCP提交时间超过10秒时，该参数的当前值和警告将被写入集群日志。

将该参数设置为零将禁用GCP停止，由于保存超时、提交超时或两者引起的停止。该参数的最大可能值为256000毫秒。

最大缓冲Epoch数

订阅节点可以落后于未处理的Epoch数。如果超过该数值，将断开订阅节点的连接。

默认值为100，足以满足大多数正常操作。如果订阅节点确实落后到断开连接，通常是由于网络或进程/线程调度问题。（在罕见的情况下，问题可能是NDB客户端中的bug。）如果Epoch较长，可能需要将该值设置得较低。

断开连接可以防止客户端问题影响数据节点服务，避免内存不足以缓冲数据，最后关闭服务。相反，只有客户端受到影响（例如二进制日志中的间隙事件），强制客户端重新连接或重新启动进程。

最大缓冲Epoch字节

该节点分配的缓冲Epoch的总字节数。

非活动事务中止检查间隔时间

超时处理通过在每个事务上检查计时器来执行，每个间隔由该参数指定。因此，如果该参数设置为1000毫秒，每个事务将每秒检查一次超时。

默认值为1000毫秒（1秒）。

事务非活动超时

该参数指定了在同一事务中允许的最大时间间隔，否则事务将被中止。

默认情况下，此参数为 4G（也是最大值）。对于需要确保事务不保持锁定的实时数据库，此参数应该设置为相对较小的值。将其设置为 0 意味着应用程序永远不会超时。单位是毫秒。

事务死锁检测超时

当节点执行事务查询时，节点等待集群中的其他节点响应，然后继续执行。这参数设置事务在数据节点内执行的时间，即事务协调器等待每个参与事务的数据节点执行请求的时间。

响应失败可能是由于以下任何原因：

这个超时参数指定事务协调器等待其他节点执行查询的时间，然后abort事务，这对于节点故障处理和死锁检测非常重要。

默认超时值为 1200 毫秒（1.2 秒）。

该参数的最小值为 50 毫秒。

磁盘同步大小

这是存储在本地检查点文件中的最大字节数，以防止写缓冲，这可能会严重影响性能。这参数 不旨在取代 TimeBetweenLocalCheckpoints。

默认值为 4M（4 兆字节）。

最大磁盘写入速度

设置本地检查点和备份操作的最大磁盘写入速度，以字节每秒为单位，当此数据节点或其他数据节点没有重启时。

要设置此数据节点重启时的最大磁盘写入速度，请使用 MaxDiskWriteSpeedOwnRestart。要设置其他数据节点重启时的最大磁盘写入速度，请使用 MaxDiskWriteSpeedOtherNodeRestart。所有 LCP 和备份操作的最小磁盘写入速度可以通过设置 MinDiskWriteSpeed 来调整。

最大磁盘写入速度（其他节点重启）

设置本地检查点和备份操作的最大磁盘写入速度，以字节每秒为单位，当一个或多个数据节点在此 NDB 集群中重启时，除了这个节点。

设置此数据节点重新启动时允许的最大磁盘写入速率，请使用 MaxDiskWriteSpeedOwnRestart。对于设置集群中没有数据节点重新启动时允许的最大磁盘写入速率，请使用 MaxDiskWriteSpeed。所有 LCP 和备份操作的最小磁盘写入速度可以通过设置 MinDiskWriteSpeed 进行调整。

MaxDiskWriteSpeedOwnRestart

设置本地检查点和备份操作在此数据节点重新启动时的最大磁盘写入速率，以字节每秒为单位。

对于设置其他数据节点重新启动时允许的最大磁盘写入速率，请使用 MaxDiskWriteSpeedOtherNodeRestart。对于设置集群中没有数据节点重新启动时允许的最大磁盘写入速率，请使用 MaxDiskWriteSpeed。所有 LCP 和备份操作的最小磁盘写入速度可以通过设置 MinDiskWriteSpeed 进行调整。

MinDiskWriteSpeed

设置本地检查点和备份操作的最小磁盘写入速率，以字节每秒为单位。

LCP 和备份操作在各种条件下的最大磁盘写入速率可以通过参数 MaxDiskWriteSpeed、MaxDiskWriteSpeedOwnRestart 和 MaxDiskWriteSpeedOtherNodeRestart 进行调整。请参阅这些参数的描述以获取更多信息。

ArbitrationTimeout

该参数指定数据节点等待仲裁器对仲裁消息的响应时间。如果超过这个时间，则认为网络已经分裂。

默认值为 7500 毫秒（7.5 秒）。

Arbitration

该 Arbitration 参数启用了仲裁方案的选择，相应于 3 个可能的值：

重新启动订阅者连接超时

该参数确定数据节点等待订阅 API 节点连接的时间。一旦该超时期限到期，任何 “缺失” API 节点将从集群断开。要禁用该超时，请将 RestartSubscriberConnectTimeout 设置为 0。

虽然该参数以毫秒为单位，但超时本身将被解析为下一个最大的整秒。

保持活动发送间隔

您可以通过设置该参数来启用和控制数据节点之间的保持活动信号的间隔。默认情况下，KeepAliveSendInterval 的值为 60000 毫秒（一分钟）；将其设置为 0 将禁用保持活动信号。值在 1 到 10 之间（包括 1 和 10）将被视为 10。

该参数可能在监控和断开空闲 TCP 连接的环境中证明有用，可能会导致集群在空闲时不必要地失败。

撤销索引缓冲区

该参数以前设置撤销索引缓冲区的大小，但是在当前版本的 NDB 集群中没有效果。

在集群配置文件中使用该参数将引发弃用警告；您应该期望它在未来 NDB 集群版本中被删除。

撤销数据缓冲区

该参数以前设置了撤销数据缓冲区的大小，但是在当前版本的 NDB 集群中没有效果。

在集群配置文件中使用该参数将引发弃用警告；您应该期望在未来 NDB 集群版本中删除该参数。

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。

日志统计级别

统计事件的报告级别，例如主键读取次数、更新次数、插入次数、缓冲区使用情况等信息。

默认级别为 0。

检查点日志级别

本地和全局检查点事件的报告级别。

默认级别为 0。

节点重启日志级别

节点重启事件的报告级别。

默认级别为 0。

连接日志级别

集群节点之间连接事件的报告级别。

默认级别为 0。

错误日志级别

集群整体错误和警告事件的报告级别。

默认级别为 0。

拥塞日志级别

拥塞事件的报告级别。

默认级别为 0。

信息日志级别

集群一般状态信息的报告级别。

默认级别为 0。

内存报告频率

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

每个数据节点的数据内存和索引内存使用情况都记录在集群日志中，以百分比和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 集群启动阶段概述”）中初始化 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

这些报告将每StartupStatusReportFrequency秒在启动阶段 4 中记录。如果StartupStatusReportFrequency为 0（默认值），那么报告将仅在 redo 日志文件初始化过程的开始和完成时写入集群日志。

DictTrace

可以使用DictTrace参数来记录创建和删除表时生成的跟踪事件。这仅供 NDB 内核代码调试使用。DictTrace采用整数值。默认值为 0，表示不记录跟踪；1 启用跟踪记录，2 启用DBDICT调试输出的记录。

WatchdogImmediateKill

您可以通过启用 WatchdogImmediateKill 数据节点配置参数来立即终止线程，以便在 watchdog 问题出现时进行调试或故障排除，以获取报告执行停止时的确切情况的跟踪文件。

BackupDataBufferSize

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

该参数的默认值为 16MB。最小值为 512K。

BackupDiskWriteSpeedPct

BackupDiskWriteSpeedPct 只适用于单线程备份；由于 NDB 8.3 支持多线程备份，因此通常不需要调整该参数，该参数在多线程情况下无效。以下讨论仅适用于单线程备份。

在正常操作期间，数据节点尝试最大化磁盘写入速度，以便在本地检查点和备份中保持在 MinDiskWriteSpeed 和 MaxDiskWriteSpeed 的限制范围内。磁盘写入限制为每个 LDM 线程分配一个相等的份额。这允许并行 LCPs 发生，而不会超过磁盘 I/O 预算。由于备份是由单个 LDM 线程执行的，因此这实际上减少了预算，导致备份完成时间延长，如果更改率足够高，可能会导致备份失败。

可以使用 BackupDiskWriteSpeedPct 配置参数来解决这个问题，该参数的值在 0-90 之间（包括），表示节点最大写入速率预算的百分比，该百分比将被保留，以便在备份过程中使用。

该参数的默认值为 50（解释为 50%）。

BackupLogBufferSize

备份日志缓冲区扮演着与备份数据缓冲区相似的角色，除了它用于生成执行备份期间的所有表写入日志。与备份数据缓冲区相同的原则适用于写入这些页面，除了当备份日志缓冲区没有更多空间时，备份将失败。因此，备份日志缓冲区的大小必须足够大以处理备份过程中的写入活动。见第 25.6.8.3 节，“配置 NDB 集群备份”。

该参数的默认值应该足够满足大多数应用程序。如果备份失败，更多的是由于磁盘写入速度不足，而不是备份日志缓冲区已满。如果磁盘子系统未配置为处理应用程序的写入负载，那么集群不太可能执行所需的操作。

更好地配置集群节点，使处理器成为瓶颈，而不是磁盘或网络连接。

该参数的默认值为 16MB。

BackupMemory

该参数已弃用，并将在未来版本的 NDB 集群中删除。对其设置的任何值都将被忽略。

BackupReportFrequency

该参数控制备份状态报告的频率，在管理客户端中，以及在集群日志中（假设集群事件日志记录已配置为允许它—见日志记录和检查点）。 BackupReportFrequency 代表备份状态报告之间的时间（以秒为单位）。

默认值为 0。

BackupWriteSize

该参数指定备份日志和备份数据缓冲区写入磁盘的默认大小。

该参数的默认值为 256KB。

BackupMaxWriteSize

该参数指定备份日志和备份数据缓冲区写入磁盘的最大大小。

该参数的默认值为 1MB。

CompressedBackup

启用此参数将导致备份文件被压缩。使用的压缩等同于 gzip --fast，可以节省50%或更多的数据节点存储未压缩备份文件所需的空间。压缩备份可以为单个数据节点或所有数据节点（通过在 [ndbd default] 部分的 config.ini 文件中设置此参数）启用。

默认值为 0（禁用）。

RequireEncryptedBackup

如果设置为 1，备份必须加密。虽然可以为每个数据节点单独设置此参数，但建议在 [ndbd default] 部分的 config.ini 全局配置文件中设置它。有关使用加密备份的更多信息，请参阅 第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”。

BackupDataBufferSize >= BackupWriteSize + 188KB

BackupLogBufferSize >= BackupWriteSize + 16KB

BackupMaxWriteSize >= BackupWriteSize

BuildIndexThreads

该参数确定在系统或节点启动时重建有序索引的线程数，以及在运行 ndb_restore --rebuild-indexes 时。

将该参数设置为 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时出现问题，因为ndbmtd在启动时分配所有内存，导致不同套接字的访问速度不同，特别是在锁定主内存页面时。

将Numa设置为 1 意味着数据节点进程使用libnuma请求交叉内存分配。（这也可以通过操作系统级别的numactl手动完成。）使用交叉分配实际上告诉数据节点进程忽略非统一内存访问，但不尝试利用快速本地内存；相反，数据节点进程尝试避免由于慢速远程内存而导致的不平衡。如果不需要交叉分配，可以将Numa设置为 0，以便在操作系统级别上确定所需的行为。

Numa配置参数仅在 Linux 系统上受支持，其中libnuma.so可用。

实时调度器

将该参数设置为 1 可以启用数据节点线程的实时调度。

默认值为 0（调度禁用）。

调度器执行计时器

该参数指定了调度器中线程执行的时间（以微秒为单位），以便将其发送出去。将其设置为 0 可以最小化响应时间；要提高吞吐量，可以增加该值，但这将延长响应时间。

默认值为 50 微秒，我们的测试表明，在高负载情况下，这可以略微提高吞吐量，而不会明显延长请求时间。

调度器响应度

设置 NDB 调度器之间的平衡，以便在速度和吞吐量之间取得平衡。该参数采用整数值，范围为 0-10， 默认值为 5。较高的值提供了更好的响应时间相对于吞吐量。较低的值提供了更高的吞吐量，但响应时间较长。

调度器自旋计时器

该参数指定了调度器中线程执行的时间（以微秒为单位），以便将其休眠。

自旋方法

该参数提供了一个简单的界面来控制数据节点上的自适应自旋，具有四个可能的值，提供了自旋参数值的预设，如下所示：

由 SpinMethod 修改的自旋参数在以下列表中描述：

在缺乏可用自旋指令的平台上，如 PowerPC 和一些 SPARC 平台，自旋时间将在所有情况下设置为 0，SpinMethod 的值除 StaticSpinning 外的所有值将被忽略。

TwoPassInitialNodeRestartCopy

可以通过将此配置参数设置为 true(默认值)来启用多线程构建有序索引，以便在初始节点重启时启用两遍复制数据。

您还必须将 BuildIndexThreads 设置为非零值。

自动线程配置

当设置为 1 时，启用自动线程配置，使用可用的 CPU 数量来配置数据节点线程，考虑到由 taskset、numactl、虚拟机、Docker 等控制应用程序可用的 CPU 的限制；否则，可以将 NumCPUs 设置为所需的 CPU 数量（最多 1024 个 CPU，可以由自动线程配置处理）。任何 ThreadConfig 和 MaxNoOfExecutionThreads 设置将被忽略。此外，启用该参数将自动禁用 ClassicFragmentation。

经典碎片化

当启用（设置为 true）时，NDB 将碎片分布在 LDM 之间，使每个节点的默认分区数等于每个数据节点的最小 LDM 线程数。

对于新集群，在首次设置集群时，将 ClassicFragmentation 设置为 false 是首选的；这样做将每个节点的分区数设置为 PartitionsPerNode 的值，确保所有分区均匀分布在所有 LDM 之间。

该参数和 AutomaticThreadConfig 是互斥的；启用 AutomaticThreadConfig 将自动禁用 ClassicFragmentation。

启用多线程备份

启用多线程备份。如果每个数据节点至少有 2 个 LDM，则所有 LDM 线程都参与备份，备份将使用每个 LDM 线程的子目录，包含 .ctl、.Data 和 .log 备份文件。

该参数通常启用（设置为 1）用于 ndbmtd。要强制单线程备份，可以使用较旧版本的 ndb_restore，请将该参数设置为 0。这必须对集群中的每个数据节点进行设置。

请参阅 第 25.6.8.5 节，“使用并行数据节点执行 NDB 备份” 和 从并行备份中恢复，以获取更多信息。

最大执行线程数

该参数直接控制ndbmtd使用的执行线程数，最高可达 72。虽然该参数设置在 [ndbd] 或 [ndbd default] 部分的 config.ini 文件中，但它专门用于 ndbmtd，不适用于 ndbd。

启用 AutomaticThreadConfig 将忽略该参数的设置。

设置 MaxNoOfExecutionThreads 将设置每种类型的线程数，如文件 storage/ndb/src/common/mt_thr_config.cpp 中的矩阵所确定的那样。下表显示了可能的 MaxNoOfExecutionThreads 值和相应的线程数。

总是有一个SUMA（复制）线程。

NoOfFragmentLogParts 应该设置为等于使用的LDM线程数目，由ndbmtd的设置确定的参数。这一比率不应该大于4:1；这种配置是明确禁止的。

LDM线程的数量也确定了未明确分区的NDB表的分区数目；这是LDM线程数目乘以集群中的数据节点数目。（如果使用ndbd而不是ndbmtd，那么总是只有一个LDM线程；在这种情况下，自动创建的分区数目只是等于数据节点的数量。请参阅第 25.2.2 节，「NDB 集群节点、节点组、碎片副本和分区」，以获取更多信息。

使用多于默认数量的LDM线程时，添加大表空间的磁盘数据表可能会导致资源和CPU使用问题，如果磁盘页缓冲区不足大；请参阅DiskPageBufferMemory配置参数的描述，以获取更多信息。

线程类型将在本节后面描述（请参阅ThreadConfig）。

将该参数设置在允许的值范围之外将导致管理服务器在启动时出现错误：Error line number: Illegal value value for parameter MaxNoOfExecutionThreads。

对于MaxNoOfExecutionThreads，值为 0 或 1 将被NDB内部设置为 2，因此 2 是该参数的默认值和最小值。

MaxNoOfExecutionThreads 通常旨在设置为可用的 CPU 线程数，并分配适合典型工作负载的线程数目。它不将特定线程分配给指定的 CPU。在需要从提供的设置中偏离或将线程绑定到 CPU 的情况下，您应该使用ThreadConfig，它允许您直接将每个线程分配给所需的类型、CPU 或两者。

多线程数据节点进程总是生成以下线程：

对于MaxNoOfExecutionThreads值为 8 或更少，TC 线程不会被创建，而是由主线程执行 TC 处理。

更改 LDM 线程的数量通常需要系统重新启动，无论是使用该参数还是 ThreadConfig，但可以使用节点初始重新启动（NI）来实现更改，前提是满足以下两个条件：

MaxSendDelay

可以使用该参数来使数据节点在将数据发送到 API 节点之前暂停一段时间；在某些情况下，如下所述，这可以导致更高的吞吐量。

MaxSendDelay 可以在许多 API 节点达到饱和点或接近饱和点时使用，这可能会导致性能的波动。这种情况下，数据节点可以快速将结果发送回 API 节点，许多小包需要处理，这可能会比处理大包慢，从而减慢 API 节点的速度；后来，数据节点开始发送更大的包。

要处理这种情况，可以将 MaxSendDelay 设置为非零值，这将确保响应不太快地发送回 API 节点。当这样做时，响应将立即发送，但是在有竞争流量时，设置 MaxSendDelay 将导致数据节点等待足够长的时间，以确保它们发送更大的包。实际上，这引入了发送过程中的人工瓶颈，从而可以显著提高吞吐量。

NoOfFragmentLogParts

设置属于该 ndbmtd 的日志文件组的数量。该参数的值应该等于 ndbmtd 使用的 LDM 线程数，如 MaxNoOfExecutionThreads 所确定的那样。禁止使用超过 4 个 redo 日志部分的配置。

请参阅 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 可以根据以下两个标准区分线程类型：

简单示例：<|start_header_id|>assistant<|end_header_id|> Please go ahead and provide the next HTML snippet for translation.

# 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 个接收线程和 1 个线程用于模式管理、异步复制和 I/O 操作。（这几乎与将 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 的设置。前两个示例展示了如何使用 cpuset 和 cpubind 定义的 CPU 集合来重叠其他（永久）线程类型：

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，因此它等同于以下设置：

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

这是分配的页面条目（页面引用）数量。它指定为 32K 页的数量，在 DiskPageBufferMemory 中。默认值足以满足大多数情况，但如果您在磁盘数据表上遇到非常大的事务问题，可能需要增加该参数的值。每个页面条目需要大约 100 字节。

DiskPageBufferMemory

这确定了磁盘上缓存页面的空间大小，以字节为单位，并在 [ndbd] 或 [ndbd default] 部分的 config.ini 文件中设置。

如果将 DiskPageBufferMemory 的值设置得太低，并且在 ThreadConfig 中使用了超过默认数量的 LDM 线程（例如 {ldm=6...}），那么在尝试将大型（例如 500G）数据文件添加到基于磁盘的 NDB 表时，可能会出现问题，进程将无限期地占用一个 CPU 核心。

这是因为，在将数据文件添加到表空间时，extent 页被锁定到内存中，以便快速访问元数据。当添加大型文件时，worker 线程没有足够的内存来存储所有数据文件的元数据。在这种情况下，您应该增加 DiskPageBufferMemory 的值，或者添加较小的表空间文件。您可能还需要调整 DiskPageBufferEntries。

您可以查询 ndbinfo.diskpagebuffer 表以确定是否应该增加该参数的值，以尽量减少不必要的磁盘寻道。请参阅 第 25.6.17.31 节，“The ndbinfo diskpagebuffer 表”，以获取更多信息。

SharedGlobalMemory

该参数确定用于日志缓冲区、磁盘操作（例如页面请求和等待队列）和表空间、日志文件组、UNDO 文件和数据文件的元数据的内存量。共享全局内存池还提供了用于满足 UNDO_BUFFER_SIZE 选项的内存要求，该选项用于 CREATE LOGFILE GROUP 和 ALTER LOGFILE GROUP 语句，包括该选项的默认值，该值由 InitialLogFileGroup 数据节点配置参数的设置所隐含。SharedGlobalMemory 可以在 [ndbd] 或 [ndbd default] 部分的 config.ini 配置文件中设置，以字节为单位。

默认值为 128M。

DiskIOThreadPool

该参数确定用于磁盘数据文件访问的未绑定线程数。在引入 DiskIOThreadPool 之前，每个磁盘数据文件都会生成一个线程，这可能会导致性能问题，特别是在使用非常大的数据文件时。使用 DiskIOThreadPool，您可以例如使用多个线程并行访问单个大型数据文件。

该参数仅适用于磁盘数据 I/O 线程。

该参数的最佳值取决于您的硬件和配置，包括以下因素：

该参数的默认值为2。

磁盘数据文件系统参数。 下面的参数列表使得可以在不使用符号链接的情况下将NDB Cluster磁盘数据文件放在特定的目录中。

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

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