1）介紹
PerconaXtraBackup（簡(jiǎn)稱PXB）是Percona公司開發(fā)的一個(gè)用于MySQL數(shù)據(jù)庫(kù)物理熱備的備份工具，支持MySQl（Oracle）、Percona Server和MariaDB，并且全部開源，真可謂是業(yè)界良心。能夠?yàn)镮nnoDB和XtraDB數(shù)據(jù)庫(kù)執(zhí)行非阻塞備份，特點(diǎn)如下：
1、快速、可靠的完成備份
2、備份期間不間斷事務(wù)處理
3、節(jié)省磁盤空間和網(wǎng)絡(luò)帶寬
4、自動(dòng)對(duì)備份文件進(jìn)行驗(yàn)證
5、恢復(fù)快，保障在線運(yùn)行時(shí)間持久性
percona-xtrabackup軟件包中中包含了兩個(gè)工具，一個(gè)是xtrabackup，另一個(gè)是innobackupex，innobackupex由per進(jìn)行封裝，在對(duì)innodb表進(jìn)行備份時(shí)會(huì)自動(dòng)調(diào)用xtraback工具，所以對(duì)InnoDB表做備份的實(shí)際是xtrabackup這個(gè)工具，xtrabackup也只能對(duì)innodb表做備份，這是一個(gè)專門對(duì)innodb開發(fā)的熱備工具，而對(duì)myisam這樣的其他引擎的表則由innobackupex來負(fù)責(zé)備份，若是全備份加增量的方案，那每次增量innobackupex工具對(duì)非innodb表都是全備份且會(huì)請(qǐng)求讀鎖。
xtrabackup對(duì)innodb表進(jìn)行備份時(shí)不再只是簡(jiǎn)單復(fù)制文件，而是利用在innodb存儲(chǔ)引擎層中的LSN（日志序列號(hào)）的新舊來識(shí)別這一數(shù)據(jù)頁(yè)是否需要備份。
xtraback工具對(duì)innodb引擎完美支持真正的熱備份，備份好的數(shù)據(jù)中數(shù)據(jù)文件與事務(wù)日志的文件因innodb cache等因素的存在，所以備份好的數(shù)據(jù)和事務(wù)日志中的數(shù)據(jù)往往是不一致的，所以，在做數(shù)據(jù)恢復(fù)時(shí)需要把事務(wù)日志中已提交的事務(wù)做redo，沒有提交的事務(wù)做undo操作，這就是在做數(shù)據(jù)恢復(fù)時(shí)要做的準(zhǔn)備工作，即prepare。
2）Xtrabackup備份原理
1、InnoDB的備份原理
在InnoDB內(nèi)部會(huì)維護(hù)一個(gè)redo日志文件，我們也可以叫做事務(wù)日志文件。事務(wù)日志會(huì)存儲(chǔ)每一個(gè)InnoDB表數(shù)據(jù)的記錄修改。當(dāng)InnoDB啟動(dòng)時(shí)，InnoDB會(huì)檢查數(shù)據(jù)文件和事務(wù)日志，并執(zhí)行兩個(gè)步驟：它應(yīng)用（前滾）已經(jīng)提交的事務(wù)日志到數(shù)據(jù)文件，并將修改過但沒有提交的數(shù)據(jù)進(jìn)行回滾操作。
備份過程
Xtrabackup在啟動(dòng)時(shí)會(huì)記住log
sequence number（LSN），并且復(fù)制所有的數(shù)據(jù)文件。復(fù)制過程需要一些時(shí)間，所以這期間如果數(shù)據(jù)文件有改動(dòng)，那么將會(huì)使數(shù)據(jù)庫(kù)處于一個(gè)不同的時(shí)間點(diǎn)。這時(shí)，xtrabackup會(huì)運(yùn)行一個(gè)后臺(tái)進(jìn)程，用于監(jiān)視事務(wù)日志，并從事務(wù)日志復(fù)制最新的修改。Xtrabackup必須持續(xù)的做這個(gè)操作，是因?yàn)槭聞?wù)日志是會(huì)輪轉(zhuǎn)重復(fù)的寫入，并且事務(wù)日志可以被重用。所以xtrabackup自啟動(dòng)開始，就不停的將事務(wù)日志中每個(gè)數(shù)據(jù)文件的修改都記錄下來。
準(zhǔn)備過程
上面就是xtrabackup的備份過程。接下來是準(zhǔn)備（prepare）過程。在這個(gè)過程中，xtrabackup使用之前復(fù)制的事務(wù)日志，對(duì)各個(gè)數(shù)據(jù)文件執(zhí)行災(zāi)難恢復(fù)（就像mysql剛啟動(dòng)時(shí)要做的一樣）。當(dāng)這個(gè)過程結(jié)束后，數(shù)據(jù)庫(kù)就可以做恢復(fù)還原了。
2、MyISAM的備份原理
以上的過程在xtrabackup的編譯二進(jìn)制程序中實(shí)現(xiàn)。程序innobackupex可以允許我們備份MyISAM表和frm文件從而增加了便捷和功能。Innobackupex會(huì)啟動(dòng)xtrabackup，直到xtrabackup復(fù)制數(shù)據(jù)文件后，然后執(zhí)行FLUSH TABLES WITH READ LOCK來阻止新的寫入進(jìn)來并把MyISAM表數(shù)據(jù)刷到硬盤上，之后復(fù)制MyISAM數(shù)據(jù)文件，最后釋放鎖。
備份MyISAM和InnoDB表最終會(huì)處于一致，在準(zhǔn)備（prepare）過程結(jié)束后，InnoDB表數(shù)據(jù)已經(jīng)前滾到整個(gè)備份結(jié)束的點(diǎn)，而不是回滾到xtrabackup剛開始時(shí)的點(diǎn)。這個(gè)時(shí)間點(diǎn)與執(zhí)行FLUSH TABLES WITH READ LOCK的時(shí)間點(diǎn)相同，所以myisam表數(shù)據(jù)與InnoDB表數(shù)據(jù)是同步的。類似oracle的，InnoDB的prepare過程可以稱為recover（恢復(fù)），myisam的數(shù)據(jù)復(fù)制過程可以稱為restore（還原）。
Xtrabackup和innobackupex這兩個(gè)工具都提供了許多前文沒有提到的功能特點(diǎn)。手冊(cè)上有對(duì)各個(gè)功能都有詳細(xì)的介紹。簡(jiǎn)單介紹下，這些工具提供了如流（streaming）備份，增量（incremental）備份等，通過復(fù)制數(shù)據(jù)文件，復(fù)制日志文件和提交日志到數(shù)據(jù)文件（前滾）實(shí)現(xiàn)了各種復(fù)合備份方式。
3）、安裝
1、使用yum方式安裝
配置倉(cāng)庫(kù)
yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm-y
檢查倉(cāng)庫(kù)
yum list | grep percona
安裝包
yum install percona-xtrabackup-24
2、使用rpm包安裝
下載rpm包
wgethttps://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
安裝：
yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
3、安裝后的目錄結(jié)構(gòu)
4）通信方式
2個(gè)工具之間的交互和協(xié)調(diào)是通過控制文件的創(chuàng)建和刪除來實(shí)現(xiàn)的，主要文件有：
xtrabackup_suspended_1
xtrabackup_suspended_2
xtrabackup_log_copied
舉個(gè)栗子，我們來看備份時(shí)xtrabackup_suspended_2是怎么來協(xié)調(diào)2個(gè)工具進(jìn)程的
innobackupex在啟動(dòng)xtrabackup進(jìn)程后，會(huì)一直等xtrabackup備份完InnoDB文件，方式就是等待xtrabackup_suspended_2這個(gè)文件被創(chuàng)建出來；
xtrabackup在備完InnoDB數(shù)據(jù)后，就在指定目錄下創(chuàng)建出這個(gè)文件，然后等這個(gè)文件被innobackupex刪除；
innobackupex檢測(cè)到文件xtrabackup_suspended_2被創(chuàng)建出來后，就繼續(xù)往下走；
innobackupex在備份完非InnoDB表后，刪除xtrabackup_suspended_2這個(gè)文件，這樣就通知xtrabackup可以繼續(xù)了，然后等xtrabackup_log_copied被創(chuàng)建；
xtrabackup檢測(cè)到xtrabackup_suspended_2文件刪除后，就可以繼續(xù)往下了。
5）備份過程
innobackupex在啟動(dòng)后，會(huì)先fork一個(gè)進(jìn)程，啟動(dòng)xtrabackup進(jìn)程，然后就等待xtrabackup備份完ibd數(shù)據(jù)文件；
xtrabackup在備份InnoDB相關(guān)數(shù)據(jù)時(shí)，是有2種線程的，1種是redo拷貝線程，負(fù)責(zé)拷貝redo文件，1種是ibd拷貝線程，負(fù)責(zé)拷貝ibd文件；redo拷貝線程只有一個(gè)，在ibd拷貝線程之前啟動(dòng)，在ibd線程結(jié)束后結(jié)束。xtrabackup進(jìn)程開始執(zhí)行后，先啟動(dòng)redo拷貝線程，從最新的checkpoint點(diǎn)開始順序拷貝redo日志；然后再啟動(dòng)ibd數(shù)據(jù)拷貝線程，在xtrabackup拷貝ibd過程中，innobackupex進(jìn)程一直處于等待狀態(tài)（等待文件被創(chuàng)建）。
xtrabackup拷貝完成idb后，通知innobackupex（通過創(chuàng)建文件），同時(shí)自己進(jìn)入等待（redo線程仍然繼續(xù)拷貝）;
innobackupex收到xtrabackup通知后，執(zhí)行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位點(diǎn)，然后開始備份非InnoDB文件（包括frm、MYD、MYI、CSV、opt、par等）。拷貝非InnoDB文件過程中，因?yàn)閿?shù)據(jù)庫(kù)處于全局只讀狀態(tài)，如果在業(yè)務(wù)的主庫(kù)備份的話，要特別小心，非InnoDB表（主要是MyISAM）比較多的話整庫(kù)只讀時(shí)間就會(huì)比較長(zhǎng)，這個(gè)影響一定要評(píng)估到。
當(dāng)innobackupex拷貝完所有非InnoDB表文件后，通知xtrabackup（通過刪文件），同時(shí)自己進(jìn)入等待（等待另一個(gè)文件被創(chuàng)建）；
xtrabackup收到innobackupex備份完非InnoDB通知后，就停止redo拷貝線程，然后通知innobackupex redo log拷貝完成（通過創(chuàng)建文件）；
innobackupex收到redo備份完成通知后，就開始解鎖，執(zhí)行UNLOCK TABLES；
最后innobackupex和xtrabackup進(jìn)程各自完成收尾工作，如資源的釋放、寫備份元數(shù)據(jù)信息等，innobackupex等待xtrabackup子進(jìn)程結(jié)束后退出。
在上面描述的文件拷貝，都是備份進(jìn)程直接通過操作系統(tǒng)讀取數(shù)據(jù)文件的，只在執(zhí)行SQL命令時(shí)和數(shù)據(jù)庫(kù)有交互，基本不影響數(shù)據(jù)庫(kù)的運(yùn)行，在備份非InnoDB時(shí)會(huì)有一段時(shí)間只讀（如果沒有MyISAM表的話，只讀時(shí)間在幾秒左右），在備份InnoDB數(shù)據(jù)文件時(shí)，對(duì)數(shù)據(jù)庫(kù)完全沒有影響，是真正的熱備。
InnoDB和非InnoDB文件的備份都是通過拷貝文件來做的，但是實(shí)現(xiàn)的方式不同，前者是以page為粒度做的(xtrabackup)，后者是cp或者tar命令(innobackupex)，xtrabackup在讀取每個(gè)page時(shí)會(huì)校驗(yàn)checksum值，保證數(shù)據(jù)塊是一致的，而innobackupex在cp MyISAM文件時(shí)已經(jīng)做了flush（FTWRL），磁盤上的文件也是完整的，所以最終備份集里的數(shù)據(jù)文件都是寫入完整的。
6）增量備份
PXB是支持增量備份的，但是只能對(duì)InnoDB做增量，InnoDB每個(gè)page有個(gè)LSN號(hào)，LSN是全局遞增的，page被更改時(shí)會(huì)記錄當(dāng)前的LSN號(hào)，page中的LSN越大，說明當(dāng)前page越新（最近被更新）。每次備份會(huì)記錄當(dāng)前備份到的LSN（xtrabackup_checkpoints文件中），增量備份就是只拷貝LSN大于上次備份的page，比上次備份小的跳過，每個(gè)ibd文件最終備份出來的是增量delta文件。
MyISAM是沒有增量的機(jī)制的，每次增量備份都是全部拷貝的。
增量備份過程和全量備份一樣，只是在ibd文件拷貝上有不同。
7）恢復(fù)過程
如果看恢復(fù)備份集的日志，會(huì)發(fā)現(xiàn)和mysqld啟動(dòng)時(shí)非常相似，其實(shí)備份集的恢復(fù)就是類似mysqld crash后，做一次crash recover。
恢復(fù)的目的是把備份集中的數(shù)據(jù)恢復(fù)到一個(gè)一致性位點(diǎn)，所謂一致就是指原數(shù)據(jù)庫(kù)某一時(shí)間點(diǎn)各引擎數(shù)據(jù)的狀態(tài)，比如MyISAM中的數(shù)據(jù)對(duì)應(yīng)的是15:00時(shí)間點(diǎn)的，InnoDB中的數(shù)據(jù)對(duì)應(yīng)的是15:20的，這種狀態(tài)的數(shù)據(jù)就是不一致的。PXB備份集對(duì)應(yīng)的一致點(diǎn)，就是備份時(shí)FTWRL的時(shí)間點(diǎn)，恢復(fù)出來的數(shù)據(jù)，就對(duì)應(yīng)原數(shù)據(jù)庫(kù)FTWRL時(shí)的狀態(tài)。
因?yàn)閭浞輹r(shí)FTWRL后，數(shù)據(jù)庫(kù)是處于只讀的，非InnoDB數(shù)據(jù)是在持有全局讀鎖情況下拷貝的，所以非InnoDB數(shù)據(jù)本身就對(duì)應(yīng)FTWRL時(shí)間點(diǎn)；InnoDB的ibd文件拷貝是在FTWRL前做的，拷貝出來的不同ibd文件最后更新時(shí)間點(diǎn)是不一樣的，這種狀態(tài)的ibd文件是不能直接用的，但是redo log是從備份開始一直持續(xù)拷貝的，最后的redo日志點(diǎn)是在持有FTWRL后取得的，所以最終通過redo應(yīng)用后的ibd數(shù)據(jù)時(shí)間點(diǎn)也是和FTWRL一致的。
所以恢復(fù)過程只涉及InnoDB文件的恢復(fù)，非InnoDB數(shù)據(jù)是不動(dòng)的。備份恢復(fù)完成后，就可以把數(shù)據(jù)文件拷貝到對(duì)應(yīng)的目錄，然后通過mysqld來啟動(dòng)了
8）備份實(shí)例
1、全量備份
[root@linux-node2 backups]#xtrabackup --backup
--target-dir=/data/backups/$(date +%F) -uroot -p123456
170427 10:46:41version_check Connecting to MySQL server withDSN'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock'as 'root'(using password: YES).
170427 10:46:41version_check Connected to MySQL server
170427 10:46:41version_check Executing a version checkagainst the server...
170427 10:46:41version_check Done.
170427 10:46:41 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock
Using server version 5.6.35-log
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/data
xtrabackup: open files limit requested 65535,set to 1024000
xtrabackup: using the following InnoDBconfiguration:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = ./
xtrabackup:innodb_log_files_in_group = 2
xtrabackup:innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170427 10:46:41 >> log scanned up to(1743474)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0
170427 10:46:41 [01] Copying ./ibdata1 to/data/backups/2017-04-27/ibdata1
170427 10:46:41 [01]...done
170427 10:46:41 [01] Copying./mysql/slave_master_info.ibd to/data/backups/2017-04-27/mysql/slave_master_info.ibd
170427 10:46:41 [01]...done
170427 10:46:41 [01] Copying./mysql/slave_relay_log_info.ibd to/data/backups/2017-04-27/mysql/slave_relay_log_info.ibd
170427 10:46:41 [01]...done
…………
170427 10:46:42 [01] Copying ./test/db.opt to/data/backups/2017-04-27/test/db.opt
170427 10:46:42 [01]...done
170427 10:46:42 Finished backing upnon-InnoDB tables and files
170427 10:46:42 [00] Writingxtrabackup_binlog_info
170427 10:46:42 [00]...done
170427 10:46:42 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (forincremental): '1743474'
xtrabackup: Stopping log copying thread.
.170427 10:46:42 >> log scanned up to(1743474)
170427 10:46:43 Executing UNLOCK TABLES
170427 10:46:43 All tables unlocked
170427 10:46:43 Backup created in directory'/data/backups/2017-04-27/'
MySQL binlog position: filename'mysql-bin.000004', position '191', GTID of the last change'0e9896a7-14f7-11e7-a0e6-000c2900551e:1-3'
170427 10:46:43 [00] Writing backup-my.cnf
170427 10:46:43 [00]...done
170427 10:46:43 [00] Writing xtrabackup_info
170427 10:46:43 [00]...done
xtrabackup: Transaction log of lsn (1743474)to (1743474) was copied.
170427 10:46:43 completed OK!#表示備份成功。
[root@linux-node2 backups]#
備份成功后，備份目錄的結(jié)構(gòu)如下：
2、增量備份
[root@linux-node2 backups]# xtrabackup--backup --target-dir=/data/backups/increment/$(date +%F-%H-%M-%S)--incremental-basedir=/data/backups/2017-04-27/ -uroot -p123456
170427 14:41:49version_check Connecting to MySQL server withDSN'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock'as 'root'(using password: YES).
170427 14:41:49version_check Connected to MySQL server
170427 14:41:49version_check Executing a version checkagainst the server...
170427 14:41:49version_check Done.
170427 14:41:49 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock
Using server version 5.6.35-log
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
incremental backup from 1743474 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/data
xtrabackup: open files limit requested 65535,set to 1024000
xtrabackup: using the following InnoDBconfiguration:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = ./
xtrabackup:innodb_log_files_in_group = 2
xtrabackup:innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170427 14:41:49 >> log scanned up to(1752524)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0
xtrabackup: using the full scan forincremental backup
170427 14:41:49 [01] Copying ./ibdata1 to/data/backups/increment/2017-04-27-14-41-49/ibdata1.delta
170427 14:41:49 [01]...done
170427 14:41:49 [01] Copying./mysql/slave_master_info.ibd to /data/backups/increment/2017-04-27-14-41-49/mysql/slave_master_info.ibd.delta
170427 14:41:49 [01]...done
170427 14:41:49 [01] Copying./mysql/slave_relay_log_info.ibd to/data/backups/increment/2017-04-27-14-41-49/mysql/slave_relay_log_info.ibd.delta
…………
170427 14:41:50 [01] Copying./incrememtal1/t1.frm to/data/backups/increment/2017-04-27-14-41-49/incrememtal1/t1.frm
170427 14:41:50 [01]...done
170427 14:41:50 Finished backing upnon-InnoDB tables and files
170427 14:41:50 [00] Writing xtrabackup_binlog_info
170427 14:41:50 [00]...done
170427 14:41:50 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (forincremental): '1752524'
xtrabackup: Stopping log copying thread.
.170427 14:41:50 >> log scanned up to(1752524)
170427 14:41:50 Executing UNLOCK TABLES
170427 14:41:50 All tables unlocked
170427 14:41:50 Backup created in directory'/data/backups/increment/2017-04-27-14-41-49/'
MySQL binlog position: filename'mysql-bin.000004', position '525', GTID of the last change'0e9896a7-14f7-11e7-a0e6-000c2900551e:1-5'
170427 14:41:50 [00] Writing backup-my.cnf
170427 14:41:50 [00]...done
170427 14:41:50 [00] Writing xtrabackup_info
170427 14:41:50 [00]...done
xtrabackup: Transaction log of lsn (1752524)to (1752524) was copied.
170427 14:41:50 completed OK!
備份成功后的目錄結(jié)構(gòu)：
查看xtrabackup_checkpoints文件，顯示備份是從lsn
1743474到lsn 1752524，通過查看上一次全量備份目錄的xtrabackup_checkpoints文件顯示，最后一個(gè)lsn是1743474。
[root@linux-node22017-04-27-14-41-49]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1743474
to_lsn = 1752524
last_lsn = 1752524
compact = 0
recover_binlog_info = 0
[root@linux-node2 2017-04-27-14-41-49]#
3、再次增量備份（基于上一次增量備份）
[root@linux-node2 increment]# xtrabackup--backup --target-dir=/data/backups/increment/$(date +%F-%H-%M-%S)--incremental-basedir=/data/backups/increment/2017-04-27-14-41-49/ -uroot-p123456
170427 15:39:26version_check Connecting to MySQL server withDSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock'as 'root'(using password: YES).
170427 15:39:26version_check Connected to MySQL server
170427 15:39:26version_check Executing a version checkagainst the server...
170427 15:39:26version_check Done.
170427 15:39:26 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock
Using server version 5.6.35-log
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
incremental backup from 1752524 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/data
xtrabackup: open files limit requested 65535,set to 1024000
xtrabackup: using the following InnoDBconfiguration:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = ./
xtrabackup:innodb_log_files_in_group = 2
xtrabackup:innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170427 15:39:26 >> log scanned up to(1758973)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0
xtrabackup: using the full scan forincremental backup
170427 15:39:26 [01] Copying ./ibdata1 to/data/backups/increment/2017-04-27-15-39-25/ibdata1.delta
170427 15:39:26 [01]...done
……
170427 15:39:26 [01] Copying./incrememtal2/t1.ibd to/data/backups/increment/2017-04-27-15-39-25/incrememtal2/t1.ibd.delta
170427 15:39:26 [01]...done
170427 15:39:27 >> log scanned up to(1758973)
170427 15:39:27 Executing FLUSHNO_WRITE_TO_BINLOG TABLES...
170427 15:39:27 Executing FLUSH TABLES WITHREAD LOCK...
170427 15:39:27 Starting to backup non-InnoDBtables and files
170427 15:39:27 [01] Copying./mysql/servers.frm to/data/backups/increment/2017-04-27-15-39-25/mysql/servers.frm
170427 15:39:27 [01]...done
……
170427 15:39:27 [01] Copying./incrememtal2/t1.frm to /data/backups/increment/2017-04-27-15-39-25/incrememtal2/t1.frm
170427 15:39:27 [01]...done
170427 15:39:27 Finished backing upnon-InnoDB tables and files
170427 15:39:27 [00] Writingxtrabackup_binlog_info
170427 15:39:27 [00]...done
170427 15:39:27 Executing FLUSH NO_WRITE_TO_BINLOGENGINE LOGS...
xtrabackup: The latest check point (forincremental): '1758973'
xtrabackup: Stopping log copying thread.
.170427 15:39:27 >> log scanned up to(1758973)
170427 15:39:27 Executing UNLOCK TABLES
170427 15:39:27 All tables unlocked
170427 15:39:27 Backup created in directory'/data/backups/increment/2017-04-27-15-39-25/'
MySQL binlog position: filename'mysql-bin.000004', position '859', GTID of the last change'0e9896a7-14f7-11e7-a0e6-000c2900551e:1-7'
170427 15:39:27 [00] Writing backup-my.cnf
170427 15:39:27 [00]...done
170427 15:39:27 [00] Writing xtrabackup_info
170427 15:39:27 [00]...done
xtrabackup: Transaction log of lsn (1758973)to (1758973) was copied.
170427 15:39:27 completed OK!
查看備份完成后的目錄結(jié)構(gòu)：
4、準(zhǔn)備恢復(fù)（preparing a backup）-基于全量備份
在在使用備份文件恢復(fù)數(shù)據(jù)之前，你需要對(duì)備份的數(shù)據(jù)進(jìn)行整理。具體原因在前面的內(nèi)容已經(jīng)介紹過，我們先看使用完全備份恢復(fù)
[root@linux-node2 2017-04-27-15-39-25]#xtrabackup --prepare --target-dir=/data/backups/2017-04-27/
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: cd to /data/backups/2017-04-27/
xtrabackup: This target seems to be notprepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected:size=8388608, start_lsn=(1743474)
xtrabackup: using the following InnoDBconfiguration for recovery:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = .
xtrabackup:innodb_log_files_in_group = 1
xtrabackup:innodb_log_file_size = 8388608
xtrabackup: using the following InnoDBconfiguration for recovery:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = .
xtrabackup:innodb_log_files_in_group = 1
xtrabackup:innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance forrecovery.
xtrabackup: Using 104857600 bytes for bufferpool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomicbuiltins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of bufferpool
InnoDB: page_cleaner coordinator priority:-20
InnoDB: Highest supported file format isBarracuda.
InnoDB: The log sequence number 1732944 in thesystem tablespace does not match the log sequence number 1743474 in theib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Doing recovery: scanned up to logsequence number 1743474 (0%)
InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002
InnoDB: Creating shared tablespace fortemporary tables
InnoDB: Setting file './ibtmp1' size to 12MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) areactive.
InnoDB: Waiting for purge to start
InnoDB: 5.7.13 started; log sequence number1743474
InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002
xtrabackup: starting shutdown withinnodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequencenumber 1743493
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDBconfiguration for recovery:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = .
xtrabackup:innodb_log_files_in_group = 2
xtrabackup:innodb_log_file_size = 536870912
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomicbuiltins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of bufferpool
InnoDB: page_cleaner coordinator priority:-20
InnoDB: Setting log file ./ib_logfile101 sizeto 512 MB
InnoDB: Progress in MB:
100200 300 400 500
InnoDB: Setting log file ./ib_logfile1 sizeto 512 MB
InnoDB: Progress in MB:
100200 300 400 500
InnoDB: Renaming log file ./ib_logfile101 to./ib_logfile0
InnoDB: New log files created, LSN=1743493
InnoDB: Highest supported file format isBarracuda.
InnoDB: Log scan progressed past thecheckpoint lsn 1743884
InnoDB: Doing recovery: scanned up to logsequence number 1743893 (0%)
InnoDB: Doing recovery: scanned up to logsequence number 1743893 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002
InnoDB: Removed temporary tablespace datafile: "ibtmp1"
InnoDB: Creating shared tablespace fortemporary tables
InnoDB: Setting file './ibtmp1' size to 12MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) areactive.
InnoDB: Waiting for purge to start
InnoDB: 5.7.13 started; log sequence number1743893
xtrabackup: starting shutdown withinnodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: page_cleaner: 1000ms intended looptook 4725ms. The settings might not be optimal. (flushed=0 and evicted=0,during the time.)
InnoDB: Shutdown completed; log sequencenumber 1743912
170427 15:52:06 completed OK!
如果已經(jīng)進(jìn)行過數(shù)據(jù)整理，再次運(yùn)行會(huì)有如下提示信息：
xtrabackup: This target seems to be alreadyprepared.
xtrabackup: notice: xtrabackup_logfile wasalready used to '--prepare'.
5、恢復(fù)備份（基于全量）
首先我們需要所整理完數(shù)據(jù)后的備份目錄內(nèi)的文件復(fù)制到mysql的數(shù)據(jù)目錄，復(fù)制的方法很多，可以使用xtrabackup –copy-back選項(xiàng)，或者—move-back選項(xiàng)，當(dāng)然我們也可以使用rsync或者cp等命令。（注意在操作前應(yīng)該先停止mysql服務(wù)，然后清空數(shù)據(jù)目錄）
[root@linux-node2 mysql]# mysqladmin -uroot-p123456 shutdown
Warning: Using a password on the command lineinterface can be insecure.
[root@linux-node2 mysql]# 170427 16:11:27mysqld_safe mysqld from pid file /usr/local/mysql/data/db01.pid ended
[1]+Done/usr/local/mysql/bin/mysqld_safe(wd: ~)
(wd now: /usr/local/mysql)
[root@linux-node2 mysql]# mv /usr/local/mysql/data/tmp/
完成后使用xtraback恢復(fù)數(shù)據(jù)
[root@linux-node2 mysql]# xtrabackup--copy-back --target-dir=/data/backups/2017-04-27/
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
170427 16:13:43 [01] Copying ib_logfile0 to /usr/local/mysql/data/ib_logfile0
170427 16:13:46 [01]...done
170427 16:13:46 [01] Copying ib_logfile1 to/usr/local/mysql/data/ib_logfile1
170427 16:13:48 [01]...done
…………
170427 16:13:49 [01]...done
170427 16:13:49 [01] Copying ./xtrabackup_infoto /usr/local/mysql/data/xtrabackup_info
170427 16:13:49 [01]...done
170427 16:13:49 [01] Copying./xtrabackup_binlog_pos_innodb to/usr/local/mysql/data/xtrabackup_binlog_pos_innodb
170427 16:13:49 [01]...done
170427 16:13:49 [01] Copying ./ibtmp1 to/usr/local/mysql/data/ibtmp1
170427 16:13:49 [01]...done
170427 16:13:49 completed OK!
對(duì)恢復(fù)后的文件授權(quán)：
[root@linux-node2
mysql]# chown -R mysql.mysql /usr/local/mysql/data/
最后重啟啟動(dòng)mysql服務(wù)
[root@linux-node2data]# Logging to '/usr/local/mysql/data/mysql-error.log'.
17042716:15:08 mysqld_safe Starting mysqld daemon with databases from/usr/local/mysql/data
[root@linux-node2data]# lsof -i :3306
COMMANDPIDUSERFDTYPE DEVICE SIZE/OFF NODE NAME
mysqld4116 mysql13uIPv6260840t0TCP *:mysql (LISTEN)
[root@linux-node2data]# mysql -uroot -p
Enterpassword:
Welcome tothe MySQL monitor.Commands end with ;or \g.
Your MySQLconnection id is 1
Serverversion: 5.6.35-log MySQL Community Server (GPL)
Copyright(c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle isa registered trademark of Oracle Corporation and/or its
affiliates.Other names may be trademarks of their respective
owners.
Type'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>show databases;
+--------------------+
|Database|
+--------------------+
|information_schema |
|mysql|
|performance_schema |
|test|
+--------------------+
4 rows inset (0.00 sec)
6、基于增量備份進(jìn)行恢復(fù)
我們現(xiàn)在的備份情況如下：
/data/backups/2017-04-27全備
[root@linux-node2 backups]# cat 2017-04-27/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1780797
last_lsn = 1780797
compact = 0
recover_binlog_info = 0
/data/backups/increment/2017-04-27-16-51-43第一次增備
[root@linux-node2 backups]# catincrement/2017-04-27-16-51-43/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1780797
to_lsn = 1788921
last_lsn = 1788921
compact = 0
recover_binlog_info = 0
/data/backups/increment/2017-04-27-16-52-18第二次增備
[root@linux-node2 backups]# catincrement/2017-04-27-16-52-18/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1788921
to_lsn = 1796758
last_lsn = 1796758
compact = 0
recover_binlog_info = 0
恢復(fù)過程如下：
使用全備進(jìn)行恢復(fù)準(zhǔn)備操作，
[root@linux-node2 backups]# xtrabackup--prepare --apply-log-only --target-dir=/data/backups/2017-04-27/
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: cd to /data/backups/2017-04-27/
xtrabackup: This target seems to be notprepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected:size=8388608, start_lsn=(1780797)
xtrabackup: using the following InnoDBconfiguration for recovery:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = .
xtrabackup:innodb_log_files_in_group = 1
xtrabackup:innodb_log_file_size = 8388608
xtrabackup: using the following InnoDBconfiguration for recovery:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = .
xtrabackup:innodb_log_files_in_group = 1
xtrabackup:innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance forrecovery.
xtrabackup: Using 104857600 bytes for bufferpool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomicbuiltins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of bufferpool
InnoDB: page_cleaner coordinator priority:-20
InnoDB: Highest supported file format isBarracuda.
InnoDB: The log sequence number 1761000 inthe system tablespace does not match the log sequence number 1780797 in theib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Doing recovery: scanned up to logsequence number 1780797 (0%)
InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002
InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002
xtrabackup: starting shutdown withinnodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequencenumber 1780806
InnoDB: Number of pools: 1
170427 16:55:24 completed OK!
合并第一次增備
[root@linux-node2 backups]# xtrabackup--prepare --apply-log-only --target-dir=/data/backups/2017-04-27/--incremental-dir=/data/backups/increment/2017-04-27-16-51-43/
合并第二次增備：
[root@linux-node2 backups]# xtrabackup--prepare --target-dir=/data/backups/2017-04-27/ --incremental-dir=/data/backups/increment/2017-04-27-16-52-18/
合并完成后，使用上面第五步的方法恢復(fù)數(shù)據(jù)庫(kù)。
9）壓縮備份（compressed backup）
XtraBackup支持壓縮備份
1、創(chuàng)建Compressed Backups
[root@linux-node2 backups]# xtrabackup--backup --compress --target-dir=/data/backups/compressed/$(date +%F) -uroot-p123456
170427 17:28:03version_check Connecting to MySQL server withDSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock'as 'root'(using password: YES).
170427 17:28:03version_check Connected to MySQL server
170427 17:28:03version_check Executing a version checkagainst the server...
170427 17:28:03version_check Done.
170427 17:28:03 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock
Using server version 5.6.35-log
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/data
xtrabackup: open files limit requested 65535,set to 1024000
xtrabackup: using the following InnoDBconfiguration:
xtrabackup:innodb_data_home_dir = .
xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:innodb_log_group_home_dir = ./
xtrabackup:innodb_log_files_in_group = 2
xtrabackup:innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170427 17:28:03 >> log scanned up to(1796758)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0
170427 17:28:04 [01] Compressing ./ibdata1 to/data/backups/compressed/2017-04-27/ibdata1.qp
170427 17:28:04 [01]...done
…………
170427 17:28:05 [01] Compressing./inc2/t1.frm to /data/backups/compressed/2017-04-27/inc2/t1.frm.qp
170427 17:28:05 [01]...done
170427 17:28:05 Finished backing upnon-InnoDB tables and files
170427 17:28:05 [00] Compressingxtrabackup_binlog_info
170427 17:28:05 [00]...done
170427 17:28:05 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (forincremental): '1796758'
xtrabackup: Stopping log copying thread.
.170427 17:28:05 >> log scanned up to(1796758)
170427 17:28:05 Executing UNLOCK TABLES
170427 17:28:05 All tables unlocked
170427 17:28:05 Backup created in directory'/data/backups/compressed/2017-04-27/'
MySQL binlog position: filename'mysql-bin.000005', position '1761', GTID of the last change '0e9896a7-14f7-11e7-a0e6-000c2900551e:1-17'
170427 17:28:05 [00] Compressingbackup-my.cnf
170427 17:28:05 [00]...done
170427 17:28:05 [00] Compressingxtrabackup_info
170427 17:28:05 [00]...done
xtrabackup: Transaction log of lsn (1796758)to (1796758) was copied.
170427 17:28:05 completed OK!
備份完成后目錄結(jié)構(gòu)如下
[root@linux-node2 backups]# llcompressed/2017-04-27/
total 248
-rw-r----- 1 root root400 Apr 27 17:28 backup-my.cnf.qp
-rw-r----- 1 root root 223722 Apr 27 17:28ibdata1.qp
drwxr-x--- 2 root root54 Apr 27 17:28 inc1
drwxr-x--- 2 root root54 Apr 27 17:28 inc2
drwxr-x--- 2 root root54 Apr 27 17:28 incrememtal1
drwxr-x--- 2 root root54 Apr 27 17:28 incrememtal2
drwxr-x--- 2 root root4096 Apr 27 17:28 mysql
drwxr-x--- 2 root root4096 Apr 27 17:28 performance_schema
drwxr-x--- 2 root root22 Apr 27 17:28 test
-rw-r----- 1 root root152 Apr 27 17:28 xtrabackup_binlog_info.qp
-rw-r----- 1 root root113 Apr 27 17:28 xtrabackup_checkpoints
-rw-r----- 1 root root560 Apr 27 17:28 xtrabackup_info.qp
-rw-r----- 1 root root381 Apr 27 17:28 xtrabackup_logfile.qp
[root@linux-node2 backups]#
2、恢復(fù)準(zhǔn)備preparing（數(shù)據(jù)整理）
準(zhǔn)備整理數(shù)據(jù)前需要先解壓備份數(shù)據(jù)，使用—decompress選項(xiàng)，如果出現(xiàn)如下錯(cuò)誤，請(qǐng)安裝qpress，可以使用yum安裝。
[root@linux-node2 backups]# xtrabackup--decompress --target-dir=/data/backups/compressed/2017-04-27/
xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)
170427 17:34:54 [01] decompressing./xtrabackup_logfile.qp
sh: qpress: command not found
cat: write error: Broken pipe
Error: thread 0 failed.
[root@linux-node2 backups]# xtrabackup --decompress--target-dir=/data/backups/compressed/2017-04-27/
xtrabackup version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64)(revision id: 6f7a799)
170427 17:35:45 [01] decompressing ./xtrabackup_logfile.qp
170427 17:35:45 [01] decompressing ./ibdata1.qp
…………
170427 17:35:46 [01] decompressing ./xtrabackup_binlog_info.qp
170427 17:35:46 [01] decompressing ./backup-my.cnf.qp
170427 17:35:46 [01] decompressing ./xtrabackup_info.qp
170427 17:35:46 completed OK!
解壓后再使用前面實(shí)例中的第4，5步操作，完成數(shù)據(jù)恢復(fù)。?r???6R
