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

深圳逆时针