Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1408755
  • 博文数量: 247
  • 博客积分: 10147
  • 博客等级: 上将
  • 技术积分: 2776
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-24 15:18
文章分类

全部博文(247)

文章存档

2013年(11)

2012年(3)

2011年(20)

2010年(35)

2009年(91)

2008年(87)

我的朋友

分类: Mysql/postgreSQL

2010-08-02 21:21:40

一、MySQL簇的联机备份

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

2
、备份参数(以下参数,都写入在mgmdconfig.ini配置文件中)
本节讨论的参数定义了与在线备份执行有关的内存缓冲集。
1BackupDataBufferSize
在创建备份的过程中,为了将数据发送到磁盘,将使用两类缓冲。备份数据缓冲用于填充由扫描节点的表而记录的数据。一旦将该缓冲填充到了指定的水平BackupWriteSize(请参见下面的介绍),就会将页发送至磁盘。在将页写入磁盘的同时,备份进程能够继续填充该缓冲,直至其空间消耗完为止。出现该情况时,备份进程将暂停扫描,直至一些磁盘写入操作完成并释放了内存为止,然后扫描继续。
该参数的默认值为2MB
2BackupLogBufferSize
备份日志缓冲扮演的角色类似于备份数据缓冲,不同之处在于,它用于生成备份执行期间进行的所有表写入的日志。相同的原理也适用于备份数据缓冲情形下的页写入,不同之处在于,当备份日志缓冲中没有多余空间时,备份将失败。出于该原因,备份日志缓冲的大小应足以处理执行备份时产生的负载。
该参数的默认值对于大多数应用程序均是适当的。事实上,备份失败的原因更可能是因为磁盘写入速度不够,而不是备份日志缓冲变满。如果没有为应用程序产生的写负载配置磁盘子系统,簇很可能无法执行所需的操作。最好按恰当的方式配置簇,使得处理器成为瓶颈而不是磁盘或网络连接。默认值是2MB
3BackupMemory
该参数是BackupDataBufferSizeBackupLogBufferSize之和。默认值是2MB + 2MB = 4MB
4BackupWriteSize
该参数指定了由备份日志缓冲和备份数据缓冲写入磁盘的消息大小。默认值是32KB.
5BackupDataDir
#
可更改默认的备份目录,BackupDataDir=/mysqlback
#
当然前提,mkdir /mysqlback ,需要在所有数据节点上运行
也能指定存放备份的目录。默认情况下,该目录是FileSystemPath/BACKUP
6FileSystemPath
该参数指定了存放为元数据创建的所有文件、REDO日志、UNDO日志和数据文件的目录。默认目录是由DataDir指定的。注意,启动ndbd进程之前,该目录必须已存在。
7DataDir
该参数指定了存放跟踪文件、日志文件、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_idbackup_id是当备份开始时包含在管理服务器应大中的备份ID(在消息备份backup_id启动中)
3
)管理服务器用消息放弃指示的备份backup_id”确认放弃请求,注意,尚未收到对该请求的实际回应。
4
)一旦放弃了备份,管理服务器将通报备份backup_idXYZ而放弃。这意味着簇中止了备份,并从簇文件系统中删除了与该备份有关的所有文件。在系统shell中使用下述命令,也能放弃正在执行的备份:shell> ndb_mgm -e "ABORT BACKUP backup_id"
注释:执行放弃操作时,如果没有IDbackup_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簇连接字符串。备份文件必须位于恢复程序参量给定的目录下。能够使用与创建时所用配置不同的配置,将备份恢复到数据库。例如,对于备份ID12的备份,该备份是在具有两个数据库节点(节点ID无恶23)的簇中创建的,可以将其恢复到具有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_MGMDconfig.ini里改下下面的参数.
NoOfReplicas=4
[
参数说明]
该全局参数仅能在[NDBD DEFAULT]中设置,它定义了簇中每个表保存的副本数。该参数还指定了节点组的大小。节点组指的是保存相同信息的节点集合。节点组是以隐式方式构成的。第1个节点组由具有最低节点ID的数据节点集合构成,下一个节点组由具有次低节点ID的数据节点集合构成,依此类推。作为示例,截顶我们有4个数据节点,并将NoOfReplicas设置为2。这四个数据节点的ID分别是2345。那么第1个节点组由节点23构成,第2个节点组由节点45构成。重要的是对簇进行相应的配置,使得同一节点组中的节点位于不同的计算机上,这是因为,如果位于相同的计算机上,单个硬件故障会导致整个簇崩溃。如果未提供节点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


阅读(3061) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~