innobackupex 備份及恢復測試簡析

本文主要給大家介紹innobackupex備份及恢復測試簡析，文章內容都是筆者用心摘選和編輯的，具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下主題內容吧。

先看看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方式將日志追加到最新時刻

看完以上關于innobackupex 備份及恢復測試簡析，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業知識信息 ，可以持續關注我們的行業資訊欄目的。