Mysql 基於innobackupex 的備份&恢復

備份，對於任何數據庫，任何系統都是重中之重。針對Mysql，我選擇percona xtrabackup軟件。我更喜歡物理層面的熱備份。而不是邏輯層面的備份（mysqldump），固然不少狀況，也要按期作mysqldump備份。增長一個安全的備份選擇。

關於如何下載安裝percona xtrabackup，請參考：

http://www.javashuo.com/article/p-mhjtfisn-gy.html

先看看innobackupex經常使用參數

--compact        建立一個不包含第二索引（除了主鍵以外的索引）的備份
--decompress        解壓以前全部以–compress參數備份出來的帶有.qp格式的備份文件，--parallel參數會容許同時解鎖或解壓多個文件。須要安裝qpress軟件。
--defaults-file=[MY.CNF] 配置文件的路徑
--incremental-basedir 以上一次全量或增量備份的路徑，做爲增量備份的基礎。指定這個參數的同時，應該一樣指定--incremental參數
--incremental 建立增量備份，當指定這個參數的時候，應該指定--incremental-lsn或--incremental-basedir參數，不然將會備份到--incremental-basedir路徑
--apply-log  在備份目錄下，經過應用名稱爲xtrabackup_logfile的交易日誌文件來準備備份。同時，建立新的交易日誌。
--redo-only 當準備數據庫的全備或合併增量備份時，須要指定這個參數。這個參數實際上執行的是xtrabackup --apply-log-only，會讓xtrabackup跳過回滾節點，只作「redo」步驟。當數據庫須要應用增量備份時，須要指定這個參數。
--incremental-dir=DIRECTORY 指定增量備份的目錄，須要搭配--incremental參數。
--no-timestamp 這個參數會讓xtrabackup在備份的時候不建立帶有時間格式的子文件夾。當指定了這個參數，備份會直接建立在指定的備份目錄下
--stream=STREAMNAME 指定流備份的格式。備份將會以指定格式輸出到STDOUT。目前支持的格式有tar 和 xbstream。若是指定了這個參數，後面須要接tmpdir目錄做爲處理流的一箇中間目錄。
--slave-info    當備份一個做爲複製環境的服務器時，這個參數會自動將CHANGE MASTER語句寫到備份中，在恢復備份後，沒必要執行CHANGE MASTER語句。
--tables-file=FILE        這個參數會接受一個字符串，這個字符串指定了一個文件，這個文件包含了要備份的表名，格式如database.table，一行一個。
--use-memory=#        這個參數用於在準備備份時，xtrabackup執行crash recovery所使用的內存大小。這個參數僅和--apply-log搭配時才生效。

更多innobackupex參數解釋，請參考官網

https://www.percona.com/doc/percona-xtrabackup/LATEST/innobackupex/innobackupex_option_reference.html

整個測試流程以下圖

下面開始個人備份&恢復測試

1. 先看一下個人/etc/my.cnf設置。我選擇了binlog是row模式的，也就是「行」模式，而不是sql模式。binlog和datafile分開存放，方便後續的數據庫管理。

binlog_format = row
expire_logs_days = 7
max_binlog_size = 100m
binlog_cache_size = 4m
max_binlog_cache_size = 512m
character_set_server = utf8
lower_case_table_names=1
datadir=/data/mysql
log_bin=/data/mysql-binlog/mysql-bin
server_id=101

備份前，建立表

test1        --innodb引擎
test2        --innodb引擎
testmyisam   --myisam引擎

2. 數據庫全備份(innobackupex參數請參考)

建立備份目錄

mkdir /backup

全庫備份

innobackupex --defaults-file=/etc/my.cnf --user=root --password='Abcd234!' /backup/20180424/

3. 全備份以後的操做

a. 建立myisam存儲引擎的表testmyisam2

mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1          |
| test2          |
| testmyisam     |
| testmyisam2    |
+----------------+
4 rows in set (0.00 sec)

b. 刪除表test2

mysql> drop table test2;
Query OK, 0 rows affected (0.03 sec)
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1          |
| testmyisam     |
| testmyisam2    |
+----------------+
3 rows in set (0.00 sec)

4. innobackupex備份mysql的過程，就是文件的拷貝，在拷貝數據的過程當中，數據會發生變化，因此備份出來的數據文件是不一致的。爲了保證數據的一致性，須要應用這段時間產生的binlog，才能作到備份數據文件的一致性。後續回覆纔能有效。

使用--apply-log參數並指定帶時間的備份子目錄，進行備份一致性合併。想要加快apply-log的進程，推薦使用--use-memory參數。

這個操做能夠在任意機器上執行準備備份動做，並不限定在備份的服務器上。

innobackupex --defaults-file=/etc/my.cnf  --apply-log --user=root --password='Abcd1234!' /backup/20180424/2018-04-22_21-22-30/

5. 恢復數據文件到mysql路徑下，恢復路徑取決於my.cnf中的datadir=/data/mysql 參數。

須要先清空datadir=/data/mysql 路徑才能恢復，否則會報錯。默認狀況下，--copy-back是不會over write已經存在的文件的，能夠經過參數--force-non-empty-directories強制覆蓋

中止mysql

service mysqld stop

清空mysql路徑(必定要慎重，建議是mv備份，而不是rm)

rm -rf /data/mysql/*

全庫恢復

innobackupex --defaults-file=/etc/my.cnf  --copy-back /backup/20180424/2018-04-22_21-22-30/

修改路徑權限

chown mysql:mysql -R /data/mysql/

啓動mysql

service mysqld start

6. 當前數據庫只是restore一個全備份，並無基於時間點，恢復到當前

全背後恢復完成以後，查詢數據庫，能夠看到test2表尚未刪除，testmyisam2也沒有出現

mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1       |
| test2       |
| testmyisam      |
+----------------+

7. 首先要經過備份文件，查找上次備份完成，的binglog position位置，在備份文件路徑下的xtrabackup_binlog_info中記錄，這個position很重要，是後面恢復的關鍵。

# cd /backup/20180424/2018-04-22_21-22-30/
# cat  xtrabackup_binlog_info
  mysql-bin.000002        29388004

8. 經過mysqlbinglog進行recover

mysqlbinlog --start-position=29388004  /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd234!'

9. 歸檔也恢復完成以後，再次查詢test2表已經刪除，testmyisam2也出現了

mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1      |
| testmyisam    |
| testmyisam2    |
+----------------+
3 rows in set (0.00 sec)

10.也能夠根據position恢復到指定的時間點範圍（下面是full restore自後再次測試的步驟，不是接上一步恢復的。）

查找position信息

# mysqlbinlog --start-position=29388004  /data/mysql-binlog/mysql-bin.000002|grep "^# at"
# at 4
# at 29388004
# at 29388069
# at 29388304
# at 29388369
# at 29388487

11. 指定範圍恢復

mysqlbinlog --start-position=29388004 --stop-position=29388304 /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd1234!'
恢復完這段binlog，能夠看到testmyisam2已經出現了
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1        |
| test2        |
| testmyisam     |
| testmyisam2    |
+----------------+
4 rows in set (0.00 sec)

12. 分段recover，有助於在人爲錯誤的數據找回

mysqlbinlog --start-position=29388304 --stop-position=29388487 /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd1234!'
恢復這段binlog，能夠看到test2已經被刪除了
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test1       |
| testmyisam    |
| testmyisam2    |
+----------------+

總結

a、對於徹底恢復，咱們須要使用備份加binlog二者結合的方式來實現

b、在恢復期間，首先使用帶read-only的apply-log方式來prepare全備(在有增量備份須要合併的狀況，沒有增量的狀況，就不須要read-only)

c、接下來使用帶read-only的apply-log方式來prepare增備，僅最後一個增備能夠不用read-only

d、中止原有實例，並copy-back後啓動恢復後的實例

e、從Innobakcupex備份信息中獲取最後的binlog日誌及位置信息

f、使用mysqlbinlog方式將日誌追加到最新時刻

參考連接

http://blog.itpub.net/26506993/viewspace-2088737/

https://blog.csdn.net/zhang123456456/article/details/72954519