第 16 章 MySQL Cluster node
前言: mysql
MySQL Cluster 是一个基于 NDB Cluster 存储引擎的完整的分布式数据库系统。不只仅具备高可用性,并且能够自动切分数据,冗余数据等高级功能。和 Oracle Real Cluster Application 不太同样的是,MySQL Cluster 是一个 Share Nothing 的架构,各个 MySQL Server 之间并不共享任何数据,高度可扩展以及高度可用方面的突出表现是其最大的特点。
虽然目前还只是 MySQL 家族中的一个新兴产品,可是已经有很多企业正在积极的尝试使用了。本章咱们将经过对 MySQL Cluster 的了解来寻找其在可扩展设计方面的优点。 web
16.1 MySQL Cluster介绍 sql
简单的说,MySQL Cluster其实是在无共享存储设备的状况下实现的一种彻底分布式数据库系统,其主要经过NDB Cluster(简称NDB)存储引擎来实现。MySQL Cluster 刚刚诞生的时候能够说是一个能够对数据进行持久化的内存数据库,全部数据和索引都必须装载在内存中才可以正常运行,可是最新的 MySQL Cluster 版本已经能够作到仅仅将全部索引装载在内存中便可,实际的数据能够不用所有装载到内存中。
一个MySQL Cluster的环境主要由如下三部分组成:
a) SQL层的SQL服务器节点(后面简称为SQL节点),也就是咱们常说的MySQL Server。
主要负责实现一个数据库在存储层之上的全部事情,好比链接管理,Query 优化和响应, Cache 管理等等,只有存储层的工做交给了 NDB 数据节点去处理了。也就是说,在纯粹的MySQL Cluster环境中的SQL节点,能够被认为是一个不须要提供任何存储引擎的 MySQL服务器,由于他的存储引擎有Cluster环境中的 NDB 节点来担任。因此,SQL层各MySQL 服务器的启动与普通的 MySQL Server 启动也有必定的区别,必需要添加ndbcluster参数选项才行。咱们能够添加在my.cnf配置文件中,也能够经过启动命令行来指定。
b) Storage 层的 NDB 数据节点,也就是上面说的 NDB Cluster。
最初的 NDB 是一个内存式存储引擎,固然也会将数据持久化到存储设备上。可是最新的 NDB Cluster 存储引擎已经改进了这一点,能够选择数据是所有加载到内存中仍是仅仅加载索引数据。NDB 节点主要是实现底层数据存储功能,来保存Cluster的数据。每个Cluster节点保存完整数据的一个fragment,也就是一个数据分片(或者一份完整的数据,视节点数目和配置而定),因此只要配置得当,MySQL Cluster在存储层不会出现单点的问题。通常来讲,NDB 节点被组织成一个一个的NDB Group,一个NDB Group实际上就是一组存有彻底相同的物理数据的NDB节点群。
上面提到了NDB各个节点对数据的组织,可能每一个节点都存有所有的数据也可能只保存一部分数据,主要是受节点数目和参数来控制的。首先在MySQL Cluster主配置文件(在管理节点上面,通常为config.ini)中,有一个很是重要的参数叫NoOfReplicas,这个参数指定了每一份数据被冗余存储在不一样节点上面的份数,该参数通常至少应该被设置成2,也只须要设置成2就能够了。由于正常来讲,两个互为冗余的节点同时出现故障的几率仍是很是小的,固然若是机器和内存足够多的话,也能够继续增大来更进一步减少出现故障的几率。
此外,一个节点上面是保存全部的数据仍是一部分数据还受到存储节点数目的限制。NDB存储引擎首先保证NoOfReplicas参数配置的要求来使用存储节点,对数据进行冗余,而后再根据节点数目将数据分段来继续使用多余的NDB节点。分段的数目为节点总数除以NoOfReplicas所得。
c) 负责管理各个节点的Manage节点主机:
管理节点负责整个Cluster集群中各个节点的管理工做,包括集群的配置,启动关闭各节点,对各个节点进行常规维护,以及实施数据的备份恢复等。管理节点会获取整个Cluster环境中各节点的状态和错误信息,而且将各Cluster集群中各个节点的信息反馈给整个集群中其余的全部节点。因为管理节点上保存了整个Cluster环境的配置,同时担任了集群中各节点的基本沟通工做,因此他必须是最早被启动的节点。
下面是一幅 MySQL Cluster 的基本架构图(出自 MySQL 官方文档手册): 数据库
经过图中咱们能够更清晰的了解整个 MySQL Cluster 环境各个节点以及客户端应用之间的关系。
因为 MySQL Cluster 目前的成熟使用并非太多,实现也较普通的 MySQL 略复杂,因此本章将首先从如何搭建一个 MySQL Cluster 环境开始来介绍他。 数组
16.2 MySQL Cluster环境搭建 服务器
搭建MySQL Cluster首先须要至少一个管理节点主机来实现管理功能,一个SQL节点主机来实现MySQL server功能和两个ndb节点主机实现NDB Cluster的功能。在后面的介绍中,我采用双SQL节点来搭建测试环境,具体信息以下:
一、硬件准备
a) MySQL节点1 192.168.0.1
b) MySQL节点2 192.168.0.2
c) ndb节点1 192.168.0.3
d) ndb节点2 192.168.0.4
e) 管理节点 192.168.0.5
二、软件安装
首先在上面5个节点的主机上尽可能确保环境基本一致,而后从MySQL官方下载相应的软件包并分发到两台SQL节点和两台NDB节点上,以备后面的安装时候的使用。
个人测试环境OS(RedHat Linux)以下(非必须):
root@mysql1:/usr/local>uname -a
Linux oratest1 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686
i686 i386 GNU/Linux
a) 安装MySQL节点:
在MySQL节点上面须要安装支持cluster的MySQL Server,能够经过自编译源代码安装也能够选择MySQL官方提供的编译好的tar包或者rpm安装包,我是经过源代码自行编译的,实际上彻底能够经过MySQL官方提供的通过优化编译的二进制tar包,只是我本身习惯了而已,个人编译设置参数以下:
root@mysql1>./configure \
--prefix=/usr/local/MySQL \
--without-debug \
--without-bench \
--enable-thread-safe-client \
--enable-assembler \
--with-charset=utf8 \
--with-extra-charsets=complex \
--with-client-ldflags=-all-static \
--with-MySQLd-ldflags=-all-static \
--with-ndbcluster \
--with-server-suffix=-max \
--datadir=/data/mysqldata \
--with-unix-socket-path=/usr/local/MySQL/sock/mysql.sock
...
root@mysql1>make
...
root@mysql1>make install
...
而后是配置设置配置文件/etc/my.cnf,因为是测试环境,因此我仅仅设置了ndbcluster所须要的最基本的两个配置项,其余全部的配置均用默认配置(后面会有较为详细的配置说明),以下:
root@mysql1>vi /etc/my.cnf
[client]
socket = /usr/local/mysql/sock/mysql.sock #因为编译时候特殊指定了,因此设置在这里,方便之后登入的时候使用
[MySQLd]
socket = /usr/local/mysql/sock/mysql.sock
ndbcluster
[MySQL_cluster]
ndb-connectstring = 192.168.0.5
继续完成后面的MySQL安装过程:
root@mysql1>cd /usr/local/mysql
root@mysql1>bin/mysql_install_db --user=mysql --
socket=/usr/local/mysql/sock/mysql.sock
Installing MySQL system tables...
OK
Filling help tables...
OK
To start MySQLd at boot time you have to copy
support-files/MySQL.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/local/mysql/bin/MySQLadmin -u root password 'new-password'
/usr/local/mysql/bin/MySQLadmin -u root -h ointest_stb password 'new-
password'
Alternatively you can run:
/usr/local/mysql/bin/MySQL_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr/local/MySQL ; /usr/local/mysql/bin/MySQLd_safe
You can test the MySQL daemon with MySQL-test-run.pl
cd MySQL-test ; perl MySQL-test-run.pl
Please report any problems with the /usr/local/mysql/bin/MySQLbug script!
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
root@mysql1>chown -R root .
root@mysql1>chgrp -R mysql .
root@mysql1>chown -R mysql.mysql /usr/local/mysql/etc
root@mysql1>chown -R mysql.mysql /usr/local/mysql/sock
root@mysql1>chown -R mysql.mysql /usr/local/mysql/log
root@mysql1>:/usr/local/mysql# ls -l
total 40
drwxr-xr-x 2 root MySQL 4096 May 4 14:47 bin
drwxr-xr-x 2 MySQL MySQL 4096 May 4 14:20 etc
drwxr-xr-x 3 root MySQL 4096 May 4 14:46 include
drwxr-xr-x 2 root MySQL 4096 May 4 14:46 info
drwxr-xr-x 3 root MySQL 4096 May 4 14:46 lib
drwxr-xr-x 2 root MySQL 4096 May 4 14:47 libexec
drwxr-xr-x 2 MySQL MySQL 4096 May 4 14:20 log
drwxr-xr-x 4 root MySQL 4096 May 4 14:47 man
drwxr-xr-x 9 root MySQL 4096 May 4 14:47 MySQL-test
drwxr-xr-x 2 MySQL MySQL 4096 May 5 22:16 sock
root@mysql1>:/usr/local/mysql#
b) 安装ndb节点:
若是但愿尽量的各环境保持一致,建议在NDB节点也和SQL节点同样安装整个带有NDB Cluster存储引擎的MySQL Server。因为安装细节和上面的SQL节点彻底同样, 因此这里就再也不累述。
另外,若是只是为了保证可以完整的MySQL Cluster这个环境,则在NDB节点上彻底能够仅安装NDB存储引擎(mysql ndb storage engine)便可。安装NDB存储引擎好像目前是找不到源码来自行编译安装的,只能经过MySQL AB官方提供的rpm包来安装。安装过程很是简单,和其余的rpm软件包安装没有任何区别。
c) 管理节点:
管理节点所须要的安装更简单,实际上只须要ndb_mgm和ndb_mgmd两个程序便可,这两个可执行程序能够在上面的MySQL节点的MySQL安装目录中的bin目录下面找到。将这两个程序copy到管理节点上面合适的位置(自行考虑,我通常会放在/usr/local/mysql/bin下面),并在path制定的目录中创建两个同名的soft link在到这两个程序上面,就能够了。
以上便是MySQL Cluster环境的软件安装过程,看上去并不复杂是吧,但愿你们的安装过程也可以一切顺利,固然若是遇到了什错误也不用担忧,MySQL官方手册中也提供了很是详细的安装过程说明。网络
三、基本配置
在上面全部节点的软件安装完成以后,就是MySQL Cluster环境的配置工做了。若是不考虑其余一些优化和个性化的配置需求,MySQL Cluster的基本配置是比较简单的。这里暂时先仅仅完成一个简单的测试环境的配置,详细的配置说明请看后面的MySQL Cluster配置介绍的章节。
对于MySQL节点和ndb节点在上面的安装过程当中已经完成了,仅须要设置[MySQL_cluster]参数组的ndb-connectstring参数便可完成最基本的配置。
管理节点的配置稍微复杂一点,由于他须要配置出Cluster环境中每个节点的基本信息。配置文件并不须要一个特别固定的位置和名称,都由用户自行设定,只须要在启动过程当中指定配置文件便可。在咱们的测试环境中配置为建名称为/var/lib/MySQL-cluster/config.ini,内容以下:
[root@mysqlMgm ~]# cat /var/lib/mysql-cluster/config.ini
[NDBD DEFAULT]
NoOfReplicas=2
DataMemory=64M
IndexMemory=16M
[TCP DEFAULT]
portnumber=2202
#管理节点
[NDB_MGMD]
id=1
hostname=192.168.0.5
datadir=/var/lib/mysql-cluster
#第一个ndbd节点:
[NDBD]
id=2
hostname=192.168.0.3
datadir=/data/mysqldata
#第二个ndbd节点:
[NDBD]
id=3
hostname=192.168.0.4
datadir=/drbddata/mysqldata
# SQL node options:
[MySQLD]
id=4
hostname=192.168.0.1
[MySQLD]
id=5
hostname=10.0.65.203
[root@mysqlMgm ~]#
1) SQL节点的配置:
MySQL节点的配置和普通的MySQL Server的配置区别主要是须要在my.cnf文件中增长[mysql_cluster]这个配置选项组,并至少指定ndb-connectstring=192.168.0.5,也就是制定管理节点的ip地址或者hostname。另外,若是但愿能在启动MySQLd的时候不用手动指定ndbcluster参数,则在[mysqld]参数选项组中增长ndbcluster项参数。除了这两项以外,其余的全部参数均可以可使用默认值。
2) NDB存储节点的配置:
NDB存储节点的配置就更简单的了,仅仅需[mysql_cluster]中的ndb-connectstring = 192.168.0.5 参数,其余全部的均可以再也不配置了。
四、环境测试
在MySQL Cluster环境搭建完成后,首先确定要对新搭建的环境进行一些基本的功能和异常测试,以确认搭建的环境是否已经能够正常提供服务。
1) 首先检测ndb引擎是否已经正常工做
经过任意客户端链接任意选定的一个SQL节点,测试各类基本的ddl,dml操做, 而后再经过客户端链接上Cluster环境中另外的SQL节点校验所做的草食是否在其余节点一样可见了。下面是测试create table 后再插入一条数据的示例:
在节点4上面:
mysql>use test;
mysql>create table t1 ( a int) engine=ndb;
Query ok, 0 rows affected (0.00 sec)
mysql>insert into t1 values(100);
Query ok, 1 rows affected (0.00 sec)
而后在节点5上面:
mysql>use test;
mysql>select * from t1;
+-----+
| id |
+-----+
| 100 |
+-----+
1 row in set (0.00 sec)
可见,在节点4上面所插入的数据,已经在节点5上面了,说明ndb引擎工做正常的。其余的测试与此相似,你们能够自行测试。
若是在测试中发如今某两个节点之间出现不一致现象,那么能够确定的是,Cluster 环境的配置有问题。在管理节点上面经过“ndb_mgm -e SHOW”命令查看各节点状态是否正常,是否都已经链接到了管理节点上面。并检查不正常节点的my.cnf配置文件,是否已经配置好了以ndbcluster方式启动MySQLd,是否有正确配置[mysql_cluster]这个参数组的最基本的ndb-connectstring参数。而后检查管理节点上面的config文件,里面是否有正确配置好各全部节点的配置,尤为是不正常的SQL节点的配置。
2) 检测冗余环境的单点故障问题
a、模拟NDB节点Crash
因为是模拟Crash,因此咱们经过在节点2上面kill掉ndb进程,而后再分别经过两个SQL节点去访问t1表,查看是否能够正常访问,数据是否同样。
在节点4上面:
mysql> use test;
mysql> select * from t1;
+-----+
| id |
+-----+
| 100 |
+-----+
1 row in set (0.00 sec)
mysql> insert into t1 values(200);
Query ok, 1 rows affected (0.00 sec)
在节点5上面:
mysql>use test;
mysql>select * from t1;
+-----+
| id |
+-----+
| 100 |
| 200 |
+-----+
2 row in set (0.00 sec)
mysql> delete from t1 where id = 100;
Query ok, 1 rows affected (0.00 sec)
再回到节点4上面:
mysql> select * from t1;
+-----+
| id |
+-----+
| 200 |
+-----+
1 row in set (0.00 sec)
能够看到,不只t1仍然能够正常访问,数据也没有任何丢失,且仍然能够正常插入,删除数据。可见,在有一个NDB节点Crash以后,真个MySQL Cluster环境仍然能够正常提供服务。固然,若是两个NDB节点都Crash以后,MySQL Cluster环境就没法正常提供服务了,你们也能够自行测试一下。
b、模拟SQL节点Crash
一样和测试NDB节点Crash同样,kill掉一个SQL节点(好比节点4)的mysqld 进程,而后经过节点5进行访问:
在节点5上面:
mysql> use test;
mysql> select * from t1;
+-----+
| id |
+-----+
| 200 |
+-----+
1 row in set (0.00 sec)
mysql> insert into t1 values(300);
Query ok, 1 rows affected (0.00 sec)
mysql> select * from t1;
+-----+
| id |
+-----+
| 200 |
| 300 |
+-----+
2 row in set (0.00 sec)
能够看到,当节点4 Crash以后,节点5仍然可以提供正常的服务。固然,若是在应用环境中,应用环境须要至少支持当一个SQL节点出现问题的时候可以自行切换到剩下的正常的SQL节点来访问。
c、管理节点的单点
通常状况来讲,管理节点是最容易控制的,实施也很是简单,只须要将配置文件和
两个可执行程序(ndb_mgmd和ndb_mgm)存放在多台机器上面便可,因此通常来讲不须要太多考虑单点故障。 架构
16.3 MySQL Cluster配置详细介绍(config.ini)并发
在MySQL Cluster环境的配置文件config.ini里面,每一类节点都有两个(或以上)的相应配置项组,每一类节点的配置项都主要由两部分组成,一部分是同类全部节点相同的配置项组,在[NDB_MGM DEFAULT]、[NDBD DEFAULT]和[MySQLD DEFAULT]这三个配置组里面, 并且每个配置组只出现一次;而另一部分则是针对每个节点独有配置内容的配置项组[NDB_MGM]、[NDBD]和[MySQLD],因为这三类配置组中配置的每个节点独有的个性化配置,因此每个配置组均可能会出现屡次(每个节点一次)。下面是每一类节点的各类配置说明:
一、管理节点相关配置
在整个MySQL Cluster环境中,管理节点相关的配置为[NDBD_MGM DEFAULT]和[NDB_MGMD]相关的两组:
1) [NDB_MGMD DEFAULT]中各管理节点的共用配置项:
PortNumber:配置管理节点的服务端程序(ndb_mgmd)监听客户端(ndb_mgm)链接请求和发送的指令,从文档上能够查找到,默认端口是1186端口。通常来讲这一项不须要更改,固然若是是为了在同一台主机上面启动多个管理节点的话,确定须要将两个管理节点启动不一样的监听端口;
LogDestination:配置管理节点上面的cluster日志处理方式。
a) 能够写入文件如:LogDestination=FILE:filename=my-
cluster.log,maxsize=500000,maxfiles=4;
b) 也能够经过标准输出来打印出来如:LogDestination=CONSOLE;
c) 还能够计入syslog里面如:LogDestination=SYSLOG:facility=syslog;
d) 甚至多种方式共存:
LogDestination=CONSOLE;SYSLOG:facility=syslog;FILE:filename=/var/log/cluster- log
Datadir:设置用于管理节点存放文件输出的位置。如process文件(.pid),cluster log文件(当LogDestination有FILE处理方式存在时候)。
ArbitrationRank:配置各节点在处理某些事件出现分歧的时候的级别。有0,1,2 三个值能够选择。
a) 0表明本节点彻底听其余节点的,不参与决策
b) 1表明本节点有最高优先权,“一切由我来决策”
c) 2表明本节点参与决策,可是优先权较1低,可是比0高
ArbitrationRank参数不只仅管理节点有,MySQL节点也有。并且通常来讲,全部的管理节点通常都应该设置成1,全部SQL节点都设置成2。
2) [NDB_MGMD]是每一个管理节点配置一组,所需配置项以下(下面的参数只能设置在[NDB_MGMD]参数组中):
Id:为节点指定一个惟一的ID号,要求在整个Cluster环境中惟一;
Hostname:配置该节点的IP地址或者主机名,若是是主机名,则该主机名必需要在配置文件所在的节点的/etc/hosts文件中存在,并且绑定的IP是准确的。
上面[NDB_MGMD DEFAULT]里面的全部参数项,均可以设置在下面的[NDB_MGMD]参数组里面,可是Id和Hostname两个参数只能设置在[NDB_MGMD]里面,而不能设置在[NDB_MGMD DEFAULT]里面,由于这两个参数项针对每个节点都是不相同的内容。
二、NDB节点相关配置
NDB节点和管理节点同样,既有各个节点共用的配置信息组[NDBD DEFAULT],也有每个节点个性化配置的[NDBD]配置组(实际上SQL节点也是如此)。
1) [NDBD DEFAULT]中的配置项:
NoOfReplicas:定义在Cluster环境中相同数据的分数,通俗一点来讲就是每一份数据存放NoOfReplicas份。若是但愿可以冗余,那么至少设置为2(通常状况来讲此参数值设置为2就够了),最大只能设置为4。另外,NoOfReplicas值得大小,实际上也就是node group大小的定义。NoOfReplicas参数没有系统默认值,因此必须设定,并且只能设置在[NDBD DEFAULT]中,由于此数值在整个Cluster集群中一个node group中全部的NDBD节点都须要同样。另外NoOfReplicas的数目对整个Cluster环境中NDB节点数量有较大的影响, 由于NDB节点总数量是NoOfReplicas * 2 * node_group_num;
DataDir:指定本地的pid文件,trace文件,日志文件以及错误日志子等存放的路径,无系统默认地址,因此必须设定;
DataMemory:设定用于存放数据和主键索引的内存段的大小。这个大小限制了能存放的数据的大小,由于ndb存储引擎需属于内存数据库引擎,须要将全部的数据(包括索引)都load到内存中。这个参数并非必定须要设定的,可是默认值很是小(80M),只也就是说若是使用默认值,将只能存放很小的数据。参数设置须要带上单位,如512M,2G等。另外,DataMemory里面还会存放UNDO相关的信息,因此,事务的大小和事务并发量也决定了DataMemory的使用量,建议尽可能使用小事务;
IndexMemory:设定用于存放索引(非主键)数据的内存段大小。和DataMemory相似,这个参数值的大小一样也会限制该节点能存放的数据的大小,由于索引的大小是随着数据量增加而增加的。参数设置也如DataMemory同样须要单位。IndexMemory默认大小为18M;
实际上,一个NDB节点能存放的数据量是会受到DataMemory和IndexMemory两个参数设置的约束,二者任何一个达到限制数量后,都没法再增长能存储的数据量。若是继续存入数据系统会报错“table is full”。
FileSystemPath:指定redo日志,undo日志,数据文件以及meta数据等的存放位置,默认位置为DataDir的设置,而且在ndbd初始化的时候,参数所设定的文件夹必须存在。在第一次启动的时候,ndbd进程会在所设定的文件夹下创建一个子文件夹叫ndb_id_fs,这里的id为节点的ID值,如节点id为3则文件夹名称为ndb_3_fs。固然,这个参数也不必定非得设置在[NDBD DEFAULT]参数组里面让全部节点的设置都同样(不过建议这样设置),还能够设置在[NDBD]参数组下为每个节点单独设置本身的FileSystemPath值;
BackupDataDir:设置备份目录路径,默认为FileSystemPath/BACKUP。
接下来的几个参数也是很是重要的,主要都是与并行事务数和其余一些并行限制有关的参数设置。
MaxNoOfConcurrentTransactions:设置在一个节点上面的最大并行事务数目,默认为4096,通常状况下来讲是足够了的。这个参数值全部节点必须设置同样,因此通常都是设置在[NDBD DEFAULT]参数组下面;
MaxNoOfConcurrentOperations:设置同时可以被更新(或者锁定)的记录数量。
通常来讲能够设置为在整个集群中相同时间内可能被更新(或者锁定)的总记录数,除以NDB节点数,所获得的值。好比,在集群中有两个NDB节点,而但愿可以处理同时更新(或锁定)100000条记录,那么此参数应该被设置为:100000 / 4 = 25000。此外,这里的记录数量并非指单纯的表里面的记录数,而是指事物里面的操做记录。当使用到惟一索引的时候,表的数据和索引二者都要算在里面,也就是说,若是是经过一个惟一索引来做为过滤条件更新某一条记录,那么这里算是两条操做记录。并且即便是锁定也会产生操做记录,好比经过惟一索引来查找一条记录,就会产生以下两条操做记录:经过读取惟一索引中的某个记录数据会产生锁定,产生一条操做记录,而后读取基表里面的数据,这里也会产生读锁,也会产生一条操做记录。MaxNoOfConcurrentOperations参数的默认值为32768。当咱们额度系统运行过程当中,若是出现此参数不够的时候,就会报出“Out of operation records in transaction coordinator”这样的错误信息;MaxNoOfLocalOperations:此参数默认是MaxNoOfConcurrentOperations * 1.1 的大小,也就是说,每一个节点通常能够处理超过平均值的10%的操做记录数量。可是通常来讲,MySQL建议单独设置此参数而不要使用默认值,而且将此参数设置得更较大一些;
如下的三个参数主要是在一个事务中执行一条query的时候临时用到存储(或者内存)的状况下所使用到的,所使用的存储信息会在事务结束(commit或者rollback)的时候释放资源;
MaxNoOfConcurrentIndexOperations:这个参数和MaxNoOfConcurrentOperations参数比较相似,只不过所针对的是Index的record而已。其默认值为8192,对伊通常的系统来讲都已经足够了,只有在事务并发很是很是大的系统上才有须要增长这个参数的设置。
固然,此参数越大,系统运行时候为此而消耗的内存也会越大;
MaxNoOfFiredTriggers:触发惟一索引(hash index)操做的最大的操做数,这个操做数是影响索引的操做条目数,而不是操做的次数。系统默认值为4000,通常系统来讲够用了。固然,若是系统并发事务很是高,并且涉及到索引的操做也很是多,天然也就须要提升这个参数值的设置了;
TransactionBufferMemory:这个buffer值得设置主要是指定用于跟踪索引操做而使用的。主要是用来存储索引操做中涉及到的索引key值和column的实际信息。这个参数的值通常来讲也不多须要调整,由于实际系统中须要的这部分buffer量很是小,虽然默认值只是1M,可是对于通常应用也已经足够了;
下面要介绍到的参数主要是在系统处理中作table scan或者range scan的时候使用的一些buffer的相关设置,设置的恰当能够既节省内存又达到足够的性能要求。
MaxNoOfConcurrentScans:这个参数主要控制在Cluster环境中并发的table scan和range scan的总数量平均分配到每个节点后的平均值。通常来讲,每个scan都是经过并行的扫描全部的partition来完成的,每个partition的扫描都会在该partition 所在的节点上面使用一个scan record。因此,这个参数值得大小应该是“scan record” 数目 * 节点数目。参数默认大小为256,最大只能设置为500;
MaxNoOfLocalScans:和上面的这个参数相对应,只不过设置的是在本节点上面的并发table scan和range scan数量。若是在系统中有大量的并发并且通常都不使用并行的话,须要注意此参数的设置。默认为MaxNoOfConcurrentScans * node数目;
BatchSizePerLocalScan:该参用于计算在Localscan(并发)过程当中被锁住的记录数,文档上说明默认为64;
LongMessageBuffer:这个参数定义的是消息传递时候的buffer大小,而这里的消息传递主要是内部信息传递以及节点与节点之间的信息传递。这个参数通常不多须要调整,默认大小为1MB大小;
下面介绍一下与log相关的参数配置说明,包括log level。这里的log level有多种,从0到15,也就是共16种。若是设定为0,则表示不记录任何log。若是设置为最高level,也就是15,则表示全部的信息都会经过标准输出来记录log。因为这里的全部信息实际上都会传递到管理节点的cluster log中,因此,通常来讲,除了启动时候的log级别须要设置为1以外,其余全部的log level都只须要设置为0就能够了。
NoOfFragmentLogFiles:这个参数实际上和Oracle的redo log的group同样的。
其实就是ndb的redo log group数目,这些redo log用于存放ndb引擎所作的全部须要变动数据的事情,以及各类checkpoint信息等。默认值为8;
MaxNoOfSavedMessages:这个参数设定了能够保留的trace文件(在节点crash的时候参数)的最大个数,文档上面说此参数默认值为25。
LogLevelStartup:设定启动ndb节点时候须要记录的信息的级别(不一样级别所记录的信息的详细程度不同),默认级别为1;
LogLevelShutdown:设定关闭ndb节点时候记录日志的信息的级别,默认为0;
LogLevelStatistic:这个参数是针对于统计相关的日志的,就像更新数量,插入数量,buffer使用状况,主键数量等等统计信息。默认日志级别为0;
LogLevelCheckpoint:checkpoint日志记录级别(包括local和global的),默认为0;
LogLevelNodeRestart:ndb节点重启过程日志级别,默认为0;
LogLevelConnection:各节点之间链接相关日志记录的级别,默认0;
LogLevelError:在整个Cluster中错误或者警告信息的日志记录级别,默认0;
LogLevelInfo:普通讯息的日志记录级别,默认为0。
这里再介绍几个用来做为log记录时候须要用到的Buffer相关参数,这些参数对于性能都有必定的影响。固然,若是节点运行在无盘模式下的话,则影响不大。
UndoIndexBuffer:undo index buffer主要是用于存储主键hash索引在变动以后产生的undo信息的缓冲区。默认值为2M大小,最小能够设置为1M,对于大多数应用来讲, 2M的默认值是够的。固然,在更新很是频繁的应用里面,适当的调大此参数值对性能仍是有必定帮助的。若是此参数过小,会报出677错误:Index UNDO buffers overloaded;
UndoDataBuffer:和undo index buffer相似,undo data buffer主要是在数据发生变动的时候所须要的undo信息的缓冲区。默认大小为16M,最小一样为1M。当这个参数值过小的时候,系统会报出以下的错误:Data UNDO buffers overloaded,错误号为891;
RedoBuffer:Redo buffer是用redo log信息的缓冲区,默认大小为8M,最小为1M。
若是此buffer过小,会报1221错误:REDO log buffers overloaded。
此外,NDB节点还有一些和metadata以及内部控制相关的参数,但大部分参数都基本上不须要任何调整,因此就不作进一步介绍。若是有兴趣但愿详细了解,能够根据MySQL 官方的相关参考手册,手册上面都有较为详细的介绍。
三、SQL节点相关配置说明
1) 和其余节点同样,先介绍一些适用于全部节点的[MySQLD DEFAULT]参数ArbitrationRank:这个参数在介绍管理节点的参数时候已经介绍过了,用于设定节点级别(主要是在多个节点在处理相关操做时候出现分歧时候设定裁定者)的。通常来讲,全部的SQL节点都应该设定为2;
ArbitrationDelay:默认为0,裁定者在开始裁定以前须要被delay多久,单位为毫秒。通常不须要更改默认值。
BatchByteSize:在作全表扫描或者索引范围扫描的时候,每一次fatch的数据量,默认为32KB;
BatchSize:相似BatchByteSize参数,只不过BatchSize所设定的是每一次fetch的record数量,而不是物理总量,默认为64,最大为992(暂时还不知道这个值是基于什么理论而设定的)。在实际运行query的过程当中,fetch的量受到BatchByteSize和BatchSize两个参数的共同制约,两者取最小值;
MaxScanBatchSize:在Cluster环境中,进行并行处理的状况下,全部节点的BatchSize总和的最大值。默认值为256KB,最大值为16MB。
2) 每一个节点独有的[MySQLD]参数组,仅有id和hostname参数须要配置,在以前各种节点均有介绍了,这里就再也不累述。
16.4 MySQL Cluster基本管理与维护
MySQL Cluster的管理和普通的MySQL Server管理区别较大,基本上大部分管理工做都是在管理节点上面完成,仅有少数管理内容须要在其余节点实施。
一、各节点启动与关闭
要想Cluster环境可以正常工做,只好要启动一个NDB节点和一个SQL节点,另外为了完成管理,也至少要启动一个管理节点。各种节点的启动顺序也有要求,首先是管理节点,而后是NDB节点,最后才是SQL节点。
1) 按顺序启动各节点:
a、 启动管理节点:
[root@localhost MySQL-cluster]# ndb_mgmd -f /var/lib/MySQL- cluster/config.ini
这里执行的ndb_mgmd命令实际上就是MySQL Cluster管理服务器,能够经过-f config_file_name或者--config=config_filename来指定MySQL Cluster集群的参数文件。
若是想了解更多关于ndb_mgmd的参数信息,能够经过运行ndb_mgmd --help来获取更详细的信息。
b、 启动用于存储数据的ndb节点要启动存储节点,必须在每一台ndb节点主机上面都执行ndbd程序,若是是第一
次启动,则须要添加--initial参数,以便进行ndb节点的初始化工做。可是,在之后的启动过程当中,是不能添加该参数的,不然ndbd程序会清除在以前创建的全部用于恢复的数据文件和日志文件。启动命令以下
root@ndb1:/root>ndbd --initial
c、 启动SQL节点
SQL节点的启动和普通MySQL Server的启动没有太多明显的差异,不过有一个前提就是须要在MySQL Server的配置文件my.cnf设置好[MySQL_cluster]配置组中的ndb-connectstring参数和[MySQLd]配置组中的ndbcluster参数。
root@mysql1:/root>MySQLd_safe --user=MySQL
2) 节点状态检查:
在各节点都启动完成后,回到管理节点,能够经过ndb_mgm来查看各节点状态:
[root@localhost MySQL-cluster]# ndb_mgm -e SHOW
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @192.168.0.3 (Version: 5.0.51, Nodegroup: 0, Master)
id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.5 (Version: 5.0.51)
[MySQLd(API)] 2 node(s)
id=4 @192.168.0.1 (Version: 5.0.51)
id=5 @10.0.65.203 (Version: 5.0.51)
这里显示出整个集群有5个几点,其中各节点信息以下:
a) 2个NDBD节点:
[ndbd(NDB)] 2 node(s)
id=2 @192.168.0.3 (Version: 5.0.51, Nodegroup: 0, Master)
id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0)
b) 两个SQL节点:
[MySQLd(API)] 2 node(s)
id=4 @192.168.0.1 (Version: 5.0.51)
id=5 @10.0.65.203 (Version: 5.0.51)
c) 1个管理节点:
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.5 (Version: 5.0.51)
3) 节点的关闭操做:
在MySQL Cluster环境中,NDB节点和管理节点的关闭均可以在管理节点的管理程序中完成,可是SQL节点却没办法。因此,在关闭整个MySQL Cluster环境或者关闭某个SQL节点的时候,首先必须到SQL节点主机上来关闭SQL节点程序。关闭方法和MySQL Server的关闭同样,就不累述。而NDB节点和管理节点则均可以在管理节点经过管理程序来完成:
ndb_mgm> shutdown
Connected to Management Server at: localhost:1186
Node 3: Cluster shutdown initiated
Node 2: Cluster shutdown initiated
Node 2: Node shutdown completed.
Node 3: Node shutdown completed.
2 NDB Cluster node(s) have shutdown.
Disconnecting to allow management server to shutdown.
二、基本管理维护
前面运行的命令ndb_mgm若是不带任何参数,其实是进入MySQL Cluster的命令行管理界面。在命令行管理界面里面能够作大量的维护工做,以下:
[root@localhost MySQL-cluster]# ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm>
而后一样执行show命令:
ndb_mgm>show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 (not connected, accepting connect from 192.168.0.3)
id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0, Master)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.5 (Version: 5.0.51)
[MySQLd(API)] 2 node(s)
id=4 @192.168.0.1 (Version: 5.0.51)
id=5 @10.0.65.203 (Version: 5.0.51)
咱们能够看到结果和上面的彻底同样。能够经过在ndb控制界面下执行help命令查看能够查看不少基本的维护管理命令:
ndb_mgm> help
---------------------------------------------------------------------------
NDB Cluster -- Management Client -- Help
---------------------------------------------------------------------------
HELP Print help text
HELP COMMAND Print detailed help for COMMAND(e.g. SHOW)
SHOW Print information about cluster
START BACKUP [NOWAIT | WAIT STARTED | WAIT COMPLETED]
Start backup (default WAIT COMPLETED)
ABORT BACKUP <backup id> Abort backup
SHUTDOWN Shutdown all processes in cluster
CLUSTERLOG ON [<severity>] ... Enable Cluster logging
CLUSTERLOG OFF [<severity>] ... Disable Cluster logging
CLUSTERLOG TOGGLE [<severity>] ... Toggle severity filter on/off
CLUSTERLOG INFO Print cluster log information
<id> START Start data node (started with -n)
<id> RESTART [-n] [-i] Restart data or management server node
<id> STOP Stop data or management server node
ENTER SINGLE USER MODE <id> Enter single user mode
EXIT SINGLE USER MODE Exit single user mode
<id> STATUS Print status
<id> CLUSTERLOG {<category>=<level>}+ Set log level for cluster log
PURGE STALE SESSIONS Reset reserved nodeid's in the mgmt server
CONNECT [<connectstring>] Connect to management server
(reconnect if already connected)
QUIT Quit management client
<severity> = ALERT | CRITICAL | ERROR | WARNING | INFO | DEBUG
<category> = STARTUP | SHUTDOWN | STATISTICS | CHECKPOINT | NODERESTART |
CONNECTION | INFO | ERROR | CONGESTION | DEBUG | BACKUP
<level> = 0 - 15
<id> = ALL | Any database node id
For detailed help on COMMAND, use HELP COMMAND.
也能够经过执行help后面跟命令名称而获取各类命令的操做说明帮助信息:
ndb_mgm> help start
---------------------------------------------------------------------------
NDB Cluster -- Management Client -- Help for START command
---------------------------------------------------------------------------
START Start data node (started with -n)
<id> START Start the data node identified by <id>.
Only starts data nodes that have not
yet joined the cluster. These are nodes
launched or restarted with the -n(--nostart) option.
It does not launch the ndbd process on a remote machine.
ndb_mgm> help shutdown
---------------------------------------------------------------------------
NDB Cluster -- Management Client -- Help for SHUTDOWN command
---------------------------------------------------------------------------
SHUTDOWN Shutdown the cluster
SHUTDOWN Shutdown the data nodes and management nodes.
MySQL Servers and NDBAPI nodes are currently not
shut down by issuing this command.
ndb_mgm> help PURGE STALE SESSIONS
---------------------------------------------------------------------------
NDB Cluster -- Management Client -- Help for PURGE STALE SESSIONS command
---------------------------------------------------------------------------
PURGE STALE SESSIONS Reset reserved nodeid's in the mgmt server
PURGE STALE SESSIONS
Running this statement forces all reserved
node IDs to be checked; any that are not
being used by nodes acutally connected to
the cluster are then freed.
This command is not normally needed, but may be
required in some situations where failed nodes
cannot rejoin the cluster due to failing to
allocate a node id.
经过上面的几个帮助命令所获取的信息得知,咱们能够经过在管理节点上面经过执行restart,stop,shutdown等基本的命令来重启某个节点,关闭某个节点,还能够同时一次性关闭全部节点。
此外,还能够经过执行备份相关的命令在管理节点对整个Cluster环境进行备份,以及经过日志相关命令实施对日志的相关管理。
16.5 基本优化思路
MySQL Cluster 虽然是一个分布式的数据库系统,可是在大部分地方的优化思路和方法仍是和普通的 MySQL Server 同样。和常规 MySQL Server 在优化方面的区别主要提如今各节点之间的协做配置以及网络环境相关的优化。
因为 MySQL Cluster 是一个分布式的环境,并且全部访问都是须要通过超过一个节点(至少有一个 SQL 节点和一个 NDB 节点)才能完成,因此各个节点之间的协做配合就显得尤其重要。
首先,因为各个节点之间存在大量的数据通信,因此节点之间的内部互联网络带宽必定要保证足够使用。为了适应不一样的网络环境和性能需求,MySQL Cluster 支持了多种内部网络互联的协议和方式。最为经常使用的天然是经过 TCP/IP 来进行互联。此外还能够有 SCI Socket 方式来进行互联,还支持 Myrinet,Infiniband,VIA 接口等等。
其次,SQL 节点和 NDB 节点的主机性能配比应该合适,而不该该出现某一类节点过早出现瓶颈的时候,另一类节点却还处于很是空闲的状态。若是在咱们遇到的环境中出现这样的状况,那么咱们就该从新评估两类节点的硬件设备配比了。不然,有一类节点的硬件资源就至关处于浪费状态了。
最后,就是 SQL 节点 和 NDB 节点二者软件配置方面的优化了。对于 SQL 节点的配置,和普通的 MySQL 区别不是太大。各种参数的配置原则也和普通 MySQL 基本相同。NDB Cluster 存储引擎的主要配置参数在前面的配置介绍中也基本都进行了性能相关的说明,这里就再也不累述了。
16.6 小结
MySQL Cluster 的核心在于 NDB Cluster 存储引擎,他不只对数据进行了水平切分,还对数据进行了跨节点冗余。既解决了数据库的扩展问题,同时也在很大程度上提升了数据库总体可用性。
虽然目前 MySQL Cluster 的应用还不如普通的 MySQL Server 应用那么普遍,可是我想随着他的不断成熟和改善,将会被愈来愈普遍的使用。这种 Share Nothing 的 Cluster架构也极可能会成为将来的趋势,就让咱们共同期待愈来愈成熟稳定高效的 MySQL Cluster吧。
摘自:《MySQL性能调优与架构设计》简朝阳
转载请注明出处: