mysql簇備份與恢復(轉載)

本文轉自：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.