[转]mysql cluster 备份与恢复

一、MySQL簇的联机备份

1、簇备份概念
备份指的是在给定时间对数据库的快照。备份包含三个主要部分：
（1）Metadata（元数据）：所有数据库表的名称和定义。
（2）Table records（表记录）：执行备份时实际保存在数据库表中的数据。
（3）Transaction log（事务日志）：指明如何以及何时将数据保存在数据库中的连续记录。
每一部分(这三部分)均会保存在参与备份的所有数据节点上。在备份过程中，每个节点均会将这三个部分保存在磁盘上的三个文件中(意思是说,有几个节点,将会把相同的数据,保存几份.例如,2个数据节点,那么就会分别在2个节点上,保存2次，保存目录默认为
[NDBD]
DateDir=/usr/local/mysql/BACKUP
（4）BACKUP-backup_id.node_id.ctl
包含控制信息和元数据的控制文件。每个节点均会将相同的表定义（对于簇中的所有表）保存在自己的该文件中
（5）BACKUP-backup_id-0.node_id.data
包含表记录的数据文件，它是按片段保存的，也就是说，在备份过程中，不同的节点会保存不同的片段。每个节点保存的文件以指明了记录所属表的标题开始。在记录清单后面有一个包含关于所有记录校验和的脚注。
（6）BACKUP-backup_id.node_id.log
包含已提交事务的记录的日志文件。在日志中，仅保存已在备份中保存的表上的事务。参与备份的节点将保存不同的记录，这是因为，不同的节点容纳了不同的数据库片段。
在上面所列的内容中，backup_id指的是备份ID，node_id是创建文件的节点的唯一ID。
使用管理服务器创建备份开始备份前，请确保已为备份操作恰当地配置了簇。

2、备份参数(以下参数,都写入在mgmd的config.ini配置文件中)
本节讨论的参数定义了与在线备份执行有关的内存缓冲集。
（1）BackupDataBufferSize
在创建备份的过程中，为了将数据发送到磁盘，将使用两类缓冲。备份数据缓冲用于填充由扫描节点的表而记录的数据。一旦将该缓冲填充到了指定的水平BackupWriteSize（请参见下面的介绍），就会将页发送至磁盘。在将页写入磁盘的同时，备份进程能够继续填充该缓冲，直至其空间消耗完为止。出现该情况时，备份进程将暂停扫描，直至一些磁盘写入操作完成并释放了内存为止，然后扫描继续。
该参数的默认值为2MB。
（2）BackupLogBufferSize
备份日志缓冲扮演的角色类似于备份数据缓冲，不同之处在于，它用于生成备份执行期间进行的所有表写入的日志。相同的原理也适用于备份数据缓冲情形下的页写入，不同之处在于，当备份日志缓冲中没有多余空间时，备份将失败。出于该原因，备份日志缓冲的大小应足以处理执行备份时产生的负载。
该参数的默认值对于大多数应用程序均是适当的。事实上，备份失败的原因更可能是因为磁盘写入速度不够，而不是备份日志缓冲变满。如果没有为应用程序产生的写负载配置磁盘子系统，簇很可能无法执行所需的操作。最好按恰当的方式配置簇，使得处理器成为瓶颈而不是磁盘或网络连接。默认值是2MB。
（3）BackupMemory
该参数是BackupDataBufferSize和BackupLogBufferSize之和。默认值是2MB + 2MB = 4MB。
（4）BackupWriteSize
该参数指定了由备份日志缓冲和备份数据缓冲写入磁盘的消息大小。默认值是32KB.
（5）BackupDataDir
#可更改默认的备份目录,BackupDataDir=/mysqlback
#当然前提,mkdir /mysqlback ,需要在所有数据节点上运行
也能指定存放备份的目录。默认情况下，该目录是FileSystemPath/BACKUP
（6）FileSystemPath
该参数指定了存放为元数据创建的所有文件、REDO日志、UNDO日志和数据文件的目录。默认目录是由DataDir指定的。注意，启动ndbd进程之前，该目录必须已存在。
（7）DataDir
该参数指定了存放跟踪文件、日志文件、pid文件以及错误日志的目录。

3、使用管理服务器创建备份包含以下步骤：
1)启动管理服务器(ndb_mgm)
2）执行命令START BACKUP
3）管理服务器将用消息“指示备份开始”作出应答。这意味着管理服务器将请求提交给了簇，但尚未收到任何回应。
4）管理服务器回复“备份backup_id开始”，其中，backup_id是该备份的唯一ID（如果未作其他配置，该ID还将保存在簇日志中）。这意味着簇已收到并开始处理备份请求。它不表示备份已完成。
5）管理服务器发出消息“备份backup_id完成”，通知备份操作已结束。

4、要想放弃正在处理的备份：
1）启动管理服务器。
2）执行命令ABORT BACKUP backup_id。backup_id是当备份开始时包含在管理服务器应大中的备份ID（在消息“备份backup_id启动”中）
3）管理服务器用消息“放弃指示的备份backup_id”确认放弃请求，注意，尚未收到对该请求的实际回应。
4）一旦放弃了备份，管理服务器将通报“备份backup_id因XYZ而放弃”。这意味着簇中止了备份，并从簇文件系统中删除了与该备份有关的所有文件。在系统shell中使用下述命令，也能放弃正在执行的备份：shell> ndb_mgm -e "ABORT BACKUP backup_id"
注释：执行放弃操作时，如果没有ID为backup_id的备份，管理服务器不会给出任何明确回应。但是，所发出的无效放弃命令将在簇日志中给出

5、如何恢复簇备份

簇恢复程序是作为单独的命令行实用工具ndb_restore实现的，它将读取由备份(由在管理节点的客户端上执行start backup)创建的文件，并将保存的信息插入数据库。必须为每组备份文件执行恢复程序，也就是说，执行次数与创建备份时运行的数据库节点数相同。(当初创建备份时,有几个数据节点参与,就需要执行这样的命令几次,2个数据节点,就需要执行2次,但第一次与第二次在参数上是不同的,第一次需要参数-m,第二次,不用加此参数,此参数的作用是,创建数据元.)

首次执行恢复程序时，还需要恢复元数据。换句话讲，必须重新创建数据库表（注意，开始执行恢复操作时，簇中应有一个空数据库,这里说的创建数据库表,并不是说,让你在sql节点上,在指定的库内,用create table建个空白,而是说,用ndb_restore命令中的一个参数 -m）。恢复程序对于簇来说相当于API，因此，需要一个空闲连接，以便与簇相连。(为此,我们可以在config.ini中添加一个[mysqld],以便于有个空的节点ID,为它提供.)可使用ndb_mgm命令SHOW（在系统shell下使用ndb_mgm -e SHOW即可完成该操作）进行验证, 查看,是否有一个空的mysql(api)节点,没有任何连接,并且允许任意主机,连接。可以使用开关“-c connectstring”来确定MGM节点的位置。（关于连接字符串的更多信息，请参见17.4.4.2节，“MySQL簇连接字符串”。备份文件必须位于恢复程序参量给定的目录下。能够使用与创建时所用配置不同的配置,将备份恢复到数据库。例如，对于备份ID为12的备份，该备份是在具有两个数据库节点（节点ID无恶2和3）的簇中创建的，可以将其恢复到具有4个节点的簇中。这样，ndb_restore必须运行两次，为创建备份时的每个数据库节点运行一次。
我恢复实例操作流程():
(1)首先备份,start backup(记住,backup_id)
(2)修改config.ini,再其追加个[mysqld] --- 最后增加一个[mysqld] 即可
增加前：

[mysqld(API)]   5 node(s)
id=6    @10.3.3.150  (mysql-5.1.44 ndb-7.1.4)
id=7    @10.3.3.151  (mysql-5.1.44 ndb-7.1.4)

增加后：

[mysqld(API)]   5 node(s)
id=6    @10.3.3.150  (mysql-5.1.44 ndb-7.1.4)
id=7    @10.3.3.151  (mysql-5.1.44 ndb-7.1.4)
id=8 (not connected, accepting connect from any host)
(3)停止mgmd,ndb_mgm -e shutdown
(4)启动mgmd,ndb_mgmd(当然,在 config.ini文件目录下执行此命令)
(5)启动数据节点:ndbd --initial(有几个节点,执行此命令几次)
(6)在数据节点上执行ndb_restore -c mgmd -n node_id -m -b backup_id -r [backup_path=]/path/to/backup/files
我的:ndb_restore -c 192.168.1.112 -n 2 -m -b 1 -r /mysql/BACKUP/BACKUP-1/
记住,这个"/",很重要.
mgmd 为管理节点的ip
node_id为数据节点ID,在mgm的客户端通过show查看
-m 在第一个数据节点上执行,它的作用恢复数据元,数据元的作用:所有数据库表的名称和定义.在其他节点,上就不需要此参数了.
backup_id 就是备份的次数.也就是你在此start backup上,提示的那个id,如果不知道,可以到保存此备份的目录下看.
执行的结果:(下)

[root@xiayali root]# /usr/local/mysql/bin/ndb_restore -c 192.168.1.112 -n 2 -m -b 1 -r /mysqlback/BACKUP/BACKUP-1/
Ndb version in backup files: Version 5.0.19
Connected to ndb!!
Successfully restored table test/def/ctest
_____________________________________________________
Processing data in table: test/def/ctest(2) fragment 0
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(1) fragment 0
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(0) fragment 0
Restored 0 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
执行过后,在其sql节点上,只能看到表,不能看到数据,哈哈,这就是-m的作用!
(7)在其他数据节点上执行
ndb_restore -c 192.168.1.112 -n 3 -b 1 -r /mysql/BACKUP/BACKUP-1/
执行的结果:(下)
[root@xiayali bin]# /usr/local/mysql/bin/ndb_restore -c 192.168.1.112 -n 3 -b 1 -r /mysqlback/BACKUP/BACKUP-1/
Ndb version in backup files: Version 5.0.19
Connected to ndb!!
_____________________________________________________
Processing data in table: test/def/ctest(2) fragment 1
_____________________________________________________
Processing data in table: sys/def/NDB$EVENTS_0(1) fragment 1
_____________________________________________________
Processing data in table: sys/def/SYSTAB_0(0) fragment 1
Restored 1 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
执行过后,就能用select看到数据了,因为,我的数据节点,只有2个,所以,我只需操作这两步,如果多个节点,我不知道,执行这一步,是否能看到数
据.不过,我马上就测试添加数据节点.哈哈...再玩备份与恢复~
注释：对于快速恢复，能够以并行方式恢复数据，但必须有足够的可用簇连接。然而，数据文件必须始终前于日志文件。
额外测试(在原有的基础上做的):
NDB_MGMD
|         |         |         |
|         |         |         |  
sql      sql       ndb       ndb
(原来这样的)
NDB_MGMD
|         |         |         |
|         |         |         |  
sql/ndb sql/ndb    ndb       ndb
(现在要在sql节点上添加ndb节点)
只需要在此NDB_MGMD的config.ini里改下下面的参数.
NoOfReplicas=4
[参数说明]
该全局参数仅能在[NDBD DEFAULT]中设置，它定义了簇中每个表保存的副本数。该参数还指定了节点组的大小。节点组指的是保存相同信息的节点集合。节点组是以隐式方式构成的。第1个节点组由具有最低节点ID的数据节点集合构成，下一个节点组由具有次低节点ID的数据节点集合构成，依此类推。作为示例，截顶我们有4个数据节点，并将NoOfReplicas设置为2。这四个数据节点的ID分别是2、3、4、5。那么第1个节点组由节点2和3构成，第2个节点组由节点4和5构成。重要的是对簇进行相应的配置，使得同一节点组中的节点位于不同的计算机上，这是因为，如果位于相同的计算机上，单个硬件故障会导致整个簇崩溃。如果未提供节点ID，那么数据节点的顺序将是节点组的决定因素。无论是否进行了明确的分配，可在管理客户端SHOW命令的输出中查看它们。
(所以,我们需要在config.ini里设置节点ID,从[ndb_mgmd]id=1开始),将其保存相同信息的节点,放置与不同的计算机,以防止崩溃~导致数据丢失~故此,我们可在config.ini里配置ID,来决定那些数据节点,为同一组.哈哈....,想怎么玩,就怎么玩~,但只能提供4个组啊!!!!哈哈.....)
NoOfReplicas没有默认值，最大的可能值为4。
追加
[ndbd]
id=6
hostname=192.168.1.113
datadir=/usr/local/mysql/data
BackupDataDir=/mysqlback #哈哈,记住,这个目录在192.168.1.113必须存在,否则,ndbd --initital 出现错误, 就是启不起来,故mkdir     
/mysqlback

[ndbd]
id=7
hostname=192.168.1.114
datadir=/usr/local/mysql/data
BackupDataDir=/mysqlback   #记住,这个目录在192.168.1.114必须存在,既mkdir /mysqlback
[mysqld]
id=8           #空一个,为ndb_restore用的节点
对于数据节点,只需要mkdir /mysqlback
用来备份mysql簇数据,存放的地方.
配置做好后,那么开始恢复工作了.流程
(1)ndb_mgm -e shutdown
(2)在四个节点上分别启动:ndbd --initial
(3)在原先的节点上,既节点2,节点3上做恢复工作,而对于新添加的节点,不需要下面的操作.
a.在节点2上操作:ndb_restore -c 192.168.1.112 -n 2 -m -b 1 -r /mysql/BACKUP/BACKUP-1/
b.在节点3上操作:ndb_restore -c 192.168.1.112 -n 3 -b 1 -r /mysql/BACKUP/BACKUP-1/
(4)测试:
a.检测mgmd客户端show命令:
ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]     4 node(s)
id=2    @192.168.1.8 (Version: 5.0.19, Nodegroup: 0)
id=3    @192.168.1.111 (Version: 5.0.19, Nodegroup: 0)
id=4    @192.168.1.113 (Version: 5.0.19, Nodegroup: 1, Master)
id=5    @192.168.1.114 (Version: 5.0.19, Nodegroup: 1)
[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.1.112 (Version: 5.0.19)
[mysqld(API)]   3 node(s)
id=6    @192.168.1.113 (Version: 5.0.19)
id=7    @192.168.1.114 (Version: 5.0.19)
id=8 (not connected, accepting connect from any host)
b.检测mysql节点,数据是否恢复成功!
这就不用说了,成功了,不然,也不敢写~
c.停止原来的节点2,3,来看节点4,5有没有复制原先的数据.
在mgmd客户端执行2 stop 3 stop

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]     4 node(s)
id=2 (not connected, accepting connect from 192.168.1.8)
id=3    @192.168.1.111 (Version: 5.0.19, Nodegroup: 0)
id=4 (not connected, accepting connect from 192.168.1.113)
id=5    @192.168.1.114 (Version: 5.0.19, Nodegroup: 1, Master)
[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.1.112 (Version: 5.0.19)
[mysqld(API)]   3 node(s)
id=6    @192.168.1.113 (Version: 5.0.19)
id=7    @192.168.1.114 (Version: 5.0.19)
id=8 (not connected, accepting connect from any host)
注意,因为,我在一开始,将节点组设置为4个,而结点为4,故一个节点一个组,而现在,我将其改成2,就是节点2与节点3为一组,节点4与节点5为一
组,故2 stop 与3 stop会出现错误,于是我将其,改成2 stop 4 stop 下面的没有变化...哈哈.
d.再到mysql节点上查询数据,哈哈.有~~那就表示,恢复成功,并且,数据节点添加成功,已经可以正常保存数据了.

**************************************************************************

测试发现：

1.备份时有几个存储节点就要执行几次恢复操作，和NoOfReplicas参数无关；

2.恢复时没有顺序，怎么执行都可以；
3.备份时每个存储节点都保存有表结构，即每个存储节点恢复时都可以指定 "-m"；
4.备份时每个存储节点只存储部分数据。

如：表tmp有31条记录，四个节点备份时分别备份了9、4、10、8条记录，从恢复日志中可以看出：

Restored 9 tuples and 0 log entries

Restored 4 tuples and 0 log entries

Restored 10 tuples and 0 log entries

Restored 8 tuples and 0 log entries