NodeId

唯一的节点 ID 用作所有集群内部消息的节点地址。对于数据节点，这是 1 到 48（含）范围内的整数。集群中的每个节点都必须有一个唯一的标识符。

NodeId是识别数据节点时使用的唯一受支持的参数名称。（Id已在 NDB 7.5.0 中删除。）

ExecuteOnComputer

这是指Id在一个[computer] 部分中定义的其中一台计算机的集合。

HostName

指定此参数定义数据节点所在计算机的主机名。要指定 以外的主机名localhost，此参数 或ExecuteOnComputer是必需的。

ServerPort

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

但是，如果您需要能够在防火墙中打开特定端口以允许数据节点和 API 节点（包括 SQL 节点）之间的通信，则可以将此参数设置为部分中所需端口的编号 [ndbd]或（如果需要为多个数据节点执行此操作）文件的[ndbd default]部分 config.ini，然后为来自 SQL 节点、API 节点或两者的传入连接打开具有该编号的端口。

TcpBind_INADDR_ANY

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

NodeGroup

此参数可用于将数据节点分配给特定节点组。它在集群第一次启动时是只读的，不能用于在线将数据节点重新分配到不同的节点组。通常不希望在文件的[ndbd default]部分中 使用此参数config.ini，并且必须注意不要以将无效数量的节点分配给任何节点组的方式将节点分配给节点组。

该NodeGroup 参数主要用于将新节点组添加到正在运行的 NDB Cluster 而无需执行滚动重启。为此，您应该将其设置为 65536（最大值）。您不需要 NodeGroup为所有集群数据节点设置值，只需为那些稍后将作为新节点组启动并添加到集群的节点设置值。有关更多信息，请参阅 第 21.6.7.3 节，“在线添加 NDB Cluster 数据节点：详细示例”。

LocationDomainId

将数据节点分配给云中的特定 可用性域（也称为可用性区域）。通过告知NDB哪些节点位于哪些可用性域中，可以通过以下方式在云环境中提高性能：

LocationDomainId取 0 到 16 之间的整数值，默认值为 0；使用 0 与不设置参数相同。

NoOfReplicas

这个全局参数只能在[ndbd default]section中设置，定义了集群中存储的每个表的分片副本数。此参数还指定节点组的大小。节点组是一组存储相同信息的节点。

节点组是隐式形成的。第一个节点组由具有最低节点 ID 的数据节点集组成，下一个节点组由下一个最低节点身份的集合组成，依此类推。举例来说，假设我们有 4 个数据节点，并且NoOfReplicas 设置为 2。这四个数据节点的节点 ID 分别为 2、3、4 和 5。那么第一个节点组由节点 2 和 3 组成，第二个节点组节点组由节点 4 和 5 组成。以这样一种方式配置集群很重要，即同一节点组中的节点不会放置在同一台计算机上，因为单个硬件故障会导致整个集群失败。

如果未提供节点 ID，则数据节点的顺序是节点组的决定因素。无论是否进行了显式分配，都可以在管理客户端 SHOW命令的输出中查看。

默认和推荐的最大值为 NoOfReplicas2。这是大多数生产环境的推荐值。

集群中的数据节点数必须能被该参数的值整除。例如，如果有两个数据节点，则 NoOfReplicas必须等于 1 或 2，因为 2/3 和 2/4 都产生分数值；如果有四个数据节点，则 NoOfReplicas必须等于 1、2 或 4。

DataDir

该参数指定放置跟踪文件、日志文件、pid 文件和错误日志的目录。

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

FileSystemPath

此参数指定为元数据、REDO 日志、UNDO 日志（用于磁盘数据表）和数据文件创建的所有文件所在的目录。默认为 指定的目录DataDir。

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

BackupDataDir

此参数指定放置备份的目录。

DataMemory

此参数定义可用于存储数据库记录的空间量（以字节为单位）。此值指定的全部数量都分配在内存中，因此机器有足够的物理内存来容纳它非常重要。

分配的内存 DataMemory用于存储实际记录和索引。每条记录有 16 字节的开销；每条记录都会产生额外的数量，因为它存储在一个 32KB 的页面中，页面开销为 128 字节（见下文）。由于每条记录仅存储在一页中，因此每页也有少量浪费。

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

最大记录大小为 14000 字节。

在 NDB 7.5（及更早版本）中，定义的内存空间 DataMemory也用于存储有序索引，每条记录使用大约 10 个字节。每个表行都在有序索引中表示。用户的一个常见错误是假设所有索引都存储在 分配的内存中 IndexMemory，但事实并非如此：只有主键和唯一哈希索引使用这块内存；有序索引使用 分配的内存 DataMemory。但是，创建主键或唯一哈希索引也会在相同键上创建有序索引，除非您 USING HASH在索引创建语句中指定。这可以通过运行来验证ndb_desc -ddb_name table_name。

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

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

一旦分配了页面，目前无法将其返回到空闲页面池，除非删除表。（这也意味着 DataMemory页面一旦分配给给定表，就不能被其他表使用。）执行数据节点恢复也会压缩分区，因为所有记录都从其他活动节点插入到空分区中。

DataMemory 内存空间还包含 UNDO 信息：对于每次更新，都会 在DataMemory. 在有序表索引中还有对每个副本的引用。只有在更新唯一索引列时才会更新唯一哈希索引，在这种情况下，索引表中会插入一个新条目，并在提交时删除旧条目。为此，还需要分配足够的内存来处理使用集群的应用程序执行的最大事务。无论如何，由于以下原因，执行一些大交易并不比使用许多小交易有优势：

在 NDB 7.5（及更早版本）中，默认值为 DataMemory80MB；在 NDB 7.6 中，这是 98MB。最小值为 1MB。没有最大大小，但实际上必须调整最大大小，以便在达到限制时进程不会开始交换。此限制由计算机上可用的物理 RAM 量以及操作系统可以提交给任何一个进程的内存量决定。32 位操作系统通常限制为每个进程 2−4GB；64位操作系统可以使用更多。对于大型数据库，出于这个原因，最好使用 64 位操作系统。

IndexMemory

在 NDB 7.5 及更早版本中，此参数控制用于 NDB Cluster 中哈希索引的存储量。哈希索引总是用于主键索引、唯一索引和唯一约束。定义主键或唯一索引时，会创建两个索引，其中一个是哈希索引，用于所有元组访问和锁处理。该索引还用于强制执行唯一约束。

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

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

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

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

  ((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数，是基表中的行数。

假设该表有 100 万行和一个以两个四字节整数t1命名的有序索引。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 字节。

在 NDB 7.6 之前，默认值为 IndexMemory18MB，最小值为 1MB；在 NDB 7.6 中，此参数的最小值和默认值是 0（零）。这对从 NDB 7.6 降级到早期版本的 NDB Cluster 有影响；有关更多信息，请参阅 第 21.3.7 节，“升级和降级 NDB Cluster”。

StringMemory

该参数决定了为表名等字符串分配多少内存，在文件的一个 [ndbd]或[ndbd default]部分 指定config.ini。介于 0和之间的值100被解释为最大默认值的百分比，该值是根据许多因素计算得出的，包括表数、最大表名大小、最大 .FRM文件 大小MaxNoOfTriggers、最大列名大小和最大默认值列值。

大于的值100被解释为字节数。

默认值为 25，即默认最大值的 25%。

在大多数情况下，默认值应该足够了，但是当你有很多 NDB表（1000 或更多）时，可能会出现 Error 773 Out of string memory，请修改 StringMemory 配置参数： Permanent error: Schema error，在在这种情况下你应该增加这个值。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 个这样的连接，那么这个事务需要 10 * 11 = 110 个事务记录，每个 MySQL 服务器，或者总共 110 * 10 = 1100 个事务记录。可以期望每个数据节点处理 TotalNoOfConcurrentTransactions / 数据节点数。对于具有 4 个数据节点的 NDB Cluster，这意味着设置 MaxNoOfConcurrentTransactions在每个数据节点上达到 1100 / 4 = 275。此外，您应该通过确保单个节点组可以容纳所有并发事务来提供故障恢复；换句话说，每个数据节点的 MaxNoOfConcurrentTransactions 足以覆盖等于 TotalNoOfConcurrentTransactions / 节点组数的事务数。如果该集群只有一个节点组， MaxNoOfConcurrentTransactions则应设置为 1100（与整个集群的并发事务总数相同）。

此外，每笔交易至少涉及一次操作；因此，为 设置的值 MaxNoOfConcurrentTransactions应始终不超过 的值 MaxNoOfConcurrentOperations。

必须为所有集群数据节点将此参数设置为相同的值。这是因为当一个数据节点发生故障时，最老的幸存节点会重新创建故障节点中正在进行的所有事务的事务状态。

可以使用滚动重启来更改此值，但集群上的流量必须保证在发生此过程时不会发生比旧级别和新级别中较低级别更多的事务。

默认值为 4096。

MaxNoOfConcurrentOperations

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

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

此参数应至少设置为事务中同时更新的记录数除以集群数据节点数。例如，在一个有四个数据节点并且预计使用事务处理一百万个并发更新的集群中，您应该将此值设置为 1000000 / 4 = 250000。为了帮助提供对故障的弹性，建议您设置此值参数设置为足够高的值以允许单个数据节点处理其节点组的负载。换句话说，您应该将值设置为total number of concurrent operations / number of node groups. （在只有一个节点组的情况下，这与整个集群的并发操作总数相同。）

因为每笔交易总是涉及至少一个操作，所以 的值 MaxNoOfConcurrentOperations应该总是大于或等于 的值 MaxNoOfConcurrentTransactions。

读取设置锁的查询也会导致创建操作记录。在各个节点内分配了一些额外的空间，以适应节点上分布不完美的情况。

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

默认值为 32768。

该参数实际上处理两个可以单独配置的值。其中第一个指定事务协调器要放置多少操作记录。第二部分指定数据库本地有多少操作记录。

在八节点集群上执行的非常大的事务需要事务协调器中的操作记录与事务中涉及的读取、更新和删除一样多。但是， 的操作记录分布在所有八个节点上。因此，如果需要为一个非常大的事务配置系统，最​​好分别配置这两个部分。 MaxNoOfConcurrentOperations 始终用于计算节点事务协调器部分的操作记录数。

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

MaxNoOfLocalOperations

默认情况下，此参数计算为 1.1 × MaxNoOfConcurrentOperations。这适合具有许多并发事务的系统，它们都不是很大。如果需要一次处理一个非常大的事务并且有很多节点，那么通过显式指定此参数来覆盖默认值是个好主意。

MaxDMLOperationsPerTransaction

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

MaxNoOfConcurrentIndexOperations

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

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

MaxNoOfFiredTriggers

默认值为 MaxNoOfFiredTriggers 4000，这对于大多数情况来说已经足够了。在某些情况下，如果 DBA 确定集群中的并行性需求不高，甚至可以减少它。

当执行影响唯一哈希索引的操作时，将创建一条记录。在具有唯一哈希索引的表中插入或删除记录或更新属于唯一哈希索引的列会触发索引表中的插入或删除。结果记录用于表示此索引表操作，同时等待触发它的原始操作完成。此操作是短暂的，但在对包含一组唯一哈希索引的基表进行许多并行写入操作的情况下，仍可能需要其池中的大量记录。

TransactionBufferMemory

受此参数影响的内存用于跟踪更新索引表和读取唯一索引时触发的操作。该内存用于存储这些操作的键和列信息。很少需要更改此参数的默认值。

默认值为 TransactionBufferMemory 1MB。

正常的读写操作使用类似的缓冲区，其使用时间更为短暂。编译时参数 ZATTRBUF_FILESIZE（在 中找到 ndb/src/kernel/blocks/Dbtc/Dbtc.hpp）设置为 4000 × 128 字节 (500KB)。一个类似的关键信息缓冲区，ZDATABUF_FILESIZE（也在 中Dbtc.hpp）包含 4000 × 16 = 62.5KB 的缓冲区空间。Dbtc是处理事务协调的模块。

BatchSizePerLocalScan

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

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

LongMessageBuffer

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

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

MaxFKBuildBatchSize

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

MaxNoOfConcurrentScans

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

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

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

MaxNoOfLocalScans

如果许多扫描未完全并行化，则指定本地扫描记录的数量。当不提供本地扫描记录数时，计算如下：

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

最小值为 32。

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)。部分LCPS使用的空间比例可以通过 RecoveryWork 配置参数的设置来修改。

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

在 NDB 7.6.7 及更高版本中，将此参数设置为 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 日志文件是环状组织的，所以集合中的第一个和最后一个日志文件（有时分别称为“头” 和“尾”日志文件）不相遇是非常重要的。当它们彼此靠得太近时，由于没有空间容纳新日志记录，节点开始中止包含更新的所有事务。

自REDO插入该日志记录以来，在完成两个必需的本地检查点之前，不会删除该日志记录。检查点频率由本章其他地方讨论的它自己的一组配置参数决定。

默认参数值为 16，默认情况下表示 16 组 4 个 16MB 文件，总共 1024MB。各个日志文件的大小可以使用 FragmentLogFileSize 参数进行配置。在需要大量更新的场景下， NoOfFragmentLogFiles 可能需要设置高达300甚至更高的值，为REDO日志提供足够的空间。

如果检查点很慢并且有太多写入数据库的日志文件已满并且无法在不危及恢复的情况下切割日志尾部，则所有更新事务都将中止并显示内部错误代码 410 ( Out of log file space temporarily)。这种情况一直存在，直到检查点完成并且可以向前移动日志尾部。

RecoveryWork

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

较低的值RecoveryWork表示：

例如，设置RecoveryWork为 60 意味着 LCP 的总大小大约是要检查点的数据大小的 1 + 0.6 = 1.6 倍。这意味着与使用完整检查点的重启期间完成的工作相比，重启的恢复阶段需要多 60% 的工作。（这在重启的其他阶段得到了更多的补偿，因此使用部分 LCP 时整体重启仍然比使用完整 LCP 时更快。）为了不填满重做日志，有必要写在1 + (1 / RecoveryWork) 乘以检查点期间数据更改的速率——因此，当 RecoveryWork= 60，需要以大约 1 + (1 / 0.6 ) = 2.67 倍的变化率写入。换句话说，如果以每秒 10 兆字节的速度写入更改，则需要以每秒大约 26.7 兆字节的速度写入检查点。

设置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 的大小。recovery_work您可以通过在源代码中更改、 insert_work和 的值delete_work并重新编译来更改模拟 。有关详细信息，请参阅程序的源代码。

InsertRecoveryWork

RecoveryWork用于插入行 的百分比 。较高的值会增加本地检查点期间的写入次数，并减小 LCP 的总大小。较低的值会减少 LCP 期间的写入次数，但会导致更多空间用于 LCP，这意味着恢复需要更长的时间。此参数仅在 EnablePartialLcp为 true 时有效，即仅在启用部分本地检查点时有效。

EnableRedoControl

启用自适应检查点速度以控制重做日志的使用。设置为false禁用（默认）。设置 EnablePartialLcp为 false也会禁用自适应计算。

启用后，EnableRedoControl允许数据节点在将 LCP 写入磁盘的速率方面具有更大的灵活性。更具体地说，启用此参数意味着可以采用更高的写入速率，以便 LCP 可以完成并更快地修剪重做日志，从而减少恢复时间和磁盘空间要求。此功能允许数据节点更好地利用现代固态存储设备和协议提供的更高速率的 I/O 和更大的带宽，例如使用 Non-Volatile Memory Express (NVMe) 的固态驱动器 (SSD)。

该参数当前默认为false （已禁用），因为NDB相对于采用固态技术（例如使用传统硬盘 (HDD) 的系统），I/O 或带宽受限的系统仍然广泛部署。在诸如此类的设置中， EnableRedoControl机制很容易导致 I/O 子系统饱和，增加数据节点输入和输出的等待时间。特别是，这可能会导致 NDB 磁盘数据表出现问题，这些表具有与数据节点 LCP 和重做日志文件共享受限 IO 子系统的表空间或日志文件组；此类问题可能包括由于 GCP 停止错误导致的节点或集群故障。

MaxNoOfAttributes

此参数设置建议的最大属性数，可以在集群中定义；就像 MaxNoOfTables，它不打算用作硬上限。

（在较旧的 NDB Cluster 版本中，此参数有时被视为某些操作的硬限制。这导致 NDB Cluster Replication 出现问题，当可能创建的表多于可复制的表时，有时会导致混淆[或不可能，视情况而定]创建多个MaxNoOfAttributes属性。）

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

设置 时，重要的是要为将来可能要执行的MaxNoOfAttributes任何语句提前做好准备 。ALTER TABLE这是因为，在ALTER TABLECluster 表上执行期间，使用的属性数量是原始表中属性数量的 3 倍，一个好的做法是允许将此数量加倍。例如，如果具有最多属性 ( greatest_number_of_attributes) 的 NDB Cluster 表有 100 个属性，则值的一个好的起点 MaxNoOfAttributes 是。 6 * greatest_number_of_attributes = 600

您还应该估计每个表的平均属性数并将其乘以 MaxNoOfTables。如果此值大于上一段中获得的值，则应使用较大的值。

假设您可以毫无问题地创建所有需要的表，您还应该通过ALTER TABLE在配置参数后尝试实际来验证此数量是否足够。如果这不成功，再增加 MaxNoOfAttributes另一个倍数 MaxNoOfTables并再次测试。

MaxNoOfTables

为每个表和集群中的每个唯一哈希索引分配一个表对象。此参数为整个集群设置建议的最大表对象数；就像 MaxNoOfAttributes，它不打算用作硬上限。

（在较旧的 NDB Cluster 版本中，此参数有时被视为某些操作的硬限制。这导致 NDB Cluster Replication 出现问题，当可能创建的表多于可复制的表时，有时会导致混淆[或不可能，视情况而定]创建多个MaxNoOfTables表。）

对于具有 BLOB数据类型的每个属性，一个额外的表用于存储大部分 BLOB数据。在定义表的总数时，也必须考虑这些表。

该参数的默认值为 128。最小值为 8，最大值为 20320。每个表对象每个节点大约消耗 20KB。

MaxNoOfOrderedIndexes

对于集群中的每个有序索引，都会分配一个对象来描述正在索引的内容及其存储段。默认情况下，每个如此定义的索引还定义了一个有序索引。每个唯一索引和主键都有一个有序索引和一个散列索引。 MaxNoOfOrderedIndexes 设置任一时刻系统中可以使用的有序索引总数。

此参数的默认值为 128。每个索引对象每个节点消耗大约 10KB 的数据。

MaxNoOfUniqueHashIndexes

对于每个不是主键的唯一索引，都会分配一个特殊的表，将唯一键映射到索引表的主键。默认情况下，还为每个唯一索引定义了一个有序索引。为防止这种情况，您必须USING HASH在定义唯一索引时指定该选项。

默认值为 64。每个索引每个节点消耗大约 15KB。

MaxNoOfTriggers

为每个唯一的散列索引分配内部更新、插入和删除触发器。（这意味着为每个唯一的哈希索引创建了三个触发器。）但是， 有序索引只需要一个触发器对象。备份还为集群中的每个普通表使用三个触发器对象。

集群之间的复制也使用内部触发器。

该参数设置集群中触发对象的最大数量。

默认值为 768。

MaxNoOfSubscriptions

NDB Cluster 中的每个NDB表都需要在 NDB 内核中订阅。对于某些 NDB API 应用程序，可能需要或需要更改此参数。但是，对于充当 SQL 节点的 MySQL 服务器的正常使用，没有任何必要这样做。

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

MaxNoOfSubscribers

仅当使用 NDB Cluster Replication 时，此参数才有意义。默认值为 0，被视为 2 * MaxNoOfTables; 也就是说，NDB对于两个 MySQL 服务器（一个充当复制源，另一个充当副本）中的每一个，每个表都有一个订阅。每个订阅者使用 16 字节的内存。

当使用循环复制、多源复制和其他涉及超过 2 个 MySQL 服务器的复制设置时，您应该将此参数增加到复制中包含的 mysqld进程数（这通常但不总是与集群）。例如，如果您有一个使用三个 NDB Cluster 的循环复制设置， 每个 cluster 附加一个mysqld ，并且这些mysqld进程中的每一个都充当源和副本，您应该设置 MaxNoOfSubscribers 等于3 * MaxNoOfTables。

有关更多信息，请参阅 第 21.7 节，“NDB Cluster 复制”。

MaxNoOfConcurrentSubOperations

该参数设置了集群中所有 API 节点一次可以执行的操作数上限。默认值 (256) 足以满足正常操作，只有在有大量 API 节点并发执行大量操作的情况下才可能需要调整。

CompressedLCP

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

默认值为0（禁用）。

在 Windows 平台上，此参数在 NDB 7.5 或 NDB 7.6 中无效。

CrashOnCorruptedTuple

启用此参数后，它会强制数据节点在遇到损坏的元组时关闭。在 NDB 7.5 中，它默认启用。

Diskless

可以将 NDB Cluster 表指定为 diskless，这意味着表不会检查到磁盘并且不会发生日志记录。这样的表只存在于主存中。使用无盘表的结果是表和这些表中的记录都不会在崩溃后幸存下来。但是，在无盘模式下运行时，可以 在无盘计算机上 运行ndbd 。

启用此功能后，集群在线备份将被禁用。此外，集群的部分启动是不可能的。

Diskless默认情况下禁用。

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、备份和重做日志使用写入，通常会降低kswapd和 CPU 使用率。在 Linux 上使用 NDB Cluster 时， ODirect如果您使用的是 2.6 或更高版本的内核，请启用。

ODirect默认情况下禁用。

ODirectSyncFlag

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

默认情况下禁用。

RestartOnErrorInsert

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

默认情况下禁用此功能。

StopOnError

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

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

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

在 NDB Cluster 7.5.5 之前，如果数据节点进程以不受控制的方式退出（例如，由于在执行查询时对数据节点进程执行 kill -9，或由于分段错误），并且StopOnError设置为0，天使进程尝试以与之前启动完全相同的方式重新启动它，即使用上次启动节点时使用的相同启动选项。因此，如果数据节点进程最初是使用该--initial 选项启动的，它也会重新启动 --initial. 这意味着，在这种情况下，如果在很短的时间内在足够数量的数据节点上发生故障，其效果就如同您对整个集群进行了初始重启一样，导致所有数据丢失。此问题已在 NDB Cluster 7.5.5 和更高版本的 NDB 7.5 版本中得到解决（错误 #83510，错误 #24945638）。

MySQL Cluster Manager 的用户应该注意，当 StopOnError等于 1 时，这会阻止 MySQL Cluster Manager 代理在执行自己的重启和恢复后重新启动任何数据节点。有关详细信息，请参阅 在 Linux 上启动和停止代理程序。

UseShm

在这个数据节点和也在这个主机上运行的 API 节点之间使用共享内存连接。设置为 1 以启用。

有关更多信息，请参阅第 21.4.3.12 节，“NDB Cluster 共享内存连接”。

TimeBetweenWatchDogCheck

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

出于实验目的或适应当地条件，可以轻松更改此参数。它可以在每个节点的基础上指定，尽管似乎没有理由这样做。

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

TimeBetweenWatchDogCheckInitial

这类似于 TimeBetweenWatchDogCheck 参数，除了 TimeBetweenWatchDogCheckInitial 控制在分配内存的早期启动阶段存储节点内部执行检查之间经过的时间量。

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

StartPartialTimeout

此参数指定在调用集群初始化例程之前集群等待所有数据节点启动的时间。此超时用于尽可能避免部分集群启动。

在执行集群的初始启动或初始重新启动时，此参数将被覆盖。

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

StartPartitionedTimeout

如果集群在等待 StartPartialTimeout 几毫秒后准备好启动但仍可能处于分区状态，则集群会等待直到超时也过去。如果 StartPartitionedTimeout 设置为 0，集群将无限期等待（2 ³² −1 毫秒，或大约 49.71 天）。

在执行集群的初始启动或初始重新启动时，此参数将被覆盖。

NDB 7.6 中的默认值为 0；以前是 60000（60 秒）。

StartFailureTimeout

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

对于非零值，此参数以毫秒为单位进行测量。对于包含极大量数据的数据节点，应增加此参数。例如，对于包含数 GB 数据的数据节点，执行节点重启可能需要长达 10-15 分钟（即 600000 到 1000000 毫秒）的时间。

StartNoNodeGroupTimeout

当一个数据节点被配置为 时 Nodegroup = 65536，被认为没有分配给任何节点组。完成后，集群等待 StartNoNodegroupTimeout几毫秒，然后将这些节点视为已添加到传递给 --nowait-nodes选项的列表中，然后启动。默认值为15000（即管理​​服务器等待 15 秒）。将此参数设置为等于0意味着集群无限期等待。

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

有关更多信息，请参阅第 21.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 如下所示的值：

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

您可以DUMP 908在数据节点日志中观察此参数的效果。

ConnectCheckIntervalDelay

此参数启用数据节点之间的连接检查，在其中一个节点心跳检查失败达 5 个间隔（最长为 HeartbeatIntervalDbDb 毫秒）之后。

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

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

TimeBetweenLocalCheckpoints

此参数是一个例外，因为它没有指定在开始新的本地检查点之前等待的时间；相反，它用于确保本地检查点不会在更新相对较少的集群中执行。在大多数具有高更新率的集群中，很可能在前一个检查点完成后立即启动一个新的本地检查点。

添加自上一个本地检查点开始以来执行的所有写操作的大小。此参数的特殊之处还在于它被指定为 4 字节字数的以 2 为底的对数，因此默认值 20 表示 4MB (4 × 2 ²⁰ ) 的写操作，21 表示 8MB，依此类推最大值为 31，相当于 8GB 的​​写入操作。

集群中的所有写操作都加在一起。设置 TimeBetweenLocalCheckpoints 为 6 或更少意味着本地检查点连续执行而不暂停，独立于集群的工作负载。

TimeBetweenGlobalCheckpoints

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

确保即使是最坏的情况（集群完全崩溃）也能得到妥善处理也很重要。为了保证这种情况发生，在给定时间间隔内发生的所有事务都被放入一个全局检查点，可以将其视为一组已刷新到磁盘的已提交事务。换句话说，作为提交过程的一部分，事务被放置在全局检查点组中。随后，该组的日志记录被刷新到磁盘，然后整个事务组被安全地提交到集群中所有计算机上的磁盘。

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

TimeBetweenGlobalCheckpointsTimeout

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

TimeBetweenEpochs

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

TimeBetweenEpochs是“ micro-GCPs ”实现的一部分，可用于提高 NDB Cluster Replication 的性能。

TimeBetweenEpochsTimeout

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

TimeBetweenEpochsTimeout 是“ micro-GCPs ”实现的一部分，可用于提高 NDB Cluster Replication 的性能。

只要 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 Cluster 中没有重新启动（通过此数据节点或任何其他数据节点）时，通过本地检查点和备份操作设置写入磁盘的最大速率（以字节/秒为单位）。

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

MaxDiskWriteSpeedOtherNodeRestart

当此 NDB Cluster 中的一个或多个数据节点重新启动时，设置本地检查点和备份操作写入磁盘的最大速率（以字节/秒为单位），而不是此节点。

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

MaxDiskWriteSpeedOwnRestart

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

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

MinDiskWriteSpeed

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

各种条件下 LCP 和备份允许的最大磁盘写入速率可使用参数 MaxDiskWriteSpeed、 MaxDiskWriteSpeedOwnRestart和 进行调整MaxDiskWriteSpeedOtherNodeRestart。有关详细信息，请参阅这些参数的说明。

ArbitrationTimeout

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

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

Arbitration

该Arbitration 参数允许选择仲裁方案，对应于该参数的 3 个可能值之一：

RestartSubscriberConnectTimeout

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

虽然此参数以毫秒为单位指定，但超时本身会解析为下一个最大的整秒。

UndoIndexBuffer

此参数以前设置撤消索引缓冲区的大小，但在当前版本的 NDB Cluster 中没有影响。

UndoDataBuffer

此参数以前设置撤消数据缓冲区的大小，但在当前版本的 NDB Cluster 中没有影响。

RedoBuffer

还需要记录所有更新活动。REDO 日志可以在系统重新启动时重播这些更新。NDB 恢复算法使用数据的 “模糊”检查点和 UNDO 日志，然后应用 REDO 日志来回放直到恢复点的所有更改。

RedoBuffer设置写入 REDO 日志的缓冲区的大小。默认值为 32MB；最小值为 1MB。

如果这个缓冲区太小， NDB存储引擎会发出错误代码 1221（REDO 日志缓冲区过载）。RedoBuffer出于这个原因，如果您试图在集群配置中在线更改 as 的一部分时 降低值，则应该小心 。

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

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

每个数据节点的数据内存和索引内存使用情况分别记录为文件中设置 的百分比和 32 KB 页数DataMemory（NDB 7.5 及更早版本） 。例如，如果 等于 100 MB，并且给定数据节点使用 50 MB 用于数据内存存储，则集群日志中的相应行可能如下所示： IndexMemoryconfig.iniDataMemory

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

MemReportFrequency 不是必需的参数。如果使用，可以在[ndbd default] 部分为所有集群数据节点设置config.ini，也可以在配置文件的相应[ndbd]部分为单个数据节点设置或覆盖。最小值（也是默认值）为 0，在这种情况下，仅当内存使用率达到特定百分比（80%、90% 和 100%）时才会记录内存报告，如 第 1节中统计事件的讨论所述21.6.3.2，“NDB Cluster 日志事件”。

StartupStatusReportFrequency

当数据节点启动时 --initial，它会在启动阶段 4 期间初始化重做日志文件（请参阅 第 21.6.4 节，“NDB Cluster 启动阶段摘要”）。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（默认值），则仅在重做日志文件初始化过程开始和完成时将报告写入集群日志。

DictTrace

使用 . 创建和删除表生成的事件可能会导致记录跟踪 DictTrace。此参数仅在调试 NDB 内核代码时有用。DictTrace 取一个整数值。0 禁用日志记录；1 启用它；将此参数设置为 2 可启用附加 DBDICT调试输出的日志记录（缺陷号 20368450）。

WatchdogImmediateKill

WatchdogImmediateKill在 NDB 7.6.7 及更高版本中，您可以通过启用数据节点配置参数 ，在出现看门狗问题时立即终止线程 。此参数应仅在调试或故障排除时使用，以获取跟踪文件，准确报告执行停止时发生的情况。

BackupDataBufferSize

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

BackupDiskWriteSpeedPct

在正常操作期间，数据节点尝试最大化用于本地检查点和备份的磁盘写入速度，同时保持在 和 设置的范围 MinDiskWriteSpeed 内 MaxDiskWriteSpeed。磁盘写入限制为每个 LDM 线程提供了相等的总预算份额。这允许在不超过磁盘 I/O 预算的情况下进行并行 LCP。因为备份仅由一个 LDM 线程执行，这实际上导致了预算削减，导致备份完成时间更长，并且——如果变化率足够高——当备份日志缓冲区填充率是高于可实现的写入速率。

这个问题可以通过使用 BackupDiskWriteSpeedPct配置参数来解决，该参数采用 0-90（含）范围内的值，该值被解释为在共享剩余预算之前保留的节点最大写入速率预算的百分比LCP 的 LDM 线程。运行备份的 LDM 线程接收备份的整个写入速率预算，加上其（减少的）本地检查点写入速率预算的份额。（这使得磁盘写入速率预算的行为类似于它在 NDB Cluster 7.3 及更早版本中的处理方式。）

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

BackupLogBufferSize

备份日志缓冲区的作用类似于备份数据缓冲区所扮演的角色，不同之处在于它用于生成在执行备份期间进行的所有表写入的日志。与备份数据缓冲区相同的原则适用于写入这些页面，除了当备份日志缓冲区中没有更多空间时，备份失败。因此，备份日志缓冲区的大小必须足够大，以处理在进行备份时由写入活动引起的负载。请参阅 第 21.6.8.3 节，“NDB Cluster 备份的配置”。

此参数的默认值对于大多数应用程序应该足够了。事实上，磁盘写入速度不足导致备份失败的可能性比备份日志缓冲区已满的可能性更大。如果磁盘子系统没有针对应用程序引起的写入负载进行配置，则集群不太可能执行所需的操作。

最好以处理器成为瓶颈而不是磁盘或网络连接的方式配置集群节点。

此参数的默认值为 16MB。

BackupMemory

此参数已弃用，并且会在 NDB Cluster 的未来版本中删除。为它所做的任何设置都将被忽略。

BackupReportFrequency

此参数控制备份期间在管理客户端中发布备份状态报告的频率，以及将此类报告写入集群日志的频率（前提是集群事件日志记录配置为允许它 - 请参阅 日志记录和检查点）。 BackupReportFrequency 表示备份状态报告之间的时间（以秒为单位）。

默认值为 0。

BackupWriteSize

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

此参数的默认值为 256KB。

BackupMaxWriteSize

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

此参数的默认值为 1MB。

CompressedBackup

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

默认值为0（禁用）。

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 应该是 0 到 65535（含）范围内的整数。

指定的 ID 数应与 确定的执行线程数相匹配 MaxNoOfExecutionThreads。但是，无法保证在使用此参数时线程会以任何给定顺序分配给 CPU。您可以使用 获得这种类型的更细粒度的控制 ThreadConfig。

LockExecuteThreadToCPU 没有默认值。

LockMaintThreadsToCPU

此参数指定分配给处理NDBCLUSTER维护线程的 CPU 的 ID。

该参数的值是一个整数，范围是 0 到 65535（含）。没有默认值。

Numa

该参数决定了 Non-Uniform Memory Access (NUMA) 是由操作系统控制还是由数据节点进程控制，数据节点是使用 ndbd还是ndbmtd。默认情况下，NDB尝试在主机操作系统提供 NUMA 支持的任何数据节点上使用交错的 NUMA 内存分配策略。

设置Numa = 0意味着数据节点进程本身不会尝试设置内存分配策略，并允许操作系统确定此行为，这可能会由单独的numactl工具进一步指导。也就是说， Numa = 0产生系统默认行为，可以通过 numactl自定义。对于许多 Linux 系统，系统默认行为是在分配时为任何给定进程分配套接字本地内存。这在使用ndbmtd时可能会出现问题；这是因为nbdmtd在启动时分配所有内存，导致不平衡，为不同的套接字提供不同的访问速度，尤其是在主内存中锁定页面时。

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

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

RealtimeScheduler

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

默认值为 0（禁用计划）。

SchedulerExecutionTimer

此参数指定线程在发送前在调度程序中执行的时间（以微秒为单位）。将其设置为 0 可最小化响应时间；要获得更高的吞吐量，您可以以更长的响应时间为代价来增加该值。

默认值为 50 微秒，我们的测试表明它可以在高负载情况下略微提高吞吐量，而不会实质性地延迟请求。

SchedulerResponsiveness

NDB在调度程序中设置速度和吞吐量之间 的平衡。此参数采用一个整数，其值在 0-10 范围内（含 0 和 10），默认值为 5。较高的值提供相对于吞吐量的更好的响应时间。较低的值以较长的响应时间为代价提供增加的吞吐量。

SchedulerSpinTimer

此参数指定线程在休眠前在调度程序中执行的时间（以微秒为单位）。

默认值为 0。

TwoPassInitialNodeRestartCopy

通过将此配置参数设置为 ，可以为数据节点的初始重启启用有序索引的多线程构建true，这可以在初始节点重启期间启用数据的两次复制。在 NDB 7.6 中，这是默认值（Bug #26704312，Bug #27109117）。

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

MaxNoOfExecutionThreads

此参数直接控制ndbmtd 使用的执行线程数，最大为 72。虽然此参数设置在 文件[ndbd]或[ndbd default]部分中 config.ini，但它是 ndbmtd独有的，不适用于 ndbd。

SettingMaxNoOfExecutionThreads设置每种类型的线程数，由文件中的矩阵确定 storage/ndb/src/kernel/vm/mt_thr_config.cpp。下表显示了 的可能值的这些线程数MaxNoOfExecutionThreads。

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

NoOfFragmentLogParts 应设置为等于 ndbmtd使用的 LDM 线程数，由此参数的设置确定。该比例不应大于 4:1；从 NDB 7.5.7 开始，明确不允许出现这种情况的配置。（缺陷号 25333414）

LDM 线程数还决定了NDB未显式分区的表使用的分区数；这是 LDM 线程数乘以集群中的数据节点数。（如果 在数据节点上使用ndbd而不是ndbmtd，那么总是有一个 LDM 线程；在这种情况下，自动创建的分区数等于数据节点数。请参阅第 21.2.2 节，“NDB集群节点、节点组、片段副本和分区”，了解更多信息。

如果磁盘页面缓冲区不够大，则在使用超过默认数量的 LDM 线程时为磁盘数据表添加大表空间可能会导致资源和 CPU 使用问题；有关详细信息，请参阅 DiskPageBufferMemory 配置参数的说明。

线程类型将在本节后面描述（参见 参考资料 ThreadConfig）。

将此参数设置在允许的值范围之外会导致管理服务器在启动时中止并显示错误错误行 ：参数 MaxNoOfExecutionThreads 的number值非法 value。

对于MaxNoOfExecutionThreads，值 0 或 1 在内部向上舍入 NDB为 2，因此 2 被视为此参数的默认值和最小值。

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

多线程数据节点进程总是至少产生此处列出的线程：

对于MaxNoOfExecutionThreads8 或更小的值，不会创建 TC 线程，而 TC 处理将由主线程执行。

在 NDB 7.6 之前，更改 LDM 线程数总是需要重新启动系统，无论是使用此参数还是 ThreadConfig. 在 NDB 7.6 及更高版本中，如果满足以下条件 ，则可以使用节点初始重启 ( NI ) 来影响更改：

在 NDB 7.6 之前，如果集群的 IndexMemory使用率大于 50%，更改此设置需要初始重启集群。（在这种情况下，建议最多 IndexMemory使用 30-35%。）否则，节点之间的资源使用和 LDM 线程分配无法平衡，这可能导致 LDM 线程未充分利用和过度利用，并最终导致数据节点故障。在 NDB 7.6 及更高版本中，不需要初始重启来影响此参数的更改。

NoOfFragmentLogParts

设置属于此ndbmtd的重做日志的日志文件组数。此参数的值应设置为等于 ndbmtd使用的 LDM 线程数，由 的设置确定 MaxNoOfExecutionThreads。从 NDB 7.5.7 开始，不允许每个 LDM 使用超过 4 个重做日志部分的配置。（缺陷号 25333414）

有关详细信息，请参阅说明 MaxNoOfExecutionThreads 。

ThreadConfig

此参数与ndbmtd一起使用，用于将不同类型的线程分配给不同的 CPU。它的值是一个字符串，其格式具有以下语法：

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

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

type := ldm | 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

参数列表周围的大括号 ( {... }) 是必需的，即使列表中只有一个参数也是如此。

A param（参数）指定以下任何或所有信息：

不同平台的 thread_prio 设置和效果。 thread_prio Linux/FreeBSD、Solaris 和 Windows 之间 的实现不同。在下面的列表中，我们依次讨论了它对每个平台的影响：

该type属性表示 NDB 线程类型。count以下列表提供了 支持的线程类型以及每种线程类型的允许值范围：

在 NDB 7.6 之前，更改ThreadCOnfig 需要系统初始重启。在 NDB 7.6（及更高版本）中，在某些情况下可以放宽此要求：

在任何其他情况下，需要系统初始重启来更改此参数。

NDB 7.6 可以通过以下两个标准区分线程类型：

简单的例子：

# 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和 定义的 CPU 组cpubind，以及线程优先级的使用。

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。主线程和代表线程可以重用这些 CPU。

此示例显示如何ThreadConfig以及 NoOfFragmentLogParts可能为具有超线程的 24 CPU 主机设置，让 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. 其中前两个演示了为 定义的 CPU 集如何 idxbld与为其他（永久）线程类型指定的 CPU 集重叠，第一个 using cpuset和第二个 using 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 系统上，您 可以通过设置 IRQBALANCE_BANNED_CPUS到 /etc/sysconfig/irqbalance， 0xFFFFF0并使用 . 有关特定信息，请参阅您的操作系统或平台文档。 isolcpusgrub.conf

DiskPageBufferEntries

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

DiskPageBufferMemory

这决定了用于在磁盘上缓存页面的空间量，并在文件的[ndbd]或 [ndbd default]部分中 设置config.ini。它以字节为单位。每页占用 32 KB。这意味着 NDB Cluster 磁盘数据存储总是使用N* 32 KB 内存，其中N是一些非负整数。

此参数的默认值为 64M（2000 页，每页 32 KB）。

如果将 的值设置得太低，并且在（例如）DiskPageBufferMemory中使用超过默认数量的 LDM 线程 ，则在尝试将大型（例如 500G）数据文件添加到基于磁盘的表时可能会出现问题，其中该过程在占用一个 CPU 内核的情况下需要无限长的时间。 ThreadConfig{ldm=6...}NDB

这是因为，作为将数据文件添加到表空间的一部分，extent 页被锁定在额外的 PGMAN 工作线程的内存中，以便快速访问元数据。添加大文件时，此 worker 的内存不足以容纳所有数据文件元数据。在这种情况下，您应该增加DiskPageBufferMemory或添加更小的表空间文件。您可能还需要进行调整 DiskPageBufferEntries。

您可以查询该 ndbinfo.diskpagebuffer 表以帮助确定是否应增加此参数的值以最大程度地减少不必要的磁盘查找。有关更多信息，请参阅 第 21.6.15.20 节，“ndbinfo diskpagebuffer 表”。

SharedGlobalMemory

此参数确定用于日志缓冲区、磁盘操作（例如页面请求和等待队列）以及表空间、日志文件组、 UNDO文件和数据文件的元数据的内存量。共享全局内存池还提供用于满足 与 语句一起使用的UNDO_BUFFER_SIZE选项 的内存要求的内存，包括 数据节点配置参数 设置为此选项隐含的任何默认值 。可以 在 _CREATE LOGFILE GROUPALTER LOGFILE GROUPInitialLogFileGroupSharedGlobalMemory[ndbd][ndbd default]config.ini配置文件，以字节为单位。

默认值为128M。

DiskIOThreadPool

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

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

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

此参数的默认值为 2。

磁盘数据文件系统参数。  以下列表中的参数可以将 NDB Cluster 磁盘数据文件放置在特定目录中，而无需使用符号链接。

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

磁盘数据对象创建参数。  接下来的两个参数使您能够在第一次启动集群时在不使用 SQL 语句的情况下创建磁盘数据日志文件组、表空间或两者。

ExtraSendBufferMemory

TotalSendBufferMemory此参数指定除了使用、 SendBufferMemory或两者 的任何集合之外要分配的传输器发送缓冲区内存量 。

TotalSendBufferMemory

此参数用于确定要在此节点上分配的内存总量，用于所有已配置传输器之间的共享发送缓冲区内存。

如果设置了该参数，其最小允许值为256KB；0 表示该参数未设置。有关更多详细信息，请参阅 第 21.4.3.13 节，“配置 NDB Cluster 发送缓冲区参数”。

RedoOverCommitCounter

当 RedoOverCommitLimit 尝试将给定的重做日志写入磁盘多次或更多次时超过时，任何未提交的事务都将中止，并且这些事务中的任何一个的 API 节点根据它的价值 DefaultOperationRedoProblemAction （通过排队要重试的操作，或中止它们）。

RedoOverCommitLimit

此参数设置在超时前尝试将给定重做日志写入磁盘的上限（以秒为单位）。数据节点尝试刷新此重做日志但花费的时间RedoOverCommitLimit长于 RedoOverCommitCounter刷新超时被中止。发生这种情况时，发起这些事务的 API 节点会根据其 DefaultOperationRedoProblemAction 设置处理构成这些事务的操作（它要么将操作排队等待重试，要么中止它们）。

StartFailRetryDelay

使用此参数设置在启动失败事件中数据节点尝试重新启动之间的秒数。默认值为 0（无延迟）。

除非等于 0， 否则 此参数和 MaxStartFailRetries 都将被忽略 。StopOnError

MaxStartFailRetries

使用此参数可以限制数据节点在启动失败的情况下进行的重新启动尝试次数。默认值为 3 次尝试。

除非等于 0， 否则 此参数和 StartFailRetryDelay 都将被忽略 。StopOnError

IndexStatAutoCreate

创建索引时启用（设置为 1）或禁用（设置为 0）自动统计信息收集。

IndexStatAutoUpdate

启用（设置为 1）或禁用（设置为 0）索引更改监视，并在检测到这些更改时触发自动统计更新。触发更新所需的更改程度由 IndexStatTriggerPct 和 IndexStatTriggerScale 选项的设置决定。

IndexStatSaveSize

NDB 系统表和mysqld内存缓存 中任何给定索引的保存统计信息所允许的最大空间（以字节为单位） 。在 NDB 7.5 及更早版本中，这会消耗 IndexMemory.

无论大小限制如何，始终至少生产一个样品。此大小按比例缩放 IndexStatSaveScale。

对于大索引，由 指定的 IndexStatSaveSize大小乘以 0.01 的值 。IndexStatTriggerPct这进一步乘以索引大小的以 2 为底的对数。设置 IndexStatTriggerPct等于 0 将禁用缩放效果。

IndexStatSaveScale

对于大索引，由 指定的 IndexStatSaveSize大小乘以 0.01 的值 。IndexStatTriggerPct这进一步乘以索引大小的以 2 为底的对数。设置 IndexStatTriggerPct等于 0 将禁用缩放效果。

IndexStatTriggerPct

触发索引统计信息更新的更新百分比变化。该值按比例缩放 IndexStatTriggerScale。IndexStatTriggerPct您可以通过设置为 0 来 完全禁用此触发器 。

IndexStatTriggerScale

IndexStatTriggerPct 对于大型索引，按此数量乘以 0.01 进行 缩放 。值为 0 将禁用缩放。

IndexStatUpdateDelay

给定索引的自动索引统计信息更新之间的最小延迟（以秒为单位）。将此变量设置为 0 将禁用任何延迟。默认值为 60 秒。