当前位置: 首页 > 文档资料 > MySQL 中文手册 >

17.4. MySQL簇的配置

优质
小牛编辑
135浏览
2023-12-01
17.4.1. 从源码创建MySQL簇
17.4.2. 安装软件
17.4.3. MySQL簇的快速测试设置
17.4.4. 配置文件
作为MySQL簇组成部份的MySQL服务器仅在一个方面上与正常的(非簇式)MySQL服务器不同,它采用了NDB簇存储引擎。该引擎也简单地称为NDB,这两个术语是同义词。

为了避免不必要的资源分配,默认情况下,在服务器的配置中将禁止NDB存储引擎。要想启用NDB,需要更改服务器的my.cnf配置文件,或使用“—ndbcluster”选项启动服务器。

由于MySQL服务器是簇的一部分,它也需要知道如何访问MGM节点,以便获得簇配置数据。默认行为是查找本地主机上MGM节点。但是,如果需要另外指定它的位置,可在my.cnf文件或MySQL服务器命令行上进行。能够使用NDB存储引擎之前,至少应有一个MGM节点是可操作的,而且还应有所需的数据节点。

17.4.1. 从源码创建MySQL簇

对于Linux、Mac OS X和Solaris,在其二进制分发版中均提供了NDB簇存储引擎。在Windows平台上尚不支持它,但我们打算在不远的将来使其能用于win32和其他平台。

如果选择从源码tarball或MySQL 5.1 BitKeeper树创建它,运行configure时,务必使用“--with-ndbcluster”选项。也可以使用BUILD/compile-pentium-max创建脚本。注意,该脚本包含OpenSSL,因此,要想成功创建,必须有或获得OpenSSL,如不然,需要更改“compile-pentium-max”以便将该要求排除在外,当然,也能采用标准步骤来编译你自己的二进制文件,然后执行常规测试和安装步骤。请参见2.8.3节,“从开发源码树安装”。

17.4.2. 安装软件

在下面的数节内,假定你已熟悉了MySQL的安装方法,在此,我们仅介绍了MySQL簇配置与不具备簇功能的MySQL配置之间的差别。如果希望了解关于后者的更多信息,请参见第2章:安装MySQL。

如果首先运行了所有的管理和数据节点,你将发现簇配置最简单,这或许是最花时间的配置部分。编辑my.cnf文件相对直接,在本节中,仅讨论与不具备簇功能的MySQL配置不同的部分。

17.4.3. MySQL簇的快速测试设置

为了帮助你熟悉基本概念,我们将介绍功能性MySQL簇的最简单的可能配置。然后,按照本章相关部分提供的信息,你应能设计自己所需的配置。

首先,应以系统根用户身份通过执行下述命令创建配置目录,如/var/lib/mysql-cluster:

shell> mkdir /var/lib/mysql-cluster

在该目录下,使用下述信息创建名为config.ini的文件,针对系统的情况,用恰当的值替换HostName和DataDir。

# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: DB, API, and MGM are aliases for NDBD, MYSQLD, and NDB_MGMD
# respectively. DB and API are deprecated and should not be used in new
# installations.
[NDBD DEFAULT]
NoOfReplicas= 1
 
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]
 
[NDB_MGMD]
HostName= myhost.example.com
 
[NDBD]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster
 
[MYSQLD]
[MYSQLD]
[MYSQLD]

现在,能够按下述方式启动管理服务器:

shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd

接下来,通过运行ndbd启动单个DB节点。首次为给定的DB节点启动ndbd时,应使用“—initial”选项,如下所示:

shell> ndbd --initial

对于后续的ndbd启动,通常不需要使用该选项:

shell> ndbd

这是因为,--initial选项将删除该数据节点的所有已有数据和日志文件(以及所有的表元数据),并创建新的数据和日志文件。该规则的一项例外是:添加了新数据节点后重启簇并从备份进行恢复之时。

默认情况下,ndbd将在端口1186上查找本地主机上的管理服务器。

注释:如果从二进制tarball安装了MySQL,需要明确指定ndb_mgmdndbd服务器的路径。(正常情况下,它们位于/usr/local/mysql/bin目录下)。

最后,进入MySQL数据目录(通常是/var/lib/mysql或/usr/local/mysql/data),并确保my.cnf文件包含启用NDB存储引擎所需的选项:

[mysqld]
ndbcluster

现在,你能按通常方式启动MySQL服务器:

shell> mysqld_safe --user=mysql &

等待一段时间,确认MySQL服务器正在恰当运行。如果发现通知用mysql停止,请检查服务器的.err文件,找出错误。

如果到目前为止一切正常,可使用簇启动它:

shell> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.1.2-alpha-Max
 
键入’help;’或’\h’获取帮助。键入’\c’清空缓冲区。
 
mysql> SHOW ENGINES\G
 
...
*************************** 12. row ***************************
Engine: NDBCLUSTER
Support: YES
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
Engine: NDB
Support: YES
Comment: Alias for NDBCLUSTER
...

(注意,上例输出中显示的行号可能与你的系统上显示的不同,具体情况取决于使用的MySQL版本,以及配置它的方式)。

shell> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.1.2-alpha-Max
 
键入’help;’或’\h’获取帮助。键入’\c’清空缓冲区。
 
mysql> USE test;
Database changed
 
mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)
 
mysql> SHOW CREATE TABLE ctest \G
*************************** 1. row ***************************
       Table: ctest
Create Table: CREATE TABLE `ctest` (
  `i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

要想检查是否恰当设置了节点,可启动管理客户端:

shell> ndb_mgm

随后,为了获得关于簇状态的报告,可从管理客户端内使用SHOW命令:

NDB> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)]     1 node(s)
id=2    @127.0.0.1  (Version: 3.5.3, Nodegroup: 0, Master)
 
[ndb_mgmd(MGM)] 1 node(s)
id=1    @127.0.0.1  (Version: 3.5.3)
 
[mysqld(API)]   3 node(s)
id=3    @127.0.0.1  (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

此时,你成功地设置了工作的MySQL簇。现在,你能使用由ENGINE=NDBCLUSTER或其别名ENGINE=NDB创建的表,将数据保存到簇中。

17.4.4. 配置文件

17.4.4.1. MySQL簇的配置示例
17.4.4.2. MySQL簇连接字符串
17.4.4.3. 定义构成MySQL簇的计算机
17.4.4.4. 定义MySQL簇管理服务器
17.4.4.5. 定义MySQL簇数据节点
17.4.4.6. 定义MySQL簇内的SQL节点
17.4.4.7. MySQL簇TCP/IP连接
17.4.4.8. 使用直接连接的MySQL簇TCP/IP连接
17.4.4.9. MySQL簇共享内存连接
17.4.4.10. MySQL簇SCI传输连接

配置MySQL簇需要与两个文件打交道:

·my.cnf:为所有的MySQL簇可执行文件指定了选项。你应熟悉了前面介绍的使用MySQL的方式,通过运行在簇中的每个可执行文件,必须能够访问该文件。

·config.ini:该文件仅由MySQL簇管理服务器读取,随后管理服务器会将包含该文件的信息分配给簇中的所有进程。config.ini文件包含对簇中各节点的描述。包括数据节点的配置参数,以及簇中所有节点间连接的配置参数。

我们正在不断改进簇配置,并努力简化该进程。尽管我们将尽量维护向后兼容性,但在某些时候,可能也需要引入不兼容的变动。在这种情况下,我们将尽量让簇用户事先了解该变动是否是向后兼容的。如果你发现了尚未记录在文档中的这类变动,请使用我们的缺陷数据库通报它。

17.4.4.1. MySQL簇的配置示例

为了支持MySQL簇,需要更新文件my.cnf,如下例所示。注意,不应将这里给出的选项与config.ini文件中出现的选项混淆起来。此外,从命令行调用可执行文件时,或许也应指定这些参数。

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid in MySQL 5.1)
 
# enable ndbcluster storage engine, and provide connectstring for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com
 
 
# provide connectstring for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com
 
# provide connectstring for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com
 
# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini

(关于连接字符的更多信息,请参见17.4.4.2节,“MySQL簇连接字符串”)。

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)
 
# enable ndbcluster storage engine, and provide connectstring for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186

或许,你也可以使用簇my.cnf中单独的[mysql_cluster]部分,设置可被所有可执行文件读取的设置,并影响所有的可执行文件:

# cluster-specific settings
[mysql_cluster]
ndb-connectstring=ndb_mgmd.mysql.com:1186

目前,配置文件采用的是INI格式,默认情况下被命名为config.ini。该文件在启动时由ndb_mgmd读取,并能被置于任何地方。在命令行上与ndb_mgmd一起使用--config-file=[<path>]<filename>,可指定其位置和名称。如果未指定配置文件,默认情况下,ndb_mgmd将尝试读取位于当前工作目录下的文件config.ini。

对于大多数参数,均定义了默认值,也能在config.ini文件中指定默认值。要想创建默认值部分,可简单地将单词DEFAULT添加到该部分的名称上。例如,数据节点是使用[NDBD]部分配置的。如果所有的数据节点使用相同大小的数据内存,而且该内存大小不同于默认的大小,应创建包含DataMemory行的[NDBD DEFAULT]部分,为所有数据节点指定默认的数据内存大小。

INI格式包含多个部分,每一部分以该部分的标题(用方括号括住)开始,后跟恰当的参数名和值。与标准格式的不同之处在于,不能用冒号“:”和等号“=”隔开参数名和值;另一处不同是,这些部分并不是用名称唯一标识的。其唯一性条目(如具有相同类型的两个不同节点)是由唯一ID标识的。

作为最低要求,配置文件必须定义簇中的计算机和节点,以及这些节点所在的计算机。下面给出了一个简单的簇配置文件示例,该簇包含1个管理服务器,2个数据节点和2个MySQL服务器:

# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the management
# server)
# The first MySQL Server can be started from any host. The second can be started
# only on the host mysqld_5.mysql.com
 
[NDBD DEFAULT]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster
 
[NDB_MGMD]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster
 
[NDBD]
HostName= ndbd_2.mysql.com
 
[NDBD]
HostName= ndbd_3.mysql.com
 
[MYSQLD]
[MYSQLD]
HostName= mysqld_5.mysql.com

在该配置文件中,有6个不同部分:

·[COMPUTER]:定义了簇主机。

·[NDBD]:定义了簇的数据节点。

·[MYSQLD]:定义了簇的MySQL服务器节点。

·[MGM]或[NDB_MGMD]:定义了簇的管理服务器节点。

·[TCP]:定义了簇中节点间的TCP/IP连接,TCP/IP是默认的连接协议。

·[SHM]:定义了节点间的共享内存连接。以前,这类连接仅能在使用“--with-ndb-shm”选项创建的二进制文件中使用。在MySQL 5.1-Max中,默认情况下它是允许的,但仍应将其视为试验性的。

注意,每个节点在config.ini文件中有自己的部分。例如,由于该簇有两个数据节点,在配置文件中,也包含定义这些节点的部分。

可以为每个部分定义DEFAULT值。所有的簇参数名称均区分大小写。

17.4.4.2. MySQL簇连接字符串

除了MySQL簇管理服务器(ndb_mgmd),构成MySQL簇的每个节点均需要1个连接字符串,该连接字符串指向管理服务器所在的位置。它用于建立与管理服务器的连接,并执行其他任务,这类其他任务取决于节点在簇内扮演的角色。连接字符串的语法如下:

<connectstring> :=
    [<nodeid-specification>,]<host-specification>[,<host-specification>]
    
<nodeid-specification> := node_id
 
<host-specification> := host[:port]

node_id是大于1的整数,用于确定config.ini中的节点。port是引用正常Unix端口的整数。host是代表有效Internet地址的字符串。

example 1 (long):    "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short):   "myhost1"

如果未提供,所有节点均将使用localhost:1186作为默认的连接字符串值。如果在连接字符串中省略了<port>,默认端口为1186。该端口在网络上总应是可用的,这是因为它是由IANA为该目的而指定的(详情请参见http://www.iana.org/assignments/port-numbers)。

通过列出多个<host-specification>值,能够指定数个冗余管理服务器。簇节点将按照指定的顺序尝试连接到每台主机上的连续管理服务器,直至成功建立起连接为止。

有多种指定连接字符串的不同方法:

·每个可执行文件有自己的命令行选项,使用它,能够在启动时指定管理服务器(关于各可执行程序的介绍,请参见相应的文档)。

·也能一次性地为簇中的所有节点设置连接字符串,方法是将其放在管理服务器的my.cnf文件的[mysql_cluster]部分。

·为了向后兼容性,还提供了两种其他选项,其使用的语法相同:

1. 设置NDB_CONNECTSTRING环境变量,使之包含connectstring(连接字符串)。

2. 将针对各可执行文件的connectstring(连接字符串)写入名为Ndb.cfg的文本文件,并将该文件放在可执行文件的启动目录下。

但是,这些方法目前已不再受重视,对于新安装,不应使用它们。

指定连接字符串时,推荐的方法是在命令行上设置它,或为每个可执行文件在my.cnf文件中设置它。

17.4.4.3. 定义构成MySQL簇的计算机

除了用于避免为系统中的每个节点定义主机名外,[COMPUTER]部分没有实际的重要意义。这里所提到的所有参数都是需要的。

·[COMPUTER]Id

这是整数值,用于引用位于配置文件中别处的主机计算机。

·[COMPUTER]HostName

这是计算机的主机名或IP地址。

17.4.4.4. 定义MySQL簇管理服务器

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

·[NDB_MGMD]Id

簇中的每个节点都有唯一的标识,由从1到63的整数表示。所有的内部簇消息使用该ID来定址结点。

·[NDB_MGMD]ExecuteOnComputer

它引用在[COMPUTER]部分中定义的计算机之一。

·[NDB_MGMD]PortNumber

这是管理服务器用于监听配置请求和管理命令的端口号。

·[NDB_MGMD]LogDestination

该参数指定了将簇登录信息发送到哪里。有三种选项,CONSOLE、SYSLOG和FILE:

o CONSOLE,将日志输出到标准输出设备(stdout):

o     CONSOLE

o 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

o FILE,将簇日志输出导向相同机器上的正规文件。可指定下述值:

§filename:日志文件的名称。

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

§maxfiles:日志文件的最大数目。

o     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可以取下述值之一:

o 0:该节点永远不会用作仲裁程序。

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

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

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

·[NDB_MGMD]ArbitrationDelay

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

·[NDB_MGMD]DataDir

它用于设置保存管理服务器输出文件的位置。这些文件包括簇日志文件、进程输出文件、以及端口监督程序的pid文件(对于日志文件,可通过设置[NDB_MGMD]LogDestination的FILE参数覆盖它,请参见本节前面的讨论)。

17.4.4.5. 定义MySQL簇数据节点

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

·ExecuteOnComputer或HostName.

·参数NoOfReplicas

这些参数需要在[NDBD DEFAULT]部分中定义。

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

识别数据节点

启动节点时,可在命令行上分配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(请参见前面的介绍)。

数据内存和索引内存

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

·[NDBD]DataMemory

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

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

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

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

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

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

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

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

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

·[NDBD]IndexMemory

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

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

考虑下例定义的表:

CREATE TABLE example (
  a INT NOT NULL,
  b INT NOT NULL,
  c INT NOT NULL,
  PRIMARY KEY(a),
  UNIQUE(b)
) ENGINE=NDBCLUSTER;

有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。

事务参数

下面讨论的三个参数十分重要,这是因为,它们会影响并发事务的数目,以及系统能够处理的事务的大小。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。

·[NDBD]MaxNoOfLocalOperations

默认情况下,将按照1.1 *MaxNoOfConcurrentOperations计算该参数,它适合于具有很多并发事务但不存在特大事务的系统。如果需要在某一时间处理特大事务而且有很多节点,最好通过明确指定该参数以覆盖默认值。

事务临时存储

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

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

·[NDBD]MaxNoOfConcurrentIndexOperations

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

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

·[NDBD]MaxNoOfFiredTriggers

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

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

·[NDBD]TransactionBufferMemory

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

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

扫描和缓冲

在Dblqh模块中(在ndb/src/kernel/blocks/Dblqh/Dblqh.hpp内)有很多附加参数,这些参数会影响读和写操作。这些参数包括:ZATTRINBUF_FILESIZE,默认值为10000*128字节(1250KB);以及ZDATABUF_FILE_SIZE,默认的缓冲空间大小为10000*16字节(约156KB)。到目前为止,没有任何迹象表明应增加这类编译时间限制参数的值,无论是用户报告还是我们自己的大量测试。

TransactionBufferMemory的默认值是1MB。

·[NDBD]MaxNoOfConcurrentScans

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

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

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

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

·[NDBD]MaxNoOfLocalScans

如果很多扫描不是完全并行化的,指定本地扫描记录的数目。

·[NDBD]BatchSizePerLocalScan

该参数用于计算锁定记录的数目,要想处理很多并发扫描操作,需要这类记录。

默认值是64,该值与SQL节点中定义的ScanBatchSize关系密切。

·[NDBD]LongMessageBuffer

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

日志和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个跟踪文件。

元数据对象

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

·[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.

·[NDBD]MaxNoOfIndexes

在MySQL 5.1中,该参数已被放弃,应使用MaxNoOfOrderedIndexes和MaxNoOfUniqueHashIndexes取而代之。

该参数仅供唯一性哈希索引使用。对于在簇中定义的每个唯一性哈希索引,在该池中需要有1条记录。

该参数的默认值为128.

布尔参数

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

·[NDBD]LockPagesInMainMemory

对于包括Solaris和Linux在内的很多操作系统,能够将进程锁定在内存中,以避免与磁盘的交换。使用它,可确保簇的实时特性。

默认情况下,该特性是被禁止的。

·[NDBD]StopOnError

出现错误时,该参数指定了NDBD进程是退出还是执行自动重启。

默认情况下,允许该特性。

·[NDBD]Diskless

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

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

允许该特性时,可执行备份操作,但不会实际保存备份数据。

将“Diskless”设置为“1”或“Y”可允许该特性。默认情况下,禁止该特性。

·[NDBD]RestartOnErrorInsert

仅当创建调试版时才能访问该特性,在执行作为测试组成部份的代码块的过程中,可以插入错误。

默认情况下,该特性是被禁止的。

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

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

·[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秒)。

缓冲和日志功能

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

将日志记录写入磁盘时,这些缓冲区用作文件系统的前端。如果节点运行在无盘模式下,那么可以将这些参数设置为它们的最小值而不会造成负面影响,这是因为,磁盘写入是由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.

备份参数

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

·[NDBD]BackupDataBufferSize

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

该参数的默认值为2MB。

·[NDBD]BackupLogBufferSize

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

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

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

默认值是2MB。

·[NDBD]BackupMemory

该参数是BackupDataBufferSize和BackupLogBufferSize之和。

默认值是2MB + 2MB = 4MB。

·[NDBD]BackupWriteSize

该参数指定了由备份日志缓冲和备份数据缓冲写入磁盘的消息大小。

默认值是32KB.

17.4.4.6. 定义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。

17.4.4.7. MySQL簇TCP/IP连接

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

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

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

·[TCP]NodeId1 ,[TCP]NodeId2

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

·[TCP]SendBufferMemory

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

·[TCP]SendSignalId

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

·[TCP]Checksum

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

·[TCP]PortNumber

(已过时)以前,该参数指定了用于监听来自其他节点的连接的端口号。不应再使用嘎参数。

·[TCP]ReceiveBufferMemory

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

17.4.4.8. 使用直接连接的MySQL簇TCP/IP连接

使用数据节点之间的直接连接建立簇时,需要在簇config.ini文件的[TCP]部分中明确指定如此连接的数据节点的交叉IP地址。

在下面的示例中,假定簇具有至少4台主机,1台用于管理服务器,一台用于SQL节点,两台用于数据节点。作为整体,簇位于LAN的172.23.72.*子网内。除了通常的网络连接外,两个数据节点使用标准的交叉电缆直接相连,并使用范围在1.1.0.*的IP地址彼此间直接通信,如下所示:

# Management Server
[NDB_MGMD]
Id=1
HostName=172.23.72.20
 
# SQL Node
[MYSQLD]
Id=2
HostName=172.23.72.21
 
# Data Nodes
[NDBD]
Id=3
HostName=172.23.72.22
 
[NDBD]
Id=4
HostName=172.23.72.23
 
# TCP/IP Connections
[TCP]
NodeId1=3
NodeId2=4
HostName1=1.1.0.1
HostName2=1.1.0.2

使用数据节点间的直接连接能够改善簇的整体效率,使用该方式,数据节点能绕过以太网设备,如交换器、Hub、路由器等,从而减少了簇的等待时间。注意,对于两个以上的数据节点,要想充分利用这类直接连接的优点,需要为各数据节点建立与相同节点组内的其他数据节点间的直接连接。

17.4.4.9. MySQL簇共享内存连接

MySQL簇将尝试使用共享内存传输器,并在可能的情况下自动配置它,尤其是在相同的簇主机上同时运行着1个以上的节点时。在MySQL簇的早期版本中,仅当使用--with-ndb-shm创建了-max二进制版本时,才支持共享内存段。明确地将共享内存定义为连接方法时,至少需要定义NodeId1、NodeId2和ShmKey。对于所有其他参数,应具有在大多数情况下均良好工作的默认值。

注释:SHM支持仍应被视为试验性的。

·[SHM]NodeId1,[SHM]NodeId2

要想确定两个节点之间的连接,需要为每个节点提供节点ID,NodeId1和NodeId2。

·[SHM]ShmKey

设置共享内存段时,节点ID用于唯一地确定通信所用的共享内存段。它以整数表示,没有默认值。

·[SHM]ShmSize

每个SHM连接均有一个共享内存段,发送方将节点之间的消息置于该处,读取方从该处读取这类消息。gai共享内存段的大小由ShmSize定义。默认值是1MB。

·[SHM]SendSignalId

为了回扫分布式消息的路径,需要为每条消息提供唯一性ID。如果将该参数设置为“Y”,也能在网络上传输这类消息ID。默认情况下,该特性是禁止的。

·[SHM]Checksum

该参数也是一种Y/N参数,默认情况下处于禁止状态。如果允许该参数,在将所有消息置于发送缓冲之前,对为所有消息计算校验和。

使用该特性,当消息等候在发送缓冲中时,能防止消息损坏。此外,它还能用于在传输过程中检查损坏的数据。

17.4.4.10. MySQL簇SCI传输连接

仅当使用--with-ndb-sci=/your/path/to/SCI创建了MySQL-Max二进制版本时,在MySQL簇中才支持使用SCI传输器来连接节点。path应指向包含最低库的目录,并应包括含SISCI库和头文件的目录。

此外,SCI要求专用硬件。

强烈建议,仅应为ndbd进程之间的通信使用SVI传输器。注意,使用SCI传输器意味着ndbd进程永不停止。因此,仅应在具有至少两块专供ndbd进程使用的CPU的机器上使用SCI传输器。每个ndbd进程至少应有1块CPU,至少还应有1块CPU用于处理操作系统的活动。

·[SCI]NodeId1,[SCI]NodeId2

为了确定两个节点之间的连接,需要为每个节点提供节点ID,NodeId1和NodeId2。

·[SCI]Host1SciId0

它用于确定第1个簇节点上的SCI节点ID(由NodeId1确定)。

·[SCI]Host1SciId1

能够为两块SCI卡间的故障切换设置SCI传输器,这两块卡应使用节点之间的不同网络。它用于确定节点ID,以及在第1个节点上使用的第2块SCI卡。

·[SCI]Host2SciId0

它用于确定第2个簇节点上的SCI节点ID(由NodeId2确定)。

·[SCI]Host2SciId1

使用两块SCI卡来提供故障切换功能时,该参数用于确定将在第2个节点上使用的第2块SCI卡。

·[SCI]SharedBufferSize

每个SCI传输器均有1个用于两节点间通信的共享内存段。可将该共享内存段设置为默认的1 MB,这足以应对大多数应用程序。如果使用较小的值,当执行大量并行插入操作时,会出现问题,如共享缓冲过小,还会导致ndbd进程崩溃。

·[SCI]SendLimit

SCI媒介前面的小缓冲用于保存消息,在通过SCI网络传输这类消息前,会将它们保存在该缓冲内。它的默认值为8kB。按照我们的基准,在64KB时性能最好,但16kB仅有少量提升,即使大于8KB有好处,好处也不大。

·[SCI]SendSignalId

为了跟踪分布式消息,需要唯一地确定每条消息。将该参数设置为“Y”时,就能在网络上传输消息ID。默认情况下禁止该特性。

·[SCI]Checksum

T该参数也是一种布尔值,默认情况下,该参数是被禁止的。启用了Checksum(校验和)时,在将所有消息置于发送缓冲之前,将为所有参数计算校验和。使用该特性,当消息等候在发送缓冲中时,可以确保消息不会损坏。此外,它还能用于在传输过程中检查损坏的数据。