XtraBackup 增量备份、恢复、原理

共计 22801 个字符，预计需要花费 58 分钟才能阅读完成。

整合了网上的一些资料，结合自己的理解，并进行了实验验证

理解一：

1，Xtrabackup 是什么

Xtrabackup 是一个对 InnoDB 做数据备份的工具，支持在线热备份(备份时不影响数据读写)，是商业备份工具 InnoDB Hotbackup 的一个很好的替代品。

Xtrabackup 有两个主要的工具：xtrabackup、innobackupex

（1）、xtrabackup 只能备份 InnoDB 和 XtraDB 两种数据表，而不能备份 MyISAM 数据表

（2）、innobackupex 是参考了 InnoDB Hotbackup 的 innoback 脚本修改而来的.innobackupex 是一个 perl 脚本封装，封装了 xtrabackup。主要是为了方便的同时备份 InnoDB 和 MyISAM 引擎的表，但

在处理 myisam 时需要加一个读锁。并且加入了一些使用的选项。如 slave-info 可以记录备份恢复后，作为 slave 需要的一些信息，根据这些信息，可以很方便的利用备份来重做 slave。

2，Xtrabackup 可以做什么 :

在线 (热) 备份整个库的 InnoDB、XtraDB 表

在 xtrabackup 的上一次整库备份基础上做增量备份(innodb only)

以流的形式产生备份，可以直接保存到远程机器上(本机硬盘空间不足时很有用)

MySQL 数据库本身提供的工具并不支持真正的增量备份，二进制日志恢复是 point-in-time(时间点)的恢复而不是增量备份。

Xtrabackup 工具支持对 InnoDB 存储引擎的增量备份，工作原理如下：

(1)首先完成一个完全备份，并记录下此时检查点的 LSN(Log Sequence Number)。

(2)在进程增量备份时，比较表空间中每个页的 LSN 是否大于上次备份时的 LSN，如果是，则备份该页，同时记录当前检查点的 LSN。

首先，在 xtrabackup_checkpoints 中找到并记录最后一个 checkpoint(“last checkpoint LSN”)，然后开始从 LSN 的位置开始拷贝 InnoDB 的 xtrabackup_checkpoints 到 xtrabackup_logfile；

接着，开始拷贝全部的数据文件.ibd；在拷贝全部数据文件结束之后，才停止拷贝 logfile。

因为 logfile 里面记录全部的数据修改情况，所以，即时在备份过程中数据文件被修改过了，恢复时仍然能够通过解析 xtrabackup_logfile 保持数据的一致。

理解二：

在备份的时候，备份工具主要执行两个任务来完成备份：

① 在后台启动一个日志拷贝线程。这个线程会监视 InnoDB 日志文件，当日志文件发生改变时，这个线程会将发生变化的数据块拷贝到备份目录下一个名为 xtrabackup_logfile 的文件中。这个

操作是必要的，因为备份可能会持续很长时间，在数据库恢复时，需要所有从备份开始到结束的这些日志文件。

② 拷贝 InnoDB 数据文件到指定备份目录下。这不是一个简单的拷贝，备份工具打开并读取文件的方式类似 InnoDB，通过读取文件目录并以页（page）为单位进行拷贝。

理解三：

backup 的恢复过程中包括恢复和还原两个部分。

先来看看完全备份集的恢复。

在 InnoDB 表的备份或者更直接的说 ibd 数据文件复制的过程中，数据库处于不一致的状态，所以要将 xtraback_logfile 中尚未提交的事务进行回滚，以及将已经提交的事务进行前滚，使各个数

据文件处于一个一致性状态，这个过程叫做“准备(prepare)”。

如果你是在一个从库上执行的备份，那说明你没有东西需要回滚，只是简单的 apply redo log 就可以了。另外在 prepare 过程中可以使用参数 –use-memory 增大使用系统内存量从而提高恢复速度。

对于增量备份的恢复过程，与完全备份集的恢复类似，只是有少许不同：

1)、恢复过程需要使用完全备份集和各个增量备份集，各个备份集的恢复与前面说的一样（前滚和回滚），之后各个增量备份集的 redo log 都会应用到完全备份集中；

2)、对于完全备机集之后产生的新表，要有特殊处理方式，以便恢复后不丢表；

3)、要以完全备份集为基础，然后按顺序应用各个增量备份集。

理解四：

完整备份的原理：

对于 InnoDB，XtraBackup 基于 InnoDB 的 crash-recovery 功能进行备份。

crash-recovery 是这样的：InnoDB 维护了一个 redo log，又称为 transaction log，也叫事务日志，它包含了 InnoDB 数据的所有改动情况。InnoDB 启动的时候先去检查 datafile 和 transaction log，然后应用所有已提交的事务并回滚所有未提交的事务。

XtraBackup 在备份的时候并不锁定表，而是一页一页地复制 InnoDB 的数据，与此同时，XtraBackup 还有另外一个线程监视着 transactions log，一旦 log 发生变化，就把变化过的 log pages 复制走(因为 transactions log 文件大小有限，写满之后，就会从头再开始写，新数据可能会覆盖到旧的数据，所以一旦变化就要立刻复制走）。在全部数据文件复制完成之后，停止复制 logfile。

XtraBackup 采用了其内置的 InnoDB 库以 read-write 模式打开 InnoDB 的数据文件，然后每次读写 1MB(1MB/16KB=64page)的数据，一页一页地遍历，同时用 InnoDB 的 buf_page_is_corrupted()函数检查此页的数据是否正常，如果正常则进行复制，如不正常则重新读取，最多重读 10 次，如果还是失败，则备份失败退出。复制 transactions log 的原理也是一样的，只不过每次读写 512KB(512KB/16KB=32page)的数据。

由于 XtraBackup 其内置的 InnoDB 库打开文件的时候是 rw 的，所以运行 XtraBackup 的用户，必须对 InnoDB 的数据文件具有读写权限。

由于 XtraBackup 要从文件系统中复制大量的数据，所以它尽可能地使用 posix_fadvise()，来告诉 OS 不要缓存读取到的数据(因为这些数据不会重用到了)，从而提升性能。如果要缓存的话，大

量的数据会对 OS 的虚拟内存造成很大的压力，其它进程（如 mysqld）很有可能会被 swap 出去，这样就出问题了。同时，XtraBackup 在读取数据的时候还尽可能地预读。

由于不锁表，所以复制出来的数据是不一致的，数据的一致性是在恢复的时候使用 crash-recovery 进行实现的。

对于 MyISAM,XtraBackup 还是首先锁定所有的表，然后复制所有文件。

理解五：

增量备份的原理：

在完整备份和增量备份文件中都有一个文件 xtrabackup_checkpoints 会记录备份完成时检查点的 LSN。在进行新的增量备份时，XtraBackup 会比较表空间中每页的 LSN 是否大于上次备份完成的

LSN，如果是，则备份该页，并记录当前检查点的 LSN。

innobackupex –apply-log：同 xtrabackup 的 –prepare 参数, 一般情况下, 在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步

至数据文件中的事务。因此，此时数据文件仍处理不一致状态。–apply-log 的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。

1、全备：

innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou /home/data/backup/full

innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou –host=172.30.1.110 /home/data/backup/full（可选，备份远程主机）

root@debian:/home/data/backup/full# innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou /home/data/backup/full

This software is published under

the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

Get the latest version of Percona XtraBackup, documentation, and help resources:

http://www.percona.com/xb/p

170306 16:16:49 innobackupex: Executing a version check against the server…

170306 16:16:49 innobackupex: Connecting to MySQL server with DSN ‘dbi:mysql:;mysql_read_default_file=/etc/mysql/my.cnf;mysql_read_default_group=xtrabackup’ as ‘root’

(using password: YES).

170306 16:16:49 innobackupex: Connected to MySQL server

170306 16:16:49 innobackupex: Done.

170306 16:16:49 innobackupex: Connecting to MySQL server with DSN ‘dbi:mysql:;mysql_read_default_file=/etc/mysql/my.cnf;mysql_read_default_group=xtrabackup’ as ‘root’

(using password: YES).

170306 16:16:49 innobackupex: Connected to MySQL server

170306 16:16:49 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

At the end of a successful backup run innobackupex

prints “completed OK!”.

innobackupex: Using server version 5.5.47-0+deb7u1-log

innobackupex: Created backup directory /home/data/backup/full/2017-03-06_16-16-49

170306 16:16:49 innobackupex: Starting ibbackup with command: xtrabackup –defaults-file=”/etc/mysql/my.cnf” –defaults-group=”mysqld” –backup –suspend-at-end —

target-dir=/home/data/backup/full/2017-03-06_16-16-49 –innodb_log_file_size=”5242880″ –innodb_data_file_path=”ibdata1:10M:autoextend” –tmpdir=/tmp –extra-

lsndir=’/tmp’

innobackupex: Waiting for ibbackup (pid=10845) to suspend

innobackupex: Suspend file ‘/home/data/backup/full/2017-03-06_16-16-49/xtrabackup_suspended_2’

xtrabackup version 2.2.13 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 70f4be3)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /var/lib/mysql

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = ./

xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 5242880

>> log scanned up to (31407794483)

xtrabackup: Generating a list of tablespaces

[01] Copying ./ibdata1 to /home/data/backup/full/2017-03-06_16-16-49/ibdata1

[01] …done

[01] Copying ./ZLECUBE/PO_Reverse_Box_Product_Relation.ibd to /home/data/backup/full/2017-03-06_16-16-49/ZLECUBE/PO_Reverse_Box_Product_Relation.ibd

[01] …done

[01] Copying ./ZLECUBE/PO_Box_RecvSend_Action_Item.ibd to /home/data/backup/full/2017-03-06_16-16-49/ZLECUBE/PO_Box_RecvSend_Action_Item.ibd

…

xtrabackup: Creating suspend file ‘/home/data/backup/full/2017-03-06_16-16-49/xtrabackup_suspended_2’ with pid ‘10846’

170306 16:18:13 innobackupex: Continuing after ibbackup has suspended

170306 16:18:13 innobackupex: Executing FLUSH NO_WRITE_TO_BINLOG TABLES…

170306 16:18:13 innobackupex: Executing FLUSH TABLES WITH READ LOCK…

170306 16:18:13 innobackupex: All tables locked and flushed to disk

170306 16:18:13 innobackupex: Starting to backup non-InnoDB tables and files

innobackupex: in subdirectories of ‘/var/lib/mysql/’

innobackupex: Backing up files ‘/var/lib/mysql//ZLECUBE/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}’ (234 files)

>> log scanned up to (31407794483)

innobackupex: Backing up files ‘/var/lib/mysql//mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}’ (72 files)

>> log scanned up to (31407794483)

innobackupex: Backing up file ‘/var/lib/mysql//test/bb.frm’

innobackupex: Backing up file ‘/var/lib/mysql//test/db.opt’

innobackupex: Backing up file ‘/var/lib/mysql//test/aa.frm’

innobackupex: Backing up files ‘/var/lib/mysql//performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}’ (18 files)

170306 16:18:14 innobackupex: Finished backing up non-InnoDB tables and files

170306 16:18:14 innobackupex: Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS…

170306 16:18:14 innobackupex: Waiting for log copying to finish

xtrabackup: The latest check point (for incremental): ‘31407794483’

xtrabackup: Stopping log copying thread.

.>> log scanned up to (31407794483)

xtrabackup: Creating suspend file ‘/home/data/backup/full/2017-03-06_16-16-49/xtrabackup_log_copied’ with pid ‘10846’

xtrabackup: Transaction log of lsn (31407794483) to (31407794483) was copied.

170306 16:18:15 innobackupex: All tables unlocked

innobackupex: Backup created in directory ‘/home/data/backup/full/2017-03-06_16-16-49’

170306 16:18:15 innobackupex: Connection to database server closed

170306 16:18:15 innobackupex: completed OK!

可以看到在备份完 innodb 的表之后，也开始备份非 innodb 的表，且同时会 lock table。

root@debian:/home/data/backup/full/2017-03-06_16-16-49# ls -l

total 18508

-rw-r–r– 1 root root 188 Mar 6 16:16 backup-my.cnf

-rw-r—– 1 root root 18874368 Mar 6 16:16 ibdata1

drwxr-xr-x 2 root root 4096 Mar 6 16:18 log

drwxr-xr-x 2 root root 4096 Mar 6 16:18 mysql

drwxr-xr-x 2 root root 4096 Mar 6 16:18 performance_schema

drwx—— 2 root root 4096 Mar 6 16:18 test

-rw-r—– 1 root root 97 Mar 6 16:18 xtrabackup_checkpoints

-rw-r–r– 1 root root 579 Mar 6 16:18 xtrabackup_info

-rw-r—– 1 root root 2560 Mar 6 16:18 xtrabackup_logfile

drwx—— 2 root root 40960 Mar 6 16:18 ZLECUBE

(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为 prepared 状态）和 LSN(日志序列号)范围信息；

每个 InnoDB 页 (通常为 16k 大小) 都会包含一个日志序列号，即 LSN。LSN 是整个数据库系统的系统版本号，每个页面相关的 LSN 能够表明此页面最近是如何发生改变的。

(2) xtrabackup_binlog_info —— mysql 服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

(若系统没开 binlog 则不会有这个文件)

(3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于 InnoDB 或 XtraDB 表的二进制日志文件的当前 position。

(4)xtrabackup_binary —— 备份中用到的 xtrabackup 的可执行文件；

(5)backup-my.cnf —— 备份命令用到的配置选项信息；

在使用 innobackupex 进行备份时，还可以使用 –no-timestamp 选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex 命令将会创建一个 BACKUP-DIR 目录来存储备份数据。

2. 全备恢复：准备 (prepare) 一个完全备份,

之后，我们就可以根据 backup-my.cnf 中的配置把数据文件复制回对应的目录了，当然你也可以自己复制回去，但 innobackupex 都会帮我们完成。在这里，对于 InnoDB 表来说是完成“后准备”

动作，我们称之为“恢复(recovery)”，而对于 MyISAM 表来说由于备份时是采用锁表方式复制的，所以此时只是简单的复制回来，不需要 apply log，这个我们称之为“还原(restore)”。

注：本文档里之所以使用恢复和还原，也是和其他数据库比如 Oracle 看起来一样。

需要停库，可以备份一下之前损坏的数据库。

cd /var/lib

mv mysql mysql.old

mkdir mysql

chown mysql.mysql mysql

一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态

。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

innobakupex 命令的 –apply-log 选项可用于实现上述功能。如下面的命令：

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log /home/data/backup/full/2017-03-06_16-16-49

在实现“准备”的过程中，innobackupex 通常还可以使用 –use-memory 选项来指定其可以使用的内存的大小，默认通常为 100M。如果有足够的内存可用，可以多划分一些内存给 prepare 的过程，以提高其完成速度。

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log –use-memory=5G /home/data/backup/full/2017-03-06_16-16-49

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log –use-memory=5G –host=172.30.1.110 /home/data/backup/full/2017-03-06_16-16-49（可选）

170213 17:14:06 innobackupex: Starting ibbackup with command: xtrabackup –defaults-file=”/home/data/backup/2017-02-13_17-11-22/backup-my.cnf” –defaults-

group=”mysqld” –prepare –target-dir=/home/data/backup/2017-02-13_17-11-22 –apply-log-only –use-memory=5G

xtrabackup: Starting InnoDB instance for recovery.

xtrabackup: Using 5368709120 bytes for buffer pool (set by –use-memory parameter)

InnoDB: Using atomics to ref count buffer pool pages

InnoDB: The InnoDB memory heap is disabled

InnoDB: Mutexes and rw_locks use GCC atomic builtins

InnoDB: Memory barrier is not used

InnoDB: Compressed tables use zlib 1.2.7

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, size = 5.0G

InnoDB: Completed initialization of buffer pool

InnoDB: Setting log file ./ib_logfile101 size to 5 MB

InnoDB: Setting log file ./ib_logfile1 size to 5 MB

InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0

InnoDB: New log files created, LSN=31405539763

InnoDB: Highest supported file format is Barracuda.

[notice (again)]

If you use binary log and don’t use any hack of group commit,

the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequence number 31405539852

170213 17:14:07 innobackupex: completed OK!

使用 copy-back 来恢复数据文件。

innobackupex –defaults-file=/etc/mysql/my.cnf –copy-back /home/data/backup/full/2017-03-06_15-31-05/

可以看到 innobackupex 在复制备份的文件到数据库的数据目录中

12g 的文件，很快就完成了，1 分钟左右。

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_15-31-05/ZLECUBE/BTC_Order_Base_Info.ibd’ to ‘/var/lib/mysql/ZLECUBE/BTC_Order_Base_Info.ibd’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_15-31-05/ZLECUBE/Rbac_base_role.ibd’ to ‘/var/lib/mysql/ZLECUBE/Rbac_base_role.ibd’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_15-31-05/ZLECUBE/Rbac_p_power_area_province_group.frm’ to

‘/var/lib/mysql/ZLECUBE/Rbac_p_power_area_province_group.frm’

innobackupex: Starting to copy InnoDB log files

innobackupex: in ‘/home/data/backup/full/2017-03-06_15-31-05’

innobackupex: back to original InnoDB log directory ‘/var/lib/mysql’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_15-31-05/ib_logfile0’ to ‘/var/lib/mysql/ib_logfile0’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_15-31-05/ib_logfile1’ to ‘/var/lib/mysql/ib_logfile1’

innobackupex: Finished copying back files.

170306 16:07:10 innobackupex: completed OK!

最后修改权限：

chown -R mysql.mysql /var/lib/mysql

启动数据库之后就可以了。

3 对完全备份的后数据库更改进行二进制日志增量备份：

3.1 查看全备：

cat xtrabackup_checkpoints

backup_type = full-prepared

from_lsn = 0

to_lsn = 31407798454

last_lsn = 31407798454

compact = 0

3.2 模拟数据库修改：

mysql -uroot -pleyou test

mysql> drop table aa;

Query OK, 0 rows affected (0.00 sec)

mysql> drop table bb;

Query OK, 0 rows affected (0.00 sec)

3.3 增量备份数据库：

innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou –incremental /home/data/backup/incr/ –incremental-basedir=/home/data/backup/full/2017-

03-06_16-44-09/ –parallel=2

root@debian:~# innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou –incremental /home/data/backup/incr/ –incremental-

basedir=/home/data/backup/full/2017-03-06_16-44-09/ –parallel=2

170306 17:04:08 innobackupex: Executing a version check against the server…

170306 17:04:08 innobackupex: Connecting to MySQL server with DSN ‘dbi:mysql:;mysql_read_default_file=/etc/mysql/my.cnf;mysql_read_default_group=xtrabackup’ as ‘root’

(using password: YES).

170306 17:04:08 innobackupex: Connected to MySQL server

170306 17:04:08 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

At the end of a successful backup run innobackupex

prints “completed OK!”.

innobackupex: Using server version 5.5.47-0+deb7u1-log

innobackupex: Created backup directory /home/data/backup/incr/2017-03-06_17-04-08

170306 17:04:08 innobackupex: Starting ibbackup with command: xtrabackup –defaults-file=”/etc/mysql/my.cnf” –defaults-group=”mysqld” –backup –suspend-at-end —

target-dir=/home/data/backup/incr/2017-03-06_17-04-08 –innodb_log_file_size=”5242880″ –innodb_data_file_path=”ibdata1:10M:autoextend” –tmpdir=/tmp –extra-

lsndir=’/tmp’ –incremental-basedir=’/home/data/backup/full/2017-03-06_16-44-09/’ –parallel=2

innobackupex: Waiting for ibbackup (pid=21857) to suspend

innobackupex: Suspend file ‘/home/data/backup/incr/2017-03-06_17-04-08/xtrabackup_suspended_2’

xtrabackup version 2.2.13 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 70f4be3)

incremental backup from 31407798454 is enabled.

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /var/lib/mysql

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = ./

xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 5242880

>> log scanned up to (31407804447)

xtrabackup: Generating a list of tablespaces

xtrabackup: using the full scan for incremental backup

xtrabackup: Starting 2 threads for parallel data files transfer

[01] Copying ./ibdata1 to /home/data/backup/incr/2017-03-06_17-04-08/ibdata1.delta

[02] Copying ./ZLECUBE/GA_GoodsArea_Info.ibd to /home/data/backup/incr/2017-03-06_17-04-08/ZLECUBE/GA_GoodsArea_Info.ibd.delta

[02] …done

[01] …done

[02] Copying ./ZLECUBE/SYS_Access_Authority_Info.ibd to /home/data/backup/incr/2017-03-06_17-04-08/ZLECUBE/SYS_Access_Authority_Info.ibd.delta

[02] …done

xtrabackup: Creating suspend file ‘/home/data/backup/incr/2017-03-06_17-04-08/xtrabackup_log_copied’ with pid ‘21858’

xtrabackup: Transaction log of lsn (31407804447) to (31407804447) was copied.

170306 17:04:33 innobackupex: All tables unlocked

…

innobackupex: Backup created in directory ‘/home/data/backup/incr/2017-03-06_17-04-08’

170306 17:04:33 innobackupex: Connection to database server closed

170306 17:04:33 innobackupex: completed OK!

root@debian:~#

du -m -s *

1 backup-my.cnf

4 ibdata1.delta

1 ibdata1.meta

1 log

2 mysql

1 performance_schema

1 test

1 xtrabackup_checkpoints

1 xtrabackup_info

1 xtrabackup_logfile

8 ZLECUBE

可以看到，增量备份的数据量很小。

root@debian:/home/data/backup/incr/2017-03-06_17-04-08# cat xtrabackup_checkpoints

backup_type = incremental

from_lsn = 31407798454

to_lsn = 31407804447

last_lsn = 31407804447

compact = 0

3.4 修改数据库，然后创建增量备份 2（这次是基于上次的增量备份）

mysql> create database test2;

Query OK, 1 row affected (0.00 sec)

innobackupex –defaults-file=/etc/mysql/my.cnf –user=root –password=leyou –incremental /home/data/backup/incr/ –incremental-basedir=/home/data/backup/incr/2017-

03-06_17-04-08/ –parallel=2

xtrabackup: Creating suspend file ‘/home/data/backup/incr/2017-03-06_17-14-16/xtrabackup_log_copied’ with pid ‘23367’

xtrabackup: Transaction log of lsn (31407804447) to (31407804447) was copied.

170306 17:14:25 innobackupex: All tables unlocked

innobackupex: Backup created in directory ‘/home/data/backup/incr/2017-03-06_17-14-16’

170306 17:14:25 innobackupex: Connection to database server closed

170306 17:14:25 innobackupex: completed OK!

也可以删除第二个备份，基于 /home/data/backup/incr/2017-03-06_17-04-08/ 重新备份

root@debian:/home/data/backup/incr# ls -lrt

total 8

drwxr-xr-x 7 root root 4096 Mar 6 17:04 2017-03-06_17-04-08

drwxr-xr-x 8 root root 4096 Mar 6 17:14 2017-03-06_17-14-16

root@debian:/home/data/backup/incr#

root@debian:/home/data/backup/incr# rm -rf 2017-03-06_17-14-16

root@debian:/home/data/backup/incr#

mysql> drop database test2;

Query OK, 0 rows affected (0.00 sec)

mysql> drop database test;

Query OK, 0 rows affected (0.00 sec)

mysql> \q

root@debian:/home/data/backup/incr/2017-03-06_17-17-54# cat xtrabackup_checkpoints

backup_type = incremental

from_lsn = 31407804447

to_lsn = 31407804447

last_lsn = 31407804447

compact = 0

3.5 增量备份恢复

增量备份的恢复大体为 3 个步骤

* 恢复完全备份

* 恢复增量备份到完全备份（开始恢复的增量备份要添加 –redo-only 参数，到最后一次增量备份去掉 –redo-only 参数）

* 对整体的完全备份进行恢复，回滚那些未提交的数据

恢复完全备份（注意这里一定要加 –redo-only 参数，该参数的意思是只应用 xtrabackup 日志中已提交的事务数据，不回滚还未提交的数据）

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log –redo-only /home/data/backup/full/2017-03-06_16-44-09/

[notice (again)]

If you use binary log and don’t use any hack of group commit,

the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequence number 31407802010

170306 17:30:37 innobackupex: completed OK!

将增量备份 1 应用到完全备份

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log –redo-only /home/data/backup/full/2017-03-06_16-44-09/ –incremental-dir=/home/data/backup/incr/2017-03-06_17-04-08/mary_by_event_name.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-04-08/performance_schema/events_waits_history.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/events_waits_history.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-04-08/performance_schema/file_instances.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/file_instances.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-04-08/performance_schema/mutex_instances.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/mutex_instances.frm’

170306 17:33:13 innobackupex: completed OK!

将增量备份 2 应用到完全备份（注意恢复最后一个增量备份时需要去掉 –redo-only 参数，回滚 xtrabackup 日志中那些还未提交的数据）

innobackupex –defaults-file=/etc/mysql/my.cnf –apply-log /home/data/backup/full/2017-03-06_16-44-09/ –incremental-dir=/home/data/backup/incr/2017-03-06_17-17-54/

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-17-54/performance_schema/file_summary_by_event_name.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-

09/performance_schema/file_summary_by_event_name.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-17-54/performance_schema/events_waits_history.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-

09/performance_schema/events_waits_history.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-17-54/performance_schema/file_instances.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-

09/performance_schema/file_instances.frm’

innobackupex: Copying ‘/home/data/backup/incr/2017-03-06_17-17-54/performance_schema/mutex_instances.frm’ to ‘/home/data/backup/full/2017-03-06_16-44-

09/performance_schema/mutex_instances.frm’

170306 17:37:42 innobackupex: completed OK!

此时两次增量备份其实都合并到全备上了, 恢复是只需要使用全备进行恢复就可以了

模拟数据故障[删除数据库的数据目录，执行如下命令还原]

innobackupex –defaults-file=/etc/mysql/my.cnf –copy-back /home/data/backup/full/2017-03-06_16-44-09/

innobackupex: Starting to copy files in ‘/home/data/backup/full/2017-03-06_16-44-09’

innobackupex: back to original data directory ‘/var/lib/mysql’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/xtrabackup_info’ to ‘/var/lib/mysql/xtrabackup_info’

innobackupex: Creating directory ‘/var/lib/mysql/ZLECUBE’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/ZLECUBE/Rbac_base_role_privilege_Backup_20160625.frm’ to

‘/var/lib/mysql/ZLECUBE/Rbac_base_role_privilege_Backup_20160625

…

ce.frm’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/file_summary_by_event_name.frm’ to

‘/var/lib/mysql/performance_schema/file_summary_by_event_name.frm’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/events_waits_history.frm’ to

‘/var/lib/mysql/performance_schema/events_waits_history.frm’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/file_instances.frm’ to ‘/var/lib/mysql/performance_schema/file_instances.frm’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/performance_schema/mutex_instances.frm’ to ‘/var/lib/mysql/performance_schema/mutex_instances.frm’

innobackupex: Starting to copy InnoDB system tablespace

innobackupex: in ‘/home/data/backup/full/2017-03-06_16-44-09’

innobackupex: back to original InnoDB data directory ‘/var/lib/mysql’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/ibdata1’ to ‘/var/lib/mysql/ibdata1’

innobackupex: Starting to copy InnoDB undo tablespaces

innobackupex: in ‘/home/data/backup/full/2017-03-06_16-44-09’

innobackupex: back to ‘/var/lib/mysql’

innobackupex: Starting to copy InnoDB log files

innobackupex: in ‘/home/data/backup/full/2017-03-06_16-44-09’

innobackupex: back to original InnoDB log directory ‘/var/lib/mysql’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/ib_logfile0’ to ‘/var/lib/mysql/ib_logfile0’

innobackupex: Copying ‘/home/data/backup/full/2017-03-06_16-44-09/ib_logfile1’ to ‘/var/lib/mysql/ib_logfile1’