mysql搭建集群高可用的相关详解
linux搭建mysql集群服务负载均衡搭建java连接mysql集群 参考地址：http://blog.csdn.net/liqi_q/article/details/78580474
MySQL Cluster 是MySQL 适合于分布式计算环境的高实用、可拓展、高性能、高冗余版本，其研发设计的初衷就是要满足许多行业里的最严酷应用要求，这些应用中经常要求数据库运行的可靠性要达到99.999%。MySQL Cluster允许在无共享的系统中部署“内存中”数据库集群，通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。
MySQL Cluster能够使用多种故障切换和负载平衡选项配置NDB存储引擎，但在Cluster 级别上的存储引擎上做这个最简单。
MySQL从结构看，由3类节点(计算机或进程)组成，分别是：
- 管理节点
管理节点负责整个Cluster 集群中各个节点的管理工作，包括集群的配置，启动关闭各节点，以及实施数据的备份恢复等。管理节点会获取整个Cluster 环境中各节点的状态和错误信息，并且将各Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存在整个Cluster 环境的配置，同时担任了集群中各节点的基本沟通工作，所以他必须是最先被启动的节点。
- 数据节点
NDB 是一个内存式存储引擎也就是说，他会将所有的数据和索引数据都load 到内存中，但也会将数据持久化到存储设备上。不过，最新版本，已经支持用户自己选择数据可以不全部Load 到内存中了，这对于有些数据量太大或者基于成本考虑而没有足够内存空间来存放
NDB 节点主要是实现底层数据存储的功能，保存Cluster 的数据。每一个NDB 节点保存完整数据的一部分（或者一份完整的数据，视节点数目和配置而定），在MySQL CLuster 里面叫做一个fragment。而每一个fragment，正常情况来讲都会在其他的主机上面有一份（或者多分）完全相同的镜像存在。这些都是通过配置来完成的，所以只要配置得当，MysqlCluster 在存储层不会出现单点的问题。
一般来说，NDB 节点被组织成一个一个的NDB Group，一个NDB Group 实际上就是一组存有完全相同的物理数据的NDB 节点群。
上面提到了NDB 各个节点对数据的组织，可能每个节点都存有全部的数据也可能只保存一部分数据，主要是受节点数目和参数来控制的。首先在Mysql Cluster 主配置文件（在管理节点上面，一般为config.ini）中，有一个非常重要的参数叫NoOfReplicas，这个参数指定了每一份数据被冗余存储在不同节点上面的份数，该参数一般至少应该被设置成2，也只需要设置成2 就可以了。因为正常来说，两个互为冗余的节点同时出现故障的概率还是非常小的，当然如果机器和内存足够多的话，也可以继续增大。一个节点上面是保存所有的数据还是一部分数据，还受到存储节点数目的限制。NDB 存储引擎首先保证NoOfReplicas 参数配置的要求对数据冗余，来使用存储节点，然后再根据节点数目将数据分段来继续使用多余的NDB 节点，分段的数目为节点总数除以NoOfReplicas 所得。
- SQL节点(API):
SQL 层的SQL 服务器节点（后面简称为SQL 节点），也就是我们常说的Mysql Server：主要负责实现一个数据库在存储层之上的所有事情，比如连接管理，query 优化和响应，cache 管理等等，只有存储层的工作交给了NDB 数据节点去处理了。也就是说，在纯粹的Mysql Cluster 环境中的SQL 节点，可以被认为是一个不需要提供任何存储引擎的Mysql服务器，因为他的存储引擎有Cluster 环境中的NDB 节点来担任。所以，SQL 层各Mysql 服务器的启动与普通的Mysql 启动有一定的区别，必须要添加ndbcluster 项，可以添加在my.cnf 配置文件中，也可以通过启动命令行来指定。
* NDB引擎
MySQL Cluster 使用了一个专用的基于内存的存储引擎——NDB引擎，这样做的好处是速度快， 没有磁盘I/O的瓶颈，但是由于是基于内存的，所以数据库的规模受系统总内存的限制， 如果运行NDB的MySQL服务器一定要内存够大，比如8G, 16G，32G等。NDB引擎是分布式的，它可以配置在多台服务器上来实现数据的可靠性和扩展性，理论上通过配置2台NDB的存储节点就能实现整个数据库集群的冗余性和解决单点故障问题。
优点：
- 多个节点之间可以分布在不同的地理位置，因此也是一个实现分布式数据库的方案。
- 扩展性很好，增加节点即可实现数据库集群的扩展。
- 冗余性很好，多个节点上都有完整的数据库数据，因此任何一个节点宕机都不会造成服务中断。
缺陷：
- 基于内存，数据库的规模受集群总内存的大小限制
- 基于内存，断电后数据可能会有数据丢失，这点还需要通过测试验证。
- 多个节点通过网络实现通讯和数据同步、查询等操作，因此整体性受网络速度影响，因此速度也比较慢。
实现高可用性的成本比较低，不象传统的高可用方案一样需要共享的存储设备和专用的软件才能实现，NDB只要有足够的内存就能实现。
MySQL Cluster 备份/恢复
在管理节点上执行备份数据命令，数据将分别备份到各个存储节点上（即不同节点备份的数据不一样），恢复时需要在各个存储节点上都执行恢复命令；
$ /usr/local/mysql/bin/ndb_mgm -e "start backup"
Connected to Management Server at: 10.10.10.173:1186
Waiting for completed, this may take several minutes
Node 2: Backup 1 started from node 1
Node 2: Backup 1 started from node 1 completed
StartGCP: 101 StopGCP: 104
#Records: 2061 #LogRecords: 0
Data: 51292 bytes Log: 0 bytes
在数据节点/data/mysql/BACKUP目录中就可以看到备份的数据;
在数据目录生成一个BACKUP目录，在该目录下，有每次备份生成的目录如BACKUP-1（表示第一次备份），在BACKUP-1有三个文件
BACKUP-1.2.log，BACKUP-1.2.ctl,BACKUP-1-0.2.DATA(.2表示备份id=2的数据节点的数据)，此时在172.16.0.30也生成这个文件件，但是是备份id=3的数据节点的数据（。3表示）。
当在sql节点上删除数据，就可以利用此备份恢复(只能恢复数据，如将表或库直接删掉了，需要手动加上，才可以恢复)；
恢复数据需要命令 ndb_restore (由包MySQL-Cluster-gpl-tools-7.1.18-1.el6.x86_64.rpm提供)，若存储节点上没有此命令，可以将其直接由管理节点上复制过去，也可以安装tools包。
在MYSQL API节点1(10.10.10.176)上删除数据表ctest。
mysql> drop table ctest;
注意：恢复数据时，管理节点上一定要有空闲MYSQL API连接（预留空闲的mysqld配置），否则无法恢复。
由于数据备份在两个数据节点，因此在各个数据节点都得执行恢复操作。
在数据节点1（10.10.10.174）上恢复：
$ ls -l /data/mysql/BACKUP/BACKUP-1/
total 56
-rw-r--r-- 1 root root 26296 Apr 27 11:31 BACKUP-1-0.2.Data
-rw-r--r-- 1 root root 22372 Apr 27 11:31 BACKUP-1.2.ctl
-rw-r--r-- 1 root root 52 Apr 27 11:31 BACKUP-1.2.log
$ /usr/local/mysql/bin/ndb_restore -n 2 -b 1 -r -m /data/mysql/BACKUP/BACKUP-1/
Nodeid = 2
Backup Id = 1
backup path = /data/mysql/BACKUP/BACKUP-1/
2017-04-27 13:16:22 [restore_metadata] Read meta data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.2.ctl'
File size 22372 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.7.18 ndb-7.5.6
2017-04-27 13:16:22 [restore_metadata] Load content
Stop GCP of Backup: 54
2017-04-27 13:16:22 [restore_metadata] Get number of Tables
2017-04-27 13:16:22 [restore_metadata] Validate Footer
Connected to ndb!!
2017-04-27 13:16:22 [restore_metadata] Restore objects (tablespaces, ..)
2017-04-27 13:16:22 [restore_metadata] Restoring tables
Successfully restored table `test2/def/ctest`
Successfully restored table event REPL$test2/ctest
2017-04-27 13:16:22 [restore_metadata] Save foreign key info
Successfully created index `PRIMARY` on `ctest`
Create foreign keys
Create foreign keys done
2017-04-27 13:16:23 [restore_data] Start restoring table data
2017-04-27 13:16:23 [restore_data] Read data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1-0.2.Data'
File size 26296 bytes
2017-04-27 13:16:23 [restore_data] Restore fragments
_____________________________________________________
Processing data in table: mysql/def/NDB$BLOB_7_3(8) fragment 0
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(3) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_head(4) fragment 0
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(2) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_schema(7) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_sample(5) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_apply_status(9) fragment 0
_____________________________________________________
Processing data in table: test2/def/ctest(10) fragment 0
2017-04-27 13:16:23 [restore_log] Read log file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.2.log'
File size 52 bytes
2017-04-27 13:16:23 [restore_log] Restore log entries
Restored 1 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
在数据节点2（10.10.10.175）上执行恢复：
$ ls -l /data/mysql/BACKUP/BACKUP-1/
total 56
-rw-r--r-- 1 root root 25652 Apr 27 13:11 BACKUP-1-0.3.Data
-rw-r--r-- 1 root root 22372 Apr 27 13:11 BACKUP-1.3.ctl
-rw-r--r-- 1 root root 52 Apr 27 13:11 BACKUP-1.3.log
$ /usr/local/mysql/bin/ndb_restore -n 3 -b 1 -r /data/mysql/BACKUP/BACKUP-1/ # 注意，由于数据表已经存在，这里不加上-m选项
Nodeid = 3
Backup Id = 1
backup path = /data/mysql/BACKUP/BACKUP-1/
2017-04-27 13:19:15 [restore_metadata] Read meta data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.3.ctl'
File size 22372 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.7.18 ndb-7.5.6
2017-04-27 13:19:15 [restore_metadata] Load content
Stop GCP of Backup: 54
2017-04-27 13:19:15 [restore_metadata] Get number of Tables
2017-04-27 13:19:15 [restore_metadata] Validate Footer
Connected to ndb!!
2017-04-27 13:19:16 [restore_metadata] Restore objects (tablespaces, ..)
2017-04-27 13:19:16 [restore_metadata] Restoring tables
2017-04-27 13:19:16 [restore_metadata] Save foreign key info
2017-04-27 13:19:16 [restore_data] Start restoring table data
2017-04-27 13:19:16 [restore_data] Read data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1-0.3.Data'
File size 25652 bytes
2017-04-27 13:19:16 [restore_data] Restore fragments
_____________________________________________________
Processing data in table: mysql/def/NDB$BLOB_7_3(8) fragment 1
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(3) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_head(4) fragment 1
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(2) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_schema(7) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_sample(5) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_apply_status(9) fragment 1
_____________________________________________________
Processing data in table: test2/def/ctest(10) fragment 1
2017-04-27 13:19:16 [restore_log] Read log file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.3.log'
File size 52 bytes
2017-04-27 13:19:16 [restore_log] Restore log entries
Restored 3 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
(4) 日志管理
mysql cluster 提供两种日志：集群日志（clusterlog），节点日志（node log），在集群客户端查看日志状态（clusterlog info），打开(clusterlog on)，关闭日志(clusterlog off)
$ /usr/local/mysql/bin/ndb_mgm -e "CLUSTERLOG INFO"
Connected to Management Server at: 172.16.0.10:1186
Severities enabled: INFO WARNING ERROR CRITICAL ALERT
cluster中的日志有很多类型（Category(startup, shutdown, statistics,checkpoint noderestart,connnection ,error ,info)
Priority (1表示“重要”，15 表示“最不重要”) ，Servrity level (alter,critical,error,warning,info,debug) ），
)
可以按照类别进行过滤。具体用法：1：node_id clusterlog category=level (用于小于或等于level的优先级将category 事件记录到cluster日志。
nodeid 可以为all(全部节点))，也可以是某个节点
clusterlog toggle severity_level # 过滤severity_level的日志
MySQL Cluster 是MySQL 适合于分布式计算环境的高实用、可拓展、高性能、高冗余版本，其研发设计的初衷就是要满足许多行业里的最严酷应用要求，这些应用中经常要求数据库运行的可靠性要达到99.999%。MySQL Cluster允许在无共享的系统中部署“内存中”数据库集群，通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。
MySQL Cluster能够使用多种故障切换和负载平衡选项配置NDB存储引擎，但在Cluster 级别上的存储引擎上做这个最简单。
MySQL从结构看，由3类节点(计算机或进程)组成，分别是：
- 管理节点
管理节点负责整个Cluster 集群中各个节点的管理工作，包括集群的配置，启动关闭各节点，以及实施数据的备份恢复等。管理节点会获取整个Cluster 环境中各节点的状态和错误信息，并且将各Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存在整个Cluster 环境的配置，同时担任了集群中各节点的基本沟通工作，所以他必须是最先被启动的节点。
- 数据节点
NDB 是一个内存式存储引擎也就是说，他会将所有的数据和索引数据都load 到内存中，但也会将数据持久化到存储设备上。不过，最新版本，已经支持用户自己选择数据可以不全部Load 到内存中了，这对于有些数据量太大或者基于成本考虑而没有足够内存空间来存放
NDB 节点主要是实现底层数据存储的功能，保存Cluster 的数据。每一个NDB 节点保存完整数据的一部分（或者一份完整的数据，视节点数目和配置而定），在MySQL CLuster 里面叫做一个fragment。而每一个fragment，正常情况来讲都会在其他的主机上面有一份（或者多分）完全相同的镜像存在。这些都是通过配置来完成的，所以只要配置得当，MysqlCluster 在存储层不会出现单点的问题。
一般来说，NDB 节点被组织成一个一个的NDB Group，一个NDB Group 实际上就是一组存有完全相同的物理数据的NDB 节点群。
上面提到了NDB 各个节点对数据的组织，可能每个节点都存有全部的数据也可能只保存一部分数据，主要是受节点数目和参数来控制的。首先在Mysql Cluster 主配置文件（在管理节点上面，一般为config.ini）中，有一个非常重要的参数叫NoOfReplicas，这个参数指定了每一份数据被冗余存储在不同节点上面的份数，该参数一般至少应该被设置成2，也只需要设置成2 就可以了。因为正常来说，两个互为冗余的节点同时出现故障的概率还是非常小的，当然如果机器和内存足够多的话，也可以继续增大。一个节点上面是保存所有的数据还是一部分数据，还受到存储节点数目的限制。NDB 存储引擎首先保证NoOfReplicas 参数配置的要求对数据冗余，来使用存储节点，然后再根据节点数目将数据分段来继续使用多余的NDB 节点，分段的数目为节点总数除以NoOfReplicas 所得。
- SQL节点(API):
SQL 层的SQL 服务器节点（后面简称为SQL 节点），也就是我们常说的Mysql Server：主要负责实现一个数据库在存储层之上的所有事情，比如连接管理，query 优化和响应，cache 管理等等，只有存储层的工作交给了NDB 数据节点去处理了。也就是说，在纯粹的Mysql Cluster 环境中的SQL 节点，可以被认为是一个不需要提供任何存储引擎的Mysql服务器，因为他的存储引擎有Cluster 环境中的NDB 节点来担任。所以，SQL 层各Mysql 服务器的启动与普通的Mysql 启动有一定的区别，必须要添加ndbcluster 项，可以添加在my.cnf 配置文件中，也可以通过启动命令行来指定。
* NDB引擎
MySQL Cluster 使用了一个专用的基于内存的存储引擎——NDB引擎，这样做的好处是速度快， 没有磁盘I/O的瓶颈，但是由于是基于内存的，所以数据库的规模受系统总内存的限制， 如果运行NDB的MySQL服务器一定要内存够大，比如8G, 16G，32G等。NDB引擎是分布式的，它可以配置在多台服务器上来实现数据的可靠性和扩展性，理论上通过配置2台NDB的存储节点就能实现整个数据库集群的冗余性和解决单点故障问题。
优点：
- 多个节点之间可以分布在不同的地理位置，因此也是一个实现分布式数据库的方案。
- 扩展性很好，增加节点即可实现数据库集群的扩展。
- 冗余性很好，多个节点上都有完整的数据库数据，因此任何一个节点宕机都不会造成服务中断。
缺陷：
- 基于内存，数据库的规模受集群总内存的大小限制
- 基于内存，断电后数据可能会有数据丢失，这点还需要通过测试验证。
- 多个节点通过网络实现通讯和数据同步、查询等操作，因此整体性受网络速度影响，因此速度也比较慢。
实现高可用性的成本比较低，不象传统的高可用方案一样需要共享的存储设备和专用的软件才能实现，NDB只要有足够的内存就能实现。
MySQL Cluster 备份/恢复
在管理节点上执行备份数据命令，数据将分别备份到各个存储节点上（即不同节点备份的数据不一样），恢复时需要在各个存储节点上都执行恢复命令；
$ /usr/local/mysql/bin/ndb_mgm -e "start backup"
Connected to Management Server at: 10.10.10.173:1186
Waiting for completed, this may take several minutes
Node 2: Backup 1 started from node 1
Node 2: Backup 1 started from node 1 completed
StartGCP: 101 StopGCP: 104
#Records: 2061 #LogRecords: 0
Data: 51292 bytes Log: 0 bytes
在数据节点/data/mysql/BACKUP目录中就可以看到备份的数据;
在数据目录生成一个BACKUP目录，在该目录下，有每次备份生成的目录如BACKUP-1（表示第一次备份），在BACKUP-1有三个文件
BACKUP-1.2.log，BACKUP-1.2.ctl,BACKUP-1-0.2.DATA(.2表示备份id=2的数据节点的数据)，此时在172.16.0.30也生成这个文件件，但是是备份id=3的数据节点的数据（。3表示）。
当在sql节点上删除数据，就可以利用此备份恢复(只能恢复数据，如将表或库直接删掉了，需要手动加上，才可以恢复)；
恢复数据需要命令 ndb_restore (由包MySQL-Cluster-gpl-tools-7.1.18-1.el6.x86_64.rpm提供)，若存储节点上没有此命令，可以将其直接由管理节点上复制过去，也可以安装tools包。
在MYSQL API节点1(10.10.10.176)上删除数据表ctest。
mysql> drop table ctest;
注意：恢复数据时，管理节点上一定要有空闲MYSQL API连接（预留空闲的mysqld配置），否则无法恢复。
由于数据备份在两个数据节点，因此在各个数据节点都得执行恢复操作。
在数据节点1（10.10.10.174）上恢复：
$ ls -l /data/mysql/BACKUP/BACKUP-1/
total 56
-rw-r--r-- 1 root root 26296 Apr 27 11:31 BACKUP-1-0.2.Data
-rw-r--r-- 1 root root 22372 Apr 27 11:31 BACKUP-1.2.ctl
-rw-r--r-- 1 root root 52 Apr 27 11:31 BACKUP-1.2.log
$ /usr/local/mysql/bin/ndb_restore -n 2 -b 1 -r -m /data/mysql/BACKUP/BACKUP-1/
Nodeid = 2
Backup Id = 1
backup path = /data/mysql/BACKUP/BACKUP-1/
2017-04-27 13:16:22 [restore_metadata] Read meta data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.2.ctl'
File size 22372 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.7.18 ndb-7.5.6
2017-04-27 13:16:22 [restore_metadata] Load content
Stop GCP of Backup: 54
2017-04-27 13:16:22 [restore_metadata] Get number of Tables
2017-04-27 13:16:22 [restore_metadata] Validate Footer
Connected to ndb!!
2017-04-27 13:16:22 [restore_metadata] Restore objects (tablespaces, ..)
2017-04-27 13:16:22 [restore_metadata] Restoring tables
Successfully restored table `test2/def/ctest`
Successfully restored table event REPL$test2/ctest
2017-04-27 13:16:22 [restore_metadata] Save foreign key info
Successfully created index `PRIMARY` on `ctest`
Create foreign keys
Create foreign keys done
2017-04-27 13:16:23 [restore_data] Start restoring table data
2017-04-27 13:16:23 [restore_data] Read data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1-0.2.Data'
File size 26296 bytes
2017-04-27 13:16:23 [restore_data] Restore fragments
_____________________________________________________
Processing data in table: mysql/def/NDB$BLOB_7_3(8) fragment 0
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(3) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_head(4) fragment 0
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(2) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_schema(7) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_sample(5) fragment 0
_____________________________________________________
Processing data in table: mysql/def/ndb_apply_status(9) fragment 0
_____________________________________________________
Processing data in table: test2/def/ctest(10) fragment 0
2017-04-27 13:16:23 [restore_log] Read log file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.2.log'
File size 52 bytes
2017-04-27 13:16:23 [restore_log] Restore log entries
Restored 1 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
在数据节点2（10.10.10.175）上执行恢复：
$ ls -l /data/mysql/BACKUP/BACKUP-1/
total 56
-rw-r--r-- 1 root root 25652 Apr 27 13:11 BACKUP-1-0.3.Data
-rw-r--r-- 1 root root 22372 Apr 27 13:11 BACKUP-1.3.ctl
-rw-r--r-- 1 root root 52 Apr 27 13:11 BACKUP-1.3.log
$ /usr/local/mysql/bin/ndb_restore -n 3 -b 1 -r /data/mysql/BACKUP/BACKUP-1/ # 注意，由于数据表已经存在，这里不加上-m选项
Nodeid = 3
Backup Id = 1
backup path = /data/mysql/BACKUP/BACKUP-1/
2017-04-27 13:19:15 [restore_metadata] Read meta data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.3.ctl'
File size 22372 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.7.18 ndb-7.5.6
2017-04-27 13:19:15 [restore_metadata] Load content
Stop GCP of Backup: 54
2017-04-27 13:19:15 [restore_metadata] Get number of Tables
2017-04-27 13:19:15 [restore_metadata] Validate Footer
Connected to ndb!!
2017-04-27 13:19:16 [restore_metadata] Restore objects (tablespaces, ..)
2017-04-27 13:19:16 [restore_metadata] Restoring tables
2017-04-27 13:19:16 [restore_metadata] Save foreign key info
2017-04-27 13:19:16 [restore_data] Start restoring table data
2017-04-27 13:19:16 [restore_data] Read data file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1-0.3.Data'
File size 25652 bytes
2017-04-27 13:19:16 [restore_data] Restore fragments
_____________________________________________________
Processing data in table: mysql/def/NDB$BLOB_7_3(8) fragment 1
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(3) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_head(4) fragment 1
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(2) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_schema(7) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_index_stat_sample(5) fragment 1
_____________________________________________________
Processing data in table: mysql/def/ndb_apply_status(9) fragment 1
_____________________________________________________
Processing data in table: test2/def/ctest(10) fragment 1
2017-04-27 13:19:16 [restore_log] Read log file header
Opening file '/data/mysql/BACKUP/BACKUP-1/BACKUP-1.3.log'
File size 52 bytes
2017-04-27 13:19:16 [restore_log] Restore log entries
Restored 3 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
(4) 日志管理
mysql cluster 提供两种日志：集群日志（clusterlog），节点日志（node log），在集群客户端查看日志状态（clusterlog info），打开(clusterlog on)，关闭日志(clusterlog off)
$ /usr/local/mysql/bin/ndb_mgm -e "CLUSTERLOG INFO"
Connected to Management Server at: 172.16.0.10:1186
Severities enabled: INFO WARNING ERROR CRITICAL ALERT
cluster中的日志有很多类型（Category(startup, shutdown, statistics,checkpoint noderestart,connnection ,error ,info)
Priority (1表示“重要”，15 表示“最不重要”) ，Servrity level (alter,critical,error,warning,info,debug) ），
)
可以按照类别进行过滤。具体用法：1：node_id clusterlog category=level (用于小于或等于level的优先级将category 事件记录到cluster日志。
nodeid 可以为all(全部节点))，也可以是某个节点
clusterlog toggle severity_level # 过滤severity_level的日志