MySQL集群节点参数说明

妖狐艹你老母 2022-09-17 10:17 204阅读 0赞

# 1. 定义MySQL集群管理服务器 #

\[NDB\_MGMD\]部分（或其别名\[MGM\]）用于配置管理服务器的行为。下面列出的所有参数均能被忽略，如果是这样，将使用其默认值。注释：如果ExecuteOnComputer和HostName参数均未出现，会为它们指定默认值localhost。

\[NDB\_MGMD\]Id：集群中的每个节点都有唯一的标识，由从1到63的整数表示。所有的内部集群消息使用该ID来定址结点。

\[NDB\_MGMD\]ExecuteOnCompute：它引用在\[COMPUTER\]部分中定义的计算机之一。

\[NDB\_MGMD\]PortNumber：这是管理服务器用于监听配置请求和管理命令的端口号。

\[NDB\_MGMD\]LogDestination：该参数指定了将集群登录信息发送到哪里。有三种选项，CONSOLE、SYSLOG和FILE：

l CONSOLE，将日志输出到标准输出设备（stdout）：CONSOLE

l SYSLOG，将日志发送到syslog（系统日志）软设备，可能的值包括：auth、authpriv、cron、daemon、ftp、kern、lpr、mail、news、syslog、user、uucp、local0、local1、local2、local3、local4、local5、local6或local7。

注释：并非所有的操作系统均支持所有的软设备。

SYSLOG:facility=syslog

l FILE，将集群日志输出导向相同机器上的正规文件。可指定下述值：

filename：日志文件的名称。

maxsize：日志记录切换到新文件之前，文件能增长到的最大尺寸。出现该情况时，将通过在文件名上添加.x，重命名日志文件，其中，x是该名称尚未使用的下一个数字。

maxfiles：日志文件的最大数目。

FILE:filename=cluster.log,maxsize=1000000,maxfiles=6

使用由分号分隔的字符串，可以指定多个日志目标，如下所示：

CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd

FILE参数的默认值是FILE:filename=ndb\_node\_id\_cluster.log,maxsize=1000000,maxfiles=6，其中，node\_id是节点的ID。

\[NDB\_MGMD\]ArbitrationRank：该参数用于定义哪个节点将扮演仲裁程序的角色。只有MGM节点和SQL节点能扮演仲裁程序的角色。ArbitrationRank可以取下述值之一：

l 0：该节点永远不会用作仲裁程序。

l 1：该节点具有高的优先级，也就是说，与低优先级节点相比，它更容易成为仲裁程序。

l 2：表明节点具有低的优先级，仅当具有高优先级的节点无法用于该目的时，才能成为仲裁程序。

通常情况下，应将ArbitrationRank设置为1（默认值），并将所有的SQL节点设置为0，将管理服务器配置为仲裁程序。

\[NDB\_MGMD\]ArbitrationDelay：整数值，以毫秒为单位规定了管理服务器对仲裁请求的延迟时间。默认情况下，该值为0，通常不需要改变它。

\[NDB\_MGMD\]DataDir：它用于设置保存管理服务器输出文件的位置。这些文件包括集群日志文件、进程输出文件、以及端口监督程序的pid文件（对于日志文件，可通过设置\[NDB\_MGMD\]LogDestination的FILE参数覆盖它，请参见本节前面的讨论）。

# 2. 定义MySQL集群数据节点 #

\[NDBD\]部分用于配置集群数据节点的行为。有很多可用于控制缓冲区大小、池大小、超时等的参数。强制性参数包括：

ExecuteOnComputer或HostName.参数NoOfReplicas，这些参数需要在\[NDBD DEFAULT\]部分中定义。

大多数数据节点参数是在\[NDBD DEFAULT\]部分中设置的。只有那些明确声明为能设置本地值的参数才能在\[NDBD\]部分中被更改。HostName、Id以及ExecuteOnComputer必须在本地\[NDBD\]部分中定义。

## 2.1. 识别数据节点 ##

启动节点时，可在命令行上分配Id值（即数据节点ID），也能在配置文件中分配Id值。

对于各参数，能够使用后缀k、M或G用于指明单位，分别表示1024、1024\*1024或1024\*1024\*1024（例如，100k表示100 \* 1024 = 102400）。目前，参数和值区分大小写。

\[NBDB\]Id：这是用作节点地址的节点ID，供有的集群内部消息使用。这是介于1～63之间的整数。集群中的每个节点均有唯一的ID。

\[NDBD\]ExecuteOnComputer：用于引用在COMPUTER部分中定义的计算机（主机）。

\[NDBD\]HostName：指定该参数的效果类似于指定ExecuteOnComputer。它定义了存储节点所在计算机的主机名。指定除localhost之外的其他主机名时，需要该参数或ExecuteOnComputer。

(OBSOLETE) \[NDBD\]ServerPort：集群中的各节点使用端口来与其他节点相连。该端口也用于连接建立阶段中的非TCP传输器。由于默认端口是动态分配的，同一台计算机上的两个节点具有不同的端口号，正常情况下不需要为该参数指定值。

\[NDBD\]NoOfReplicas：该全局参数仅能在\[NDBD DEFAULT\]中设置，它定义了集群中每个表保存的副本数。该参数还指定了节点组的大小。节点组指的是保存相同信息的节点集合。

节点组是以隐式方式构成的。第1个节点组由具有最低节点ID的数据节点集合构成，下一个节点组由具有次低节点ID的数据节点集合构成，依此类推。作为示例，我们有4个数据节点，并将NoOfReplicas设置为2。这四个数据节点的ID分别是2、3、4、5。那么第1个节点组由节点2和3构成，第2个节点组由节点4和5构成。重要的是对集群进行相应的配置，使得同一节点组中的节点位于不同的计算机上，这是因为，如果位于相同的计算机上，单个硬件故障会导致整个集群崩溃。

如果未提供节点ID，那么数据节点的顺序将是节点组的决定因素。无论是否进行了明确的分配，可在管理客户端SHOW命令的输出中查看它们。

NoOfReplicas没有默认值，最大的可能值为4。

\[NDBD\]DataDir：该参数指定了存放跟踪文件、日志文件、pid文件以及错误日志的目录。

\[NDBD\]FileSystemPath：该参数指定了存放为元数据创建的所有文件、REDO日志、UNDO日志和数据文件的目录。默认目录是由DataDir指定的。注意，启动ndbd进程之前，该目录必须已存在。

为MySQl集群推荐的目录层次包括/var/lib/mysql-cluster，在其下为节点的文件系统创建1个为目录。该子目录包含节点ID。例如，如果节点ID为2，该子目录的名称为ndb\_2\_fs。

\[NDBD\]BackupDataDir：也能指定存放备份的目录。默认情况下，该目录是FileSystemPath/BACKUP。

## 2.2. 数据内存和索引内存 ##

参数DataMemory和IndexMemory指定了存放实际记录及其索引的内存段的大小。这是它们的值时，重要的是应掌握使用DataMemory和IndexMemory的方式，这是因为，为了反映集群的实际使用情况，常常需要更新它们：

\[NDBD\]DataMemory：该参数定义了用于保存数据库记录的空间大小。全部空间均是分配在内存中的，因此，机器应具有足够的物理内存来容纳该值，这点极其重要。

由DataMemory分配的内存用于保存实际记录和索引。目前，每条记录具有固定的大小（甚至VARCHAR列也保存为固定宽度列）。每条记录的开销为16字节，此外，每条记录还需要额外的空间，这是因为，这类记录保存在具有128字节页面开销的32KB页中（请参见下面的介绍）。由于每条记录仅保存在1个页中，因而每页有少量的浪费。目前，最大记录大小为8052字节。

由DataMemory定义的内存空间也用于保存有序索引，对于每条记录，索引约使用10字节。在有序索引中，表示了每个表行。用户常犯的一个错误是，想当然地认为所有的索引均保存在由IndexMemory分配的内存中，但情况并非如此：只有主键和唯一性混编索引使用该内存，有序索引使用的是由DataMemory分配的内存。然而，创建主键或唯一性混编索引时，也会在相同的 键上创建有序索引，除非在索引创建语句中指定了USING HASH。通过在管理客户端中运行ndb\_desc -d db\_name table\_name，可对其进行验证。

DataMemory分配的内存空间由多个32KB页构成，它们是为表片段分配的。通常情况下，为每一表划分的表片段数目与集群中的节点数目相同。因此，对于每一节点，片段数目与在NoOfReplicas中设置的相同。一旦分配了1页，目前无法将其返回到自由页池中，除非删除表。执行节点恢复也将压缩分区，这是因为，所有记录均会被插入到其他活动节点的空分区中。

DataMemory内存空间也包含UNDO信息：对于每一更新，未改变记录的副本将被分配到DataMemory中。在有序表索引中，还有对每一副本的引用。仅当更新唯一性索引列时，才会更新唯一性混编索引，在该情况下，将在索引表中插入新的条目，并在提交时删除旧的条目。因此，也有必要分配足够的内存，以便处理由使用集群的应用程序执行的最大事务。在任何情况下，执行少量大的事务并不比使用众多小的事务占优，原因如下：

l 大事务的速度没有较小事务的速度快。

l 大的事务会增加丢失操作的数目，一旦事务失败，必须重复执行。

l 大的事务使用更多的内存。

DataMemory的默认值是80MB，最小为1MB。没有最大尺寸限制，但在实际使用过程中，最大限制应恰当，以便当达到最大限制时，进程不会启动交换功能。该限制由机器上可用的物理RAM量、以及操作系统能提交给任何进程的内存量决定。对于32位操作系统，该限制值为每进程2～4GB，对于64位操作系统，该限制值更大。对于大的数据库，出于该原因，最好使用64位操作系统。此外，在每台机器上也能运行一个以上的ndbd进程，在使用多CPU的机器上，该特性颇具优势。

\[NDBD\]IndexMemory：该参数用于控制MySQL集群中哈希（混编）索引所使用的存储量。哈希（混编）索引总用于主键索引、唯一性索引、以及唯一性约束。注意，定义主键和唯一性索引时，将创建两条索引，其中一条是用于所有tuple访问和锁定处理的哈希（混编）索引。此外，它还能用于增强唯一性约束。

哈希（混编）索引的大小是每记录25字节，再加上主键的大小。对大于32字节的主键，还需加上8字节。

考虑下例定义的表：

<table> 
 <tbody> 
 <tr> 
 <td> CREATE&nbsp;TABLE&nbsp;example&nbsp;( &nbsp;&nbsp;a&nbsp;INT&nbsp;NOT&nbsp;NULL, &nbsp;&nbsp;b&nbsp;INT&nbsp;NOT&nbsp;NULL, &nbsp;&nbsp;c&nbsp;INT&nbsp;NOT&nbsp;NULL, &nbsp;&nbsp;PRIMARY&nbsp;KEY(a), &nbsp;&nbsp;UNIQUE(b) )&nbsp;ENGINE=NDBCLUSTER; </td> 
 </tr> 
 </tbody> 
</table>

有12字节的开销（无可空列将节省4字节的开销）加上每记录12字节的数据。此外，在列a和b上有两个有序索引，假定每记录分别耗用约10字节的空间。在每记录约使用29字节的基表上有1条主键哈希索引。唯一性约束由以b作为主键以及a作为列的单独表实现。对于该表，每记录将耗用额外的29字节索引内存，在示例表中，还包括12字节的开销再加上8字节的记录数据。

因此，对于100万条记录，需要58MB的索引内存来处理用于主键和唯一性约束的哈希索引。还需要64 MB来处理基表和唯一索引表、以及两个有序索引表的记录。

由此可见，哈希索引占用了相当大的内存空间，但作为回报，它们提供了对数据的极快访问。在MySQl集群中，它们也用于处理唯一性约束。

目前仅有的分区算法是散列法，有序索引对每个节点来说都是局部性的。因此，有序索引不能用于处理一般情况下的唯一性约束。

对于IndexMemory和DataMemory，重要的是，总的数据库大小是各节点组的所有数据内存和所有索引内存之和。每个节点组用于保存复制信息，因此，如果有4个节点和2个副本，将有2个节点组。对于每个数据节点，可用的总数据内存是2\*DataMemory。

强烈建议为所有的节点设置相同的DataMemory值和IndexMemory值。由于数据是平均分布在集群中的所有节点上，任何节点可用的最大空间不超过集群中最小节点的可用空间。

DataMemory和IndexMemory可被更改，但降低任何一个的值均会导致危险，如果这样做，很容易使某一节点甚至整个集群因缺少足够的内存空间而无法重启。增加它们的值应是可接受的，但建议采用与软件升级相同的方式升级它，

首先更新配置文件，然后重启管理服务器，最后依次重启每个数据节点。

更新不会增加所用的索引内存。插入将立刻生效，但是，在提交事务之前并不会实际删除行。

IndexMemory的默认值是18MB。最小值为1MB。

## 2.3. 事务参数 ##

下面讨论的三个参数十分重要，这是因为，它们会影响并发事务的数目，以及系统能够处理的事务的大小。MaxNoOfConcurrentTransactions用于设置节点内可能的并发事务数目。MaxNoOfConcurrentOperations用于设置能同时出现在更新阶段或同时锁定的记录数目。

对于打算设定特定值、不使用默认值的用户，这两个参数可能正是他们所需的（尤其是MaxNoOfConcurrentOperations）。默认值是为使用小型事务的系统而设置的，为的是确保这类事务不会使用过多的内存。

\[NDBD\]MaxNoOfConcurrentTransactions：对于集群中的每个活动事务，必须在集群节点之一中有1条记录。对事务的协调任务是在各节点间进行的：在集群中，事务记录的总数等于任意给定节点中的事务数乘以集群中的节点数。

事务记录被分配给单独的MySQL服务器。正常情况下，对于使用集群中任何表的每个连接，必须为其分配至少1条事务记录。出于该原因，应确保集群中的事务记录数大于集群中所有MySQL服务器的并发连接数。

对于所有的集群节点，必须将该参数设置为相同的值。

更改该参数不安全，如果这样做，会导致集群崩溃。当某一节点崩溃时，集群中的一个节点（实际上是生存时间最久的节点）将为崩溃之时正在崩溃节点中运行的所有事务建立事务状态。因此，重要的是，该节点的事务记录数不低于失效节点中的事务记录数。该参数的默认值为4096。

\[NDBD\]MaxNoOfConcurrentOperations：根据事务的大小和数目调整该参数的值，这个想法不错。执行仅包含少量操作且不涉及很多记录的事务时，不需要将该参数设置得很高。但在执行涉及大量记录的大事务时，需要将该参数设置得较高。

对于每次事务更新的集群数据，均会保存记录，并会将它们保存在事务协调器中以及执行实际更新的节点中。这些记录包含所需的状态信息，这类信息可用于为回滚操作找到UNDO记录，用于锁定查询或其他目的。

该参数应被设置为：事务中同时更新的记录数除以集群数据节点的数目。例如，在包含4个数据节点的集群中，如果预期处理的、使用事务的并发更新数为1000000，就应将该值设置为1000000 / 4 = 250000。

设置锁定的读请求也会导致操作记录的创建。在单独节点内也会分配一些额外的空间，以便处理在节点间分配不完美的问题。

当查询使用唯一性哈希索引时，对于事务中的每条记录，实际上将使用两条操作记录。第1条记录代表在索引表中的读，第2条记录负责处理基表上的操作。

该参数的默认值为32768。

该参数实际上处理的是能分别配置的两个值。第1个值指定了将多少操作记录放到事务协调器中，第2个值指定了多少操作记录是数据库的本地记录。

对于在8节点集群上执行的特大事务，它要求事务协调器中的操作记录数不少于事务中涉及的读取、更新和删除次数。然而，集群中的操作记录分布在所有的8个节点上。因此，如果有必要为特大事务配置系统，良好的方法是分别配置该参数的两个部分。MaxNoOfConcurrentOperations总会被用于计算节点的事务协调器部分中的操作记录数。

应了解操作记录对内存的要求，这点也很重要。每记录约消耗1KB。

（MaxNoOfConcurrentOperations：设置同时能够被更新（或者锁定）的记录数量。一般来说可以设置为在整个集群中相同时间内可能被更新（或者锁定）的总记录数，除以NDB节点数，所得到的值。比如，在集群中有两个NDB节点，而希望能够处理同时更新（或锁定）100000条记录，那么此参数应该被设置为：100000 / 4 = 25000。此外，这里的记录数量并不是指单纯的表里面的记录数，而是指事务里面的操作记录。当使用到唯一索引的时候，表的数据和索引两者都要算在里面，也就是说，如果是通过一个唯一索引来作为过滤条件更新某一条记录，那么这里算是两条操作记录。而且即使是锁定也会产生操作记录，比如通过唯一索引来查找一条记录，就会产生如下两条操作记录：通过读取唯一索引中的某个记录数据会产生锁定，产生一条操作记录，然后读取基表里面的数据，这里也会产生读锁，也会产生一条操作记录。MaxNoOfConcurrentOperations参数的默认值为32768。当我们额度系统运行过程中，如果出现此参数不够的时候，就会报出“Out of operation records in transaction coordinator”这样的错误信息）。

\[NDBD\]MaxNoOfLocalOperations：默认情况下，将按照1.1 \* MaxNoOfConcurrentOperations计算该参数，也就是说，每个节点一般可以处理超过平均值的10%的操作记录数量。它适合于具有很多并发事务但不存在特大事务的系统。如果需要在某一时间处理特大事务而且有很多节点，最好通过明确指定该参数以覆盖默认值。

## 2.4. 事务临时存储 ##

下一组参数用于决定执行作为集群事务组成部分的查询时所需的临时存储空间。查询完成后将释放所有记录，集群将等待提交或回滚事件。

对于大多数情况，这些参数的默认值是恰当的。但是，如果需要支持涉及大量行或操作的事务，用户或许应增大这些参数的值，以便在系统中获得更好的平行性。对于需要相对较少事务的应用程序，用户可降低这些参数的值，以便节省内存。

\[NDBD\]MaxNoOfConcurrentIndexOperations：对于使用唯一性哈希索引的查询，在查询执行期间，将使用操作记录的另一个临时集合。该参数用于设置记录池的大小。因此，仅当执行查询的某一部分时才会分配该记录，一旦该部分执行完成，将释放记录。对于处理放弃和提交所需的状态，它是由正常的操作记录负责处理的，这类记录的池大小由参数MaxNoOfConcurrentOperations设置。

该参数的默认值为8192。只有在极其罕见的情况下，需要使用唯一性哈希索引执行极高的并行操作时，才有必要增大该值。如果DBA（数据库管理员）确信该集群不需要高的并行操作，可以使用较小的值并节省内存。

\[NDBD\]MaxNoOfFiredTriggers：默认值是4000，它足以应付大多数情况。在某些情况下，如果DBA认为在集群中对并行操作的要求并不高，甚至还能降低它。

执行会影响唯一哈希索引的操作时，将创建记录。在具有哈希索引的表中插入或删除记录时，或更新作为唯一哈希索引组成部分的列时，均会触发索引表中的插入或删除操作。所获得的记录用于代表该索引表操作，同时等待促使其完成的初始操作。该操作的时间很短，但对于在基表（包含唯一哈希索引）上有很多并发写操作的情形，仍需要在记录池中有大量的记录。

\[NDBD\]TransactionBufferMemory：该参数影响的内存用于跟踪更新索引表和读取唯一索引时执行的操作。该内存用于保存关于这类操作的键和列信息。几乎不需要更改该参数的默认值。

## 2.5. 扫描和缓冲 ##

\[NDBD\]MaxNoOfConcurrentScans：该参数用于控制可在集群中执行的并行扫描的数目。每个事务协调程序均能处理为该参数定义的并行扫描。对于每次执行的扫描查询，将以并行方式扫描所有分区。每次分区扫描将使用分区所在节点内的扫描记录，记录数等于该参数的值乘以节点数。集群应能支持从集群内所有节点同时执行的MaxNoOfConcurrentScans扫描。

扫描实际上是在两种情况下执行的。第1种情况是，处理查询时不存在哈希或有序索引，在该情况下，查询是通过执行全表扫描进行的。第2种情况是，没有支持查询的哈希索引，但存在有序索引。使用有序索引意味着将执行并发范围扫描。由于顺序仅保存在本地分区上，需要在所有分区上执行索引扫描。

MaxNoOfConcurrentScans的默认值是256。最大值为500。该参数指定了事务协调器中的可能扫描数。如果未提供本地扫描记录的数目，会对其进行计算，等于MaxNoOfConcurrentScans乘以系统中数据节点的数目。

\[NDBD\]MaxNoOfLocalScans：如果很多扫描不是完全并行化的，指定本地扫描记录的数目。

\[NDBD\]BatchSizePerLocalScan：该参数用于计算锁定记录的数目，要想处理很多并发扫描操作，需要这类记录。默认值是64，该值与SQL节点中定义的ScanBatchSize关系密切。

\[NDBD\]LongMessageBuffer：这是用于在单独节点内和节点之间传递消息的内部缓冲。尽管几乎不需要改变它，但它仍是可配置的。默认情况下，它被设置为1MB。

## 2.6. 日志和Checkpointing ##

\[NDBD\]NoOfFragmentLogFiles：该参数用于设置节点的REDO日志文件的大小。REDO日志文件是按循环方式组织的。第1个和最后1个日志文件（有时也分别称为“头”日志文件和“尾”日志文件）不应相遇，这点极其重要，当它们彼此过于接近时，由于缺少新日志记录的空间，节点将开始放弃所有事务，包括更新。

自插入日志记录开始，在三个本地检查点完成之前，不会删除REDO日志记录。检查点的频率由其自己的配置参数集决定，请参见本章的相应部分。

默认的参数值为8，它表示有8个集合，每个集合有4个16MB文件，总容量为512MB。换句话讲，REDO日志空间必须按64MB的块大小分配。在需要大量更新的情况下，可能需要将NoOfFragmentLogFiles的值增加到300或更高，以便为REDO日志提供足够的空间。

如果checkpointing很慢，并有很多对数据库的写操作以至于日志文件已满，而且在没有jeapo rdising恢复功能的情况下无法截断日志尾部，那么所有的更新日志均将被放弃，并给出错误代码410或缺少临时日志空间。该状况将一直持续，直至完成了检查点操作并能将日志尾部向前移动为止。

\[NDBD\]MaxNoOfSavedMessages：该参数用于设置跟踪文件的最大数目，在覆盖旧文件之前，将保留这些跟踪文件。无论出于何种原因，当节点崩溃时将创建跟踪文件。默认为25个跟踪文件。

## 2.7. 元数据对象 ##

下一组参数为元数据对象定义了池的大小，可用于定义最大属性数，表，索引，索引使用的触发程序对象，事件，以及集群之间的复制。注意，这些参数仅是对集群的“建议”，任何未指定的参数均将采用其默认值。

\[NDBD\]MaxNoOfAttributes：定义了可在集群中定义的属性数目。该参数的默认值为1000，最小的可能值为32。没有最大值限制。对于每一属性，每节点约需200字节的存储空间，这是应为，所有的元数据将完整地复制到服务器上。

设置MaxNoOfAttributes时，应实现准备好打算在将来执行的任何ALTER TABLE命令，这点很重要。这是因为下述事实，在集群表上执行ALTER TABLE的过程中，所使用的属性数目是原始表中的3倍。例如，如果某一表需要100个属性，而且你打算在以后更改它，那么就需要将MaxNoOfAttributes的值设为300。有一个良好的经验规则，如果你能在不出现问题的情况下创建所有所需的表，请将最大表中属性数目的两倍加到MaxNoOfAttributes上。完成该设置后，应通过执行实际的ALTER TABLE操作，验证该数目是足够的。如果失败，将原始值的倍数加到MaxNoOfAttributes上，并再次测试。

\[NDBD\]MaxNoOfTables：表对象是为每个表、唯一哈希索引和有序索引分配的。该参数为作为整体的集群设置了最大表对象数目。

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

该参数的默认值为128。最小值为8，最大值为1600。每个表对象每节点约需20KB的空间。

\[NDBD\]MaxNoOfOrderedIndexes：对于集群中的每个有序索引，将分配1个对象，该对象描述了编入索引的是什么以及其存储段。默认情况下，每个这样定义的索引还将定义1个有序索引。每个唯一索引和主键既有1个有序索引还有1个哈希索引。该参数的默认值为128。每个对象每节点约需10KB的数据。

\[NDBD\]MaxNoOfUniqueHashIndexes：对于每个不是主键的唯一索引，将分配1个特殊表，该表将唯一键映射到索引表的主键上。默认情况下，对于每个唯一索引，还将定义1个有序索引。为了防止该情况，定义唯一索引时，必须使用USING HASH选项。默认值是64。每个索引每节点约需15KB的空间。

\[NDBD\]MaxNoOfTriggers：对于每个唯一性哈希索引，将分配内部更新、插入、和删除触发程序（这意味着对于每个唯一性哈希索引，将创建三个触发程序）。但是，1个有序索引仅需要1个触发程序对象。对于集群中每个正常表，备份也将使用三个触发程序对象。

注释：支持集群之间的复制时，也将使用内部触发程序。该参数用于设置集群中触发程序对象的最大数目。该参数的默认值为768。

## 2.8. 布尔参数 ##

数据节点的行为也会受具有布尔值的一组参数的影响。将其设为“1”或“Y”，可将这类参数设置为“真”，将其设为“0”或“N”，可将这类参数设置为“假”。

\[NDBD\]LockPagesInMainMemory：对于包括Solaris和Linux在内的很多操作系统，能够将进程锁定在内存中，以避免与磁盘的交换。使用它，可确保集群的实时特性。默认情况下，该特性是被禁止的。

\[NDBD\]StopOnError：出现错误时，该参数指定了NDBD进程是退出还是执行自动重启。默认情况下，允许该特性。

\[NDBD\]Diskless：能够将MySQL集群的表指定为“无磁盘的”，这意味着不会在磁盘上对表执行检查点操作，也不会出现日志操作。这类表仅存在于主内存中。使用“无磁盘”表的一个结果是，出现崩溃侯，不会保留这类表，也不会保留这类表中的任何记录。但是，当工作在“无磁盘”模式下时，能够在无盘计算机上运行ndbd。

要点：该特性会使整个集群运行在“无磁盘”模式下。

允许该特性时，可执行备份操作，但不会实际保存备份数据。将“Diskless”设置为“1”或“Y”可允许该特性。默认情况下，禁止该特性。

\[NDBD\]RestartOnErrorInsert：仅当创建调试版时才能访问该特性，在执行作为测试组成部份的代码块的过程中，可以插入错误。默认情况下，该特性是被禁止的。

## 2.9. 控制超时、间隔、和磁盘分页 ##

有多种用于指定超时以及集群数据节点中各种动作间时间间隔的参数。大多数超时值以毫秒为单位指定。任何例外均将在适用时指明。

\[NDBD\]TimeBetweenWatchDogCheck：为了防止主线程在某一点上陷入无限循环，采用了“看门狗”线程来检查主线程。该参数以毫秒为单位指定了检查之间的时间间隔。如果三次检查之后进程仍保持在相同的状态，它将被“看门狗”线程中止。

出于试验目的，可方便地更改该参数，也可以对其进行调整以适合本地条件。也可以按节点指定它，虽然这样作的理由很少。默认超时为4000毫秒（4秒）。

\[NDBD\]StartPartialTimeout：该参数指定了在调用集群初始化子程序之前，集群等待所有存储节点出现的时间。该超时参数由于防止部分集群启动。

默认值是30000毫秒（30秒）。0表示无限超时，换句话讲，仅当所有节点均可能时才会启动集群。

\[NDBD\]StartPartitionedTimeout：等待了StartPartialTimeout毫秒后，如果集群做好了启动准备但仍可能处于隔离状态，集群将等待该超时时间结束。默认超时为60000毫秒（60秒）。

\[NDBD\]StartFailureTimeout：如果数据节点在该参数指定的时间内未完成其启动序列，节点启动将失败。如果将该参数设置为0，表示不采用数据节点超时。默认值是60000毫秒(60秒）。对于包含大量数据的数据节点，应增加该参数。例如，对于包含数GB数据的存储节点，为了执行节点重启，可能需要10～15分钟（即600000～1000000毫秒）。

\[NDBD\]HeartbeatIntervalDbDb：发现失败节点的主要方法之一是使用“心跳”数。该参数指明了心跳信号的发送频率，以及接收它们的频率。如果在1行内丢失了三次心跳，节点将被宣告为死亡。因此，通过心跳机制发现故障的最大时间是心跳间隔的四倍。默认的心跳间隔为1500毫秒（1.5秒）。不得大幅度更改该参数，各节点间该参数的变化范围也不得过宽。例如，如果某一节点使用了5000毫米的值，而观察它的节点采用1000毫秒，很显然，该节点很快就会被宣布为死亡。能够在软件升级期间更改该参数，但增量应较小。

\[NDBD\]HeartbeatIntervalDbApi：每个数据节点会将心跳信号发送到各MySQL服务器（SQL节点），以确保保持接触。如果某一MySQL服务器未能及时发出心跳信号，它将被宣布为死亡。在这种情况下，所有正在进行的事务将结束并释放所有资源。SQL节点不能重新连接，直至由以前的MySQL实例初始化的所有活动完成为止。用于该判断的3心跳判据与HeartbeatIntervalDbDb描述的相同。

默认时间间隔为1500毫秒（1.5秒）。不同的数据节点之间，该间隔可以有所不同，这是因为，每个存储节点均会独立于所有其他数据节点观察与之相连的MySQL服务器。

\[NDBD\]TimeBetweenLocalCheckpoints：该参数是一个例外，它未指定启动新的本地检查前应等待的时间，相反，它用于确保在出现相对较少更新的集群内未执行本地检查点操作。在具有较高更新率的大多数集群内，很可能在前一个本地检查点操作完成后立刻启动一个新的检查点操作。

从前一个本地检查点启动后，所有已执行写操作的大小将增加。该参数也是一个例外，原因在于它被指定为4字节字总数的以2为底数的对数，因此，默认值20表示4MB (4 × 220)写操作，21表示8MB，依此类推，直至等同于8GB写操作的最大值31。

集群中所有的写操作将加在一起。将TimeBetweenLocalCheckpoints设置为6或更小表示本地检查点操作将不停顿地连续执行，与集群的工作负荷无关。

\[NDBD\]TimeBetweenGlobalCheckpoints：提交事务时，它被提交到存有镜像数据的所有节点的主内存中。但是，事务日志记录不会作为提交进程的一部分写入磁盘。其原因在于，在至少两台独立主机机器上安全体提交事务应能满足关于关于持久性的合理标准。

另一个很重要的方面是，应确保即使在最差情况下（集群完全崩溃），也能进行恰当地处理。为了确保这点，在给定时间间隔内出现的所有事务均会被放到全局检查点，可将其视为写入磁盘的已提交事务的集合。换句话讲，作为提交进程的组成部分，事务将被放入全局检查点组；稍后，该组的日志记录将被写入磁盘，然后将整个事务组安全地提交到集群内所有计算机的磁盘上。。

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

\[NDBD\]TimeBetweenInactiveTransactionAbortCheck：对于该参数指定的每个时间间隔，通过检查每个事务的定时器来执行超时处理。因此，如果该参数被设为1000毫秒，每隔1秒就会对事务进行检查。该参数的默认值为1000毫秒（1秒）。

\[NDBD\]TransactionInactiveTimeout如果事务目前未执行任何查询，而是等待进一步的用户输入，该参数指明了放弃事务之前用户能够等待的最长时间。

该参数的默认值是0（无超时）。对于需要确保无任何事务锁定了过长时间的数据库，应将参数设置为较小的值。单位为毫秒。

\[NDBD\]TransactionDeadlockDetectionTimeout：当节点执行涉及事务的查询时，在继续之前，节点将等待集群中其他节点作出回应。如果出现下述原因，将无法予以回应：

1.    节点“死亡”。

2.    操作进入锁定队列。

3.    被请求执行动作的节点负荷过重。

该超时参数指明了放弃事务之前，事务协调器等候另一节点执行查询的时间长短，该参数在节点失败处理和死锁检测方面十分重要。在涉及死锁和节点失败的情形下，如果将其设置的过高，会导致不合需要的行为。默认的超时值为1200毫秒（1.2秒）。

\[NDBD\]NoOfDiskPagesToDiskAfterRestartTUP：执行本地检查点操作时，相应的算法会将所有数据页写入磁盘。如果追求尽快完成该操作而不是适中，很可能会对处理器、网络和磁盘带来过重负担。为了控制写入速度，该参数指明了每100毫秒可写入多少数据页。在本情形下，1个数据页定义为8KB，因而该参数的单位是每秒80KB。因此，如果将NoOfDiskPagesToDiskAfterRestartTUP设置为20，那么在执行本地检查点操作期间，要求每秒想磁盘写入1.6MB的数据。该值包括针对数据页的UNDO日志记录写入，也就是说，该参数能处理来自数据内存的写入限制。置于针对索引页的UNDO日志记录，它们是由参数NoOfDiskPagesToDiskAfterRestartACC处理的（关于索引页的更多信息，请参见关于IndexMemory的条目）。

简而言之，该参数指定了执行本地检查点操作的速度，并能与NoOfFragmentLogFiles、DataMemory和IndexMemory一起使用。默认值是40（每秒3.2MB的数据页）。

\[NDBD\]NoOfDiskPagesToDiskAfterRestartACC：该参数使用的单位与NoOfDiskPagesToDiskAfterRestartTUP的相同，工作方式也类似，但限制的是从索引内存进行的索引页写入速度。该参数的默认值为每秒20个索引内存页（1.6MB每秒）。

\[NDBD\]NoOfDiskPagesToDiskDuringRestartTUP：该参数的工作方式类似于NoOfDiskPagesToDiskAfterRestartTUP和NoOfDiskPagesToDiskAfterRestartACC，但仅对重启节点时在节点内执行的本地检查点操作有效。作为所有节点重启的组成部份，总会执行本地检查点操作。在节点重启过程中，能够以比其他时间更快的速度执行磁盘写入操作，这是因为，此时在节点内执行的活动数较少。该参数涉及从数据内存写入的页。默认值是40（3.2MB每秒）。

\[NDBD\]NoOfDiskPagesToDiskDuringRestartACC：在节点重启的本地检查点阶段，对能够写入到磁盘的索引内存页的数目进行控制。

与NoOfDiskPagesToDiskAfterRestartTUP和NoOfDiskPagesToDiskAfterRestartACC一样，该参数的值采用的单位也是每100毫秒写入8KB（80KB/秒）。默认值是20 (1.6MB每秒）。

\[NDBD\]ArbitrationTimeout：该参数指定了数据节点等待仲裁程序对仲裁消息的回应的时间。如果超过了该时间，将假定网络已断开。默认值是1000毫秒（1秒）。

## 2.10. 缓冲和日志功能 ##

一些与以前的编译时间参数对应的配置参数仍可用。使用这些参数，高级用户能够对节点进程使用的资源进行更多的控制，并能根据需要调整各种缓冲区大小。

将日志记录写入磁盘时，这些缓冲区用作文件系统的前端。如果节点运行在无盘模式下，那么可以将这些参数设置为它们的最小值而不会造成负面影响，这是因为，磁盘写入是由NDB存储引擎的文件系统提取层虚拟的。

\[NDBD\]UndoIndexBuffer：该缓冲用于本地检查点操作执行期间。NDB存储引擎采用了一种恢复方案，该方案建立在检查点一致性以及操作性REDO日志值上。为了在不隔断整个系统的写操作的情况下获得一致的检查点，在执行本地检查点操作的同时，将执行UNDO日志操作。UNDO日志功能每次是在单个表偏短上触发的。由于表全部保存在主内存中，该优化是可能的。

UNDO索引缓冲用于主键哈希索引上的更新。插入和删除操作会导致哈希索引的重新排列，NDB存储引擎将映射了所有物理变化的UNDO日志记录写入索引页，以便能在系统重启时撤销这些变化。它还能记录启动本地检查点操作时对每个偏短的所有插入操作。

读取和更新能够设置锁定位，并更新哈希索引条目中的标题。这类变更由页写入算法负责处理，以确保这些操作不需要UNDO日志。

该缓冲的默认大小为2MB。最小值为1MB，对于大多数应用，最小值已足够。对于执行极大和／或大量插入和删除操作、并处理大事务和大主键的应用程序，或许有必要增大该缓冲。如果该缓冲过小，NDB存储引擎会发出错误代码677“索引UNDO缓冲过载”。

\[NDBD\]UndoDataBuffer：UNDO数据缓冲的作用与UNDO索引缓冲的相同，不同之处在于，它作用在数据内存上而不是索引内存上。对于插入、删除和更新，该缓冲是在片段的本地检查点阶段使用的。

由于UNDO日志条目会随着所记录操作的增加而增大，该缓冲大于与之对应的索引内存缓冲，默认值为16MB。

对于某些应用程序，该内存可能过大。在这种情况下，可降低它的值，最小为1MB。需要增加该缓冲的情况十分罕见。如果确实有这方面的要求，较好的方式是，检查磁盘是否能实际处理数据库更新活动所产生的负荷。如果缺少足够的磁盘空间，即使增加该缓冲的大小也不能解决问题。

如果该缓冲过小并变得“拥挤不堪”，NDB存储引擎将发出错误代码891“数据UNDO缓冲过载”。

\[NDBD\]RedoBuffer：所有的更新活动也需要被记录到日志中。使用这类日志，当系统重启时，能够重现这类更新。NDB恢复算法采用了“模糊”数据检查点和UNDO日志，然后使用REDO日志再现所有变化直至到达恢复点。该缓冲的默认大小是8MB。最小值为1MB。

如果该缓冲过小，NDB存储引擎将发出错误代码1221“REDO日志缓冲过载”。

在管理集群的过程中，应能控制为各种事件类型发送至标准输出装置的日志消息的数目，这点十分重要。有16种可能的事件级别（编号从0到15）。如果将给定事件类别的事件通报级别设置为15，那么该类别中的所有事件报告均会被发送至标准输出装置，如果将其设置为0，表示在该类别中的没有事件报告。默认情况下，仅会将启动消息发送至标准输出装置，其余的事件通报级别默认为0。这样做的原因在于，这些消息也会被发送至管理服务器的集群日志。对于管理客户端，也能设置类似的级别，用以确定在集群日志中记录哪些级别的事件。

\[NDBD\]LogLevelStartup：通报级别，用于进程启动过程中生成的事件。

默认级别为1.

\[NDBD\]LogLevelShutdown：通报级别，用于作为节点恰当关闭进程组成部分而生成的事件。默认级别为0.

\[NDBD\]LogLevelStatistic：通报级别，用于统计事件，如主键法读取次数，更新数目，插入数目，与缓冲使用有关的信息等。默认级别为0.

\[NDBD\]LogLevelCheckpoint：通报级别，用于由本地和全局检查点操作生成的事件。默认级别为0.

\[NDBD\]LogLevelNodeRestart：通报级别，用于在节点重启过程中生成的事件。默认级别为0.

\[NDBD\]LogLevelConnection：通报级别，用于由集群节点间的连接生成的事件。默认级别为0.

\[NDBD\]LogLevelError：通报级别，用于由在整个集群内的错误和警告生成的事件。这类错误不会导致任何节点失败，当仍值得通报。默认级别为0.

\[NDBD\]LogLevelInfo：通报级别，用于为集群的一般状态信息而生成的事件。默认级别为0.

## 2.11. 备份参数 ##

本节讨论的参数定义了与在线备份执行有关的内存缓冲集。

\[NDBD\]BackupDataBufferSize：在创建备份的过程中，为了将数据发送到磁盘，将使用两类缓冲。备份数据缓冲用于填充由扫描节点的表而记录的数据。一旦将该缓冲填充到了指定的水平BackupWriteSize（请参见下面的介绍），就会将页发送至磁盘。在将页写入磁盘的同时，备份进程能够继续填充该缓冲，直至其空间消耗完为止。出现该情况时，备份进程将暂停扫描，直至一些磁盘写入操作完成并释放了内存为止，然后扫描继续。该参数的默认值为2MB。

\[NDBD\]BackupLogBufferSize：备份日志缓冲扮演的角色类似于备份数据缓冲，不同之处在于，它用于生成备份执行期间进行的所有表写入的日志。相同的原理也适用于备份数据缓冲情形下的页写入，不同之处在于，当备份日志缓冲中没有多余空间时，备份将失败。出于该原因，备份日志缓冲的大小应足以处理执行备份时产生的负载。

该参数的默认值对于大多数应用程序均是适当的。事实上，备份失败的原因更可能是因为磁盘写入速度不够，而不是备份日志缓冲变满。如果没有为应用程序产生的写负载配置磁盘子系统，集群很可能无法执行所需的操作。

最好按恰当的方式配置集群，使得处理器成为瓶颈而不是磁盘或网络连接。

默认值是2MB。

\[NDBD\]BackupMemory：该参数是BackupDataBufferSize和BackupLogBufferSize之和。默认值是2MB + 2MB = 4MB。

\[NDBD\]BackupWriteSize：该参数指定了由备份日志缓冲和备份数据缓冲写入磁盘的消息大小。默认值是32KB.

# 3. 定义MySQL集群内的SQL节点 #

在config.ini文件的\[MYSQLD\]部分中，定义了用于访问集群数据的MySQL服务器（SQL节点）的行为。不需要其中所给出的参数。如果未提供计算机或主机名，那么任何主机均能使用该SQL节点。

\[MYSQLD\]Id：该值用作节点的地址，供所有的集群内部消息使用，它必须是介于1和63之间的整数。在集群内，每个集群节点必须有唯一的ID。

\[MYSQLD\]ExecuteOnComputer：它引用的是在配置文件的\[COMPUTER\]部分定义的主机（计算机）之一。

\[MYSQLD\]ArbitrationRank：该参数用于定义可作为仲裁程序的节点。MGM节点和SQL节点均能成为仲裁程序。如果值为0，表明给定的节点永远不会用作仲裁程序，如果值为1，表明给定的节点在成为仲裁程序方面具有高的优先级，如果值为2，表明给定的节点在成为仲裁程序方面具有低的优先级。对于正常配置，使用管理服务器作为仲裁程序，将它的ArbitrationRank设置为1（默认），并将所有SQL节点的ArbitrationRank设置为0。

\[MYSQLD\]ArbitrationDelay：如果将该参数设置为除0（默认值）以外的其他值，表示仲裁程序对仲裁请求的相应将被延迟设定的毫秒数。通常不需要更改该值。

\[MYSQLD\]BatchByteSize：对于转换为全表扫描或对索引的范围扫描的查询，要想获得最佳性能，重要的是以恰当的大小获取记录。能够以记录数为单位（BatchSize）和字节为单位（BatchByteSize）设置恰当的大小。实际的批大小由两个参数限定。

查询的执行速度可能会出现40％的变化，具体情况取决于该参数的设置。在未来的版本中，MySQL服务器将根据查询类型恰当地设置与批大小相关的参数。该参数以字节为单位，默认值是32KB。

\[MYSQLD\]BatchSize：该参数以记录数为单位，默认值是64。最大值为992。

\[MYSQLD\]MaxScanBatchSize：批大小指的是从各数据节点发送的每批数据的大小。大多数扫描均是以并行方式执行的，目的是为了防止MySQL服务器收到来自众多节点的过多数据，该参数对所有节点上的总的批大小进行了限制。该参数的默认值为256KB。其最大大小为16MB

# 4. MySQL集群TCP/IP连接 #

在MySQL集群中，TCP/IP是用于建立连接的默认传输协议。正常情况下不需要定义连接，这是因为，集群能自动建立数据节点间、数据节点与所有MySQL服务器节点、以及数据节点与管理服务器之间的连接（关于该规则的例外，，请参见[17.4.4.8节，“使用直接连接的MySQL集群TCP/IP连接”][17.4.4.8_MySQL_TCP_IP])。

如果打算覆盖默认的连接参数，才需要定义连接。在这种情况下，至少需要定义NodeId1、NodeId2、以及打算更改的参数。

通过在\[TCP DEFAULT\]部分进行设置，也能更改这些参数的默认值。

\[TCP\]NodeId1 , \[TCP\]NodeId2：要想确定两个节点之间的连接，需要在配置文件的［TCP］部分中提供每个节点的ID。

\[TCP\]SendBufferMemory：在向操作系统发出调用请求之前，TCP传输器采用缓冲来保存所有的消息。当该缓冲达到64KB时，将发送其内容，执行完一组消息循环后，也将发送这些内容。为了处理临时过载情况，也能定义一个较大的发送缓冲。发送缓冲的默认值是256KB。

\[TCP\]SendSignalId：为了能够回扫分布式消息图，需要确定每条消息。将该参数设置为“Y”时，将通过网络传输消息ID。默认情况下禁止该特性。

\[TCP\]Checksum：该参数也是一个布尔参数（Y/N或1/0），默认情况下是禁止的。启用了该参数时，在将所有消息置于发送缓冲之前，将为所有参数计算校验和。使用该特性，当消息等候在发送缓冲中时，可以确保消息不会损坏，也能确保消息不会被传输机制破坏。

\[TCP\]ReceiveBufferMemory：指定了从TCP/IP套接字接收数据时所使用的缓冲大小。几乎不需要更改该参数的默认值，默认值为64KB，但是如果打算节省内存，也能更改它。

转自：

[http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html][http_dev.mysql.com_doc_refman_5.1_zh_ndbcluster.html]

[17.4.4.8_MySQL_TCP_IP]: http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html#mysql-cluster-direct-tcp-definition
[http_dev.mysql.com_doc_refman_5.1_zh_ndbcluster.html]: http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html