防僞碼：志向不過是記憶的奴隸，生氣勃勃地降生，但卻很難成長。
一、mysqldump備份結合binlog日誌恢復
MySQL 備份一般採取全庫備份加日誌備份的方式，例如每天執行一次全備份，每小時執行一
次二進制日誌備份。這樣在 MySQL 故障後可以使用全備份和日誌備份將數據恢復到最後一個
二進制日誌備份前的任意位置或時間。
1、binlog介紹
mysql的二進制日誌記錄着該數據庫的所有增刪改的操作日誌(前提是要在自己的服務器上
開啓binlog)，還包括了這些操作的執行時間。爲了顯示這些二進制內容，我們可以使用
mysqlbinlog命令來查看。
Binlog的用途
1：主從同步
2：恢復數據庫
開啓 binary log 功能
通過編輯my.cnf中的 log-bin 選項可以開啓二進制日誌；形式如下：
log-bin [=DIR/[filename]]
其中，DIR 參數指定二進制文件的存儲路徑；filename 參數指定二級制文件的文件名，其形
式爲filename.number，number 的形式爲 000001、000002 等。每次重啓mysql服務或運行
mysql> flush logs;都會生成一個新的二進制日誌文件，這些日誌文件的 number 會不斷地遞增。
除了生成上述的文件外還會生成一個名爲filename.index的文件。這個文件中存儲所有二進
制日誌文件的清單又稱爲二進制文件的索引
配置保存以後重啓mysql的服務器，用mysql> show variables like 'log_bin';查看 bin-log 是否
開啓，如圖：
查看產生的 binary log 注：查看binlog內容是爲了恢復數據
bin-log 因爲是二進制文件，不能通過文件內容查看命令直接打開查看，mysql提供兩種方式
查看方式，在介紹之前，我們先對數據庫進行一下增刪改的操作，否則 log 裏邊數據有點空。
重新開始一個新的日誌文件
查看 MySQL Server 上的二進制日誌
查看二進制日誌信息的命令：
語法格式：SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,]row_count]
查看二進制日誌中的事件
查看指定的二進制日誌中的事件
該命令還包含其他選項以便靈活查看
SHOW BINARY LOGS 等價於 SHOWMASTER LOGS
PURGE BINARY LOGS 用於刪除二進制日誌，如：
PURGE BINARY LOGS TO 'mysql-bin.00010'; //把這個文件之前的其他文件都刪除掉
PURGE BINARY LOGS BEFORE '2016-08-2822:46:26';//把指定時間之前的二進制文件
刪除了
RESET MASTER 與 RESET SLAVE
前者清空 index 文件中列出的所有二進制日誌，重置 index 文件爲空，並創建一個新的二進
制日誌文件，一般用於 MASTER 首次啓動時。後者使 SLAVE 忘記其在 MASTER 二進制日
志文件中的複製位置，它會刪除 master.info、relay-log.info 和所有中繼日誌文件並開始一
個新的中繼日誌文件，以便於開始一個乾淨的複製。在使用 RESET SLAVE 前需先關閉
SLAVE 複製線程。
上述方式可以查看到服務器上存在的二進制日誌文件及文件中的事件，但是想查看到文件中
具體的內容並應於恢復場景還得藉助mysqlbinlog這個工具。
語法格式：mysqlbinlog [options] log_file ...
輸出內容會因日誌文件的格式以及mysqlbinlog工具使用的選項不同而略不同。
mysqlbinlog的可用選項可參考 man 手冊。
二進制日誌文件的格式包含行模式、語句模式和混合模式（也即有服務器決定在什麼情況下
記錄什麼類型的日誌），基於語句的日誌中事件信息包含執行的語句等，基於行的日誌中事
件信息包含的是行的變化信息等。混合模式的日誌中兩種類型的事件信息都會記錄。
爲了便於查看記錄了行變化信息的事件在當時具體執行了什麼樣的 SQL 語句可以使用
mysqlbinlog工具的-v（--verbose）選項，該選項會將行事件重構成被註釋掉的僞 SQL 語句，
如果想看到更詳細的信息可以將該選項給兩次如-vv，這樣可以包含一些數據類型和元信息
的註釋內容，如
先切換到binlog所在的目錄下
#mysqlbinlog mysql-bin.000001
#mysqlbinlog -v mysql-bin.000001
#mysqlbinlog -vv mysql-bin.000001
另外mysqlbinlog和可以通過--read-from-remote-server 選項從遠程服務器讀取二進制日誌文
件，這時需要一些而外的連接參數，如-h，-P，-p，-u 等，這些參數僅在指定了
--read-from-remote-server 後有效。
無論是本地二進制日誌文件還是遠程服務器上的二進制日誌文件，無論是行模式、語句模式
還是混合模式的二進制日誌文件，被mysqlbinlog工具解析後都可直接應用與 MySQL Server
進行基於時間點、位置或數據庫的恢復。
下面我們就來演示如何使用binlog恢復之前刪除數據（id=2 那條記錄）
注意：在實際生產環境中，如果遇到需要恢復數據庫的情況，不要讓用戶能訪問到數據庫，
以避免新的數據插入進來，以及在主從的環境下，關閉主從。
查看binlog文件，從中找出 delete from test.tb1 where id=2
[root@localhost ~]# cd/usr/local/mysql/data/
[root@localhost data]# mysqlbinlog -vmysql-bin.000002
/*!50530 SET@@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170217 23:55:08 server id 1 end_log_pos 123 CRC32 0x368a9c96 Start: binlog v 4, server v 5.7.13-logcreated 170217 23:55:08
# Warning: this binlog is either in use orwas not closed properly.
BINLOG '
3BynWA8BAAAAdwAAAHsAAAABAAQANS43LjEzLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AZacijY=
'/*!*/;
# at 123
#170217 23:55:08 server id 1 end_log_pos 154 CRC32 0x3c5eccbd Previous-GTIDs
# [empty]
# at 154
#170217 23:55:38 server id 1 end_log_pos 219 CRC32 0x6dfd7ead Anonymous_GTID last_committed=0 sequence_number=1
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at219
#170217 23:55:38 server id 1 end_log_pos 287 CRC32 0xdec1d0d1 Query thread_id=10 exec_time=0 error_code=0
SET TIMESTAMP=1487346938/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1,@@session.sql_auto_is_null=0, @@session.unique_checks=1,@@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1,@@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET@@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 287
#170217 23:55:38 server id 1 end_log_pos 336 CRC32 0x4ca711bf Table_map: `test`.`tb1` mapped to number108
# at 336
#170217 23:55:38 server id 1 end_log_pos 385 CRC320xe7adf1d2 Delete_rows:table id 108 flags: STMT_END_F
BINLOG '
+hynWBMBAAAAMQAAAFABAAAAAGwAAAAAAAEABHRlc3QAA3RiMQACAw8CPAACvxGnTA==
+hynWCABAAAAMQAAAIEBAAAAAGwAAAAAAAEAAgAC//wCAAAACHpoYW5nc2Fu0vGt5w==
'/*!*/;
### DELETE FROM `test`.`tb1`
### WHERE
### @1=2
### @2='zhangsan'
# at 385
#170217 23:55:38 server id 1 end_log_pos 416CRC32 0xec501e68 Xid = 29
COMMIT/*!*/;
從中可以看出 delete 事件發生 position 是 287，事件結束 position 是 416
恢復流程：直接用 bin-log 日誌將數據庫恢復到刪除位置 287 前,然後跳過故障點,再進行恢復
下面所有的操作,命令如下
由於之前沒有做過全庫備份，所以要使用所有binlog日誌恢復，所以生產環境中需要很長時
間恢復，導出相關binlog文件
刪除 test 數據庫
利用binlog恢復數據
恢復完成後，我們檢查下表的數據是否完整
Ok完整的都恢復過來了
mysqlbinlog選項示例
常見的選項有以下幾個：
--start-datetime
從二進制日誌中讀取指定時間戳或者本地計算機時間之後的日誌事件。
--stop-datetime
從二進制日誌中讀取指定時間戳或者本地計算機時間之前的日誌事件。
--start-position
從二進制日誌中讀取指定position 事件位置作爲開始。
--stop-position
從二進制日誌中讀取指定position 事件位置作爲事件截至。
2、mysqldump介紹
mysqldump是mysql用於備份和數據轉移的一個工具。它主要產生一系列的 SQL 語句，可以
封裝到文件，該文件包含有所有重建你的數據庫所需要的 SQL 命令如 CREATE DATABASE，
CREATETABLE，INSERT 等等。可以用來實現輕量級的快速遷移或恢復數據庫。
mysqldump是將數據表導成 SQL 腳本文件，在不同的 MySQL 版本之間升級時相對比較合適，
這也是最常用的備份方法。
mysqldump一般在數據量很小的時候（幾個 G）可以用於備份。當數據量比較大的情況下，
就不建議用mysqldump工具進行備份了。
數據庫的導出
導出對象說明：
mysqldump可以針對單個表、多個表、單個數據庫、多個數據庫、所有數據庫進行導出的操
作
#mysqldump [options] db_name [tbl_name ...] //導出指定數據庫或單個表
#mysqldump [options] --databases db_name ... //導出多個數據庫
#mysqldump[options] --all-databases //導出所有
導出數據庫 test
#mysqldump -uroot -p --flush-logs test > /opt/test.sql //--flush-logs 這個選項就會完整備份
的時候重新開啓一個新binlog
數據庫的導入
#mysql -uroot -p test < /opt/test.sql
在前面我們介紹了mysql的binlog和mysqldump工具，下面我們來學習如何實現mysqldump
全庫備份+binlog的數據恢復
環境準備與備份還原：
檢查開啓binlog
先創建一些原始數據
方案：mysqldump全庫備份+binlog還原
1、mysqldump備份方案：
每週一凌晨 1 點全庫備份
2、備份步驟
（1）創建備份目錄
（2）全庫備份
這裏我們模擬週一的完整備份數據庫任務
備份mysqldump全庫備份之前的binlog日誌文（注：生產環境中可能不只一個binlog文件）
#cp /usr/local/mysql/data/mysql-bin.000001 /opt/mysqlbackup/daily/
# mysql-uroot -p -e "purge binary logs to 'mysql-bin.000002'"
模擬下操作失誤,將數據修改錯誤了
備份自mysqldump之後的binlog日誌文件
cp/usr/local/mysql/data/mysql-bin.000002 /opt/mysqlbackup/daily/
上面的模擬的誤操作是刪除了 id=1 的記錄
（3）現在我們使用mysqldump的全庫備份和binlog來恢復數據。
使用mysqldump的備份進行全庫恢復
# mysql-uroot -p test_db< /opt/mysqlbackup/test_db_2016_09_12.sql
查詢一下數據
從顯示結果可以看到使用mysqldump備份將數據還原到了備份時的狀態，剛纔刪除的數據
（id=2）恢復回來了，但備份後產生的數據卻丟失了所以還得利用binlog進一步不原
因爲刪除是在全庫備份後發生的，而mysqldump全庫備份時使用--flush-logs 選項，所以只需
要分析全庫備份後的binlog即 mysql-bin.000002。
查看 mysql-bin.000002 中的事件，可以看到有刪除事件
mysql-bin.000002| 219 | Query | 1 | 294 | BEGIN |
|mysql-bin.000002 | 294 | Table_map | 1 | 346 | table_id: 108(test_db.tb1) |
|mysql-bin.000002 | 346 |Delete_rows | 1 | 391 | table_id: 108 flags: STMT_END_F |
|mysql-bin.000002 | 391 | Xid | 1 | 422 | COMMIT /* xid=51 */
使用mysqlbinlog命令可以查看備份的binlog文件的詳細事件。
恢復流程：我們直接用 bin-log 日誌將數據庫恢復到刪除位置前,然後跳過故障點,再進行恢復
刪除後的所有操作。
#mysqlbinlog -v /opt/mysqlbackup/daily/mysql-bin.000002
我們先用mysqlbinlog命令找到 delete 那條語句的位置
# at 219
#170218 0:54:46 server id 1 end_log_pos 294 CRC32 0x60d549db Query thread_id=7 exec_time=0 error_code=0
SETTIMESTAMP=1487350486/*!*/;
SET@@session.pseudo_thread_id=7/*!*/;
SET@@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET@@session.sql_mode=1075838976/*!*/;
SET@@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\Cutf8 *//*!*/;
SET@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET@@session.lc_time_names=0/*!*/;
SET@@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
#at 294
#170218 0:54:46 server id 1 end_log_pos 346 CRC32 0xc1921e5d Table_map: `test_db`.`tb1` mapped to number108
#at 346
#170218 0:54:46 server id 1 end_log_pos 391 CRC32 0x2c8954b3 Delete_rows: table id 108 flags: STMT_END_F
BINLOG'
1iqnWBMBAAAANAAAAFoBAAAAAGwAAAAAAAEAB3Rlc3RfZGIAA3RiMQACAw8CPAACXR6SwQ==
1iqnWCABAAAALQAAAIcBAAAAAGwAAAAAAAEAAgAC//wBAAAABHRvbTGzVIks
'/*!*/;
###DELETE FROM `test_db`.`tb1`
###WHERE
### @1=1
### @2='tom1'
#at 391
#170218 0:54:46 server id 1 end_log_pos422 CRC32 0xfd1df8a7 Xid = 51
COMMIT/*!*/;
通過mysqlbinlog命令所顯示的結果可以看到誤操作 delete 的開始postion爲 219，結束
position是 422。
從二進制日誌中讀取指定 position=219 事件位置作爲截至，即把數據恢復到 delete 刪除前
#mysqlbinlog --stop-position=219 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql-u root -p
從二進制日誌中讀取指定 position=422 事件位置作爲開始，即跳過刪除事件，恢復刪除事件
之後對數據的正常操作
#mysqlbinlog--start-position=422 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql -u root –p
查看恢復結果：
從上面顯示可以看出數據恢復到正常狀態
生產環境中Mysql數據庫的備份是週期性重複的操作，所以通常是要編寫腳本實現，通過
crond計劃任務週期性執行備份腳本
mysqldump備份方案：
週日凌晨 1 點全庫備份
週一到週六凌晨每隔 4 個小時增量備份一次
設置crontab任務，每天執行備份腳本
#crontab –e
#每個星期日凌晨 1:00 執行完全備份腳本
01 * * 0 /root/mysqlfullbackup.sh >/dev/null 2>&1
#週一到週六每隔 4 個小時增量備份一次
0*/4 * * 1-6 /root/mysqldailybackup.sh >/dev/null 2>&1
mysqlfullbackup.sh腳本內容：
[root@localhostDesktop]# cat mysqlfullbackup.sh
#!/bin/sh
#Name:mysqlFullBackup.sh
# 定義數據庫目錄
mysqlDir=/usr/local/mysql
# 定義用於備份數據庫的用戶名和密碼
user=root
userpwd=123.abc
dbname=test_db
# 定義備份目錄
databackupdir=/opt/mysqlbackup
[! -d $databackupdir ]&&mkdir $databackupdir
# 定義郵件正文文件
emailfile=$databackupdir/email.txt
# 定義郵件地址
# 定義備份日誌文件
logfile=$databackupdir/mysqlbackup.log
DATE=`date-I`
echo"" > $emailfile
echo$(date +"%y-%m-%d %H:%M:%S") >> $emailfile
cd$databackupdir
# 定義備份文件名
dumpfile=mysql_$DATE.sql
gzdumpfile=mysql_$DATE.sql.tar.gz
# 使用mysqldump備份數據庫，請根據具體情況設置參數
$mysqlDir/bin/mysqldump-u$user -p$userpwd --flush-logs -x $dbname> $dumpfile
# 壓縮備份文件
if[ $? -eq0 ]; then
tarczf$gzdumpfile $dumpfile>> $emailfile 2>&1
echo"BackupFileName:$gzdumpfile" >> $emailfile
echo"DataBase Backup Success!" >> $emailfile
rm-f $dumpfile
else
echo"DataBase Backup Fail!" >> $emailfile
fi
# 寫日誌文件
echo"--------------------------------------------------------" >>$logfile
cat$emailfile>> $logfile
# 發送郵件通知
cat$emailfile | mail -s "MySQL Backup" $email
[root@localhostDesktop]# cat mysqldailybackup.sh
#!/bin/sh
#Name:mysqlDailyBackup.sh
# 定義數據庫目錄和數據目錄
mysqldir=/usr/local/mysql
datadir=$mysqldir/data
# 定義用於備份數據庫的用戶名和密碼
user=root
userpwd=123.abc
# 定義備份目錄，每日備份文件備份到$dataBackupDir/daily
databackupdir=/opt/mysqlbackup
dailybackupdir=$databackupdir/daily
[! -d $dailybackupdir ]&&mkdir -p $databackupdir/daily
# 定義郵件正文文件
emailfile=$databackupdir/email.txt
# 定義郵件地址
# 定義日誌文件
logfile=$databackupdir/mysqlbackup.log
echo"" > $emailfile
echo$(date +"%y-%m-%d %H:%M:%S") >> $emailfile
#
# 刷新日誌，使數據庫使用新的二進制日誌文件
$mysqldir/bin/mysqladmin-u$user -p$userpwd flush-logs
cd$datadir
# 得到二進制日誌列表
filelist=`catmysql-bin.index`
icounter=0
forfile in $filelist
do
icounter=`expr$icounter + 1`
done
nextnum=0
ifile=0
forfile in $filelist
do
binlogname=`basename$file`
nextnum=`expr$nextnum + 1`
# 跳過最後一個二進制日誌（數據庫當前使用的二進制日誌文件）
if[ $nextnum -eq $icounter ]; then
echo"Skip lastest!" > /dev/null
else
dest=$dailybackupdir/$binlogname
# 跳過已經備份的二進制日誌文件
if[ -e $dest ]; then
echo"Skip exist $binlogname!" > /dev/null
else
# 備份日誌文件到備份目錄
cp$binlogname $dailybackupdir
if[ $? -eq0 ]; then
ifile=`expr$ifile + 1`
echo"$binlogname backup success!" >> $emailfile
fi
fi
fi
done
if[ $ifile -eq 0 ];then
echo"No Binlog Backup!" >> $emailfile
else
echo"Backup $ifile File(s)." >> $emailfile
echo"Backup MySQL Binlog OK!" >> $emailfile
fi
# 發送郵件通知
cat$emailfile | mail -s "MySQL Backup" $email
# 寫日誌文件
echo"--------------------------------------------------------" >>$logfile
cat$emailfile>> $logfile
二、使用xtrabackup進行 MySQL 數據庫備份
前面介紹mysqldump備份方式是採用邏輯備份，其最大的缺陷就是備份和恢復速度都慢，
對於一個小於 50G 的數據庫而言，這個速度還是能接受的，但如果數據庫非常大，那再使
用mysqldump備份就不太適合了。
這時就需要一種好用又高效的工具，xtrabackup就是其中一款，號稱免費版的InnoDB
HotBackup。
Xtrabackup實現是物理備份，而且是物理熱備
目前主流的有兩個工具可以實現物理熱備：ibbackup和xtrabackup；ibbackup是商業軟件，
需要授權，非常昂貴。而xtrabackup功能比ibbackup還要強大，但卻是開源的。因此我們
這裏就來介紹xtrabackup的使用。
Xtrabackup提供了兩種命令行工具：
xtrabackup：專用於備份InnoDB和XtraDB引擎的數據；
innobackupex：這是一個perl腳本，在執行過程中會調用xtrabackup命令，這樣用該命令即
可以實現備份InnoDB，也可以備份MyISAM引擎的對象。
Xtrabackup是由percona提供的mysql數據庫備份工具，特點：
(1)備份過程快速、可靠；
(2)備份過程不會打斷正在執行的事務；
(3)能夠基於壓縮等功能節約磁盤空間和流量；
(4)自動實現備份檢驗；
(5)還原速度快。
官方鏈接地址：http://www.percona.com/software/percona-xtrabackup；可以下載源碼編譯安
裝，也可以下載適合的 RPM 包或使用 yum 進行安裝或者下載二進制源碼包。
安裝xtrabackup
1)下載xtrabackup
wgethttps://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/bin
ary/tarball/percona-xtrabackup-2.4.4-Linux-x86_64.tar.gz
2)解壓
3)進入解壓目錄
4)複製 bin 下的所有程序到/usr/bin
Xtrabackup中主要包含兩個工具：
xtrabackup：是用於熱備份innodb, xtradb表中數據的工具，支持在線熱備份，可以在不
加鎖的情況下備份Innodb數據表，不過此工具不能操作Myisam引擎表；
innobackupex：是將xtrabackup進行封裝的perl腳本，能同時處理Innodb和Myisam，
但在處理Myisam時需要加一個讀鎖。
由於操作Myisam時需要加讀鎖，這會堵塞線上服務的寫操作，而Innodb沒有這樣的限制，所以數據庫中Innodb表類型所佔的比例越大，則越有利。
4)安裝相關插件
#yuminstall perl-DBI perl-DBD-MySQL perl-Time-HiResperl-IO-Socket-SSL
perl-TermReadKey.x86_64perl-Digest-MD5 –y
5)下載percona-toolkit 並安裝
#wgethttps://www.percona.com/downloads/percona-toolkit/2.2.19/RPM/percona-toolkit-2
.2.19-1.noarch.rpm
下面就可以啓動備份了
方案：xtrabackup 完全備份+binlog 增量備份
1、備份
創建備份目錄
#mkdir -p /opt/mysqlbackup/{full,inc}
full：全備存放的目錄；inc：增量備份存放的目錄
1)完全備份
基本語法：# innobackupex --user=DBUSER--password=DBUSERPASS /path/to/BACKUP-DIR/
執行下面的命令進行完全備份：
#innobackupex --user=root --password=123456 /opt/mysqlbackup/full
注： --defaults-file=/etc/my.cnf 指定 mysql 的配置文件 my.cfg，如果指定則必須是第一個
參數。
/path/to/BACKUP-DIR/指定備份所存放的目標目錄，備份過程會創建一個以當時備份時間
命名的目錄存放備份文件。
出現如下提示。表示成功
備份後的文件：
在備份的同時，備份數據會在備份目錄下創建一個以當前日期時間爲名字的目錄存放備
份文件：
各文件說明：
(1)xtrabackup_checkpoints—— 備份類型（如完全或增量）、備份狀態（如是否已經爲
prepared狀態）和 LSN(日誌序列號)範圍信息；
每個 InnoDB 頁(通常爲 16k 大小)都會包含一個日誌序列號，即 LSN。LSN 是整個數據庫
系統的系統版本號，每個頁面相關的 LSN 能夠表明此頁面最近是如何發生改變的。
(2)xtrabackup_binlog_info—— mysql 服務器當前正在使用的二進制日誌文件及至備份
這一刻爲止二進制日誌事件的位置。
(3)xtrabackup_binlog_pos_innodb—— 二進制日誌文件及用於 InnoDB 或 XtraDB 表的二進制日誌文件的當前 position。
(4)xtrabackup_binary—— 備份中用到的 xtrabackup 的可執行文件；
(5)backup-my.cnf—— 備份命令用到的配置選項信息；
在使用 innobackupex 進行備份時，還可以使用--no-timestamp 選項來阻止命令自動創建
一個以時間命名的目錄；如此一來，innobackupex 命令將會創建一個 BACKUP-DIR 目錄
來存儲備份數據
注意：相關選項說明：
其中，--user 指定連接數據庫的用戶名，--password 指定連接數據庫的密碼，--defaults-file
指定數據庫的配置文件，innobackupex 要從其中獲取 datadir 等信息；--database 指定要
備份的數據庫，這裏指定的數據庫只對 MyISAM 表有效，對於 InnoDB 數據來說都是全
備（所有數據庫中的 InnoDB 數據都進行了備份，不是隻備份指定的數據庫，恢復時也
一樣）；/opt/mysqlbackup/full 是備份文件的存放位置。
注意：備份數據庫的用戶需要具有相應權限，如果要使用一個最小權限的用戶進行備份，
則可基於如下命令創建此類用戶：
mysql>create user 'bkpuser'@'localhost' identified by '123456';
mysql>revoke all privileges,grant option from 'bkpuser'@'localhost';
mysql>grant reload,lock tables,replication client, process on *.* to'bkpuser'@'localhost';
mysql>flush privileges;
至此全備完全成功，然後向 mysql 某個庫插入幾條數據，然後進行增量備份
對完全備份的後數據庫更改進行二進制日誌增量備份：
查看完全備份時 binlog 日誌位置(position)：
模擬數據庫修改：
2)增量備份二進制文件：
2、還原數據庫：
模擬數據庫損壞：
我這裏直接使用刪除數據目錄文件來模擬損壞。
#rm -fr /usr/local/mysql/data/*
還原完全備份：
（1）準備(prepare)一個完全備份
一般情況下，在備份完成後，數據尚且不能用於恢復操作，因爲備份的數據中可能會包
含尚未提交的事務或已經提交但尚未同步至數據文件中的事務。因此，此時數據文件仍
處於不一致狀態。“準備”的主要作用正是通過回滾未提交的事務及同步已經提交的事
務至數據文件也使得數據文件處於一致性狀態。
在準備（prepare）過程結束後，InnoDB 表數據已經前滾到整個備份結束的點，而不是
回滾到 xtrabackup 剛開始時的點。
innobakupex命令的--apply-log 選項可用於實現上述功能。如下面的命令：
--apply-log指明是將日誌應用到數據文件上，完成之後將備份文件中的數據恢復到數據
庫中：
#innobackupex --apply-log /opt/mysqlbackup/full/2016-09-12_11-29-55/
注：/opt/mysqlbackup/full/2016-09-12_11-29-55/備份文件所在目錄名稱
如果執行正確，其最後輸出的幾行信息通常如下：
在實現“準備”的過程中，innobackupex 通常還可以使用--use-memory 選項來指定其可
以使用的內存的大小，默認通常爲 100M。如果有足夠的內存可用，可以多劃分一些內
存給 prepare 的過程，以提高其完成速度。
innobackupex命令的--copy-back 選項用於執行恢復操作，其通過複製所有數據相關的文
件至 mysql 服務器 DATADIR 目錄中來執行恢復過程。innobackupex 通過 backup-my.cnf
來獲取 DATADIR 目錄的相關信息。
（2）還原數據庫語法：
#innobackupex --copy-back /opt/mysqlbackup/full/2016-09-12_11-29-55/
這裏的--copy-back 指明是進行數據恢復。數據恢復完成之後，需要修改相關文件的權
限 mysql 數據庫才能正常啓動。
如果執行正確，其輸出信息的最後幾行通常如下：
請確保如上信息的最行一行出現“completed OK!”。
修改還原後的數據目錄權限:
當數據恢復至 DATADIR 目錄以後，還需要確保所有數據文件的屬主和屬組均爲正確的用
戶，如 mysql，否則，在啓動 mysqld 之前還需要事先修改數據文件的屬主和屬組。如：
驗證還原後的數據：
（3）還原增量備份：
爲了防止還原時產生大量的二進制日誌，在還原時可臨時關閉二進制日誌後再還原：
重新啓動二進制日誌並驗證還原數據：
mysql>set sql_log_bin=1;
驗證數據是否恢復回來
附：Xtrabackup 的“流”及“備份壓縮”功能
Xtrabackup對備份的數據文件支持“流”功能，即可以將備份的數據通過 STDOUT 傳
輸給 tar 程序進行歸檔，而不是默認的直接保存至某備份目錄中。要使用此功能，僅需
要使用--stream 選項即可。如：
#innobackupex --user=root --password="123456" --stream=tar/opt/mysqlbackup/full/
|gzip >/opt/mysqlbackup/full/full_`date +%F_%H%M%S`.tar.gz
