xtrabackup 資料庫備份

Percona XtraBackup是一款基于MySQL的熱備份的開源實用程式，它可以備份5.1到5.7版本上InnoDB,XtraDB,MyISAM存儲引擎的表，

Xtrabackup有兩個主要的工具：xtrabackup、innobackupex

　　（1）xtrabackup隻能備份InnoDB和XtraDB兩種資料表，而不能備份MyISAM資料表

　　（2）innobackupex則封裝了xtrabackup，是一個腳本封裝，是以能同時備份處理innodb和myisam，但在處理myisam時需要加一個讀鎖

首先我們先來簡單的了解一下xtrabackup是怎麼工作的。xtrabackup基于innodb的crash-recovery（執行個體恢複）功能，先copy innodb的實體檔案（這個時候資料的一緻性是無法滿足的），然後進行基于redo log進行恢複，達到資料的一緻性。詳細的資訊可以參數https://www.percona.com/doc/percona-xtrabackup/LATEST/how_xtrabackup_works.html 我就不翻譯了。

我們還是簡單的來看一下日常工作中具體的使用：

全備：

xtrabackup --backup --target-dir=/data/backup/base

可以先看到

在備份過程中,可以看到很多輸出顯示資料檔案被複制,以及日志檔案線程反複掃描日志檔案和複制。

同樣的它也輸出了目前的binlog filename和position，如果有gtid(同樣也會輸出) 可以用于搭建主從。最後一行一定會是你的lsn被copy的資訊。

這是因為每次啟動備份，都會記錄170429 12:54:10 >> log scanned up to (1676085)），然後開始拷貝檔案，一般來講資料庫越大拷貝檔案是要花費越長的時間，是以說這期間一般情況都會有新的操作，是以說所有檔案也可能記錄的并不是一個時間點的資料，

為了解決資料這個問題，XtraBackup 就會啟動一個背景程序來每秒1次的觀測mysql的事務日志，直到備份結束。而且把事務日志中的改變記錄下來。我們知道事物日志是會重用的（redo log）,是以這個程序會把redolog寫到自己的日志檔案xtrabackup_log，這個背景監控程序會記錄所有的事務日志的改變，用于保證資料一緻性所。

增量備份：

當我們做過全量備份以後會在目錄下産生xtrabackup_checkpoints的檔案 這裡面記錄了lsn和備份方式，我們可以基于這次的全量做增量的備份。

$cat xtrabackup_checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 1676085

last_lsn = 1676085

compact = 0

recover_binlog_info = 0

xtrabackup --backup --target-dir=/data/backup/inc1 --incremental-basedir=/data/backup/base

這個時候xtrabackup也是去打開了xtrabackup_checkpoints檔案進行上一次備份的資訊檢視。這個時候去檢視增量備份的xtrabackup_checkpoints也記錄了這些資訊

$cat xtrabackup_checkpoints 

backup_type = incremental

from_lsn = 1676085

to_lsn = 1676085

last_lsn = 1676085

compact = 0

recover_binlog_info = 0

這也意味着你可以在增量的備份上繼續增量的備份。

同樣的xtrabackup也支援壓縮（--compress）、加密（--encrypt）、并行(--parallel)等操作，但是和mysqlbackup不同的是這個沒有同時的備份binlog,而mysqlbackup是備份了binlog的。

我們來模拟一個恢複的過程深入的了解一下原理

檢視目前資料:

[email protected] 03:04:33>select * from t;

+------+

| id |

+------+

| 1 |

+------+

1 row in set (0.00 sec)

全量備份

$xtrabackup --backup --target-dir=/data/backup/base 

模拟增量資料

[email protected] 03:07:16>select * from t;

+------+

| id |

+------+

| 1 |

| 2 |

+------+

2 rows in set (0.00 sec)

進行增量備份：

$xtrabackup --backup --target-dir=/data/backup/inc1 --incremental-basedir=/data/backup/base

模拟無備份操作：

[email protected] 03:09:42>select * from t;

+------+

| id |

+------+

| 1 |

| 2 |

| 3 |

+------+

3 rows in set (0.00 sec)

模拟誤操作：

[email protected] 03:09:45>truncate table t;

Query OK, 0 rows affected (0.00 sec)

摸拟恢複操作：

step 1:找到誤操作的log position

[email protected] 03:10:19>show master logs;

[email protected] 03:10:47>show binlog events in 'mysql-bin.000001';

1333

我們需要分别對全量、增量備份各做一次prepare操作。

xtrabackup --prepare --apply-log-only --target-dir=/data/backup/base

增量

xtrabackup --prepare --apply-log-only --target-dir=/data/backup/base \

--incremental-dir=/data/backup/inc1

如果我們使用它自帶的還原指令的時候就要先把data目錄給清空。不然就會報如下的錯誤

$innobackupex --copy-back /data/backup/base/

170429 15:37:19 innobackupex: Starting the copy-back operation

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackupex

prints "completed OK!".

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)

Original data directory /u01/my3307/data is not empty!

當然我們大多資料時候是不會在原來的執行個體上做操作的，都會把相應的備份在奇他的執行個體上進行恢複，然後再導出導入到誤操作的執行個體。這裡我們直接清掉目錄，然後再次運作，檢視恢複後的資料：

[email protected] 03:41:56>select * from t;

+------+

| id |

+------+

| 1 |

| 2 |

+------+

2 rows in set (0.00 sec)

同樣的被恢複的目錄裡會多出來兩個檔案，一個是xtrabackup_binlog_pos_innodb，一個是xtrabackup_info。在這兩個檔案中都可以看到你最後的log,pos。在info裡還可以看到lsn。我們基于這個pos再進行binlog的重演，恢複在binlog沒有被備份的資料。

1076

$mysqlbinlog mysql-bin.000001 --start-position=1076 --stop-position=1333 -vv >increment.sql

[email protected] 03:51:25>source /u01/my3307/log/increment.sql

[email protected] 03:51:34>select * from t;

+------+

| id |

+------+

| 1 |

| 2 |

| 3 |

+------+

3 rows in set (0.00 sec)

至此資料恢複完成

https://www.percona.com/doc/percona-xtrabackup/LATEST/backup_scenarios/full_backup.html

深圳逆時針