運維筆記：利用 xtrabackup 進行線上 MySQL 數據庫主從恢復

xtrabackup介紹

Percona XtraBackup（簡稱PXB）是 Percona 公司開發的一個用於 MySQL 數據庫物理熱備的備份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，並且全部開源，真可謂是業界良心。

xtrabackup命令參數解釋

--defaults-file
同 xtrabackup 的 --defaults-file 參數
--apply-log
對xtrabackup的–prepare參數的封裝
--copy-back
做數據恢復時將備份數據文件拷貝到MySQL服務器的datadir ；
--remote-host=HOSTNAME
通過ssh將備份數據存儲到進程服務器上；
--stream=[tar]
備 份文件輸出格式, tar時使用tar4ibd , 該文件可在XtarBackup binary文件中獲得.如果備份時有指定–stream=tar, 則tar4ibd文件所處目錄一定要在$PATH中(因爲使用的是tar4ibd去壓縮, 在XtraBackup的binary包中可獲得該文件)。
在 使用參數stream=tar備份的時候，你的xtrabackup_logfile可能會臨時放在/tmp目錄下，如果你備份的時候併發寫入較大的話 xtrabackup_logfile可能會很大(5G+)，很可能會撐滿你的/tmp目錄，可以通過參數–tmpdir指定目錄來解決這個問題。
--tmpdir=DIRECTORY
當有指定–remote-host or --stream時, 事務日誌臨時存儲的目錄, 默認採用MySQL配置文件中所指定的臨時目錄tmpdir
--redo-only
強制備份日誌時只redo ,跳過rollback。這在做增量備份時非常必要。
--use-memory=#
該參數在prepare的時候使用，控制prepare時innodb實例使用的內存量
--throttle=IOS
同xtrabackup的–throttle參數
--sleep=是給ibbackup使用的，指定每備份1M數據，過程停止拷貝多少毫秒，也是爲了在備份時儘量減小對正常業務的影響，具體可以查看ibbackup的手冊 ；
--compress[=LEVEL]
對備份數據迚行壓縮，僅支持ibbackup，xtrabackup還沒有實現；
--include=REGEXP
對 xtrabackup參數–tables的封裝，也支持ibbackup。備份包含的庫表，例如：–include=“test."，意思是要備份 test庫中所有的表。如果需要全備份，則省略這個參數；如果需要備份test庫下的2個表：test1和test2,則寫 成：–include=“test.test1|test.test2”。也可以使用通配符，如：–include="test.test”。
--databases=LIST
列出需要備份的databases，如果沒有指定該參數，所有包含MyISAM和InnoDB表的database都會被備份；
--uncompress
解壓備份的數據文件，支持ibbackup，xtrabackup還沒有實現該功能；
--slave-info
備 份從庫, 加上–slave-info備份目錄下會多生成一個xtrabackup_slave_info 文件, 這裏會保存主日誌文件以及偏移, 文件內容類似於:CHANGE MASTER TO MASTER_LOG_FILE=’’, MASTER_LOG_POS=0
--socket=SOCKET
指定mysql.sock所在位置，以便備份進程登錄mysql.

恢復MySQL主從

數據庫主從因爲各種原因斷了，而且沒辦法恢復。線上數據庫也不能停止。這時候想恢復主從關係就可以藉助熱備份工具xtrabackup。

第一步：備份線上數據庫

[root@ddz_db5 data]# innobackupex --slave-info /data/

如果沒有指定備份目錄，xtrabackup會在當前目錄自動生成以當前時間命名的備份文件夾。100G數據用時在半小時左右。

[root@ddz_db5 data]# ll
drwxr-x--- 5 root  root     4096 May 27 10:16 2017-05-27_09-57-24
drwxr-xr-x 5 mysql mysql    4096 May 27 16:40 mysql

第二步：xtrabackup --apply-log把已提交的事務合併到ibdata文件
這一步持續時間會很長，1小時左右。

[root@ddz_db5 data] xtrabackup --apply-log 2017-05-27_09-57-24
170527 11:10:23 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

innobackupex version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: cd to /data/2017-05-27_10-36-22/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=822542336, start_lsn=(16153415803165)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
...

InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 16153415803165
InnoDB: Doing recovery: scanned up to log sequence number 16153421045760 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 16153426288640 (1%)
InnoDB: Doing recovery: scanned up to log sequence number 16153431531520 (2%)
InnoDB: Doing recovery: scanned up to log sequence number 16153436774400 (2%)
InnoDB: Doing recovery: scanned up to log sequence number 16153442017280 (3%)
InnoDB: Doing recovery: scanned up to log sequence number 16153447260160 (4%)
InnoDB: Doing recovery: scanned up to log sequence number 16153452503040 (5%)
InnoDB: Doing recovery: scanned up to log sequence number 16153457745920 (5%)
InnoDB: Doing recovery: scanned up to log sequence number 16153462988800 (6%)
...
InnoDB: Doing recovery: scanned up to log sequence number 16153788440576 (50%)
InnoDB: Doing recovery: scanned up to log sequence number 16153793683456 (51%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 16153798926336 (52%)
InnoDB: Doing recovery: scanned up to log sequence number 16153804169216 (53%)

第三步：scp備份目錄到從機

[root@ddz_db5 data] scp -r 2017-05-27_09-57-24 slave:/data/

第四步：啓動從機的數據庫

[root@slave data] mv 2017-05-27_09-57-24 mysql
[root@slave data] service mysqld start

第五步：建立主從關係

[root@slave data] cat mysql/xtrabackup_binlog_info
mysqlbin-log.011197     1057212057
[root@slave data] mysql
...
mysql> change master to master_host='master',master_user='slave',master_password='slave',master_log_file='mysqlbin-log.011197',master_log_pos=1057212057;
mysql> start slave;

以上，不需要停止線上業務，成功恢復了主從關係。

熱備份數據庫

TODO

從熱備恢復數據

TODO

參考

https://www.percona.com
MySQL · 物理備份 · Percona XtraBackup 備份原理
mysql之使用xtrabackup進行物理備份、恢復、在線克隆從庫、在線重做主從
mysql innobackupex xtrabackup 大數據量 備份 還原