MariaDB/MySQL備份恢復系列：備份和恢復(一)：mysqldump工具用法詳述備份和恢復(二)：導入、導出表數據備份和恢復(三)：xtrabackup用法和原理詳述本文目錄： 1.安裝xtrabackup 2.備份鎖 3.xtrabackup備份原理說明 3.1 備份過程(back ...

MariaDB/MySQL備份恢復系列：
備份和恢復(一)：mysqldump工具用法詳述
 備份和恢復(二)：導入、導出表數據
 備份和恢復(三)：xtrabackup用法和原理詳述

本文目錄：
1.安裝xtrabackup
2.備份鎖
3.xtrabackup備份原理說明
　3.1 備份過程(backup階段)
　3.2 準備過程(preparing階段)
　3.3 恢復過程(copy back階段)
4.準備實驗環境
5.innobackupex工具
　5.1 innobackupex實現全備份和恢復的過程
　5.2 innobackupex實現增量備份和恢復的過程
　5.3 innobackupex實現導出和導入單張表的過程
　5.4 innobackupex實現部分備份和恢復的過程
　5.5 innobackupex實現定時點恢復
　5.6 流備份和遠程備份
　5.7 加速備份
6.xtrabackup工具
　6.1 xtrabackup實現全備
　6.2 xtrabackup實現增備
　6.3 xtrabackup實現部分備份

xtrabackup是percona團隊研發的備份工具，比MySQL官方的ibbackup的功能還要多。支持myisam溫全備、innodb熱全備和溫增備，還可以實現innodb的定時點恢復，而且備份和恢復的速度都較快。在目前MySQL的備份實現上，考慮價格、速度、安全、一致性等角度，xtrabackup是非常合適的工具。

MariaDB也可以使用percona xtrabackup進行備份，不過MariaDB基於percona xtrabackup開發了它自己的備份工具：MariaDB Backup。它基於xtrabackup開發，所以所用方法基本和xtrabackup相同，只是有些自己的特性。詳細內容見MariaDB Backup官方手冊：https://mariadb.com/kb/en/library/mariadb-backup/

xtrabackup官方手冊：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

1.安裝xtrabackup

下載地址：https://www.percona.com/downloads/XtraBackup/LATEST/

rpm倉庫(實際上是percona的倉庫)：http://repo.percona.com/release/

清華大學percona源：https://mirrors.tuna.tsinghua.edu.cn/percona/

因為只是一個備份工具，所以沒必要編譯安裝，直接下載它的rpm包即可。但是該rpm包依賴於libev.so.4，該依賴包可以在epel源中找到。

這裡安裝的是目前最新版的xtrabackup-24-2.4.11。

cat <<eof>>/etc/yum.repos.d/percona.repo
[percona]
name = Percona
baseurl = https://mirrors.tuna.tsinghua.edu.cn/percona/release/\$releasever/RPMS/\$basearch
enabled = 1
gpgcheck = 0

[epel]
name=epelrepo
baseurl=https://mirrors.aliyun.com/epel/\$releasever/\$basearch
gpgcheck=0
enable=1
eof

[root@node1 ~]# yum list all| grep xtraback -i
Repository epel is listed more than once in the configuration
holland-xtrabackup.noarch                      1.0.14-3.el6                 epel
percona-xtrabackup.x86_64                      2.3.10-1.el6                 percona
percona-xtrabackup-20.x86_64                   2.0.8-587.rhel6              percona
percona-xtrabackup-20-debuginfo.x86_64         2.0.8-587.rhel6              percona
percona-xtrabackup-20-test.x86_64              2.0.8-587.rhel6              percona
percona-xtrabackup-21.x86_64                   2.1.9-746.rhel6              percona
percona-xtrabackup-21-debuginfo.x86_64         2.1.9-746.rhel6              percona
percona-xtrabackup-22.x86_64                   2.2.13-1.el6                 percona
percona-xtrabackup-22-debuginfo.x86_64         2.2.13-1.el6                 percona
percona-xtrabackup-24.x86_64                   2.4.11-1.el6                 percona
percona-xtrabackup-24-debuginfo.x86_64         2.4.11-1.el6                 percona
percona-xtrabackup-debuginfo.x86_64            2.3.10-1.el6                 percona
percona-xtrabackup-test.x86_64                 2.3.10-1.el6                 percona
percona-xtrabackup-test-21.x86_64              2.1.9-746.rhel6              percona
percona-xtrabackup-test-22.x86_64              2.2.13-1.el6                 percona
percona-xtrabackup-test-24.x86_64              2.4.11-1.el6                 percona

[root@node1 ~]# yum -y install percona-xtrabackup-24

裝完xtrabackup後，生成以下幾個工具。

[root@node1 ~]# rpm -ql percona-xtrabackup-24 | grep bin | xargs ls -hl
lrwxrwxrwx 1 root root   10 May  8 19:19 /usr/bin/innobackupex -> xtrabackup
-rwxr-xr-x 1 root root 3.5M Apr 19 01:11 /usr/bin/xbcloud
-rwxr-xr-x 1 root root 3.0K Apr 19 01:04 /usr/bin/xbcloud_osenv
-rwxr-xr-x 1 root root 3.5M Apr 19 01:11 /usr/bin/xbcrypt
-rwxr-xr-x 1 root root 3.5M Apr 19 01:11 /usr/bin/xbstream
-rwxr-xr-x 1 root root  21M Apr 19 01:11 /usr/bin/xtrabackup

xbcloud和xbcloud_osenv是xtrabackup新的高級特性：雲備份；
xbcrypt也是新的特性，加密備份集；
xbstream是xtrabackup的流數據功能，通過流數據功能，可將備份內容打包並傳給管道後的壓縮工具進行壓縮；
xtrabackup是主程式；
innobackupex在以前是一個perl腳本，會調用xtrabackup這個二進位工具，從xtrabackup 2.3開始，該工具使用C語言進行了重寫，當前它是xtabackup二進位工具的一個軟連接，但是實際的使用方法卻不同，並且在以後的版本中會刪除該工具。

在本文中，會分別對兩個主程式innobackupex和xtrabackup的備份恢復方法進行詳細的說明，還會在說明過程中儘可能的解釋它們是如何工作的，另外還會介紹它們的一些特殊功能的選項，如流備份選項。

2.備份鎖

一篇不錯的介紹xtrabackup鎖的文章：https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/。

percona Server 5.6+ 支持一種新鎖——backup lock(備份鎖)，這種鎖是percona對MySQL的補充，專門為備份而設計。這種鎖在percona Server 5.6+ 有，MariaDB中也有，但是Oracle的MySQL中沒有，至少MySQL 5.7中沒有。

這種鎖用在備份的時候替代 flush tables with read lock 獲取全局鎖，是一種輕量級的全局鎖。它有兩種類型的鎖：備份表鎖和二進位日誌鎖。為此新增了3種語法：

lock tables for backup   # 申請備份表鎖
lock binlog for backup   # 申請二進位日誌鎖
unlock binlog            # 釋放二進位日誌鎖

備份表鎖在全局範圍內只對非innodb表加鎖，所以持有該鎖後無法修改非innodb表，但卻不影響innodb表的DML。當然，因為是全局鎖，所以也會阻塞DDL操作。

二進位日誌鎖在全局範圍內鎖定二進位日誌，所以會阻塞其他會話修改二進位日誌。這樣可以保證能夠獲取到二進位日誌中一致性的位置坐標。

3.xtrabackup備份原理說明

不管是使用innobackupex還是xtrabackup工具進行備份和恢復，都有3個步驟：備份(backup)、準備(prepare)、恢復(copy back)。

註意，xtrabackup備份過程中，先備份innodb表，再備份非innodb表。

3.1 備份過程(backup階段)

(1).在啟動xtrabackup時記下LSN並將redo log拷貝到備份目標目錄下的xtrabackup_logfile文件中。由於拷貝需要一定時間，如果在拷貝時間段內有日誌寫入，將導致拷貝的日誌和MySQL的redo log不一致，所以xtrabackup還有一個後臺進程監控著mysql的redo log，每秒監控一次，當MySQL的redo log有變化，該監控進程會立即將變化的內容寫入到xtrabackup_logfile文件，這樣就能保證拷貝走的redo log中記錄了一切變化。但是這也是有風險的，因為redo是輪訓式迴圈寫入的，如果某一時刻有非常大量的日誌寫到redo log中，使得還沒開始複製的日誌就被新日誌覆蓋了，這樣會日誌丟失，並報錯。

(2).拷貝完初始版的redo log後，xtrabackup開始拷貝innodb表的數據文件(即表空間文件.ibd文件和ibdata1)。註意，此時不拷貝innodb的frm文件。

(3).當innodb相關表的數據文件拷貝完成後，xtrabackup開始準備拷貝非innodb的文件。但在拷貝它們之前，要先對非innodb表進行加鎖防止拷貝時有語句修改這些類型的表數據。

對於不支持backup lock的版本，只能通過flush tables with read lock來獲取全局讀鎖，但這樣也同樣會鎖住innodb表，殺傷力太大。所以使用xtrabackup備份Oracle的MySQL，實質上只能實現innodb表的部分時間熱備、部分時間溫備。

對於支持backup lock的版本，xtrabackup通過lock tables for backup獲取輕量級的backup locks來替代flush tables with read lock，因為它只鎖定非innodb表，所以由此實現了innodb表的真正熱備。

(4).當獲取到非innodb表的鎖以後，開始拷貝非innodb表的數據和.frm文件。當這些拷貝完成之後，繼續拷貝其他存儲引擎類型的文件。(實際上，拷貝非innodb表的數據是在獲取backup locks(如果支持)後自動進行的，它們屬於同一個過程)

(5).當拷貝階段完成後，就到了備份的收尾階段。包括獲取二進位日誌中一致性位置的坐標點、結束redo log的監控和拷貝、釋放鎖等。

對於不支持backup lock的版本，收尾階段的過程是這樣的：獲取二進位日誌的一致性坐標點、結束redo log的監控和拷貝、釋放鎖。

對於支持backup lock的版本，收尾階段的過程是這樣的：先通過lock binlog for bakcup來獲取二進位日誌鎖，然後結束redo log的監控和拷貝，再unlock tables釋放表鎖，隨後獲取二進位日誌的一致性位置坐標點，最後unlock binlog釋放二進位日誌鎖。

(6).如果一切都OK，xtrabackup將以狀態碼0退出。

所以，對是否支持backup lock的版本，xtrabackup備份的時的行為是不一樣的。

backup階段的過程具體如下圖所示：

FTWRL：flush table with read lock;

3.2 準備過程(prepare階段)

由於備份的時候拷貝走的數據文件可能是不一致的，比如監控著MySQL的redo log中在拷貝過程完成後又新的事務提交了，而拷貝走的數據是未提交狀態的，那麼就需要對該事務前滾；如果監控到的日誌中有事務未提交，那麼該事務就需要回滾。

但是如果只備份了myisam表或其他非事務表數據，因為備份階段直接鎖定了這些表，所以不會有不一致的狀態。

xtrabackup有一個"準備"的階段。這個階段的實質就是對備份的innodb數據應用redo log，該回滾的回滾，該前滾的前滾，最終保證xtrabackup_logfile中記錄的redo log已經全部應用到備份數據頁上，並且實現了一致性。當應用結束後，會重寫"xtrabackup_logfile"再次保證該redo log和備份的數據是對應的。

準備過程不需要連接資料庫，該過程可以在任意裝了xtrabackup軟體的機器上進行，之所能實現是因為xtrabackup軟體的內部嵌入了一個簡化的innodb存儲引擎，可以通過它完成日誌的應用。

3.3 恢復過程(copy back階段)

xtrabackup的恢復過程實質是將備份的數據文件和結構定義等文件拷貝回MySQL的datadir。同樣可以拷貝到任意機器上。

要求恢復之前MySQL必須是停止運行狀態，且datadir是空目錄，除非恢復的操作是導入表的操作。具體見後文對應的內容。

4.準備實驗環境

創建測試資料庫backuptest，並創建myisam表和innodb表，此處簡單的使用數值輔助表並分別插入1億條數據。

DROP DATABASE IF EXISTS backuptest;
CREATE DATABASE backuptest;
USE backuptest;

# 創建myisam類型的數值輔助表和對應插入數據的存儲過程
CREATE TABLE num_isam(n INT NOT NULL PRIMARY KEY)ENGINE=MYISAM;
DELIMITER $$
DROP PROCEDURE IF EXISTS proc_num1$$
CREATE PROCEDURE proc_num1(num INT) 
BEGIN
    DECLARE rn INT DEFAULT 1;
    TRUNCATE TABLE backuptest.num_isam;
    INSERT INTO backuptest.num_isam VALUES(1);
    dd: WHILE rn*2 < num DO
        BEGIN
            INSERT INTO backuptest.num_isam SELECT rn+n FROM backuptest.num_isam;
            SET rn = rn*2;
        END;
    END WHILE dd;
    INSERT INTO backuptest.num_isam SELECT n+rn FROM num_isam WHERE n+rn <=num;
END;$$
DELIMITER ;

# 創建innodb類型的數值輔助表和對應插入數據的存儲過程
CREATE TABLE num_innodb(n INT NOT NULL PRIMARY KEY)ENGINE=INNODB;
DELIMITER $$
DROP PROCEDURE IF EXISTS proc_num2$$
CREATE PROCEDURE proc_num2(num INT) 
BEGIN
    DECLARE rn INT DEFAULT 1;
    TRUNCATE TABLE backuptest.num_innodb;
    INSERT INTO backuptest.num_innodb VALUES(1);
    dd: WHILE rn*2 < num DO
        BEGIN
            INSERT INTO backuptest.num_innodb SELECT rn+n FROM backuptest.num_innodb;
            SET rn = rn*2;
        END;
    END WHILE dd;
    INSERT INTO backuptest.num_innodb SELECT n+rn FROM backuptest.num_innodb WHERE n+rn <=num;
END;$$
DELIMITER ;

# 分別向兩個數值輔助表中插入1億條數據，
CALL proc_num1(100000000);
CALL proc_num2(100000000);

5.innobackupex工具

5.1 innobackupex實現全備份和恢復的過程

(1). 全備

除了給定連接MySQL伺服器的連接參數，只需再給定一個目錄即可，該目錄是備份的目標位置。預設xtrabackup連接資料庫的時候從配置文件中去讀取和備份相關的配置，可以使用選項--defaluts-file指定連接時的參數配置文件，但如果指定該選項，該選項只能放在第一個選項位置。

innobackupex --user=root --password=123456 /bakdir/

預設備份的路徑是指定路徑/bakdir下的一個以時間為時間戳的目錄。

[root@xuexi bakdir]# du -sh /bakdir/2017-04-02_07-09-47/*
4.0K    /bakdir/2017-04-02_07-09-47/backup-my.cnf
4.0G    /bakdir/2017-04-02_07-09-47/backuptest
589M    /bakdir/2017-04-02_07-09-47/ibdata1
1.8M    /bakdir/2017-04-02_07-09-47/mysql
8.0K    /bakdir/2017-04-02_07-09-47/Performance
636K    /bakdir/2017-04-02_07-09-47/performance_schema
1008K   /bakdir/2017-04-02_07-09-47/world
4.0K    /bakdir/2017-04-02_07-09-47/xtrabackup_binlog_info
4.0K    /bakdir/2017-04-02_07-09-47/xtrabackup_checkpoints
4.0K    /bakdir/2017-04-02_07-09-47/xtrabackup_info
4.0K    /bakdir/2017-04-02_07-09-47/xtrabackup_logfile

查看該文件目錄中文件和大小，可以看出xtrabackup的行為就是複製了目標資料庫的相關文件，並新建了幾個文件。

其中：

backup-my.cnf是拷貝過來的配置文件。裡面只包含[mysqld]配置片段和備份有關的選項。

xtrabackup_binlog_info中記錄的是當前使用的二進位日誌文件。

[root@xuexi bakdir]# cat 2017-04-02_07-09-47/xtrabackup_binlog_info 
mysql-bin.000001        120

xtrabackup_checkpoints中記錄了備份的類型是全備還是增備，還有備份的起始、終止LSN號。

[root@xuexi bakdir]# cat 2017-04-02_07-09-47/xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 7533359841
last_lsn = 7533359841
compact = 0
recover_binlog_info = 0

xtrabackup_info中記錄的是備份過程中的一些信息。

[root@xuexi bakdir]# cat 2017-04-02_07-09-47/xtrabackup_info 
uuid = 66f34974-1730-11e7-9d09-000c299af3f3
name = 
tool_name = innobackupex
tool_command = --user=root --password=...  /bakdir/
tool_version = 2.4.6
ibbackup_version = 2.4.6
server_version = 5.6.35-log
start_time = 2017-04-02 07:09:47
end_time = 2017-04-02 07:10:31
lock_time = 0
binlog_pos = filename 'mysql-bin.000001', position '120'
innodb_from_lsn = 0
innodb_to_lsn = 7533359841
partial = N          # N表示未啟用該方面的功能，如此處表示不是備份部分資料庫或表
incremental = N
format = file
compact = N
compressed = N
encrypted = N

xtrabackup_logfile是複製和監控後寫的redo日誌。該日誌是備份後下一個操作"準備"的關鍵。只有通過它才能實現數據一致性。

(2). 全備的準備過程

在全備份完成之後，備份的數據中如果有innodb數據，則還不能用來恢復。因為從xtrabackup開始備份的時候就監控著MySQL的redo log，在拷貝的innodb數據文件中很可能還有未提交的事務，並且拷貝完innodb數據之後還可能提交了事務或者開啟了新的事務等等。總之，全備之後的狀態不一定是一致的。但是如果只備份了myisam表或其他非事務表數據，因為備份階段直接鎖定了這些表，所以不會有不一致的狀態。

例如，備份的innodb數據文件中存在未提交的事務，但是在監控到的日誌中進行了提交，那麼就需要對該事務前滾；如果監控到的日誌中有事務未提交，那麼該事務就需要回滾。

準備階段使用的模式選項是"--apply-log"。準備階段不會連接MySQL，所以不用指定連接選項如--user等。

[root@xuexi bakdir]# innobackupex --apply-log /bakdir/2017-04-02_07-09-47/

在準備成功時，會在頻幕上輸出如下提示內容：

InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 7533367063
170402 12:11:23 completed OK!

在準備階段，有一個記憶體使用量選項"--use-memory"，該選項預設值為100M，值越大準備的過程越快。當然，將該值加大的前提是伺服器記憶體夠用。

(3). 全備份的恢復過程

恢復的階段就是向MySQL的datadir拷貝。全備份的恢復要求MySQL必須處於stop狀態，並且datadir必須為空哪怕是和MySQL無關的文件也不能存在，它不會去覆蓋datadir中已存在的內容。否則會提示如下錯誤：

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)
Original data directory /mydata/data is not empty!

停止mysql並清空datadir。

service mysqld stop
rm -rf /mydata/data/*

恢復時使用的模式是"--copy-back"，選項後指定要恢復的源備份目錄。恢復時因為不需要連接資料庫，所以不用指定連接選項，如--user等。

[root@xuexi bakdir]# innobackupex --copy-back /bakdir/2017-04-02_07-09-47/
170402 12:36:09 completed OK!

拷貝完成後，MySQL的datadir的文件的所有者和屬組是innobackupex的調用者，所以需要改回mysql.mysql。

[root@xuexi bakdir]# ll /mydata/data/
total 712736
drwxr-x--- 2 root root      4096 Apr  2 12:36 backuptest
-rw-r----- 1 root root 616562688 Apr  2 12:35 ibdata1
-rw-r----- 1 root root  50331648 Apr  2 12:35 ib_logfile0
-rw-r----- 1 root root  50331648 Apr  2 12:35 ib_logfile1
-rw-r----- 1 root root  12582912 Apr  2 12:36 ibtmp1
drwxr-x--- 2 root root      4096 Apr  2 12:36 mysql
drwxr-x--- 2 root root      4096 Apr  2 12:35 Performance
drwxr-x--- 2 root root      4096 Apr  2 12:36 performance_schema
drwxr-x--- 2 root root      4096 Apr  2 12:35 world
-rw-r----- 1 root root        23 Apr  2 12:35 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root       494 Apr  2 12:35 xtrabackup_info

[root@xuexi bakdir]# chown -R mysql.mysql /mydata/data/*

完成這些之後，就可以啟動MySQL伺服器了。可以進入mysql測試backuptest資料庫中的數據是否完整。

5.2 innobackupex實現增量備份和恢復的過程

增量備份依賴於全備份。xtrabackup實現增量備份的原理是通過比較全備份的終點LSN和當前的LSN，增備時將從終點LSN開始一直備份到當前的LSN。在備份時也有redo log的監控線程，對於增備過程中導致LSN增長的操作也會寫入到日誌中。

增備的實現依賴於LSN，所以只對innodb有效，對myisam表使用增備時，背後進行的是全備。

(1). 要進行增備，首先要有全備文件。這裡重新進行一次全備。

innobackupex --user=root --password=123456 /bakdir/

全備完成後，在/bakdir目錄下生成的全備目錄是2017-04-02_13-26-35。

[root@xuexi ~]# ls /bakdir/2017-04-02_13-26-35/
backup-my.cnf  ibdata1  Performance         secure_dir  xtrabackup_binlog_info  xtrabackup_info
backuptest     mysql    performance_schema  world       xtrabackup_checkpoints  xtrabackup_logfile

查看xtrabackup_checkpoints可以得知相關的LSN。

[root@xuexi ~]# cat /bakdir/2017-04-02_13-26-35/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 7533367093
last_lsn = 7533367093
compact = 0
recover_binlog_info = 0

註意：要實現增備，這一次的全備一定不能進行"準備"操作，原因稍後給出。

(2). 進行第一次增備。

假設對示例數據可backuptest中的num_innodb表進行了truncate操作。

mysql> truncate backuptest.num_innodb;

然後再增備。增備時使用"--incremental"選項表示增量備份，增量備份時需要通過"--incremental-basedir=fullback_PATH"指定基於哪個備份集備份，因為是第一次增備，所以要基於完全備份增量集。

[root@xuexi ~]# innobackupex --user=root --password=123456 --incremental /bakdir/ --incremental-basedir=/bakdir/2017-04-02_13-26-35/

增備完成後，生成的增備集為/bakdir/2017-04-02_13-39-05/，查看其中的xtrabackup_checkpoints，可以看到備份的起始LSN是上次全備完成後的LSN。

[root@xuexi ~]# cat /bakdir/2017-04-02_13-39-05/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 7533367093
to_lsn = 7533372535
last_lsn = 7533372535
compact = 0
recover_binlog_info = 0

預設情況下，增備的起始LSN是自動獲取的，但是在某些情況下無法獲取，還有些情況下無法獲取到將要增備的basedir。xtrabackup提供的選項"--incremental-lsn=N"可以顯式指定增備的起始LSN，顯式指定LSN時，可以無需提供增備的basedir。

例如，如果獲取到了上次全備的終止LSN為7533367093，可以如下方式增備：

innobackupex --user=root --password=123456 --incremental /bakdir/ --incremental-lsn=7533367093

這樣增備後也在/bakdir中生成一個時間戳目錄/bakdir/2017-04-02_13-50-33。查看LSN信息：

[root@xuexi ~]# cat /bakdir/2017-04-02_13-50-33/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 7533367093
to_lsn = 7533372535
last_lsn = 7533372535
compact = 0
recover_binlog_info = 0

由此可知和指定--incremental-basedir進行增備是一樣的。

(3). 進行第二次增備。

假設在第一次增備後，向上次truncate的表backuptest.num_innodb表中插入的100W條記錄。

mysql> call backuptest.proc_num2(1000000);      
mysql> select count(*) from backuptest.num_innodb;
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+

然後進行增備。這次增備是基於第一次增備的（當然也可以基於全備進行備份，這樣實現的是差異備份）。

[root@xuexi ~]# innobackupex --user=root --password=123456 --incremental /bakdir/ --incremental-basedir=/bakdir/2017-04-02_13-39-05/

這次增備完成後生成的備份集為/bakdir/2017-04-02_14-03-51/。查看LSN信息：

[root@xuexi ~]# cat /bakdir/2017-04-02_14-03-51/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 7533372535
to_lsn = 7585150275
last_lsn = 7585150275
compact = 0
recover_binlog_info = 0

(4). 增備的準備過程

增備的準備過程和全備的準備過程有點不一樣，不到最後恢復的時候不能進行任何"準備"過程。

增備過程中的每一次備份行為都會監控MySQL的redo log，寫入到xtrabackup_logfile的日誌中可能會有未提交的事務，但是到後面增備的時候進行了提交，也就是說提交過程記錄到了增備時監控的日誌xtrabackup_logfile中。如果在增備前進行了"準備"，那麼該事務就會被回滾，後面增備中的提交就丟失了，由此會造成數據丟失。

要保證將所有的備份集進行整合，需要使用在每個備份集的"準備"過程中使用"--redo-only"選項，這樣應用日誌時會"直線向前"直到最後一個備份集。它的本質是向全備集中不斷的追加應用增備中的日誌。但是，最後一個增備集需要作為備份集整合的終點，所以它不能使用"--redo-only"選項。整合完成之後，原來的全備就已經完整了，這時再對追加完成的全備集進行一次"準備"即可用於後面的恢復。

所以，如果全備為A，3次增備分別為B/C/D，如果只想恢復到C，那麼從A開始整合到C結束即可。

因為在每一個增備的"準備"過程中都需要向整合的開始備份集中追加應用日誌，所以每一次增備的"準備"都需要指定整合的開始備份集目錄作為basedir。例如指定全備份作為整合的初始備份集。

從以上實驗過程中，得到的全備集是2017-04-02_13-26-35，第一次和第二次增備集分別是2017-04-02_13-26-35、2017-04-02_14-03-51。下麵是它們的"準備"過程。

# 對整合的開始備份集——全備集應用日誌，並指定"--redo-only"表示開始進入日誌追加
innobackupex --apply-log --redo-only /bakdir/2017-04-02_13-26-35

# 對第一個增備集進行"準備"，將其追加到全備集中
innobackupex --apply-log --redo-only /bakdir/2017-04-02_13-26-35 --incremental-dir=/bakdir/2017-04-02_13-39-05

# 對第二個增備集進行"準備"，將其追加到全備集中，但是不再應用"--redo-only"，表示整合的結束點
innobackupex --apply-log /bakdir/2017-04-02_13-26-35 --incremental-dir=/bakdir/2017-04-02_14-03-51

# 對整合完成的全備集進行一次整體的"準備"
innobackupex --apply-log /bakdir/2017-04-02_13-26-35

當所有的備份集整合完畢後，就像是一個完整的全備集，全備中的LSN會更新到整合的結束點。如下：

[root@xuexi data]# cat /bakdir/2017-04-02_13-26-35/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 7585150275  #整合完成後全備中的LSN
last_lsn = 7585150275
compact = 0
recover_binlog_info = 0

[root@xuexi data]# cat /bakdir/2017-04-02_14-03-51/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 7533372535
to_lsn = 7585150275       #整合的結束備份集中的LSN
last_lsn = 7585150275
compact = 0
recover_binlog_info = 0

如果不小心整合的順序錯誤了，那麼整合的備份集將是無效的，需要重新整合。

(5). 增備的恢復過程

因為整合結束後就等價於一個全備集，所以可以直接進行恢復。

恢復過程同樣需要保證MySQL的datadir是空的，且MySQL伺服器是stop的。

service mysqld stop
rm -rf /mydata/data/*
innobackupex --copy-back /bakdir/2017-04-02_13-26-35
chown -R mysql.mysql /mydata/data/*

然後重啟MySQL，進入查看可知num_innodb的數據為100W行記錄，即恢覆成功。

mysql> select count(*) from backuptest.num_innodb;
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+

5.3 innobackupex實現導出和導入單張表的過程

預設情況下，InnoDB表不能通過直接複製表文件的方式在mysql伺服器之間進行移植，即便使用了innodb_file_per_table選項。而使用Xtrabackup工具可以實現此種功能，不過只能"導出"具有.ibd文件的表，也就是說導出表的mysql伺服器啟用了innodb_file_per_table選項，而且要導出的表還是在啟用該選項之後才創建的。

導入表的是，要求導入表的伺服器版本是MySQL 5.6+，且啟用了innodb_file_per_table選項。

(1). 導出表

導出表是在"準備"的過程中進行的，不是在備份的時候導出。對於一個已經備份好的備份集，使用"--apply-log"和"--export"選項即可導出備份集中的表。

假如以全備份集/bakdir/2017-04-02_17-41-38為例，要導出其中的表。

innobackupex --apply-log --export /bakdir/2017-04-02_17-41-38

在導出過程中，會看到如下信息：

xtrabackup: export metadata of table 'backuptest/num_innodb' to file `./backuptest/num_innodb.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=144, page=3

它說明瞭創建了一個.exp文件。

查看備份集目錄下的backuptest目錄，會發現多出了2個文件：.cfg和.exp，再加上.ibd文件，這3個文件是後續導入表時所需的文件。

-rw-r--r-- 1 root root  349 Apr  2 18:15 num_innodb.cfg
-rw-r----- 1 root root  16K Apr  2 18:15 num_innodb.exp
-rw-r----- 1 root root 8.4K Apr  2 17:41 num_innodb.frm
-rw-r----- 1 root root  31M Apr  2 17:41 num_innodb.ibd

其中.cfg文件是一種特殊的innodb數據字典文件，它和exp文件的作用是差不多的，只不過後者還支持在xtradb中導入，嚴格地講，要將導出的表導入到MySQL5.6或者percona server 5.6中，".cfg"文件完全可以不需要，但是如果有該文件的話，會進行架構驗證。

(2). 導出表

要在mysql伺服器上導入來自於其它伺服器的某innodb表，需要先在當前伺服器上創建一個跟原表表結構一致的表，而後才能實現將表導入：

mysql> CREATE TABLE tabletest (...)  ENGINE=InnoDB;

然後將此表的表空間：

mysql> ALTER TABLE mydatabase.tabletest  DISCARD TABLESPACE;

接下來，將來自於"導出"表的的.ibd和.exp文件複製到當前伺服器的數據目錄，如果導入目標伺服器是MySQL 5.6+，也可以複製.cfg文件。然後使用如下命令將其“導入”：

mysql> ALTER TABLE mydatabase.tabletest IMPORT TABLESPACE;

5.4 innobackupex實現部分備份和恢復的過程

xtrabackup支持部分備份，意味著可以指定備份哪個資料庫或者哪個表。

部分備份只有一點需要註意：在恢復的時候不要通過"--copy-back"的方式拷貝回datadir，而是應該使用導入表的方式。儘管使用拷貝的方式有時候是可行的，但是很多情況下會出現資料庫不一致的狀態。

(1). 備份

創建部分備份有三種方式：

通過"--include"選項可以指定正則來匹配要備份的表，這種方式要使用完整對象引用格式，即db_name.tab_name的方式。
將要備份的表分行枚舉到一個文件中，通過"--tables-file"指定該文件。
或者使用"--databases"指定要備份的資料庫或表，指定備份的表時要使用完整對象引用格式，多個元素使用空格分開。

使用前兩種部分備份方式，只能備份innodb表，不會備份任何myisam，即使指定了也不會備份。而且要備份的表必須有獨立的表空間文件，也就是說必須開啟了innodb_file_per_table，更精確的說，要備份的表是在開啟了innodb_file_per_table選項之後才創建的。第三種備份方式可以備份myisam表。

例如 --include='^back.*[.]num_*' ，將備份back字母開頭的資料庫中num開頭的表，其中"[.]"的中括弧不能少，因為正則中"."有特殊意義，所以使用中括弧來枚舉以實現對象的完整引用。

innobackupex --user=root --password=123456 --include='^back*[.]num_*' /bakdir/

使用"--include"和"--tables-file"備份後，會生成一個時間戳目錄，目錄中只有和要備份的表有關的文件。

[root@xuexi data]# ls /bakdir/2017-04-02_17-35-46/
backup-my.cnf  ibdata1  xtrabackup_binlog_info  xtrabackup_checkpoints  xtrabackup_info  xtrabackup_logfile

如果使用的是--databases選項，則會生成一個時間戳目錄，裡面有備份的資料庫代表的目錄，如果只備份了某個表，則該資料庫目錄中只有該表相關的文件。

innobackupex --user=root --password=123456 --databases='mysql.user backuptest' /bakdir/

上面只備份mysql.user表和backuptest資料庫，在生成的時間戳目錄中將有兩個mysql目錄和backuptest目錄。

[root@xuexi data]# ls /bakdir/2017-04-02_17-41-38/
backup-my.cnf  backuptest  ibdata1  mysql  xtrabackup_binlog_info  xtrabackup_checkpoints  xtrabackup_info  xtrabackup_logfile

[root@xuexi data]# ls /bakdir/2017-04-02_17-41-38/backuptest/
db.opt  num_innodb.frm  num_innodb.ibd  num_isam.frm  num_isam.MYD  num_isam.MYI

[root@xuexi data]# ls /bakdir/2017-04-02_17-41-38/mysql/
user.frm  user.MYD  user.MYI

(2). 部分備份的準備和恢復過程

部分備份的準備和恢復過程分別是導出表和導入表的過程。見上文。

5.5 innobackupex實現定時點恢復

xtrabackup本身無法實現定時點恢復，只能通過恢復備份後通過二進位日誌實現。實現方法和一般定時點恢復是一樣的。見：二進位日誌定點還原資料庫。

5.6 流備份和遠程備份

xtrabackup支持備份流，當前可用的流類型只有tar和xtrabackup自帶的xbstream，通過流可以將它們傳遞給其他程式進行相關的操作，如壓縮。但是不建議在備份的同時進行壓縮，因為壓縮會占用極大的cpu資源，使得備份時間延長很多，溫備的過程也就延長了。

另外，MySQL的數據文件壓縮比非常大，所以建議備份後在空閑的時候進行壓縮。

xtrabackup還支持遠程備份，只需使用"--remote-host"指定遠程的主機名即可，指定方式和ssh指定的方式一樣。如[email protected]。

使用流備份的方法如下：

# 使用tar流
innobackupex --user=root --password=123456 --stream=tar /bakdir/ >/tmp/a.tar
# 使用tar流的同時交給gzip壓縮
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | gzip >/tmp/a.tar.gz
# 使用tar流備份到遠程主機中並歸檔
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | ssh root@192.168.100.10  "cat -  > /tmp/`date +%F_%H-%M-%S`.tar"
# 使用tar流備份到原遠程主機中並解包
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | ssh root@192.168.100.10  "cat -  | tar -x -C /tmp/"

# 使用xtrabackup自帶的xbstream流
innobackupex --user=root --password=123456 --stream=xbstream /bakdir/ >/tmp/b.xbs
# 解壓xbstream流
innobackupex --user=root --password=

MariaDB/MySQL備份和恢復(三)：xtrabackup用法和原理詳述