如何進行MySQL中的xtrabackup備份恢復

這篇文章給大家介紹如何進行MySQL中的xtrabackup備份恢復，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

   XtraBackup是Percona推出的一款備份工具，算是對于mysqldump的一個補充。對于大批量數據的導入使用mysqldump會出現一定的瓶頸，這一點做過一些數據遷移項目的同學可能感同身受。

  數據遷移中的數據量，小有小的好，大有大的招，見招拆招，找到適合的場景是最佳的。

    如果現在去Percona官網下載，就會發現最新的版本已經是2.4.6了。下載可以選擇一個完整的打包，或者逐個的rpm根據需求來安裝也可以。完整的工具大概在60M左右。

    而目前的MySQL版本大多都在5.5， 5.6, 對于5.7相對來說要新一些。中間會有一些時間的過渡，在多年前，可能相對來說用2.0版本一下的還比較多。

   XtraBackup其實包含兩個工具，一個是xtrabackup，另外一個是innobackupex。我們暫且以一個較早的版本作為演示，然后使用新版本來對比下。

# xtrabackup --version
xtrabackup version 1.6.5 for Percona Server 5.1.59

innobackupex --version
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012.  All Rights Reserved.

   可以看到這兩個工具的版本還有一些差別，

xtrabackup主要是用于熱備份innodb,或者是 xtradb表中數據的工具，不能備份其他類型的表，也不能備份數據表結構；

innobackupex是將xtrabackup進行封裝的perl腳本，可以備份和恢復MyISAM表以及數據表結構。

   所以總體來看InnoDB的使用場景雖然最為普遍，但是還得考慮到MyISAM,兩者總體來說，使用innobackex的場景會多一些。

備份淺析

  使用innobackupex備份，命令選項還不少，可以使用innobackupex --help來查看明細的參數使用。

比如我需要做一個全備。可以采用如下類似的方式，在備份命令中加幾個輔助選項，備份使用socket連接，備份目錄在/home/databak/full/20170322下。

innobackupex --socket=/home/mysql/mysql.sock  /home/databak/full/20170322  --no-timestamp --no-lock --throttle=100備份后查看對應的目錄，備份的數據情況如下，其中紅色的幾個文件是備份中額外生成的。整體看來和源庫的目錄結構一樣。

# du -sh ./*
2.6G    ./backend
4.0K    ./backup-my.cnf
646M    ./gm
1.0G    ./ibdata1
99M     ./mobile_activity
5.0G    ./mobile_billing
1.1M    ./mysql
2.0G    ./oem_mon
212K    ./performance_schema
112K    ./test
4.0K    ./xtrabackup_binary
4.0K    ./xtrabackup_checkpoints
4.0K    ./xtrabackup_logfile對于上面生成的文件，我們簡單看一下。

binary結尾的文件是備份中用到的可執行文件，這個可以對應幾個版本，比如xtrabackup_51,xtrabackup_55等

# more xtrabackup_binary
xtrabackup_55logfile結尾的文件的內容無法直接查看，但是可以用strings來看。通過strings解析可以看到對應的二進制日志，當然事務的Xid也有的。

# strings xtrabackup_logfile
xtrabkup 170322 16:33:40
{       ';{
        ';{
MySQLXid
./mysql-bin.000009
        393102654
08360000000039DB下面的這個文件就更特別了，這個是作為數據的備份恢復的關鍵，里面有著備份恢復所有的檢查點LSN,從下面的數據來看，這是一個全備，因為from_lsn=0.

# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 30754980731
last_lsn = 30754980731

而在源庫的目錄結構下，我們稍作過濾，也會得到一個幾乎和這個工具備份出來一樣的目錄結構來。  

# du -sh ./*|grep -v mysql-bin|grep -v innodb|grep -v log
2.6G    ./backend
646M    ./gm
1.0G    ./ibdata1
4.5M    ./ib_lru_dump
99M     ./mobile_activity
5.0G    ./mobile_billing
1.1M    ./mysql
4.0K    ./mysql.pid
0       ./mysql.sock
2.0G    ./oem_mon
212K    ./performance_schema
112K    ./test所以xtrabackup這樣一個工具就是一個熱備工具，有點類似有文件級別的拷貝，但是不止于此，我們往下看。   

全庫恢復模擬

  數據恢復是DBA最重要的工作之一，多年之前，這個“之一“的字眼還要去掉。數據無法恢復，則備份無意義。

   數據的恢復還是使用innobackupex這個工具，這是參數有些差別。

   這里的數據恢復分為兩個步驟，prepare和還原恢復，prepare的意義就在于，如果我們備份數據的時候，存在未提交的事務，但是數據卻存在于備份中，這樣就是一個數據不一致的狀態，在啟動數據庫的時候需要走一個前滾，然后是一個回滾的操作。這個體現主要就在于logfile和ibdata。是使用apply-log這個選項實現的。

   我們使用如下的方式來做。

innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --apply-log /home/databak/full/20170322這個過程其實就會隱式調用xtrabackup_55這個可執行文件，調用的命令類似于：

xtrabackup_55  --defaults-file="/home/databak/full/20170322/backup-my.cnf"默認會使用100M的內存，也可以使用選項--use-memory來調整，整個過程會重構redo日志文件和ibdata.

   這個步驟完成之后就是最關鍵的地方了，還原恢復。這個過程是使用copy-back的選項實現的。

innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --copy-back /home/databak/full/20170322整個過程就是大量的拷貝工作。

完成之后需要修改一下文件的屬主，默認是root,然后啟動即可。

增量備份恢復

   我們接下來看看增量備份和恢復，先來創建一些數據。我們在數據庫test下創建一個表test2.

> create table test2 (id int);
Query OK, 0 rows affected (0.01 sec)
> insert into test2 values(1),(2);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

因為剛剛已經做了全備，我們繼續做一個增備。

使用的命令如下：

 innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322 --incremental /home/databak/incre/20170322但是很不幸，執行失敗了。這個錯誤帶有典型的意義。

170322 18:05:34  innobackupex: Starting ibbackup with command: xtrabackup_55  --defaults-file="/etc/my.cnf" --backup --suspend-at-end --target-dir=/home/databak/incre/20170322/2017-03-22_18-05-32 --incremental-basedir='/home/databak/incre/20170322'
innobackupex: Waiting for ibbackup (pid=4079) to suspend
innobackupex: Suspend file '/home/databak/incre/20170322/2017-03-22_18-05-32/xtrabackup_suspended'
...
xtrabackup: Error: cannot open /home/databak/incre/20170322/xtrabackup_checkpoints
xtrabackup: error: failed to read metadata from /home/databak/incre/20170322/xtrabackup_checkpoints
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 349.原因就在于里面的一個關鍵文件 _checkpoints

使用增備得有一個參考點，從哪里開始，即從哪個LSN開始，這個LSN在指定的參數--incremental-basedir=/home/databak/incre/20170322 下不存在，因為這個是一個新目錄，所以需要指向全庫備份的目錄。

  然后修復后備份就沒問題了，英為有了這個參考點LSN，所以需要要說明的是這個備份其實有累計增量和差異增量了。

  這個怎么理解呢，比如周日做一個全備，周一做一個增備，周二做一個周日全備到周二的一個增備，這就是一個累計增量備份，而周三的時候做一個周二至周三數據變化的備份，就是一個差異增量備份。

  下面的是一個累計增量備份。因為基準是上次的一個全備，備份后會自動生成一個目錄，比如 2017-03-22_18-07-38

  innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/full/20170322 --incremental /home/databak/incre/20170322   為了區別兩次增量，我繼續插入兩行數據。

> insert into test2 values (3),(4);
Query OK, 2 rows affected (0.00 sec)  這樣表test2就有4條數據了，每次插入2條。

  下面的是一個差異增量備份。基于上一次的增備。

 innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322/2017-03-22_18-07-38 --incremental /home/databak/incre/20170322  整個恢復的過程是下面的形式，還是一個prepare的過程，首先是全備:

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322然后是增備，注意這里標紅的參數。

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322 --incremental-dir=/home/databak/incre/20170322/2017-03-22_18-07-38這樣做其實是一個merge的過程，對于增備來說，會生成如下的幾個文件，都是.delta, .meta之類的文件。

[test]# ll
total 132
-rw-r--r-- 1 mysql mysql    61 Mar 22 17:58 db.opt
-rw-rw---- 1 mysql mysql  8556 Mar 22 18:03 test2.frm
-rw-r--r-- 1 root  root  81920 Mar 22 18:08 test2.ibd.delta
-rw-r--r-- 1 root  root     18 Mar 22 18:08 test2.ibd.meta

增備目錄下的checkpoint文件就有意思了。有一個很清晰的LSN的增量描述。

[ 2017-03-22_18-07-38]# cat *checkpoints
backup_type = incremental
from_lsn = 30754980731
to_lsn = 30754984465
last_lsn = 30754984465而prepare之后的全備里面的checkpoint文件其實已經發生了變化

# cat *checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 30754984465
last_lsn = 30754984465這個時候我們使用如下的方式來還原恢復。

#innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/incre/20170322/2017-03-22_18-07-38這個時候表test2里面的數據是幾條？ 是2條。

   這個過程我們相當于完成了一個全備+一個增備的數據恢復過程。

  而我們在一個增備之后又插入了一些數據，這個怎么繼續恢復呢，還是prepare的過程。這個路徑需要注意，還是merge到全備中。

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322  --incremental-dir=/home/databak/incre/20170322/2017-03-22_18-11-26繼續還原恢復。

innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/full/20170322再次查看數據,我們要恢復的4條數據都恢復回來了。

> select *from test2;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
+------+
4 rows in set (0.06 sec)

備份中的選項補充

innobackupex中的選項很多，有幾個還是比較有特色的，比如stream選項，--slave-info選項能夠方便搭建從庫，生成偏移量的信息，比如并行--parallel等，還可以根據LSN來備份，選項是--incremental-lsn

對于stream選項，默認是打包，可以結合管道來實現壓縮，比如：innobackupex --defaults-file=/etc/my.cnf --user=root --stream=tar  /home/databak/full/20170322_2 | gzip > /home/databak/full/20170322_2/20170322_2.tar.gz   

備份中的常用場景

   很多時候其實我不想備份整個庫，我只想備份一個表，那么這個操作如何來實現呢。

innobackupex --defaults-file=/etc/my.cnf --user=root --include='test.test2'  /home/databak/full/20170322_2這里有幾點需要注意，工具還是會逐個去掃描，只是那些不符合的會被忽略掉，也就意味著備份出來的情況和全備的目錄結構是一樣的，但是指定的表會備份出ibd，frm文件。

[test]# ll
total 1036
-rw-r--r-- 1 mysql mysql    8556 Mar 22 18:34 test2.frm
-rw-r--r-- 1 root  root  1048576 Mar 22 19:26 test2.ibd
[ test]# cd ../mysql
[ mysql]# ll
total 0而且有一點值得吐槽一下的是，ibdata也會完整備份出來，如果這個文件很大，那就相當不給力了。

不過也別對這種備份失去信心，有一個場景還是很實用的。那就是遷移表。

遷移表

  還是剛剛的這個場景，如果表test2需要拷貝到另外一套環境中，我們可以使用Innobackupex來做物理備份，然后還原導入，達到遷移的目的。

下面的命令會聲明指定目錄下的備份需要導出對象。    innobackupex --apply-log --export /home/databak/full/20170322_2/2017-03-22_19-26-46這個過程的直接產物就是生成了一個.exp文件，在MySQL原生版本中是.cfg文件

[ test]# ll
total 1052
-rw-r--r-- 1 root  root    16384 Mar 22 19:29 test2.exp
-rw-r--r-- 1 mysql mysql    8556 Mar 22 18:34 test2.frm
-rw-r--r-- 1 root  root  1048576 Mar 22 19:26 test2.ibd對表test2做數據信息截斷。

> alter table test2 discard tablespace;
Query OK, 0 rows affected (0.07 sec)然后就是物理拷貝，復制.exp文件和.ibd文件到指定目錄下，修改屬主權限。

然后使用import的方式即可完成導入。

> alter table test2 import tablespace;
Query OK, 0 rows affected (0.00 sec)有另外一點值得說的是，這個.exp文件是不是必須的，其實也不是。

我們只拷貝.ibd文件也照樣可以。可能在新版本中會有一些警告提示，我們重新來做一下。

[test]> alter table test2 discard tablespace;
Query OK, 0 rows affected (0.03 sec)同時刪除剛剛拷貝過來的.exp文件。

然后拷貝ibd文件到指定目錄，賦權限

導入表空間信息。

[test]> alter table test2 import tablespace;
Query OK, 0 rows affected (0.00 sec)查看數據的情況，發現數據還是回來了。

[test]> select *from test2;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
+------+
4 rows in set (0.00 sec)當然這個過程中還是有很多需要注意的地方。

關于如何進行MySQL中的xtrabackup備份恢復就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。