ITPub博客

首页 > Linux操作系统 > Linux操作系统 > mysql簇备份与恢复(转载)

mysql簇备份与恢复(转载)

原创 Linux操作系统 作者:season0891 时间:2009-05-26 10:09:45 0 删除 编辑

本文转自:http://www.1398.net/blog/user1/badboy/archives/2007/659.html


这是一篇,将资料与个人理解与实际操作实验的文章,可以说,在网上,很难找到比这还详细的资料了,因为,我花了,整整3天时间,来搞这个.为什

么要写出来,原因,很简单,网上对这说的很少,要么就是让你一知半解的,很晕的!为了弥补,我就努力一把,写一份吧!
至于原创,应该算吧
那就写个HAHAZHU 原创
MY QQ:383088680

MySQL簇的联机备份
簇备份概念
备份指的是在给定时间对数据库的快照。备份包含三个主要部分:
·         Metadata(元数据):所有数据库表的名称和定义。

·         Table records(表记录):执行备份时实际保存在数据库表中的数据。

·         Transaction log(事务日志):指明如何以及何时将数据保存在数据库中的连续记录。

每一部分(这三部分)均会保存在参与备份的所有数据节点上。在备份过程中 ,每个节点均会将这三个部分保存在磁盘上的三个文件中(意思是

说,有几个节点,将会把相同的数据,保存几份.例如,2个数据节点,那么就会分别在2个节点上,保存2次.保存目录默认为[NDBD]

DateDir=/usr/local/mysql/BACKUP下):

·         BACKUP-backup_id.node_id.ctl

包含控制信息和元数据的控制文件。每个节点均会将相同的表定义(对于簇中的所有表)保存在自己的该文件中。

·         BACKUP-backup_id-0.node_id.data

包含表记录的数据文件,它是按片段保存的,也就是说,在备份过程中,不同的节点会保存不同的片段。每个节点保存的文件以指明了记录所

属表的标题开始。在记录清单后面有一个包含关于所有记录校验和的脚注。

·         BACKUP-backup_id.node_id.log

包含已提交事务的记录的日志文件。在日志中,仅保存已在备份中保存的表上的事务。参与备份的节点将保存不同的记录,这是因为,不同的

节点容纳了不同的数据库片段。

在上面所列的内容中,backup_id指的是备份ID,node_id是创建文件的节点的唯一ID。

使用管理服务器创建备份
开始备份前,请确保已为备份操作恰当地配置了簇。
[start]
备份参数(以下参数,都写入在mgmd的config.ini配置文件中)

本节讨论的参数定义了与在线备份执行有关的内存缓冲集。

·         [NDBD]BackupDataBufferSize

在创建备份的过程中,为了将数据发送到磁盘,将使用两类缓冲。备份数据缓冲用于填充由扫描节点的表而记录的数据。一旦将该缓冲填充到

了指定的水平BackupWriteSize(请参见下面的介绍),就会将页发送至磁盘。在将页写入磁盘的同时,备份进程能够继续填充该缓冲,直至其

空间消耗完为止。出现该情况时,备份进程将暂停扫描,直至一些磁盘写入操作完成并释放了内存为止,然后扫描继续。

该参数的默认值为2MB。

·         [NDBD]BackupLogBufferSize

备份日志缓冲扮演的角色类似于备份数据缓冲,不同之处在于,它用于生成备份执行期间进行的所有表写入的日志。相同的原理也适用于备份

数据缓冲情形下的页写入,不同之处在于,当备份日志缓冲中没有多余空间时,备份将失败。出于该原因,备份日志缓冲的大小应足以处理执

行备份时产生的负载。

该参数的默认值对于大多数应用程序均是适当的。事实上,备份失败的原因更可能是因为磁盘写入速度不够,而不是备份日志缓冲变满。如果

没有为应用程序产生的写负载配置磁盘子系统,簇很可能无法执行所需的操作。

最好按恰当的方式配置簇,使得处理器成为瓶颈而不是磁盘或网络连接。

默认值是2MB。

·         [NDBD]BackupMemory

该参数是BackupDataBufferSize和BackupLogBufferSize之和。

默认值是2MB + 2MB = 4MB。

·         [NDBD]BackupWriteSize

该参数指定了由备份日志缓冲和备份数据缓冲写入磁盘的消息大小。

默认值是32KB.

·         [NDBD]BackupDataDir
#可更改默认的备份目录,BackupDataDir=/mysqlback
#当然前提,mkdir /mysqlback ,需要在所有数据节点上运行

也能指定存放备份的目录。默认情况下,该目录是FileSystemPath/BACKUP

·         [NDBD]FileSystemPath

该参数指定了存放为元数据创建的所有文件、REDO日志、UNDO日志和数据文件的目录。默认目录是由DataDir指定的。注意,启动ndbd进程之前

,该目录必须已存在。

·         [NDBD]DataDir

该参数指定了存放跟踪文件、日志文件、pid文件以及错误日志的目录。

[end]
使用管理服务器创建备份包含以下步骤:

1.    启动管理服务器(ndb_mgm)。

2.    执行命令START BACKUP。

3.    管理服务器将用消息“指示备份开始”作出应答。这意味着管理服务器将请求提交给了簇,但尚未收到任何回应。

4.    管理服务器回复“备份backup_id开始”,其中,backup_id是该备份的唯一ID(如果未作其他配置,该ID还将保存在簇日志中)。这意

味着簇已收到并开始处理备份请求。它不表示备份已完成。

5.    管理服务器发出消息“备份backup_id完成”,通知备份操作已结束。

要想放弃正在处理的备份:

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的备份,管理服务器不会给出任何明确回应。但是,所发出的无效放弃命令将在簇日志中给出

17.6.5.3. 如何恢复簇备份
簇恢复程序是作为单独的命令行实用工具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]
(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节点上查询数据,哈哈.有~~那就表示,恢复成功,并且,数据节点添加成功,已经可以正常保存数据了.

在这备份与恢复一章节中,花了我足足3天的时间,总算,搞定了~~希望,喜欢技术的朋友,能与我交流,我的QQ:383088680

[英语参考资料]
ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r [backup_path=]/path/to/backup/files
The -c option is used to specify a connectstring which tells ndb_restore where to locate the cluster management server. (See

Section 15.4.4.2, “The Cluster Connectstring”, for information on connectstrings.) If this option is not used, then

ndb_restore attempts to connect to a management server on localhost:1186. This utility acts as a cluster API node, and so

requires a free connection “slot” to connect to the cluster management server. This means that there must be at least one

[API] or [MYSQLD] section that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty

[API] or [MYSQLD] section in config.ini that is not being used for a MySQL server or other application for this reason (see

Section 15.4.4.6, “Defining SQL and Other API Nodes”).

You can verify that ndb_restore is connected to the cluster by using the SHOW command in the ndb_mgm management client. You

can also accomplish this from a system shell, as shown here:

shell> ndb_mgm -e "SHOW"
-n is used to specify the node ID of the data node on which the backups were taken.

The first time you run the ndb_restore restoration program, you also need to restore the metadata. In other words, you must

re-create the database tables — this can be done by running it with the -m option. Note that the cluster should have an

empty database when starting to restore a backup. (In other words, you should start ndbd with --initial prior to performing

the restore.)

The -b option is used to specify the ID or sequence number of the backup, and is the same number shown by the management

client in the Backup backup_id completed message displayed upon completion of a backup. (See Section 15.8.2, “Using The

Management Client to Create a Backup”.)

The path to the backup directory is required, and must include the subdirectory corresponding to the ID backup of the backup

to be restored. For example, if the data node's DataDir is /var/lib/mysql-cluster, then the backup directory is

/var/lib/mysql-cluster/BACKUP, and the backup files for the backup with the ID 3 can be found in /var/lib/mysql-

cluster/BACKUP/BACKUP-3. The path may be absolute or relative to the directory in which the ndb_restore executable is

located, and may be optionally prefixed with backup_path=.

Important
When restoring cluster backups, you must be sure to restore all data nodes from backups having the same backup ID. Using

files from different backups will at best result in restoring the cluster to an inconsistent state, and may fail altogether.

It is possible to restore a backup to a database with a different configuration than it was created from. For example,

suppose that a backup with backup ID 12, created in a cluster with two database nodes having the node IDs 2 and 3, is to be

restored to a cluster with four nodes. Then ndb_restore must be run twice — once for each database node in the cluster where

the backup was taken. However, ndb_restore cannot always restore backups made from a cluster running one version of MySQL to

a cluster running a different MySQL version. See Section 15.5.2, “Cluster Upgrade and Downgrade Compatibility”, for more

information.

Note
For more rapid restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster

connections available. That is, when restoring to multiple nodes in parallel, you must have an [API] or [MYSQLD] section in

the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied

before the logs.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/90618/viewspace-604170/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-06-10

  • 博文量
    791
  • 访问量
    1929060