NodeId

每个节点都需要唯一的标识符。数据节点使用唯一的整数地址，范围从1到144inclusive。

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

ExecuteOnComputer

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

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

HostName

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

ServerPort

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

然而，如果您需要在防火墙中打开特定的端口，以便允许数据节点和 API 节点（包括 SQL 节点）之间的通信，可以将该参数设置为所需端口的号码，在 [ndbd] 部分或（如果需要对多个数据节点进行设置）[ndbd default] 部分的 config.ini 文件中，然后打开该端口以便从 SQL 节点、API 节点或双方接收 incoming 连接。

TcpBind_INADDR_ANY

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

NodeGroup

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

NodeGroup参数主要用于在运行的 NDB 集群中添加新节点组，而无需执行rolling restart。为此，您应该将其设置为 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

该参数指定trace文件、日志文件、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中分配。同时，在有序表索引中还存在对每个副本的引用。唯一哈希索引在唯一索引列更新时才会被更新，在这种情况下，索引表中将插入新的条目，并且在提交事务时删除旧条目。因此，对于使用集群的应用程序来说，也需要分配足够的内存来处理最大的事务。在任何情况下，执行一些大事务并不能比执行许多小事务更好，因为以下原因：

默认值为DataMemory98MB。最小值为1MB。没有最大大小限制，但实际上需要根据物理RAM的可用量和操作系统可以分配给任何进程的内存量来调整这个限制。32位操作系统通常限制每个进程到2-4GB；64位操作系统可以使用更多。对于大型数据库，可能更好地使用64位操作系统以此原因。

IndexMemory

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

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

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

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

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

有序索引的统计信息（当这些被启用时）将被存储在mysql.ndb_表中。由于该表具有哈希索引，这增加了索引内存使用量。给定有序索引的行数上限可以按照以下公式计算：

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

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

在前面的公式中，key_是有序索引键的大小（以字节为单位），key_是有序索引键中的属性数目，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—that is, 25 percent of the default maximum.

在大多数情况下，缺省值应该足够，但是当您有许多NDB表（1000或更多）时，可以出现Error 773Out of string memory, please modify StringMemory config parameter: Permanent error: Schema error，在这种情况下，您应该增加该值。25(25%)不太过分，应该防止在所有情况下出现此错误。

MaxNoOfConcurrentTransactions

每个集群数据节点都需要为每个活动事务在集群中记录一个事务记录。协调事务的任务分布于所有数据节点中。集群中的总事务记录数等于任何给定节点中的事务数乘以集群中的节点数。

事务记录被分配到 individual MySQL 服务器上。每个连接到 MySQL 服务器都需要至少一个事务记录，plus 每个访问该连接的表的额外事务对象。这意味着总的事务记录数在集群中的合理最小值可以用以下公式表示：

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

假设有10个SQL节点使用集群。一个涉及10个表的连接操作需要11个事务记录；如果在一个事务中有10个这样的连接操作，那么每个MySQL服务器就需要110个事务记录，总共需要110 * 10 = 1100个事务记录。每个数据节点可以预期处理TotalNoOfConcurrentTransactions / 数据节点数量的并发事务。对于一个拥有4个数据节点的NDB集群，这意味着在每个数据节点上设置MaxNoOfConcurrentTransactions为1100 / 4 = 275。在此外，您还应该确保单个节点组可以容纳所有并发事务，即每个数据节点的MaxNoOfConcurrentTransactions足够涵盖TotalNoOfConcurrentTransactions / 节点组数量的交易。如果这个集群只有一个节点组，那么MaxNoOfConcurrentTransactions应该设置为1100（与整个集群的并发事务总数相同）。

此外，每个事务至少涉及一个操作；因此，设置MaxNoOfConcurrentTransactions的值始终不能超过MaxNoOfConcurrentOperations的值。

这个参数必须在所有集群数据节点上设置相同的值。这是因为，当一个数据节点失败时， oldest surviving node 会重新创建失败节点中所有仍在进行的事务状态。

可以使用滚动重启更改这个值，但是集群中的流量必须足够小，以便在更改期间不超过旧和新水平的交易量。

默认值为4096。

MaxNoOfConcurrentOperations

根据数据大小和事务数量调整该参数的值通常是一个好主意。对涉及少量操作和记录的事务，通常默认值足够。但是，对于涉及大量记录的事务，通常需要增加其值。

每个事务更新集群数据时都会保留记录，这些记录在事务协调器和实际更新节点中都存在。这些记录包含回滚、锁队列等目的所需的状态信息。

该参数应该设置为事务中同时更新记录的最小值，除以集群数据节点的数量。例如，在具有四个数据节点的集群中，预计可以处理一百万个并发更新事务，您应该将该值设置为1000000 / 4 = 250000。为了提供对故障的恢复能力，您应该将该参数设置为一个高 enough 的值，以便每个数据节点都可以处理其节点组的负载。换言之，您应该将该值设置为total number of concurrent operations / number of node groups。 (在只有一个节点组的情况下，这与整个集群的并发操作数相同。)

由于每个事务至少涉及到一个操作，因此MaxNoOfConcurrentOperations的值应该总是大于或等于MaxNoOfConcurrentTransactions的值。

读取查询也会创建操作记录。为了处理不完美的分布情况，每个节点中都分配了一些额外空间。

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

默认值为32768。

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

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

了解操作记录的内存需求也很重要，这些记录约占用 1KB。

MaxNoOfLocalOperations

默认情况下，这个参数被计算为1.1 × MaxNoOfConcurrentOperations。这适合有许多同时事务的系统，但这些事务都不是很大。如果需要处理一个非常大的事务，同时存在多个节点，那么可以通过明确指定这个参数来override默认值。

这个参数已被弃用，可能在未来的NDB集群版本中被删除。此外，这个参数与TransactionMemory参数不兼容；如果您尝试在集群配置文件(config.ini)中同时设置这两个参数，管理服务器将无法启动。

MaxDMLOperationsPerTransaction

节点重启：需要对集群进行滚动重启。 (NDB 8.4.0)

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

MaxNoOfConcurrentIndexOperations

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

该参数的默认值为8192。只有在极少数情况下，使用唯一哈希索引进行高并发查询时才需要增加这个值。使用较小的值是可能的，可以节省内存，如果DBA确定集群中不需要高并发查询。

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

MaxNoOfFiredTriggers

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

当对唯一哈希索引进行操作时，会创建一个记录。插入或删除表中具有唯一哈希索引的记录，或者更新包含在唯一哈希索引中的列都会在索引表中插入或删除一个记录。这个结果记录将用于表示等待原始操作完成的索引表操作。这项操作虽然短暂，但仍然可能需要大量记录在其池中，以应对具有多个并行写操作的基础表，其中包含了唯一哈希索引集。

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

TransactionBufferMemory

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

TransactionBufferMemory 的默认值为 1MB。

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

ReservedConcurrentIndexOperations

一个数据节点上同时执行的索引操作数量，拥有专用资源。

ReservedConcurrentOperations

一个数据节点上同时执行的操作数量，拥有专用资源在事务协调器中。

ReservedConcurrentScans

一个数据节点上同时进行的扫描数量，拥有专用资源。

ReservedConcurrentTransactions

一个数据节点上同时进行的事务数量，拥有专用资源。

ReservedFiredTriggers

一个 ndbd(DB) 节点上的触发器数量，拥有专门资源。

ReservedLocalScans

一个数据节点上的同时碎片扫描数量，拥有专门资源。

ReservedTransactionBufferMemory

每个数据节点分配的键和属性数据动态缓冲区空间（以字节为单位）。

TransactionMemory

这个参数确定每个数据节点上的事务内存（以字节为单位）。设置事务内存的方式如下：

TransactionMemory不兼容的参数. 以下参数不能与TransactionMemory同时使用，因此已经弃用：

在集群配置文件（config.ini）中设置了TransactionMemory时，明确地设置上述任何参数将阻止管理节点启动。

有关 NDB 集群数据节点资源分配的更多信息，请见第25.4.3.13节，“Data Node Memory Management”。

BatchSizePerLocalScan

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

已弃用。

BatchSizePerLocalScan与BatchSize在 SQL 节点中定义的相关联。

LongMessageBuffer

节点重启：需要对集群进行滚动重启。 (NDB 8.4.0)

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

这个参数很少需要从默认值中更改。

用于构建外键的最大扫描批量大小。将该参数设置的值增加可能会加速外键构建，但同时也会对 ongoing 交通产生更大的影响。

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 集群处于高负载情况下，无法快速关闭分片日志文件，而需要打开新的分片日志文件时非常有用（最多只能同时打开 2 个分片日志文件）；增加分片日志文件的大小可以给集群更多时间来打开每个新分片日志文件。该参数的默认值为 16M。

有关分片日志文件的更多信息，请参见NoOfFragmentLogFiles的描述。

InitialNoOfOpenFiles

该参数设置了对打开文件的初始内部线程数。

默认值为27。

InitFragmentLogFiles

默认情况下，当数据节点进行初始启动时，碎片日志文件将以稀疏方式创建—that is，取决于操作系统和文件系统的使用，不一定所有字节都写入磁盘。但是，可以通过该参数来override这个行为，并强制所有字节都被写入，regardless of the platform and file system type being used。InitFragmentLogFiles 可以取两个值：

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

EnablePartialLcp

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

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

关于完整和部分LCP文件和目录的更多信息，请见NDB Cluster Data Node File System Directory。

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

LcpScanProgressTimeout

本地检查点碎片扫描 watchdog 定期检查每个碎片扫描是否有进度，如果在给定的时间内没有进度，则关闭节点。这段时间可以使用LcpScanProgressTimeout数据节点配置参数设置，设置本地检查点碎片扫描 watchdog 可以等待的最大时间。

默认值为 60 秒（提供与之前版本的兼容性）。将该参数设置为 0 将禁用本地检查点碎片扫描 watchdog altogether。

MaxNoOfOpenFiles

该参数设置了为打开文件分配的内部线程的上限。任何需要更改此参数的情况都应该报告为错误。

默认值是 0。然而，这个参数可以设置的最小值是 20。

MaxNoOfSavedMessages

此参数设置错误日志中写入的最大错误数，以及在覆盖现有跟踪文件之前保留的最大跟踪文件数。当节点由于某种原因崩溃时，会生成跟踪文件。

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

MaxLCPStartDelay

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

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

NoOfFragmentLogFiles

This parameter sets the number of REDO log files for the node, and thus the amount of space allocated to REDO logging. Because the REDO log files are organized in a ring, it is extremely important that the first and last log files in the set (sometimes referred to as the “head” and “tail” log files, respectively) do not meet. When these approach one another too closely, the node begins aborting all transactions encompassing updates due to a lack of room for new log records.

直到该日志记录被插入以来，完成了两个所需的本地检查点后，该REDO日志记录才会被删除。checkpointing频率由本章其他地方讨论的配置参数确定。

默认参数值为16，这意味着默认情况下将创建16个4个16MB文件的集合，总共1024MB。使用FragmentLogFileSize参数可以配置单个日志文件的大小。在需要大量更新的情况下，可能需要将NoOfFragmentLogFiles参数设置为高达300或更高，以提供足够的REDO日志空间。

如果checkpointing速度慢，数据库写入操作非常频繁，使得日志文件满了且无法将日志尾部移动到前面，而这可能会危及恢复，这时所有更新事务都会被abort，返回内部错误代码410（Out of log file space temporarily）。这种情况直到完成一个检查点并将日志尾部移到前面为止。

RecoveryWork

LCP 文件存储空间占用百分比。这参数只有在EnablePartialLcp为 true 时才生效，即只有当局部检查点部分启用时才有效。较高的值意味着：

RecoveryWork 的较低值意味着：

例如，将RecoveryWork设置为60意味着LCP的总大小大约是数据checkpoint的大小的1+0.6=1.6倍。这意味着在恢复阶段，需要比使用完整检查点时多做60%的工作。 (这在其他restart阶段中被补偿，以至于使用部分LCP的restart总体仍然比使用完整LCP的restart快.)为了不填满redo日志，需要在checkpoint期间写入数据变化率的1+(1/RecoveryWork)倍—因此，当RecoveryWork=60时，需要写入大约2.67倍的变化率。在其他字中，如果变化率为10 MByte每秒，checkpoint需要写入大约26.7 MByte每秒。

将RecoveryWork设置为40意味着只需要LCP总大小的1.4倍（因此恢复阶段需要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（每个 LCP 包含插入、更新和删除操作），并在每个 LCP 完成后报告 LCP 的大小。你可以通过修改源代码中的recovery_work、insert_work和delete_work的值来改变模拟结果，并重新编译。更多信息，请查看程序的源代码。

InsertRecoveryWork

插入行的百分比，用于RecoveryWork。高值增加本地检查点中的写操作数，减少LCP的总大小。低值减少LCP中的写操作数，但结果是LCP占用更多空间，这意味着恢复时间更长。这参数只有在EnablePartialLcp为真时才生效，即只有当部分本地检查点启用时才有效。

EnableRedoControl

启用自适应检查点速度，以控制redo日志使用。

当启用（默认），EnableRedoControl 允许数据节点在写入LCP到磁盘时拥有更大的灵活性。具体来说，启用这个参数意味着可以使用更高的写入速度，以便更快地完成LCP和清理redo日志，从而减少恢复时间和磁盘空间需求。这项功能允许数据节点更好地利用现代固态存储设备和协议（如固态驱动器（SSDs）使用非易失性记忆体表达（NVMe））提供的更高I/O速度和更大带宽。

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

MaxNoOfAttributes

这个参数设置了集群中可以定义的建议最大属性数量；像MaxNoOfTables一样，它不是硬上限。

(在更早的 NDB 集群版本中，这个参数有时被视为某些操作的硬限制。这可能会导致 NDB 集群复制问题，当可以创建更多表时，但不能被复制，或者在某些情况下无法创建超过 MaxNoOfAttributes 属性。)

默认值为 1000，minimum 可以是 32，maximum 是 4294967039。每个属性在每个节点上占用约 200 字节的存储空间，因为所有元数据都完全复制到服务器上。

在设置MaxNoOfAttributes时，需要事先预备可能在将来执行的ALTER TABLE语句。这是因为在对Cluster表执行ALTER TABLE操作时，使用了原表的3倍属性数量，因此建议允许双倍这个数量。例如，如果NDB Cluster表具有最多属性(greatest_number_of_attributes)为100个，那么MaxNoOfAttributes的初始值可以设置为6 * greatest_number_of_attributes = 600.

您还应该估算每个表的平均属性数量，然后乘以MaxNoOfTables。如果这个值大于前面paragraph中获得的值，您应该使用较大的值。

假设您可以创建所有所需的表格无问题，您也应该验证这个数字是否足够，通过尝试实际ALTER TABLE语句后配置参数。如果这不成功，请增加MaxNoOfAttributes的值，直到可以成功测试。

MaxNoOfTables

对每个表和每个唯一哈希索引在集群中分配一个表对象。这参数设置了整个集群的建议最大表对象数目，像MaxNoOfAttributes一样，不是硬性上限。

(在较早的 NDB 集群版本中，这个参数有时被视为某些操作的硬限制，这导致了 NDB 集群复制问题，当可能创建更多表格而不能被复制时，或者在某些情况下无法创建超过MaxNoOfTables 表格时会出现混淆。)

对于每个具有BLOB数据类型的属性，-extra 表将用来存储大多数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， treated as 2 * MaxNoOfTables + 2 * [API 节点数量]。对于每两个 MySQL 服务器（一个作为 replication 源，另一个作为副本），每个表都有一个订阅，每个订阅使用 16 字节的内存。

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

更多信息，请见第 25.7 节，“NDB 集群复制”。

MaxNoOfConcurrentSubOperations

该参数设置了集群中所有 API 节点同时可以执行的操作数量上限。默认值（256）对于正常操作通常足够，可能需要在有许多 API 节点，每个节点都执行高并发操作的情况下进行调整。

CompressedLCP

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

默认值为0(禁用)。

CrashOnCorruptedTuple

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

无盘

可以将 NDB 集群表指定为无盘ndbd。

在启用该特性时，NDB 集群在线备份将被禁用。此外，集群的部分启动不可能。

Diskless 默认处于禁用状态。

EncryptedFileSystem

加密 LCP 和表空间文件，包括undo日志和redo日志。默认禁用（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尝试使用O_DIRECT写入LCP、备份和redo日志，通常降低kswapd和CPU使用率。在使用 NDB 集群时，在 Linux 上启用ODirect如果您正在使用 2.6 或更高版本的内核。

ODirect默认禁用。

ODirectSyncFlag

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

默认禁用。

RequireCertificate

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

RequireTls

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

RestartOnErrorInsert

这个功能只有在构建调试版本时可用，在测试中可以将错误插入到代码块的执行中。

这个功能默认禁用。

StopOnError

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

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

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

MySQL 集群管理器的用户应注意，在StopOnError等于1时，这会防止 MySQL 集群管理器代理在其自己的重启和恢复后重启任何数据节点。请参阅Linux 上的 Agent 启动和停止，了解更多信息。

UseShm

在该数据节点和 API 节点（运行于同一主机）之间启用共享内存连接。设置为 1 可以启用。

TimeBetweenWatchDogCheck

节点重启：需要对集群进行滚动重启。 (NDB 8.4.0)

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

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

TimeBetweenWatchDogCheckInitial

这个参数类似于TimeBetweenWatchDogCheck，except that TimeBetweenWatchDogCheckInitial控制在早期启动阶段内存分配时执行检查之间的时间间隔。

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

StartPartialTimeout

该参数指定了集群等待所有数据节点启动完成之前，初始化程序被调用所需的时间。这一超时用于尽量避免部分集群启动。

在进行初始启动或初始重启集群时，这个参数将被覆盖。

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

StartPartitionedTimeout

如果集群在等待StartPartialTimeout毫秒后仍可能处于分区状态，集群将等待这个超时期限过期。如果StartPartitionedTimeout设置为0，集群将等待不定期限（2³²−1 ms，约49.71天）。

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

StartFailureTimeout

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

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

StartNoNodeGroupTimeout

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

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

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

HeartbeatIntervalDbDb

心跳机制是发现失败节点的主要方法之一。这参数确定了心跳信号发送的频率和期望接收的心跳信号的频率。心跳信号不能被禁用。

如果连续四次心跳间隔都没有收到信号，那么该节点将被宣布死亡。因此，通过心跳机制发现故障的最大时间是五个心跳间隔的总和。

默认心跳间隔为5000毫秒（5秒）。这个参数不能大幅更改，并且在不同节点之间 shouldn't vary widely。如果一个节点使用5000毫秒，而监控它的节点使用1000毫秒，那么显然该节点很快被宣布死亡。这参数可以在在线软件升级期间更改，但只能以小步骤进行。

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

HeartbeatIntervalDbApi

每个数据节点向 MySQL 服务器（SQL 节点）发送心跳信号，以确保保持联系。如果 MySQL 服务器在规定时间内无法发送心跳信号，它将被宣布“死亡”，在这种情况下，所有正在进行的事务将被完成，并释放所有资源。 SQL 节点不能重新连接，直到前一个 MySQL 实例启动的所有活动都已完成。用于确定此判定的三个心跳标准与HeartbeatIntervalDbDb中描述的一致。

默认间隔为 1500 毫秒（1.5 秒）。这个间隔可以在个体数据节点之间发生变化，因为每个数据节点独立地监控连接到它的 MySQL 服务器。

更多信息，请见网络通信和延迟。

HeartbeatOrder

数据节点之间以环形方式发送心跳信号，每个数据节点监控前一个节点。如果某个数据节点未检测到心跳信号，它将宣布前一个数据节点“死亡”（即不再由集群可访问）。确定数据节点死亡的判定是全球性的，即一旦数据节点被宣布死亡，它将被所有集群节点视为死亡。

在不同的主机上运行的数据节点之间可能存在心跳信号传输速度太慢的问题（例如，由于heartbeat间隔太短或临时连接问题），导致数据节点被宣布死亡，即使该节点仍然可以作为集群的一部分。。

在这种情况下，心跳信号之间的顺序可能会影响某个数据节点是否被宣布死亡。如果这种宣布是非必要的，这可能会导致节点组的无谓丢失，从而导致集群失败。

考虑一个设置，其中有4个数据节点A、B、C和D运行在2个主机计算机host1和host2上，并且这些数据节点组成2个节点组，如下表所示：

假设心跳信号以顺序A->B->C->D->A发送。在这种情况下，主机之间的心跳丢失导致节点B将节点A宣布死亡，节点C将节点B宣布死亡。这 ultimately 导致 Node Group 0 失败，从而导致集群崩溃。反之，如果心跳信号顺序为 A->B->D->C->A（其他条件保持不变），那么心跳丢失将导致节点A和D被宣布死亡；在这种情况下，每个节点组都有一个存活的节点，集群可以幸免。

HeartbeatOrder 配置参数使得心跳传输顺序可由用户配置。 HeartbeatOrder 的默认值为零；在所有数据节点上使用默认值将使心跳传输顺序由 NDB 决定。如果使用了该参数，它必须在每个数据节点中设置一个非零值（最大65535），且每个数据节点的值必须唯一；这将导致心跳传输从数据节点到数据节点按照它们的 HeartbeatOrder 值从低到高进行（然后是从具有最高 HeartbeatOrder 值的数据节点到具有最低值的数据节点，完成循环）。这些值不需要连续。例如，要强制心跳传输顺序为 A->B->D->C->A，如下所示，可以将 HeartbeatOrder 值设置为以下内容：

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

两次顺序重启集群。所有节点都必须在两个顺序重启中以相同的顺序重新启动。

ConnectCheckIntervalDelay

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

在这些时间间隔内，如果数据节点继续无法响应，且在ConnectCheckIntervalDelay毫秒的时间间隔内，则该数据节点被认为是可疑的，并在两个这样的时间间隔后被认为已经死亡。这可以在存在延迟问题的设置中非常有用。

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

TimeBetweenLocalCheckpoints

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

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

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

TimeBetweenGlobalCheckpoints

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

在确保最坏的情况下（整个集群崩溃）被正确处理时，也非常重要。为了 guarantee 这种情况的发生，所有在给定时间间隔内进行的事务都将被放入全局检查点中，这可以被认为是一个已经flush到磁盘上的已提交事务集合。在其他字面上，作为 commit 过程的一部分，事务将被放入一个全局检查点组中。后来，这个组的日志记录将被flush到磁盘，然后整个组的事务将在集群中的所有计算机上安全地commit到磁盘。

当使用固态硬盘（特别是使用 NVMe 的）与 Disk Data 表时，我们建议您减少这个值。在这种情况下，您还应该确保MaxDiskDataLatency被设置为合适的级别。

这个参数定义了全局检查点之间的间隔。默认是 2000 毫秒。

TimeBetweenGlobalCheckpointsTimeout

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

TimeBetweenEpochs

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

TimeBetweenEpochs 是 NDB 集群复制实现的一部分，可以用于改进 NDB 集群复制的性能。

TimeBetweenEpochsTimeout

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

TimeBetweenEpochsTimeout 是 NDB 集群复制的实现的一部分，可以用于改进 NDB 集群复制的性能。

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

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

MaxBufferedEpochs

订阅节点可以延迟的未处理epochs数量。如果超过这个数字，会导致延迟的订阅节点被断开连接。

默认值100通常足够满足正常操作。如果订阅节点延迟到导致断开连接，这通常是由于网络或进程/线程调度问题。 (在极少数情况下，可能是NDB客户端的bug) 在epochs较长时，可能需要将值设置低于默认值。

断开连接可以防止客户端问题影响数据节点服务，避免由于缓冲数据而运行出内存，最后关闭。相反，只有客户端受到影响（例如，二进制日志中的gap事件），迫使客户端重新连接或重启进程。

MaxBufferedEpochBytes

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

TimeBetweenInactiveTransactionAbortCheck

超时处理是通过在每个事务中检查一个计时器，每隔指定的时间间隔一次进行的。因此，如果该参数设置为1000毫秒，那么每个事务将在每秒钟被检查以确定是否超时。

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

TransactionInactiveTimeout

该参数指定了在同一事务中操作之间允许的最大时间间隔，以防止事务被终止。

该参数的默认值为4G（也就是最大值）。对于需要确保事务不持锁太久的实时数据库，这个参数应该设置为一个相对较小的值。将其设置为0意味着应用程序从不超时。单位是毫秒。

TransactionDeadlockDetectionTimeout

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

无法响应可能是由于以下原因之一：

这个超时参数确定了事务协调器等待另一个节点执行查询的时间限制，直到事务被中止，并且对节点故障处理和死锁检测都非常重要。

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

这个参数的最小值是 50 毫秒.

DiskSyncSize

这是存储数据到本地检查点文件之前可以存储的最大字节数量。这是为了防止写缓冲，否则可能会严重影响性能。此参数不是TimeBetweenLocalCheckpoints的替代品。

默认值为 4M（4 megabytes）.

MaxDiskWriteSpeed

在无其他数据节点重启的情况下，设置磁盘写入的最大速率（以字节每秒为单位），由本地检查点和备份操作执行。

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

MaxDiskWriteSpeedOtherNodeRestart

在本 NDB 集群中有一个或多个数据节点正在重启（除此节点外）时，设置磁盘写入的最大速率（以字节每秒为单位），由本地检查点和备份操作执行。

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

MaxDiskWriteSpeedOwnRestart

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

为了在其他数据节点重启时设置磁盘写入的最大速率，使用MaxDiskWriteSpeedOtherNodeRestart。为了在集群中没有任何数据节点重启时设置磁盘写入的最大速率，使用MaxDiskWriteSpeed。所有LCP和备份操作的磁盘写入速度的最小值可以通过设置MinDiskWriteSpeed进行调整。

MinDiskWriteSpeed

通过设置本地检查点和备份操作的磁盘写入速率（以字节每秒为单位），将最小速度进行调整。

使用参数MaxDiskWriteSpeed、MaxDiskWriteSpeedOwnRestart和MaxDiskWriteSpeedOtherNodeRestart可以调整磁盘写入速率的最大值，用于LCPs和备份在不同情况下。请查看这些参数的描述以获取更多信息。

ArbitrationTimeout

该参数指定数据节点等待仲裁员对仲裁消息的响应时间。如果超出这个时间，网络将被假设已经分裂。

默认值为7500毫秒（7.5秒）

Arbitration

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

RestartSubscriberConnectTimeout

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

虽然这个参数指定了毫秒，但超时本身将被解析到下一个整秒。

KeepAliveSendInterval

您可以通过设置该参数来启用和控制数据节点之间的keep-alive信号间隔。KeepAliveSendInterval 的默认值为 60000 毫秒（一分钟），将其设置为 0 可以禁用keep-alive信号。1 到 10 之间的值将被视为 10。

在监控和断开闲置 TCP 连接的环境中，这个参数可能会有所帮助，防止在集群空闲时出现不必要的数据节点故障。

UndoIndexBuffer

此参数以前设置了undo索引缓冲区的大小，但在当前 NDB 集群版本中无效。

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

UndoDataBuffer

此参数以前设置了undo数据缓冲区的大小，但在当前 NDB 集群版本中无效。

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

RedoBuffer

所有更新活动也需要被记录。REDO日志使得在系统重新启动时可以回放这些更新。NDB恢复算法使用数据的“模糊”检查点 zusammen mit 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

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

每个数据节点的数据内存和索引内存使用情况都记录为百分比和 32 KB 页的 DataMemory 的数量，如 config.ini 文件中设置的那样。例如，如果 DataMemory 等于 100 MB，并且给定数据节点正在使用 50 MB 用于数据内存存储，则集群日志中的相应行可能如下所示：

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

MemReportFrequency不是必需参数。如果使用，可以在config.ini文件的[ndbd default]部分为所有集群数据节点设置，并且可以在对应的[ndbd]部分单独设置或覆盖该参数。最小值也是默认值是0，在这种情况下，内存报告将在内存使用达到某些百分比（80%、90%和100%）时被记录，如第25.6.3.2节，“NDB Cluster Log Events”中讨论的统计事件。

StartupStatusReportFrequency

当数据节点使用--initial选项启动时，它将在启动阶段4（见第25.6.4节，“NDB集群启动阶段总结”）中初始化redo日志文件。当设置了NoOfFragmentLogFiles、FragmentLogFileSize或二者很大的值，这个初始化过程可能需要很长时间。您可以通过StartupStatusReportFrequency配置参数强制在这个过程中间期望报告被记录，例如每隔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 启用 trace 日志记录；2 启用额外DBDICT调试输出。

WatchdogImmediateKill

您可以通过启用WatchdogImmediateKill数据节点配置参数，使得在 watchdog 发生问题时立即杀死线程。这一参数仅供调试或故障排除使用，以获取 trace 文件，报告执行中止的确切情况。

BackupDataBufferSize

在创建备份时，用于将数据发送到磁盘的两个缓冲区。备份数据缓冲区用于填充扫描节点表中的数据。一旦这个缓冲区被填满到指定的BackupWriteSize级别，页面将被发送到磁盘。在将数据写入磁盘时，备份过程可以继续填充这个缓冲区直到它没有空间了。当这发生时，备份过程会暂停扫描并等待一些磁盘写入完成，以释放内存以便继续扫描。

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

BackupDiskWriteSpeedPct

BackupDiskWriteSpeedPct 只在备份是单线程时生效；由于 NDB 8.4 支持多线程备份，因此通常不需要调整这个参数，因为它在多线程情况下没有影响。以下讨论เฉพาะ单线程备份。

在正常运行中，数据节点尝试最大化用于本地快照和备份的磁盘写入速度，同时保持由MinDiskWriteSpeed和MaxDiskWriteSpeed设置的边界。磁盘写入调速将每个LDM线程分配等量的总预算。这允许并行LCPs同时进行，而不超过磁盘I/O预算。由于备份由单个LDM线程执行，这实际上导致了预算削减，结果是备份完成时间延长，如果变化率足够高，还可能导致备份无法完成，当备份日志缓冲区填充率高于可达的写入速率时。

可以通过使用BackupDiskWriteSpeedPct配置参数来解决这个问题，该参数取值范围为0-90（包括），被解释为节点的最大写入速率预算中保留的百分比，用于LCPs。执行备份的LDM线程将获得整个写入速率预算加上其（减少）的写入速率预算份额用于本地快照。

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

BackupLogBufferSize

备份日志缓冲区扮演着与备份数据缓冲区相似的角色，除了用于生成在备份执行期间所有表写入的日志记录。对于写入这些页面，同样适用备份数据缓冲区的原则，只是当备份日志缓冲区没有更多空间时，备份将失败。在这种情况下，备份日志缓冲区的大小必须足够处理由写活动引起的负载。请参阅第25.6.8.3节，“NDB 集群备份配置”。

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

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

这个参数的默认值是 16MB。

BackupMemory

这个参数已经弃用，可能在未来的 NDB 集群版本中被删除。对其设置将被忽略。

BackupReportFrequency

该参数控制在备份过程中，管理客户端中备份状态报告的频率，以及将这些报告写入集群日志（假设已配置了集群事件记录—见Logging and checkpointing）。BackupReportFrequency表示备份状态报告之间的时间间隔（以秒为单位）。

默认值是0。

BackupWriteSize

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

该参数的默认值为256KB。

BackupMaxWriteSize

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

该参数的默认值为 1MB。

CompressedBackup

启用该参数将使备份文件被压缩。使用的压缩算法等同于gzip --fastconfig.ini文件的[ndbd default]部分设置该参数）。

默认值为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时，重建有序索引的线程数。它仅在每个数据节点中表的碎片数量大于1时支持（例如，在使用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

This parameter specifies the ID of the CPU assigned to handle NDBCLUSTER maintenance threads.

The value of this parameter is an integer in the range 0 to 65535 (inclusive). There is no default value.

Numa

这个参数确定了是否由操作系统或数据节点进程控制非uniform memory access（NUMA），数据节点是否使用ndbd或ndbmtd。默认情况下，NDB 尝试在任何提供NUMA支持的主机操作系统上使用交错NUMA内存分配策略。

将Numa = 0设置意味着数据节点进程不会自己尝试为内存分配设置策略，而是允许操作系统根据numactl工具的指导来确定该行为。换言之，Numa = 0将导致系统默认行为，可以通过numactl进行自定义。在许多 Linux 系统中，系统默认行为是将 socket本地内存分配给任何进程，以便在分配时。但是在使用ndbmtd时，这可能会导致问题，因为ndbmtd在启动时分配所有内存，从而导致不均衡，给不同 socket 提供不同的访问速度，特别是在锁定主内存页时。

将Numa = 1设置意味着数据节点进程使用libnuma请求交错内存分配。 (这也可以通过操作系统级别的numactl来实现。) 使用交错分配实际上告诉数据节点进程忽略非uniform 内存访问，但不尝试利用快速本地内存，而是尝试避免由于慢速远端内存导致的不均衡。如果不想使用交错分配，请将Numa设置为 0，以便在操作系统级别上确定所需行为。

只有在 Linux 系统中存在libnuma.so文件时，Numa配置参数才被支持。

RealtimeScheduler

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

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

SchedulerExecutionTimer

该参数指定了调度器在执行线程之前等待的微秒数。将其设置为0可以最小化响应时间；为了提高吞吐量，可以增加值，但这将导致更长的响应时间。

默认值为 50 微秒，我们的测试结果表明，在高负载情况下，稍微增加吞吐量不会显著延迟请求。

SchedulerResponsiveness

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

SchedulerSpinTimer

该参数指定了调度器在执行线程之前需要等待的微秒数。

SpinMethod

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

由SpinMethod修改的spin参数列表如下：

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

TwoPassInitialNodeRestartCopy

可以通过将该配置参数设置为true(默认值)来启用多线程构建有序索引的功能，以便在数据节点的初始重启时进行两次复制操作。

您还需要将BuildIndexThreads设置为非零值。

AutomaticThreadConfig

设置为1时，启用自动线程配置，使用数据节点可用的CPU数量，并考虑由taskset、numactl、虚拟机、Docker等控制哪些CPU可供给定的应用程序（在Windows平台上，自动线程配置使用所有在线的CPU）。Alternatively，您可以将NumCPUs设置为所需的CPU数量（最多1024，自动线程配置可处理的最大CPU数量）。ThreadConfig和MaxNoOfExecutionThreads的设置将被忽略。此外，启用该参数自动禁用ClassicFragmentation。

ClassicFragmentation

当设置为true时，NDB将fragments分布到LDMs中，以使每个节点的默认分区数等于每个数据节点的最小本地数据管理器(LDM)线程数。

对于新集群，设置ClassicFragmentation为false在第一次设置集群时更好一些；这样做将使每个节点的分区数等于PartitionsPerNode的值，从而确保所有分区都被均匀地分布在所有LDMs之间。

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

EnableMultithreadedBackup

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

这个参数通常在ndbmtd中启用（设置为1）。要强制单线程备份，可以使用更老版本的ndb_restore进行恢复， disable multi-threaded backup by setting this parameter to 0。需要对每个数据节点在集群中设置该参数。

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

MaxNoOfExecutionThreads

这个参数直接控制ndbmtd使用的执行线程数，直到达到最大值72。虽然这个参数在[ndbd]或[ndbd default]部分的config.ini文件中设置，但它是独特的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线程时，为 Disk Data 表空间添加大型表空间可能会导致资源和 CPU 使用率问题，如果磁盘页面缓冲区大小不足见DiskPageBufferMemory配置参数的描述，以获取更多信息。

线程类型在本节后面进行描述（见ThreadConfig）。

将该参数设置到允许的值范围外，管理服务器在启动时会_abort_WithErrorError line number: Illegal value value for parameter MaxNoOfExecutionThreads。

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

MaxNoOfExecutionThreads通常旨在设置为可用的CPU线程数，并分配每种类型的线程，以适应典型工作负载。它不将特定的线程分配到指定的CPU中。在需要从提供的设置中异步或将线程绑定到CPU时，您应该使用ThreadConfig，它允许您将每个线程直接分配给所需的类型、CPU或双方。

多线程数据节点进程总是至少.spawn_以下线程：

对于MaxNoOfExecutionThreads值为 8 或以下，无TC线程将被创建，而是由主线程执行 TC 处理。

更改 LDM 线程数量通常需要系统重启，是否使用该参数或ThreadConfig都可以，但是在满足以下两个条件的情况下，可以使用节点初始重启（NI）:

MaxSendDelay

该参数可以用于导致数据节点在发送数据到 API 节点之前暂停一会儿；在某些情况下，描述在以下段落中，这可能会导致更高的数据传输效率和总体吞吐量。

MaxSendDelay 在 API 节点饱和或接近饱和时非常有用，这可能会导致性能波动。这种情况发生在数据节点能够快速将结果返回给 API 节点，且发送许多小包，以便处理较长的字节流，从而减慢 API 节点；后来，数据节点开始发送更大的包。

为了处理这种场景，您可以将 MaxSendDelay 设置为非零值，这样可以确保响应不会立即返回给 API 节点。当没有其他竞争流量时，响应会立即发送，但当有竞争流量时，设置 MaxSendDelay 会导致数据节点等待足够长的时间，以便发送更大的包。实际上，这引入了一个人为瓶颈到发送过程中，可以实际提高吞吐量。

NoOfFragmentLogParts

设置redo日志组的数量，为ndbmtd所属的redo日志。该参数的值应该设置为ndbmtd中LDM线程的数量，根据MaxNoOfExecutionThreads的设置确定。使用超过4个redo日志部分per LDM的配置是被禁止的。

请查看MaxNoOfExecutionThreads的描述以获取更多信息。

NumCPUs

使自动线程配置使用指定数量的 CPU。无效，如果AutomaticThreadConfig未启用。

PartitionsPerNode

设置每个节点上使用的分区数，当创建新的NDB表时。这使得可以避免在数据管理器(LDMs)数量高时将表分割到过多的分区中。

虽然可以在不同的数据节点上设置不同的值，但这也没有什么好处；因此，建议简单地在全局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_ 设置和每个平台的效果. thread_ 在 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操作的线程。 (这几乎是当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上。主线程和复制线程可以重用这些CPU。

这个示例展示了如何在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的设置。第一个两个示例演示了如何使用cpuset或cpubind定义的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设置只锁定线程到8个核心编号为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，并使用isolcpus引导选项在grub.conf文件中来实现。具体信息，请参阅您的操作系统或平台文档。

DiskPageBufferEntries

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

DiskPageBufferMemory

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

如果将DiskPageBufferMemory的值设置太低，同时使用了默认数量以上的LDM线程（例如在ThreadConfig中设置为{ldm=6...}），当尝试将大型（例如500G）数据文件添加到磁盘基于的NDB表时，可能会出现问题，其中进程将长时间占用一个CPU核心。

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

您可以查询ndbinfo.diskpagebuffer表来帮助确定是否需要增加该参数的值以最小化不必要的磁盘 seeks。请参阅第25.6.17.31节，“The ndbinfo diskpagebuffer Table”，了解更多信息。

SharedGlobalMemory

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

默认值是128M。

DiskIOThreadPool

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

这个参数只适用于 Disk Data I/O 线程。

这个参数的最佳值取决于您的硬件和配置，并考虑以下因素：

该参数的默认值为 2。

Disk Data 文件系统参数 。以下参数使得可以将 NDB 集群 Disk Data 文件置于特定目录中，而无需使用符号链接。

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

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