xtrabackup介紹

Percona XtraBackup（簡稱PXB）是 Percona 公司開發(fā)的一個用于 MySQL 數(shù)據(jù)庫物理熱備的備份工具，支持 MySQl（Oracle）祥诽、Percona Server 和 MariaDB，并且全部開源捣域，真可謂是業(yè)界良心。

xtrabackup命令參數(shù)解釋

--defaults-file
同xtrabackup的--defaults-file參數(shù)
--apply-log
對xtrabackup的--prepare參數(shù)的封裝
--copy-back
做數(shù)據(jù)恢復(fù)時將備份數(shù)據(jù)文件拷貝到MySQL服務(wù)器的datadir 斗忌；
--remote-host=HOSTNAME
通過ssh將備份數(shù)據(jù)存儲到進程服務(wù)器上能犯；
--stream=[tar]
備 份文件輸出格式, tar時使用tar4ibd , 該文件可在XtarBackup binary文件中獲得.如果備份時有指定--stream=tar, 則tar4ibd文件所處目錄一定要在$PATH中(因為使用的是tar4ibd去壓縮, 在XtraBackup的binary包中可獲得該文件)。
在 使用參數(shù)stream=tar備份的時候沈贝，你的xtrabackup_logfile可能會臨時放在/tmp目錄下杠人，如果你備份的時候并發(fā)寫入較大的話 xtrabackup_logfile可能會很大(5G+)，很可能會撐滿你的/tmp目錄宋下，可以通過參數(shù)--tmpdir指定目錄來解決這個問題嗡善。
--tmpdir=DIRECTORY
當有指定--remote-host or --stream時, 事務(wù)日志臨時存儲的目錄, 默認采用MySQL配置文件中所指定的臨時目錄tmpdir
--redo-only
強制備份日志時只redo ,跳過rollback。這在做增量備份時非常必要学歧。
--use-memory=#
該參數(shù)在prepare的時候使用罩引，控制prepare時innodb實例使用的內(nèi)存量
--throttle=IOS
同xtrabackup的--throttle參數(shù)
--sleep=是給ibbackup使用的，指定每備份1M數(shù)據(jù)枝笨，過程停止拷貝多少毫秒袁铐，也是為了在備份時盡量減小對正常業(yè)務(wù)的影響，具體可以查看ibbackup的手冊 横浑；
--compress[=LEVEL]
對備份數(shù)據(jù)迚行壓縮剔桨，僅支持ibbackup，xtrabackup還沒有實現(xiàn)徙融；
--include=REGEXP
對 xtrabackup參數(shù)--tables的封裝洒缀，也支持ibbackup。備份包含的庫表欺冀，例如：--include="test."帝洪，意思是要備份 test庫中所有的表。如果需要全備份脚猾，則省略這個參數(shù)；如果需要備份test庫下的2個表：test1和test2,則寫 成：--include="test.test1|test.test2"砚哗。也可以使用通配符龙助，如：--include="test.test"。
--databases=LIST
列出需要備份的databases蛛芥，如果沒有指定該參數(shù)提鸟，所有包含MyISAM和InnoDB表的database都會被備份；
--uncompress
解壓備份的數(shù)據(jù)文件仅淑，支持ibbackup称勋，xtrabackup還沒有實現(xiàn)該功能；
--slave-info
備 份從庫, 加上--slave-info備份目錄下會多生成一個xtrabackup_slave_info 文件, 這里會保存主日志文件以及偏移, 文件內(nèi)容類似于:CHANGE MASTER TO MASTER_LOG_FILE='', MASTER_LOG_POS=0
--socket=SOCKET
指定mysql.sock所在位置涯竟，以便備份進程登錄mysql.

恢復(fù)MySQL主從

數(shù)據(jù)庫主從因為各種原因斷了赡鲜，而且沒辦法恢復(fù)空厌。線上數(shù)據(jù)庫也不能停止。這時候想恢復(fù)主從關(guān)系就可以借助熱備份工具xtrabackup银酬。

第一步：備份線上數(shù)據(jù)庫

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

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

[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把已提交的事務(wù)合并到ibdata文件
這一步持續(xù)時間會很長赋朦，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/

第四步：啟動從機的數(shù)據(jù)庫

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

第五步：建立主從關(guān)系

[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;

以上李破，不需要停止線上業(yè)務(wù)宠哄，成功恢復(fù)了主從關(guān)系。

熱備份數(shù)據(jù)庫

TODO

從熱備恢復(fù)數(shù)據(jù)

TODO

參考

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