MySQL Cluster安装与配置

Published on 2016 - 06 - 12

引言

MySQL Cluster是一个基于NDB Cluster存储引擎的完整的分布式数据库系统。它不仅具有高可用性,还有自动切分数据、冗余数据等高级功能。和Oracle Real Cluster Application不太一样的是,MySQL Cluster是一个Share Nothing的架构,各个MySQL Server之间并不共享任何数据,高度可扩展及可用性方面的突出表现是其最大的特色。虽然目前还只是MySQL家族中的一个新兴产品,但是已经有不少企业正在积极地尝试使用了。本文将通过对MySQL Cluster的介绍来了解其在可扩展设计方面的优势。

MySQL Cluster介绍

简单地说,MySQL Cluster实际上是在无共享存储设备的情况下实现的一种完全分布式的数据库系统,它主要通过NDB Cluster(简称NDB)存储引擎来实现。MySQL Cluster刚刚诞生时是一个能对数据进行持久化的内存数据库,所有数据和索引都必须装载在内存中才能够正常运行,但最新的MySQL Cluster版本已经有所改进,去掉了部分限制。

一个MySQL Cluster的环境主要由以下三部分组成:

  • SQL层的SQL服务器节点(后面简称为SQL节点),即常说的MySQL Server

主要负责实现一个数据库在存储层之上的所有事情,比如连接管理,Query优化和响应,Cache管理等,只有存储层的工作交给NDB数据节点去处理。也就是说,在纯粹的MySQL Cluster环境中的SQL节点,可以被认为是一个不须要提供任何非系统表使用的存储引擎的MySQL服务器,因为它的存储引擎由Cluster环境中的NDB节点来担任。所以,SQL层各MySQL服务器的启动与普通的MySQL Server启动也有一定的区别,必须添加ndbcluster参数选项才行。可以将其添加在my.cnf配置文件中,也可以通过启动命令行来指定。

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

  • 负责管理各个节点的Manage节点主机

管理节点负责整个Cluster集群中各个节点的管理工作,包括集群的配置,启动关闭各节点,对节点进行常规维护,以及实施数据的备份恢复等。管理节点会获取整个Cluster环境中各节点的状态和错误信息,并且将各Cluster集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存了整个Cluster环境的配置,同时担任了集群中各节点的基本沟通工作,所以它必须是最先被启动的节点。

图1是一幅MySQL Cluster的架构示意图(出自MySQL官方文档手册):

通过图1可以更清晰地了解整个MySQL Cluster环境各个节点及与客户端应用之间的关系。

由于目前MySQL Cluster的成熟使用并不是太多,实施也较普通的MySQL略复杂,所以本文将首先从如何搭建一个MySQL Cluster环境开始介绍。

MySQL Cluster环境搭建

搭建MySQL Cluster首先需要至少一个管理节点主机来实现管理功能,一个SQL节点主机来实现MySQL server功能,以及两个NDB节点主机实现NDB Cluster的功能。在后面的介绍中,将采用双SQL节点来搭建测试环境,具体信息如下:

硬件准备

  1. SQL节点1 192.168.0.1
  2. SQL节点2 192.168.0.2
  3. ndb节点1 192.168.0.3
  4. db节点2 192.168.0.4
  5. 管理节点 192.168.0.5

软件安装

首先在上面5个节点的主机上尽量确保环境基本一致,然后从MySQL官方下载相应的软件包并分发到两台SQL节点和两台NDB节点上,以备后面安装之用。

测试环境OS(RedHat Linux)如下(非必须):

  • 安装SQL节点

在MySQL节点上面须要安装支持Cluster的MySQL Server,可以通过自编译源代码安装,或者选择MySQL官方提供的已编译的tar包或rpm安装包。

然后是设置配置文件/etc/my.cnf,由于是测试环境,所以我仅仅设置了ndbcluster所需要的最基本的两个配置项,其他所有的配置均用默认配置(后面会有较详细的配置说明),如示例代码2所示:

  • 安装NDB节点

如果希望各节点环境尽可能保持一致,建议在NDB节点也和SQL节点一样安装整个带有NDB Cluster存储引擎的MySQL Server。其安装细节和上面的SQL节点完全一致。

另外,如果只是为了保证有一个完整的MySQL Cluster环境,则在NDB节点上仅安装NDB存储引擎(mysql ndb storage engine)即可。NDB存储引擎目前似乎找不到源码来编译安装,只能通过MySQL AB官方提供的rpm包完成。安装过程和其他的rpm软件包安装没有任何区别。

  • 管理节点

管理节点的安装只要有db_mgm和ndb_mgmd两个程序即可,可以在上面的SQL节点的MySQL安装目录中的bin目录下找到。将这两个程序复制到管理节点上合适的位置(一般会放在/usr/local/mysql/bin下),并在path制定的目录中建立两个同名的软链接到这两个程序上。

以上即是MySQL Cluster环境的软件安装过程,希望大家的安装过程也能够顺利。如果遇到了困难也不用担心,MySQL官方手册中有详细的安装过程说明。

基本配置

在上面所有节点的软件安装完成之后,就是配置MySQL Cluster环境的工作了。如果不考虑优化和个性化的配置需求,MySQL Cluster的基本配置是比较简单的。

SQL节点和NDB节点在上面的安装过程中已经完成了,仅须设置[mysql_cluster]参数组的ndb-connectstring参数即可完成基本配置。

管理节点的配置稍微复杂一点,因为它须要配置出Cluster环境中每一个节点的基本信息。配置文件无需固定的位置和名称,可由用户自行设定,只要在启动过程中指定即可。在测试环境中配置文件名称为/var/lib/mysql-cluster/config.ini,内容如示例代码4所示:


  • SQL节点的配置

SQL节点的配置和普通的MySQL Server配置区别主要是要在my.cnf文件中增加[mysql_cluster]这个配置选项组,并至少指定ndb-connectstring=192.168.0.5,也就是指定管理节点的IP地址或hostname。另外,如果希望能在启动mysqld的时候不用手动指定ndbcluster参数,则要在[mysqld]参数选项组中增加ndbcluster项参数。除了这两项之外,其他的所有参数都可以使用默认值。

  • NDB存储节点的配置

NDB存储节点的配置就更简单了,仅仅配置[mysql_cluster]中的ndb-connectstring = 192.168.0.5参数即可,其他的都可以不再配置。

环境测试

在MySQL Cluster环境搭建完成后,首先肯定要对新搭建的环境进行一些基本的功能和异常测试,以确认搭建的环境是否可以正常提供服务。

首先检测NDB引擎是否已经正常工作

通过任意客户端连接任意选定的一个SQL节点,测试各种基本的DDL、DML操作,再通过客户端连接上Cluster环境中另外的SQL节点校验所作的测试是否在其他节点同样可见。示例代码5是测试create table后再插入一条数据的示例:

可见,在节点4上面所插入的数据,已经在节点5上面了,说明NDB引擎工作正常。其他的测试与此类似,大家可以自行测试。

如果测试中发现某两个节点不一致,那么可以肯定Cluster环境的配置有问题。可在管理节点上通过“ndb_mgm -e SHOW”命令查看各节点状态是否正常,是否已连接到管理节点上。并检查不正常节点的my.cnf配置文件是否已经配置好,并以ndbcluster方式启动mysqld,是否正确配置[mysql_cluster]这个参数组最基本的ndb-connectstring参数。然后检查管理节点上的config文件中是否正确配置好配置节点,尤其是不正常的SQL节点的配置。

检测冗余环境的单点故障问题

  • 模拟NDB节点崩溃(Crash)

由于是模拟Crash,所以在节点2上面中止(Kill)掉NDB进程,然后再分别通过两个SQL节点去访问t1表,查看是否可以正常访问,数据是否一样,示例如代码6。

可以看到,不仅t1可以正常访问,数据也没有任何丢失,且仍然可以正常插入、删除数据。可见,有一个NDB节点Crash之后,整个MySQL Cluster环境仍然可以正常提供服务。当然,如果两个NDB节点都Crash之后,MySQL Cluster环境就无法正常提供服务了,大家也可以自行测试。

  • 模拟SQL节点Crash

和测试NDB节点Crash一样,Kill掉一个SQL节点(比如节点4)的mysqld进程,然后通过节点5进行访问,示例如代码7:

可以看到,在节点4 Crash之后,节点5仍然能够提供正常的服务。当然,如果在应用环境中,至少要支持当一个SQL节点出现问题时能够自行切换到剩下的正常SQL节点来访问的情况。

  • 管理节点的单点

一般情况来说,管理节点是最容易控制的,实施也非常简单,将配置文件和两个可执行程序(ndb_mgmd和ndb_mgm)存放在多台机器上面即可,可无须太多考虑单点故障。

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]两组。

[NDB_MGMD DEFAULT]中各管理节点的共用配置项。

PortNumber:配置管理节点的服务端程序(ndb_mgmd)监听客户端(ndb_mgm)连接请求和发送的指令,从文档上可以查找到默认端口是1186。一般来说这一项无须更改,当然如果为了在同一台主机上面启动多个管理节点,肯定要在两个管理节点启动不同的监听端口。

LogDestination:配置管理节点上的Cluster日志处理方式。

  • 可以写入文件,如:LogDestination=FILE:filename=my-cluster.log,maxsize=500000, maxfiles=4;
  • 也可以通过标准输出来打印,如:LogDestination=CONSOLE;
  • 还可以计入syslog中,如:LogDestination=SYSLOG:facility=syslog;
  • 甚至可多种方式共存,如:LogDestination=CONSOLE;SYSLOG:facility=syslog;FILE: filename=/ var/log/cluster-log

Datadir:设置用于管理节点存放文件输出的位置。如进程文件(.pid)、cluster log文件(当LogDestination有FILE处理方式存在时)。

ArbitrationRank:配置各节点在处理某些事件出现分歧时的级别。有0、1、2这3个值可以选择。

  • 0代表本节点完全听从其他节点的安排,不参与决策。
  • 1代表本节点有最高优先权,“一切由我来决策”。
  • 2代表本节点参与决策,但是优先权较1低,比0高。

不仅管理节点有ArbitrationRank参数,SQL节点也有。而且一般来说,所有的管理节点一般都应该设置成1,所有SQL节点都设置成2。

[NDB_MGMD]是每个管理节点配置一组,所需配置项如下所列(以下参数只能设置在[NDB_MGMD]参数组中)

Id:为节点指定一个唯一的ID号,要求在整个Cluster环境中唯一;

Hostname:配置该节点的IP地址或主机名,如果是主机名,则该主机名必须要在配置文件所在的节点的/etc/hosts文件中存在,而且绑定的IP是确定的。

上面[NDB_MGMD DEFAULT]中的所有参数项,都可以设置在下面的[NDB_MGMD]参数组中,但是id和hostname两个参数只能设置在[NDB_MGMD]中,因为这两个参数项针对每一个节点都是不相同的内容。

NDB节点相关配置

NDB节点和管理节点一样,既有各个节点共用的配置信息组[NDBD DEFAULT],也有每一个节点个性化配置的[NDBD]配置组(实际上SQL节点也是如此)。

[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存储引擎属于内存数据库引擎,要将所有的数据(包括索引)都加载到内存中。这个参数并不是一定需要设定的,但是默认值非常小(80MB),也就是说如果使用默认值,将只能存放很小的数据。参数设置要带上单位,如512MB,2GB等。另外,DataMemory中还会存放UNDO相关的信息,所以,事务的大小和并发量也决定了DataMemory的使用量,建议尽量使用小事务。

IndexMemory:设定用于存放索引(非主键)数据的内存段大小。和DataMemory类似,这个参数值同样也会限制该节点能存放的数据的大小,因为索引的大小是随着数据量增长而增长的。参数设置也如DataMemory一样需要单位。IndexMemory默认大小为18MB。

实际上,一个NDB节点能存放的数据量受到DataMemory和IndexMemory两个参数设置的约束,两者中任何一个达到限制数量后,都无法再增加存储的数据量。如果继续存入数据,系统会报错“table is full”。

FileSystemPath:指定redo日志、undo日志、数据文件及元数据等的存放位置,默认位置为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。此外,这里的记录数量并不是指单纯的表的记录数,而是指一个事务在整个集群中的操作记录。当使用到唯一索引的时候,表的数据和索引两者都要算在里面,也就是说,如果是通过一个唯一索引来作为过滤条件更新某一条记录,那么这里算是两条操作记录,所以上面是除以4而不是除以2。而且即使是锁定也会产生操作记录,比如通过唯一索引来查找一条记录,就会产生如下两条操作记录:通过读取唯一索引中的某个记录数据会产生锁定,产生一条操作记录,然后读取基表中的数据,也会产生读锁,产生一条操作记录。MaxNoOfConcurrentOperations参数的默认值为32768。系统运行过程中,如果出现此参数不够的情况,就会报出“Out of operation records in transaction coordinator”这样的报错信息.

MaxNoOfLocalOperations:此参数默认是MaxNoOfConcurrentOperations×1.1的值,也就是说,每个节点一般可以处理超过平均值的10%的操作记录数量。但是一般来说,MySQL建议单独设置此参数而不要使用默认值,并且将此参数设置得更大一些。

以下的3个参数主要是在一个事务中执行一条Query的时候临时用到存储(或者内存)的情况下使用,其存储信息会在事务结束(commit或者rollback)的时候释放资源。

MaxNoOfConcurrentIndexOperations:这个参数和MaxNoOfConcurrentOperations参数比较类似,只不过所针对的是Index的Record。其默认值为8192,对于一般的系统来说已经足够了,只有在事务并发非常突出的系统上才须要增加这个参数的设置。当然,此参数越大,系统运行时候为此而消耗的内存也会越大。

MaxNoOfFiredTriggers:触发唯一索引(Hash Index)操作的最大的操作数,该操作数是影响索引的操作条目数,而不是操作的次数。系统默认值为4000,一般来说够用了。当然,如果系统并发事务非常多,而且涉及索引的操作也非常多,自然也就要提高这个参数值的设置。

TransactionBufferMemory:这个buffer值的设置主要用于跟踪索引操作。主要用它存储索引操作中涉及的索引键值和字段的实际信息。这个参数的值一般很少调整,因为实际系统中需要的这部分buffer量非常小,虽然默认值是1MB,但是对于一般应用已经足够了。

下面要介绍的参数主要是在系统处理中做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有16种,从0到15。如果设定为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信息的缓冲区。默认值为2MB,最小可以设置为1MB,对于大多数应用来说,默认值足够。当然,在更新非常频繁的应用中,适当调大此参数值对性能还是有一定帮助的。如果此参数太小,会报出677错误——Index UNDO buffers overloaded。

UndoDataBuffer:和undo index buffer类似,undo data buffer主要是在数据发生变更时所需要的undo信息的缓冲区。默认大小为16MB,最小同样为1MB。当这个参数值太小的时候,系统会报出如下的错误——Data UNDO buffers overloaded,错误号为891。

RedoBuffer:Redo buffer是用redo log信息的缓冲区,默认大小为8MB,最小为1MB。如果此buffer太小,会报出1221错误——REDO log buffers overloaded。

此外,NDB节点还有一些和元数据及内部控制相关的参数,但大部分参数都基本上不需要任何调整,所以就不进一步介绍。如果希望详细了解的话,可以查阅MySQL官方的参考手册。

SQL节点相关配置说明

和其他节点一样,先介绍一些适用于所有节点的[MYSQLD DEFAULT]参数

ArbitrationRank:这个参数在介绍管理节点的参数时候已经提过,用于设定节点级别(主要是当多个节点在处理相关操作出现分歧的时候设定裁定者)的。一般来说,所有的SQL节点都应该设定为2。

ArbitrationDelay:默认值为0,裁定者在开始裁定之前需要被Delay的时间,单位为毫秒。一般不需要更改默认值。

BatchByteSize:在做全表扫描或者索引范围扫描的时候,每一次Fetch的数据量,默认为32KB。

BatchSize:类似BatchByteSize参数,只不过BatchSize所设定的是每一次Fetch的record数量,而不是物理总量,默认为64,最大为992(目前还不清楚这个值是基于什么理论设定的)。在实际运行Query的过程中,Fetch的数据量受BatchByteSize和BatchSize两个参数的共同制约,取二者中的最小值。

MaxScanBatchSize:在Cluster环境中,进行并行处理的情况下,所有节点的BatchSize总和的最大值。默认值为256KB,最大值为16MB。

每个节点独有的[MYSQLD]参数组,仅有id和hostname参数需要配置,在之前已有介绍,这里就不再赘述

MySQL Cluster基本管理与维护

MySQL Cluster的管理和普通的MySQL Server管理区别较大,大部分管理工作都是在管理节点上完成的,仅有少数管理内容须要在其他节点实施。

各节点启动与关闭

要想Cluster环境能够正常工作,至少要启动一个NDB节点和一个SQL节点,另外为了完成管理,也至少要启动一个管理节点。各类节点的启动顺序也有要求,首先是管理节点,然后是NDB节点,最后才是SQL节点。

按顺序启动各节点

  • 启动管理节点,如示例代码8所示。

这里执行的ndb_mgmd命令实际上就是MySQL Cluster管理服务器,可以通过-f config_file_name或者--config=config_filename来指定MySQL Cluster集群的参数文件。如果想了解更多关于ndb_mgmd的参数信息,可以运行ndb_mgmd --help来获取。

  • 启动用于存储数据的NDB节点

要启动存储节点,必须在每一台NDB节点主机上都执行ndbd程序。如果是第一次启动,则须要添加—initial参数,以便进行NDB节点的初始化工作。但是,在以后的启动过程中,则是不能添加该参数的,否则ndbd程序会清除在之前建立的所有用于恢复的数据文件和日志文件。启动命令如示例代码9所示。

  • 启动SQL节点

SQL节点的启动如示例代码10所示,和普通MySQL Server的启动没有明显的差别,不过有一个前提:要在MySQL Server的配置文件my.cnf内设置好[mysql_cluster]配置组的ndb-connectstring参数和[mysqld]配置组的ndbcluster参数。

节点状态检查

在各节点都启动完成后,回到管理节点,可以通过ndb_mgm来查看各节点状态,如示例代码11所示。

这里显示出整个集群有5个节点,各节点信息如下。

  • 两个NDBD节点
  • 两个SQL节点
  • 1个管理节点

节点的关闭操作

在MySQL Cluster环境中,NDB节点和管理节点的关闭都可以在管理节点的管理程序中完成,但是SQL节点不行。所以,在关闭整个MySQL Cluster环境或某个SQL节点的时候,首先必须到SQL节点主机上关闭SQL节点程序。关闭方法和MySQL Server一样,NDB节点和管理节点的关闭命令如示例代码12所示。

基本管理维护

前面运行的命令ndb_mgm如果不带任何参数,实际上是进入MySQL Cluster的命令行管理界面。在命令行管理界面中可以做大量的维护工作,如示例代码13所示。

还可以通过示例代码14在ndb控制界面下执行help命令查看基本的维护管理命令:

通过上面的几个帮助命令所获取的信息得知,我们可以通过在管理节点上面执行restart、stop、shutdown等基本的命令来重启某个节点,关闭某个节点,或者一次性关闭所有节点。

此外,还可以通过执行备份相关的命令在管理节点对整个Cluster环境进行备份,以及通过日志相关命令实施对日志的相关管理。

基本优化思路

MySQL Cluster虽然是一个分布式的数据库系统,但大部分的优化思路和方法还是与普通的MySQL Server一样。和常规MySQL Server的区别主要体现在各节点之间的协作配置及网络环境相关的优化上。

由于MySQL Cluster是一个分布式的环境,而且所有访问都要经过一个以上的节点(至少有一个SQL节点和一个NDB节点)才能完成,所以各个节点之间的协作配合就显得特别重要。

首先,由于各个节点之间存在大量的数据通信,所以节点之间的内部互联网络带宽一定要保证够用。为了适应不同的网络环境和性能需求,MySQL Cluster支持了多种内部网络互联的协议和方式。最为常用的自然是通过TCP/IP来进行互联。此外还有SCI Socket方式,也支持Myrinet、Infiniband,VIA接口,等等。

其次,SQL节点和NDB节点的主机性能配比要合适,不应该出现某一类节点过早成为瓶颈而另外一类节点却还处于空闲的状态。如果在我们遇到的环境中出现这样的情况,那么就该重新评估两类节点的硬件设备配比了。否则,有一类节点的硬件资源就将处于浪费状态。

参考文档