NodeId

一个唯一的节点ID用作所有集群内部消息的节点地址。对于数据节点，取值范围为1 ~ 48(含48)。集群中的每个节点必须有唯一的标识符。

NodeId标识数据节点时使用的唯一受支持的参数名。（Id在NDB 7.5.0中被移除。)

ExecuteOnComputer

这是指Id属性中定义的计算机之一(计算机)部分。

主机名

指定此参数将定义数据节点所在计算机的主机名。指定的主机名本地主机，该参数或ExecuteOnComputer是必需的。

ServerPort

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

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

TcpBind_INADDR_ANY

将此参数设置为真正的或1结合IP_ADDR_ANY因此可以从任何地方建立连接(对于自动生成的连接)。默认为假（0)．

节点组

该参数用于将数据节点分配给指定的节点组。该参数仅在集群首次启动时生效，不能用于将数据节点在线重新分配给其他节点组。方法中使用此参数通常不可取(ndbd违约)部份config.ini文件，必须注意不要将节点分配给节点组，以免将无效数量的节点分配给任何节点组。

的节点组参数主要用于向正在运行的NDB集群中添加一个新的节点组，而无需执行滚动重启。为此，您应该将其设置为65536(最大值)。不需要设置节点组值，仅适用于稍后将启动并作为新节点组添加到集群的那些节点。有关更多信息，请参见21.5.7.3节“在线添加NDB集群数据节点详细示例”．

LocationDomainId

将数据节点分配给特定对象可用性域(也称为可用性区域)。的通知NDB在云环境中，哪些节点在哪些可用性域中，可以通过以下方式提高性能:

LocationDomainId接受0到16之间的整数值，其中0为默认值;使用0等同于不设置参数。

NoOfReplicas

该全局参数只能在(ndbd违约)节，并定义存储在集群中的每个表的片段副本的数量。该参数还用于指定节点组的大小。节点组是一组存储相同信息的节点。

节点组是隐式形成的。第一个节点组由具有最低节点id的数据节点集组成，下一个节点组由下一个最低节点标识集组成，依此类推。举个例子，假设我们有4个数据节点NoOfReplicas设置为2。4个数据节点编号分别为2、3、4、5。第一个节点组由节点2和节点3组成，第二个节点组由节点4和节点5组成。重要的是，配置集群时不要将相同节点组中的节点放在同一台计算机上，因为单个硬件故障将导致整个集群故障。

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

的默认和建议最大值NoOfReplicas是2。这是大多数生产环境的推荐值．

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

DataDir

该参数指定跟踪文件、日志文件、pid文件和错误日志的存放路径。

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

FileSystemPath

该参数指定存放为元数据、REDO日志、UNDO日志(磁盘数据表)和数据文件创建的所有文件的目录。默认为指定的目录DataDir．

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

BackupDataDir

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

DataMemory

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

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

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

最大记录大小为14000字节。

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

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

目前，NDB集群每个分区最多可以使用512 MB的哈希索引，这意味着在某些情况下可以获得桌子满了MySQL客户端应用程序的错误ndb_mgm -e "所有报告内存使用情况"显示出明显的自由DataMemory．这还可能导致数据节点在数据负载过重的节点上重新启动的问题。

在NDB 7.5.4及以后版本中，您可以通过设置NDB_TABLE选项PARTITION_BALANCE到其中一个值FOR_RA_BY_LDM，FOR_RA_BY_LDM_X_2，FOR_RA_BY_LDM_X_3,或FOR_RA_BY_LDM_X_4，在创建表时，为每个LDM分别配置1、2、3或4个分区(请参见章节13.1.18.9，设置NDB_TABLE选项)．

你也可以使用MinFreePct配置参数，以帮助避免节点重启问题。

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

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

的DataMemory内存空间还包含UNDO信息:对于每次更新，未更改记录的副本分配在DataMemory．在已排序的表索引中还有对每个副本的引用。唯一哈希索引只有在唯一索引列更新时才会更新，在这种情况下，索引表中的新条目将被插入，旧条目将在提交时删除。因此，还需要分配足够的内存来处理使用集群的应用程序执行的最大事务。在任何情况下，执行几个大型事务并不比使用许多小型事务有优势，原因如下:

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

IndexMemory

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

从NDB 7.6.2开始，IndexMemory参数已弃用(并将在将来删除);分配给的任何内存IndexMemory而是分配到与DataMemory，它完全负责在内存中存储数据和索引所需的所有资源。在NDB 7.6.2及以后版本中，使用IndexMemory在集群配置文件中触发来自管理服务器的警告。

你可以用下面的公式来估计哈希索引的大小:

大小= (片段* 32k) + (行* 18)) *fragment_replicas

片段是片段的数量，fragment_replicas片段副本的数量(通常是两个)，和行是行数。如果一个表有一百万行，八个片段和两个片段副本，预期的索引内存使用计算如下所示:

((8 * 32K) +(1000000 * 18)) * 2 =((8 * 32768) +(1000000 * 18)) * 2 =(262144 + 18000000) * 2 = 18262144 * 2 = 36524288字节= ~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是编号ot属性在有序索引键，和行基表中的行数。

假设这张表t1有100万行和一个有序索引命名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.2之前，默认值为IndexMemory为18MB，最低为1mb;在NDB 7.6.2及以后版本中，该参数的最小值和默认值为0(零)。这意味着从NDB 7.6到更早版本的NDB集群的降级;看到21.2.7节“升级和降级新db集群”，以获取更多资料。

StringMemory

此参数确定为字符串(如表名)分配多少内存，并在(ndbd)或(ndbd违约)部份config.ini文件。值为0而且One hundred.包含被解释为最大默认值的百分比，该百分比是根据许多因素计算的，包括表的数量、表名的最大大小、的最大大小.FRM文件,MaxNoOfTriggers、最大列名大小和最大默认列值。

值大于One hundred.解释为字节数。

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

在大多数情况下，默认值应该是足够的，但当您有很多NDB表(1000或更多)，有可能得到错误773string内存不足，请修改StringMemory配置参数:永久错误:模式错误，在这种情况下，您应该增加该值。25(25%)并不过分，应该可以防止这种错误在除最极端条件外的所有情况下再次发生。

MaxNoOfConcurrentTransactions

每个集群数据节点都需要集群中每个活动事务的事务记录。协调事务的任务分布在所有数据节点之间。集群中的事务记录总数是任意给定节点中的事务数量乘以集群中的节点数量。

事务记录被分配给单独的MySQL服务器。到MySQL服务器的每个连接至少需要一个事务记录，以及由该连接访问的每个表一个额外的事务对象。这意味着集群中事务总数的合理最小值可以表示为

TotalNoOfConcurrentTransactions =(在任何单个事务中访问的最大表数+ 1)* SQL节点数

假设有10个SQL节点使用集群。涉及10个表的单个连接需要11个事务记录;如果一个事务中有10个这样的连接，那么每个MySQL服务器需要10 * 11 = 110个事务记录，或者110 * 10 = 1100个事务记录。每个数据节点都可以处理TotalNoOfConcurrentTransactions /数据节点数量。对于一个有4个数据节点的NDB集群，这意味着设置MaxNoOfConcurrentTransactions在每个数据节点上到1100 / 4 = 275。此外，您应该通过确保单个节点组可以容纳所有并发事务来提供故障恢复;换句话说，每个数据节点的MaxNoOfConcurrentTransactions足以覆盖等于TotalNoOfConcurrentTransactions /节点组数量的事务数量。如果此集群具有单个节点组，则MaxNoOfConcurrentTransactions应该设置为1100(与整个集群的并发事务总数相同)。

此外，每个事务至少涉及一个操作;因此，为设置的值MaxNoOfConcurrentTransactions应该永远不超过的价值MaxNoOfConcurrentOperations．

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

可以使用滚动重新启动来更改这个值，但是集群上的通信量必须保证在此期间发生的事务不超过新旧级别中的较低级别。

缺省值为4096。

MaxNoOfConcurrentOperations

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

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

此参数应设置为事务中要同时更新的记录数量，除以集群数据节点的数量。例如，在一个有4个数据节点的集群中，预计将使用事务处理100万个并发更新，您应该将这个值设置为1000000 / 4 = 250000。为了帮助提供针对故障的弹性，建议您将此参数设置为一个足够高的值，以允许单个数据节点处理其节点组的负载。换句话说，您应该将值设置为并发操作总数/节点组数．(如果是单节点组，则与整个集群的并发操作总数相同。)

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

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

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

缺省值为32768。

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

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

了解操作记录的内存需求也很重要。每条记录占用大约1KB。

MaxNoOfLocalOperations

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

MaxDMLOperationsPerTransaction

此参数限制事务的大小。如果事务需要的DML操作超过这个数，事务就会中止。每个事务的最小操作数为32;但是，您可以设置MaxDMLOperationsPerTransaction到0以禁用对每个事务的DML操作数量的任何限制。最大值(和默认值)是4294967295。

MaxNoOfConcurrentIndexOperations

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

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

MaxNoOfFiredTriggers

的默认值MaxNoOfFiredTriggers为4000，这对于大多数情况都是足够的。在某些情况下，如果DBA确信集群对并行性的需求不高，甚至可以减少并行性。

当执行影响唯一哈希索引的操作时，将创建一条记录。在具有唯一哈希索引的表中插入或删除记录，或更新作为唯一哈希索引一部分的列，将触发索引表中的插入或删除操作。生成的记录用于表示该索引表操作，同时等待触发该操作的原始操作完成。此操作的寿命很短，但对于包含一组惟一哈希索引的基表上有许多并行写操作的情况，它的池中仍然需要大量记录。

TransactionBufferMemory

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

的默认值TransactionBufferMemory是1 mb。

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

BatchSizePerLocalScan

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

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

LongMessageBuffer

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

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

MaxFKBuildBatchSize

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

NDB 7.6.4新增

MaxNoOfConcurrentScans

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

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

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

MaxNoOfLocalScans

如果许多扫描没有完全并行，则指定本地扫描记录的数量。当不提供本地扫描记录数时，计算方法如下所示:

4 * MaxNoOfConcurrentScans *[#数据节点]+ 2

最小值为32。

MaxParallelCopyInstances

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

MaxParallelScansPerFragment

可以配置并行扫描的最大数量(锤头扫描和晚礼服在开始排队进行串行处理之前，允许扫描)。在并行执行大量扫描时，您可以增加这个值，以利用任何未使用的CPU，并提高其性能。

MaxReorgBuildBatchSize

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

NDB 7.6.4新增

MaxUIBuildBatchSize

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

NDB 7.6.4新增

FragmentLogFileSize

设置此参数可以直接控制重做日志文件的大小。这在NDB集群在高负载下运行时非常有用，并且在尝试打开新的片段日志文件之前无法足够快地关闭片段日志文件(一次只能打开2个片段日志文件);增加片段日志文件的大小可以让集群在不得不打开每个新的片段日志文件之前有更多的时间。默认值为16M。

有关片段日志文件的详细信息，请参见NoOfFragmentLogFiles．

InitialNoOfOpenFiles

此参数设置为打开的文件分配的初始内部线程数。

缺省值为27。

InitFragmentLogFiles

默认情况下，在执行数据节点的初始启动时，片段日志文件是稀疏地创建的——也就是说，根据所使用的操作系统和文件系统，并不是所有字节都必须写入磁盘。但是，可以通过此参数重写此行为并强制写入所有字节，而不管所使用的平台和文件系统类型是什么。InitFragmentLogFiles取两个值中的任意一个:

根据您的操作系统和文件系统，设置InitFragmentLogFiles =全可以帮助消除写入REDO日志时的I/O错误。

EnablePartialLcp

当真正的，启用局部本地检查点:这意味着每个LCP只记录整个数据库的一部分，加上自上一个LCP以来更改的任何记录;如果没有行更改，则LCP只更新LCP控制文件，不更新任何数据文件。

如果EnablePartialLcp已禁用(假)，每个LCP只使用一个文件，并写一个完整的检查点;这对LCP需要最少的磁盘空间，但增加了每个LCP的写负载。默认值为enabled (真正的)．的设置可以修改部分LCPS使用的空间比例RecoveryWork配置参数。

有关用于完整和部分lcp的文件和目录的详细信息，请参见集群数据节点文件系统目录．

在NDB 7.6.7及以后版本中将此参数设置为假也禁止自适应LCP控制机制使用的磁盘写速度的计算。

LcpScanProgressTimeout

本地检查点片段扫描看门狗定期检查作为本地检查点的一部分执行的每个片段扫描是否没有进展，如果在给定的时间过去后没有进展，则关闭节点。方法设置此间隔LcpScanProgressTimeoutdata节点配置参数，用于设置LCP分片扫描看门狗关闭节点前本地检查点暂停的最长时间。

默认值是60秒(提供与以前版本的兼容性)。将该参数设置为0时，禁用LCP分片扫描看门狗。

MaxNoOfOpenFiles

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

缺省值为0。但是，该参数可以设置的最小值为20。

MaxNoOfSavedMessages

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

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

MaxLCPStartDelay

在并行数据节点恢复中，实际上只有表数据被并行复制和同步;元数据(如字典和检查点信息)的同步是以串行方式完成的。此外，字典和检查点信息的恢复不能与本地检查点的执行同时进行。这意味着，当并发地启动或重新启动多个数据节点时，数据节点可能被迫在执行本地检查点时等待，这可能导致更长的节点恢复时间。

可以在本地检查点强制延迟以允许更多(可能是所有)数据节点完成元数据同步;一旦每个数据节点的元数据同步完成，所有数据节点都可以并行地恢复表数据，甚至在执行本地检查点时也是如此。要强制这样的延迟，请设置MaxLCPStartDelay，它决定了在数据节点继续同步元数据时，集群可以等待启动本地检查点的秒数。该参数需要在(ndbd违约)部份config.ini文件，以便对所有数据节点都是相同的。最大值为600;默认值为0。

NoOfFragmentLogFiles

该参数设置节点的REDO日志文件数量，以及分配给REDO日志的空间大小。因为REDO日志文件是在一个环中组织的，所以集合中的第一个和最后一个日志文件(有时称为”头”而且”尾巴”日志文件)不满足。当它们彼此过于接近时，节点开始中止包含更新的所有事务，因为没有空间容纳新的日志记录。

一个重做插入日志记录后，直到两个必需的本地检查点都已完成，才会删除日志记录。检查点的频率由它自己的配置参数集决定，在本章的其他地方讨论过。

默认值为16，默认为16组4个16MB的文件，总容量为1024MB。属性可配置各个日志文件的大小FragmentLogFileSize参数。在需要大量更新的场景中，为的值NoOfFragmentLogFiles可能需要设置为300甚至更高，以便为REDO日志提供足够的空间。

如果检查点很慢，并且对数据库的写操作太多，导致日志文件已满，并且不能在不危及恢复的情况下切断日志尾，则所有更新事务都会中止，并使用内部错误代码410 (日志文件空间暂时不足)．这种情况一直存在，直到检查点完成，日志尾可以向前移动。

RecoveryWork

LCP文件存储开销的百分比。该参数仅当EnablePartialLcp仅在启用部分本地检查点时为true。较高的值意味着:

的较低值RecoveryWork意思是:

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

设置RecoveryWork= 40意味着只需要总LCP大小的1.4倍(因此恢复阶段所需的时间减少了10%到15%。在本例中，检查点写速率是变更速率的3.5倍。

NDB源代码发行版包括一个模拟lcp的测试程序。lcp_simulator.cc可在存储/ ndb / src /内核/块/备份/．要在Unix平台上编译并运行它，执行下面所示的命令:

Shell > GCC lcp_simulator。Cc shell> ./ a.b 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

启用自适应检查点速度来控制重做日志的使用。设置为假禁用(默认值)。设置EnablePartialLcp来假同时禁用自适应计算。

当启用时,EnableRedoControl允许数据节点在将lcp写入磁盘的速率方面具有更大的灵活性。更具体地说，启用该参数意味着可以使用更高的写速率，以便更快地完成lcp并修整Redo日志，从而减少恢复时间和磁盘空间需求。该功能允许数据节点更好地利用现代固态存储设备和协议提供的更高的I/O速率和更大的带宽，例如使用非易失性内存快速(NVMe)的固态硬盘(ssd)。

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

MaxNoOfAttributes

该参数设置可以在集群中定义的属性的建议最大数量;就像MaxNoOfTables，它不打算作为一个硬上限。

(在旧的NDB集群版本中，该参数有时被视为某些操作的硬限制。这导致了NDB集群复制的问题，当创建的表可能比复制的表多时，有时会导致混乱，当创建的表可能[或不可能，取决于情况]超过时MaxNoOfAttributes属性)。

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

当设置MaxNoOfAttributes因此，提前做好任何准备都是很重要的ALTER TABLE将来可能要执行的语句。这是由于事实，在执行过程中ALTER TABLE在Cluster表上，使用的属性数量是原始表的3倍，一个良好的实践是允许这个数量的两倍。例如，如果NDB集群表拥有最多数量的属性(greatest_number_of_attributes的值有100个属性，这是一个很好的起点MaxNoOfAttributes将6 *greatest_number_of_attributes= 600．

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

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

MaxNoOfTables

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

(在旧的NDB集群版本中，该参数有时被视为某些操作的硬限制。这导致了NDB集群复制的问题，当创建的表可能比复制的表多时，有时会导致混乱，当创建的表可能[或不可能，取决于情况]超过时MaxNoOfTables表)。

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

缺省值为128。最小值为8，最大值为20320。每个表对象每个节点占用大约20KB。

MaxNoOfOrderedIndexes

对于集群中的每个有序索引，分配一个对象，描述被索引的对象及其存储段。默认情况下，这样定义的每个索引还定义一个有序索引。每个唯一索引和主键都有一个有序索引和一个哈希索引。MaxNoOfOrderedIndexes设置在任何时候系统中可以使用的有序索引的总数。

缺省值为128。每个索引对象每个节点消耗大约10KB的数据。

MaxNoOfUniqueHashIndexes

对于每个不是主键的唯一索引，分配一个特殊的表，将唯一键映射到索引表的主键。默认情况下，还为每个惟一索引定义了有序索引。为防止这种情况，必须指定使用哈希选项。

缺省值为64。每个索引每个节点占用大约15KB。

MaxNoOfTriggers

为每个惟一的散列索引分配内部更新、插入和删除触发器。(这意味着为每个惟一哈希索引创建三个触发器。)然而,一个命令索引只需要一个触发器对象。备份还为集群中的每个普通表使用三个触发器对象。

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

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

缺省值为768。

MaxNoOfSubscriptions

每一个NDBNDB集群中的表需要在NDB内核中订阅。对于某些NDB API应用程序，可能需要或希望更改此参数。然而，对于作为SQL节点的MySQL服务器的正常使用，不需要这样做。

的默认值MaxNoOfSubscriptions是0，它被视为等于MaxNoOfTables．每个订阅占用108字节。

MaxNoOfSubscribers

只有在使用NDB集群复制时，此参数才有用。默认值为0，视为2 * MaxNoOfTables；也就是说，每个订阅NDB表为两个MySQL服务器(一个作为复制源，另一个作为副本)。每个订阅者使用16个字节的内存。

当使用循环复制、多源复制和其他涉及2个以上MySQL服务器的复制设置时，您应该将此参数增加到mysqld复制中包含的进程(这通常(但不总是)与集群的数量相同)。例如，如果您有一个循环复制设置使用三个NDB集群，只有一个mysqld连接到每一个集群，每一个mysqldProcesses作为源和副本，您应该设置MaxNoOfSubscribers等于3 * MaxNoOfTables．

有关更多信息，请参见第21.6节，“NDB集群复制”．

MaxNoOfConcurrentSubOperations

该参数用于设置集群中所有API节点同时执行操作的上限。默认值(256)对于正常操作来说已经足够了，只有在有很多API节点同时执行大量操作的情况下才可能需要调整。

CompressedLCP

将此参数设置为1导致本地检查点文件被压缩。所使用的压缩相当于gzip,快，可以节省数据节点上存储未压缩检查点文件所需的50%或更多空间。压缩lcp可以为单个数据节点启用，也可以为所有数据节点启用(通过在(ndbd违约)部份config.ini文件)。

默认值为0(禁用)。

CrashOnCorruptedTuple

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

无盘

可以将NDB集群表指定为无盘，这意味着表不会被检查点到磁盘，也不会发生日志记录。这样的表只存在于主存中。使用无磁盘表的结果是，表和这些表中的记录都无法在崩溃中幸存。但是，当在无磁盘模式下操作时，可以运行ndbd在无磁盘计算机上。

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

无盘默认禁用。

LateAlloc

在建立到管理服务器的连接之后，为该数据节点分配内存。默认启用。

LockPagesInMainMemory

对于许多操作系统，包括Solaris和Linux，可以将进程锁定在内存中，从而避免任何交换到磁盘的操作。这可以用来帮助保证集群的实时特性。

该参数取一个整数值0，1,或2，其作用如下表所示:

如果操作系统没有配置为允许无特权用户锁定页面，那么使用此参数的数据节点进程可能必须以系统根用户身份运行。（LockPagesInMainMemory使用mlockall函数。从Linux内核2.6.9开始，非特权用户可以按限制锁定内存最大锁定内存．有关更多信息，请参见ulimit - l而且http://linux.die.net/man/2/mlock)．

ODirect

启用此参数会导致NDB尝试使用O_DIRECT写LCP，备份和重做日志，通常降低kswapdCPU使用率。Linux下使用NDB集群时，启用ODirect如果您正在使用2.6或更高版本的内核。

ODirect默认禁用。

ODirectSyncFlag

当启用此参数时，将执行重做日志写入，以便每次完成的文件系统写入都被处理为调用fsync．如果至少满足以下条件之一，则忽略此参数的设置:

默认禁用。

RestartOnErrorInsert

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

默认情况下，该特性是禁用的。

StopOnError

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

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

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

在NDB集群7.5.5之前，如果数据节点进程以不受控制的方式退出(例如，由于执行kill - 9对数据节点进程执行查询时，或对分割故障)，和StopOnError设置为0时，天使进程尝试以与之前启动时完全相同的方式重新启动它——也就是说，使用与上次启动节点时使用的相同启动选项。因此，如果数据节点进程最初是使用——初始选项，它也将被重新启动——初始．这意味着，在这种情况下，如果故障在很短的时间间隔内发生在足够数量的数据节点上，其效果与执行整个集群的初始重新启动相同，导致所有数据丢失。此问题已在NDB集群7.5.5及以后的NDB 7.5版本中解决(Bug #83510, Bug #24945638)。

MySQL集群管理器的用户应该注意，当StopOnError= 1，这可以防止MySQL集群管理器代理在执行了自己的重启和恢复后重新启动任何数据节点。看到Linux操作系统下启动和停止Agent，以获取更多资料。

UseShm

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

看到章节21.3.3.12，“NDB集群共享内存连接”，以获取更多资料。

TimeBetweenWatchDogCheck

为了防止主线程在某个时刻陷入无休止的循环，可以使用”监管机构”线程检查主线程。该参数指定两次检查之间的毫秒数。如果进程在三次检查后仍然处于相同的状态，看门狗线程将终止它。

为了实验目的或适应当地条件，可以很容易地改变该参数。它可以在每个节点的基础上指定，尽管这样做似乎没有什么理由。

默认超时时间为6000毫秒(6秒)。

TimeBetweenWatchDogCheckInitial

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

默认超时时间为6000毫秒(6秒)。

StartPartialTimeout

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

当首次启动或首次重启集群时，该参数将被覆盖。

缺省值是30000毫秒(30秒)。0禁用超时，在这种情况下，集群只有在所有节点都可用时才能启动。

StartPartitionedTimeout

等待后，集群是否准备启动StartPartialTimeout毫秒，但仍然可能处于分区状态，集群等待，直到这个超时时间也过去。如果StartPartitionedTimeout设置为0时，集群将无限期地等待(2³²−1毫秒，约49.71天)。

当首次启动或首次重启集群时，该参数将被覆盖。

从NDB 7.6.4开始的默认值为0;之前是60000(60秒)。

StartFailureTimeout

如果数据节点在设置的时间内没有完成启动顺序，则节点启动失败。将该参数设置为0(默认值)意味着不应用数据节点超时。

对于非零值，该参数以毫秒为单位进行测量。对于包含大量数据的数据节点，应该增加该参数。例如，对于包含数g数据的数据节点，执行节点重启可能需要10 ~ 15分钟(即600000 ~ 1000000毫秒)。

StartNoNodeGroupTimeout

当数据节点配置为Nodegroup = 65536，则认为未分配给任何节点组。完成后，集群等待StartNoNodegroupTimeout，然后将这些节点视为已添加到传递给——nowait-nodes选项，然后开始。默认值为15000(即管理服务器等待15秒)。将此参数设置为0意味着集群无限期地等待。

StartNoNodegroupTimeout集群中的所有数据节点必须相同;出于这个原因，您应该始终将其设置在(ndbd违约)部份config.ini文件，而不是单独的数据节点。

看到21.5.7节“在线添加NDB集群数据节点”，以获取更多资料。

HeartbeatIntervalDbDb

发现故障节点的主要方法之一是使用心跳。这个参数表示心跳信号的发送频率和预期接收频率。心跳不能被禁用。

在连续错过四个心跳间隔之后，该节点被声明为死亡。因此，通过心跳机制发现故障的最大时间是心跳间隔的5倍。

默认心跳周期为5000毫秒(5秒)。这个参数不能有太大的变化，并且在节点之间不应该有太大的变化。如果一个节点使用5000毫秒，而监视它的节点使用1000毫秒，显然该节点很快就会被宣布死亡。该参数可在软件在线升级过程中修改，但增量较小。

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

HeartbeatIntervalDbApi

每个数据节点都向每个MySQL服务器(SQL节点)发送心跳信号，以确保其保持联系。如果MySQL服务器未能及时发送心跳，则声明它”死了,”在这种情况下，所有正在进行的事务都已完成，所有资源都已释放。在前一个MySQL实例启动的所有活动完成之前，SQL节点不能重新连接。此确定的三心跳标准与所描述的相同HeartbeatIntervalDbDb．

缺省值是1500毫秒(1.5秒)。这个时间间隔可以在各个数据节点之间有所不同，因为每个数据节点都独立于所有其他数据节点监视连接到它的MySQL服务器。

有关更多信息，请参见网络通信和延迟．

HeartbeatOrder

数据节点以循环方式相互发送心跳，每个数据节点监视前一个数据节点。如果给定数据节点未检测到心跳，则该节点声明圆圈中的前一个数据节点”死”(即不再被集群访问)。数据节点死亡的判断是全局完成的;换句话说;一旦一个数据节点被声明为死亡，集群中的所有节点都将其视为死亡。

与其他节点对之间的心跳相比，位于不同主机上的数据节点之间的心跳可能太慢(例如，由于非常低的心跳间隔或临时连接问题)，以至于一个数据节点被宣布死亡，即使该节点仍然可以作为集群的一部分。

在这种情况下，心跳在数据节点之间传输的顺序可能会影响某个特定数据节点是否被宣布死亡。如果不必要地进行这种声明，则会导致节点组的不必要损失，从而导致集群失败。

考虑这样一种设置:在2台主机上运行4个数据节点a、B、C和Dhost1而且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->AHeartbeatOrder值如下所示:

如果要更改运行中的NDB集群的心跳传输顺序，必须先设置HeartbeatOrder对于全局配置中的集群中的每个数据节点(config.ini)文件(或多个)。要使修改生效，必须执行以下操作之一:

你可以使用转储908观察该参数在数据节点日志中的影响。

ConnectCheckIntervalDelay

该参数允许在其中一个数据节点的心跳检查失败后，在数据节点之间进行连接检查HeartbeatIntervalDbDb毫秒。

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

该参数的默认值为0(禁用)。

TimeBetweenLocalCheckpoints

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

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

集群中的所有写操作都被加在一起。设置TimeBetweenLocalCheckpoints到6或更少意味着不间断地连续执行本地检查点，与集群的工作负载无关。

TimeBetweenGlobalCheckpoints

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

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

该参数定义全局检查点之间的间隔。缺省值是2000毫秒。

TimeBetweenGlobalCheckpointsTimeout

此参数定义全局检查点之间的最小超时时间。缺省值是120000毫秒。

TimeBetweenEpochs

该参数定义了NDB集群复制的同步时间间隔。缺省值是100毫秒。

TimeBetweenEpochs是部分实施的吗”micro-GCPs”，可用于提高NDB集群复制的性能。

TimeBetweenEpochsTimeout

该参数定义了NDB集群复制的同步周期超时时间。当节点在该时间内未参与全局检查点时，该节点将被关闭。默认值为0;换句话说，超时是禁用的。

TimeBetweenEpochsTimeout是部分实施的吗”micro-GCPs”，可用于提高NDB集群复制的性能。

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

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

MaxBufferedEpochs

订阅节点可能落后于的未处理的时间周期数。超过此数字将导致延迟订户断开连接。

默认值100对于大多数正常操作已经足够。如果订阅节点确实延迟到导致断开连接的程度，通常是由于进程或线程方面的网络或调度问题。(在极少数情况下，该问题可能是由于NDB客户端)。当epoch较长时，可能需要将该值设置为低于默认值。

断开连接可以防止客户端问题影响数据节点服务、耗尽内存缓冲数据并最终关闭。相反，由于断开连接(例如，通过二进制日志中的间隙事件)，只有客户端受到影响，迫使客户端重新连接或重新启动进程。

MaxBufferedEpochBytes

此节点为缓冲周期分配的总字节数。

TimeBetweenInactiveTransactionAbortCheck

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

缺省值是1000毫秒(1秒)。

TransactionInactiveTimeout

此参数表示在事务中止之前允许在同一事务中的操作之间间隔的最大时间。

此参数的默认值为4 g(也是最大值)。对于需要确保没有事务长时间保持锁的实时数据库，这个参数应该设置为一个相对较小的值。将其设置为0意味着应用程序永远不会超时。单位为毫秒。

TransactionDeadlockDetectionTimeout

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

响应失败可能发生在以下任何原因:

这个超时参数表示事务协调器在终止事务之前等待另一个节点执行查询的时间，对于节点故障处理和死锁检测都很重要。

默认的超时值是1200毫秒(1.2秒)。

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

DiskSyncSize

这是将数据刷新到本地检查点文件之前要存储的最大字节数。这样做是为了防止写入缓冲，这可能会严重影响性能。该参数为不打算取代的TimeBetweenLocalCheckpoints．

缺省值为4M (4mb)。

MaxDiskWriteSpeed

设置NDB集群中未重启(该数据节点或任何其他数据节点)时本地检查点和备份操作写入磁盘的最大速率，单位为字节/秒。

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

MaxDiskWriteSpeedOtherNodeRestart

设置NDB集群中除该节点外的一个或多个数据节点重启时，本地检查点和备份操作写入磁盘的最大速率，单位为字节/秒。

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

MaxDiskWriteSpeedOwnRestart

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

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

MinDiskWriteSpeed

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

在各种条件下，lcp和备份允许的最大磁盘写速率可以通过这些参数进行调整MaxDiskWriteSpeed，MaxDiskWriteSpeedOwnRestart,MaxDiskWriteSpeedOtherNodeRestart．有关更多信息，请参阅这些参数的描述。

ArbitrationTimeout

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

缺省值是7500毫秒(7.5秒)。

仲裁

的仲裁参数启用仲裁方案的选择，对应于此参数的3个可能值之一:

RestartSubscriberConnectTimeout

此参数确定数据节点等待订阅API节点连接的时间。一旦这个超时过期，任何”失踪”API节点与集群断开连接。若要禁用此超时，请设置RestartSubscriberConnectTimeout为0。

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

UndoIndexBuffer

UNDO索引缓冲区的大小由该参数设置，在本地检查点期间使用。的NDB存储引擎使用基于检查点一致性的恢复方案，并结合操作REDO日志。为了生成一致的检查点而不阻塞整个系统的写操作，在执行本地检查点时执行UNDO日志记录。UNDO日志记录一次在单个表片段上激活。这种优化是可能的，因为表完全存储在主存中。

UNDO索引缓冲区用于更新主键哈希索引。插入和删除重新排列哈希索引;NDB存储引擎写入UNDO日志记录，将所有物理更改映射到索引页，以便系统重新启动时可以撤销这些更改。它还在本地检查点的开始记录每个片段的所有活动插入操作。

读取和更新设置锁位并更新哈希索引条目中的报头。这些更改由页面写入算法处理，以确保这些操作不需要UNDO日志记录。

该缓冲区默认为2MB。最小值为1MB，对于大多数应用程序来说已经足够了。对于执行非常大或大量插入和删除以及大型事务和大主键的应用程序，可能需要增加该缓冲区的大小。如果这个缓冲区太小，NDB存储引擎会发出内部错误码677 (索引UNDO缓冲区重载)．

UndoDataBuffer

该参数设置UNDO数据缓冲区的大小，它执行类似于UNDO索引缓冲区的功能，只是UNDO数据缓冲区是关于数据内存而不是索引内存使用的。这个缓冲区在片段的本地检查点阶段用于插入、删除和更新。

由于UNDO日志条目会随着记录的操作的增加而增大，因此这个缓冲区也比对应的索引内存大，默认值为16MB。

对于某些应用程序来说，这个内存量可能太大了。在这种情况下，可以将这个大小减小到最小1MB。

很少需要增加这个缓冲区的大小。如果有这样的需求，最好检查磁盘是否能够实际处理数据库更新活动引起的负载。磁盘空间不足的问题不能通过增加缓冲区的大小来解决。

如果这个缓冲区太小而发生拥塞，NDB存储引擎会发出内部错误码891 (数据撤销缓冲区过载)．

RedoBuffer

所有更新活动都需要记录日志。REDO日志使得每当系统重新启动时都可以重播这些更新。NDB恢复算法使用a”模糊”然后应用REDO日志来回放到恢复点之前的所有更改。

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

如果此缓冲区太小，则NDB存储引擎出现错误代码1221 (重做日志缓冲区过载)．出于这个原因，如果您试图降低的值，您应该非常小心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页面的数量记录DataMemoryand (NDB 7.5及更早版本)IndexMemory，分别设置在config.ini文件。例如，如果DataMemory等于100 MB，并且给定的数据节点使用50 MB的数据内存存储，在集群日志中对应的行可能是这样的:

2006-12-24 01:18:16 [MgmSrvr] INFO—节点2:数据使用率是50%(1280 32K页总数2560)

MemReportFrequency不是必需的参数。对象中的所有集群数据节点都可以设置(ndbd违约)的部分config.ini，也可以为对应的单个数据节点设置或覆盖(ndbd)部分的配置文件。最小值(也是默认值)为0，在这种情况下，内存报告仅在内存使用达到某些百分比(80%、90%和100%)时记录，如中统计事件的讨论中所述章节21.5.3.2，“NDB集群日志事件”．

StartupStatusReportFrequency

属性启动数据节点时——初始，它会在启动阶段4期间初始化重做日志文件(请参阅第21.5.4节“NDB集群启动阶段总结”)．当设置的值非常大时NoOfFragmentLogFiles，FragmentLogFileSize，或者两者都有，这个初始化可能需要很长时间。You can force reports on the progress of this process to be logged periodically, by means of theStartupStatusReportFrequency配置参数。在这种情况下，进程会在集群日志中报告，包括已初始化的文件数量和空间量，如下所示:

2009-06-20 16:39:23 [MgmSrvr] INFO——节点2:本地重做日志文件初始化状态:#Total files: 80, Completed: 60 #Total MBytes: 20480, Completed: 15557 2009-06-20 16:39:23 [MgmSrvr] INFO——节点2:本地重做日志文件初始化状态:#Total files: 80, Completed: 60 #Total MBytes: 20480, Completed: 15570

这些报告都有日志记录StartupStatusReportFrequency启动阶段4期间的秒。如果StartupStatusReportFrequency为0(默认值)，则仅在重做日志文件初始化过程开始时和完成时才将报告写入集群日志。

DictTrace

使用创建和删除表所生成的事件可以记录跟踪记录DictTrace．此参数仅在调试NDB内核代码时有用。DictTrace接受整数值。0(默认-无日志记录)和1(启用日志记录)是NDB 7.5.2之前仅支持的值。在NDB 7.5.2及以后版本中，将该参数设置为2将启用附加日志记录DBDICT调试输出(Bug #20368450)。

WatchdogImmediateKill

在NDB 7.6.7及以后的版本中，当看门狗问题出现时，你可以通过启用WatchdogImmediateKill数据节点配置参数。此参数只应在调试或故障排除时使用，以获取跟踪文件，报告在执行停止时发生了什么。

BackupDataBufferSize

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

该参数的默认值为16MB。最小值在NDB 7.5.1中从2M更改为512K。(错误# 22749509)

BackupDiskWriteSpeedPct

在正常操作期间，数据节点试图最大限度地提高用于本地检查点和备份的磁盘写速度，同时保持在设置的范围内MinDiskWriteSpeed而且MaxDiskWriteSpeed．磁盘写节流为每个LDM线程提供了总预算的平等份额。这允许并行lcp在不超过磁盘I/O预算的情况下发生。由于备份仅由一个LDM线程执行，这实际上会导致预算减少，从而导致更长的备份完成时间，并且如果更改率足够高，则在备份日志缓冲区填充率高于可实现的写速率时无法完成备份。

方法可以解决此问题BackupDiskWriteSpeedPct配置参数，该参数的取值范围为0-90(包括)，该值被解释为在LDM线程之间为lcp共享剩余预算之前保留的节点最大写速率预算的百分比。运行备份的LDM线程接收备份的整个写速率预算，再加上本地检查点的写速率预算中它(减少的)份额。(这使得磁盘写速率预算的行为与NDB集群7.3和更早版本的处理方式类似。)

该参数的默认值是50(解释为50%)。

BackupLogBufferSize

备份日志缓冲区所扮演的角色与备份数据缓冲区所扮演的角色类似，不同的是它用于生成备份执行期间所做的所有表写的日志。写入这些页的原则与写入备份数据缓冲区的原则相同，不同的是，当备份日志缓冲区中没有更多空间时，备份将失败。因此，备份日志缓冲区的大小必须足够大，以处理在进行备份时由写活动引起的负载。看到章节21.5.8.3“NDB集群备份配置”．

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

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

该参数的默认值为16MB。

BackupMemory

此参数已弃用，在NDB集群的未来版本中可能会被移除。为它所做的任何设置都将被忽略。

BackupReportFrequency

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

缺省值为0。

BackupWriteSize

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

该参数的默认值为256KB。

BackupMaxWriteSize

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

该参数的默认值为1MB。

CompressedBackup

启用该参数后，备份文件将被压缩。所使用的压缩相当于gzip,快，可节省数据节点上存储未压缩备份文件所需空间的50%或以上。压缩备份可以为单个数据节点启用，也可以为所有数据节点启用(通过在(ndbd违约)部份config.ini文件)。

默认值为0(禁用)。

BackupDataBufferSize >= BackupWriteSize + 188KB

backupuplogbuffersize >= BackupWriteSize + 16KB

BackupMaxWriteSize >= BackupWriteSize

BuildIndexThreads

该参数确定在系统或节点启动期间以及运行时重建有序索引时要创建的线程数ndb_restore——rebuild-indexes．只有当每个数据节点有多个表片段时(例如，当评论= " NDB_TABLE = PARTITION_BALANCE = FOR_RA_BY_LDM_X_2”与创建表)．

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

使用时支持ndbd或ndbmtd．

属性可以在数据节点初始重启期间启用多线程构建TwoPassInitialNodeRestartCopy数据节点配置参数为真正的．

LockExecuteThreadToCPU

与连用时ndbd，这个参数(现在是一个字符串)指定分配给处理NDBCLUSTER执行线程。与连用时ndbmtd，该参数的值是一个以逗号分隔的CPU id列表，分配给处理执行线程。列表中的每个CPU ID必须为0 ~ 65535(含)之间的整数。

指定的id数量应与所确定的执行线程数量相匹配MaxNoOfExecutionThreads．但是，在使用此参数时，不能保证线程以任何给定顺序分配给cpu。您可以使用。获得此类型的更细粒度控制ThreadConfig．

LockExecuteThreadToCPU没有默认值。

LockMaintThreadsToCPU

分配给处理器的CPU IDNDBCLUSTER维护线程。

取值范围为0 ~ 65535(含)的整数。缺省值为0．

Numa

此参数确定非统一内存访问(NUMA)是由操作系统控制还是由数据节点进程控制，数据节点是否使用ndbd或ndbmtd．默认情况下,NDB尝试在主机操作系统提供NUMA支持的任何数据节点上使用交错NUMA内存分配策略。

设置Numa = 0意味着datanode进程本身不试图为内存分配设置策略，并允许此行为由操作系统决定，操作系统可能进一步由分开的进程指导使用工具。也就是说,Numa = 0产生系统默认行为，可由使用．对于许多Linux系统，系统默认行为是在分配时将套接字本地内存分配给任何给定的进程。这在使用时可能会有问题ndbmtd；这是因为nbdmtd在启动时分配所有内存，导致不平衡，为不同的套接字提供不同的访问速度，特别是在主存中锁定页面时。

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

的Numaconfiguration参数仅在Linux系统下支持libnuma.so是可用的。

RealtimeScheduler

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

默认值是0(禁用调度)。

SchedulerExecutionTimer

此参数指定线程在发送之前在调度程序中执行的时间(以微秒为单位)。将其设置为0可以最小化响应时间;为了获得更高的吞吐量，可以以牺牲更长的响应时间为代价来提高值。

默认值是50 μsec，我们的测试表明，在高负载情况下，它可以稍微提高吞吐量，而不会严重延迟请求。

SchedulerResponsiveness

中设置余额NDB速度和吞吐量之间的调度器。该参数接受一个整数，取值范围为0 ~ 10(含10)，默认值为5。相对于吞吐量，较高的值提供更好的响应时间。较低的值以较长的响应时间为代价提供了更高的吞吐量。

SchedulerSpinTimer

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

缺省值为0。

TwoPassInitialNodeRestartCopy

通过将此配置参数设置为，可以为数据节点的初始重启启用有序索引的多线程构建真正的，它允许在初始节点重新启动时进行两次数据复制。从NDB 7.6.4开始，这是默认值(Bug #26704312, Bug #27109117)。

你还必须设置BuildIndexThreads到非零值。

MaxNoOfExecutionThreads

此参数直接控制所使用的执行线程数ndbmtd，最多72个。虽然这个参数是在(ndbd)或(ndbd违约)各部分config.ini文件，它是专属的ndbmtd并不适用于ndbd．

设置MaxNoOfExecutionThreads设置由文件中的矩阵确定的每种类型的线程数存储/ ndb / src /内核/ vm / mt_thr_config.cpp．这个表显示了线程数的可能值MaxNoOfExecutionThreads．

总是有一个SUMA(复制)线程。

NoOfFragmentLogParts应该设置为LDM线程使用的数量ndbmtd，由该参数的设置决定。这个比例不应大于4:1;从NDB 7.5.7和NDB 7.6.3开始，这种情况的配置是特别不允许的。(错误# 25333414)

LDM线程的数量也决定了线程使用的分区的数量NDB表未显式分区;这是LDM线程数乘以集群中的数据节点数。(如果ndbd是用在数据节点上，而不是ndbmtd，则总有一个LDM线程;在这种情况下，自动创建的分区数量等于数据节点的数量。看到章节21.1.2，“NDB集群节点，节点组，片段副本和分区”，以获取更多资料。

如果磁盘页缓冲区不够大，在使用超过默认LDM线程数的情况下为Disk Data表添加大表空间可能会导致资源和CPU使用问题;的描述DiskPageBufferMemory配置参数，以获取更多信息。

线程类型将在本节后面描述(参见ThreadConfig)．

将此参数设置在允许的值范围之外会导致管理服务器在启动时出现错误而中止误差线数量:非法值价值参数MaxNoOfExecutionThreads．

为MaxNoOfExecutionThreads， 0或1的值在内部由NDB到2，因此2被认为是该参数的默认值和最小值。

MaxNoOfExecutionThreads通常打算将其设置为与可用CPU线程数相等，并为每种类型分配适合典型工作负载的线程数。它不会将特定的线程分配给指定的cpu。如果需要改变所提供的设置，或者将线程绑定到cpu，则应该使用ThreadConfig相反，它允许您直接将每个线程分配给所需的类型、CPU或两者兼而有之。

多线程数据节点进程总是生成，至少，下面列出的线程:

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

在NDB 7.6之前，更改LDM线程数总是需要重新启动系统，无论是使用此参数更改还是使用ThreadConfig．在NDB 7.6及以后版本中，可以通过节点初始重启来实现更改(倪)，但须符合下列条件:

在NDB 7.6之前，如果集群的IndexMemory使用率大于50%，更改此情况需要初始重新启动集群。(最多30-35%IndexMemory建议在这种情况下使用。)否则，资源使用和LDM线程分配无法在节点之间实现平衡，这可能导致LDM线程未充分利用和过度利用，最终导致数据节点故障。在NDB 7.6及以后版本中，初始重启为不需要对该参数进行更改。

NoOfFragmentLogParts

为属于此的重做日志设置日志文件组的数量ndbmtd．此参数的值应设置为与所使用的LDM线程数相等ndbmtd由设置确定为MaxNoOfExecutionThreads．从NDB 7.5.7和7.6.3开始，每个LDM使用超过4个重做日志部件的配置是不允许的。(错误# 25333414)

参见MaxNoOfExecutionThreads获取更多信息。

ThreadConfig

此参数与ndbmtd将不同类型的线程分配给不同的cpu。其值为字符串，格式语法如下:

ThreadConfig: =条目(,条目[…]]条目: =类型= {参数(,参数[…]]}类型:= LDM | main | recv | send | rep | IO | tc | watchdog | idxbld .输出说明参数: = =数量| cpubind =cpu_list| cpuset =cpu_list| spintime =数量|实时= {0}| 1 | nosend = {0} | 1 | thread_prio = {0 . .10} | cpubind_exclusive=cpu_list| cpuset_exclusive =cpu_list

大括号(｛.．.｝)，即使列表中只有一个参数，也需要围绕参数列表。

一个参数(parameter)指定以下任何或所有信息:

Thread_prio根据平台设置和效果。实施thread_prio不同于Linux/FreeBSD, Solaris和Windows。在下面的列表中，我们依次讨论它对每个平台的影响:

的类型属性表示NDB线程类型。支持的线程类型和允许的范围数每个的值在下面的列表中提供:

在NDB 7.6之前，正在更改ThreadCOnfig需要重新启动系统。在NDB 7.6及以后版本中，在某些情况下可以放宽这一要求:

其他情况下，需要重启系统才能修改该参数。

NDB 7.6.4及以后版本可以通过以下两个标准来区分线程类型:

简单的例子:

#例1。ThreadConfig=ldm={count=2,cpubind=1,2}，main={cpubind=12}，rep={cpubind=11} #示例2。主要Threadconfig = = {cpubind = 0}, ldm = {count = 4, cpubind = 1、2、5、6},io = {cpubind = 3}

在为数据节点主机配置线程使用情况时，通常需要为操作系统和其他任务预留一个或多个cpu。因此，对于具有24个CPU的主机，您可能希望使用20个CPU线程(留下4个用于其他用途)、8个LDM线程、4个TC线程(LDM线程数量的一半)、3个发送线程、3个接收线程，以及每个用于模式管理、异步复制和I/O操作的1个线程。(这几乎与时使用的线程分布相同MaxNoOfExecutionThreads设置为20。)以下ThreadConfigsetting执行这些分配，另外将所有这些线程绑定到特定的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上，就像我们在刚才的示例中所做的那样。

下面的示例合并了使用这两种方法定义的cpu组cpuset而且cpubind，以及线程优先级的使用。

ThreadConfig=ldm={count=4, cpubind= 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}， \ main={count=1,cpubind=10}，rep={count=1,cpubind=11}

在本例中，我们创建了两个LDM组;第一次使用cpubind第二种用途cpuset．thread_prio而且spintime为每个组设置相同的值。这意味着总共有8个LDM线程。)你应该确保NoOfFragmentLogParts也设置为8。)四个TC线程只使用两个cpu;使用时是可能的cpuset在组中指定的cpu比线程少。(这不是真的cpubind)。发送线程使用两个线程usingcpubind将这些线程绑定到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可以重叠那些为其他(永久)线程类型指定的，第一个使用cpuset第二种用法cpubind：

ThreadConfig=main,ldm={count=4, cpubind=1 -4}，tc={count=4,cpuset=5,6,7}， \ io={cpubind=8}，idxbld={cpubind=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的8个内核，它等价于这里显示的设置:

ThreadConfig =主要,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来0 xfffff0，以及使用isolcpus启动选项grub.conf．有关具体信息，请参阅您的操作系统或平台文档。10bet官方网站

DiskPageBufferEntries

这是要分配的页条目(页引用)的数量。它被指定为32K页的数量DiskPageBufferMemory．默认值对于大多数情况已经足够了，但是如果遇到Disk Data表上非常大的事务问题，则可能需要增加该参数的值。每个页面条目大约需要100个字节。

DiskPageBufferMemory

这决定了用于在磁盘上缓存页面的空间量，并在(ndbd)或(ndbd违约)部份config.ini文件。它以字节为单位。每页大小为32kb。这意味着NDB集群磁盘数据存储始终使用N* 32kb内存N是某个非负整数。

该参数的默认值为64米(2000页，每张32 KB)。

如果的值为DiskPageBufferMemory是否设置过低，与使用超过默认数量的LDM线程有关ThreadConfig(例如{ldm = 6…})时，在尝试将大型(例如500G)数据文件添加到基于磁盘的数据文件时，可能会出现问题NDB表，在这个表中，进程占用一个CPU核的时间是无限长的。

这是因为，作为向表空间添加数据文件的一部分，区段页被锁定在额外的PGMAN工作线程中的内存中，以便快速访问元数据。当添加一个大文件时，这个worker没有足够的内存来存放所有数据文件元数据。在这种情况下，您应该增加DiskPageBufferMemory，或添加更小的表空间文件。你也可能需要调整DiskPageBufferEntries．

您可以查询ndbinfo.diskpagebuffer表，以帮助确定是否应增加此参数的值以尽量减少不必要的磁盘寻道。看到第21.5.14.20节“ndbinfo diskpagebuffer表”，以获取更多资料。

SharedGlobalMemory

该参数决定了用于日志缓冲区、磁盘操作(如页面请求和等待队列)以及表空间、日志文件组、撤销文件和数据文件。共享全局内存池还提供用于满足UNDO_BUFFER_SIZE选项与创建日志文件组而且修改日志文件组属性的设置为此选项暗示的任何默认值InitialLogFileGroup数据节点配置参数。SharedGlobalMemory可以设置在(ndbd)或(ndbd违约)部份config.ini配置文件，以字节为单位。

默认值为128米．

DiskIOThreadPool

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

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

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

缺省值为2。

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

有关更多信息，请参见章节21.5.10.1，“NDB集群磁盘数据对象”．

Disk数据对象创建参数。下面两个参数使您在第一次启动集群时可以在不使用SQL语句的情况下创建Disk Data日志文件组、表空间或两者。

ExtraSendBufferMemory

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

TotalSendBufferMemory

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

如果设置了该参数，其最小允许值为256KB;0表示未设置该参数。有关更详细的信息，请参见21.3.3.13节“配置NDB集群发送缓冲区参数”．

RedoOverCommitCounter

当RedoOverCommitLimit当尝试将给定的重做日志写入磁盘这多次或更多次时，任何未提交的事务都被中止，并且这些事务起源于哪里的API节点根据其值处理构成这些事务的操作DefaultOperationRedoProblemAction(通过将需要重新尝试的操作排队或中止它们)。

RedoOverCommitLimit

该参数设置了在超时前尝试将给定重做日志写入磁盘的上限(以秒为单位)。数据节点试图刷新此重做日志，但耗时较长的次数RedoOverCommitLimit，是保存和比较的RedoOverCommitCounter，如果刷新所需的时间比该参数的值长，则由于刷新超时而未提交的任何事务都将中止。当发生这种情况时，产生这些事务的API节点将根据其属性处理组成这些事务的操作DefaultOperationRedoProblemAction设置(它要么对要重新尝试的操作进行排队，要么中止它们)。

StartFailRetryDelay

使用此参数设置数据节点在启动失败时两次重新启动之间的秒数。默认为0(无延迟)。

这个参数和MaxStartFailRetries被忽略，除非StopOnError等于0。

MaxStartFailRetries

使用此参数可以限制数据节点在启动失败时尝试重新启动的次数。默认是3次尝试。

这个参数和StartFailRetryDelay被忽略，除非StopOnError等于0。

IndexStatAutoCreate

在创建索引时启用(set = 1)或禁用(set = 0)自动统计信息收集。默认禁用。

IndexStatAutoUpdate

启用(设置为1)或禁用(设置为0)监视索引的更改，并触发检测到的自动统计信息更新。属性的设置决定了触发更新所需的更改量和程度IndexStatTriggerPct而且IndexStatTriggerScale选项。

IndexStatSaveSize

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

无论大小有多大限制，至少要生产一个样品。这个大小是按IndexStatSaveScale．

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

IndexStatSaveScale

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

IndexStatTriggerPct

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

IndexStatTriggerScale

规模IndexStatTriggerPct用这个量乘以0.01对于一个大的指数。值为0禁用伸缩。

IndexStatUpdateDelay

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