甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
整合了网上的一些资料，结合自己的理解，并进行了实验验证
在太平等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计制作、网站设计 网站设计制作定制网站开发,公司网站建设,企业网站建设,高端网站设计,成都全网营销,外贸网站建设,太平网站建设费用合理。
理解一：
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
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.
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#
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'
innobackupex: Finished copying back files.
170307 15:11:51 innobackupex: completed OK!
root@debian:/var/lib#
chown -R mysql:mysql /var/lib/mysql/
root@debian:/var/lib# /etc/init.d/mysql restart
root@debian:/var/lib# mysql -uroot -pleyou
mysql>
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| ZLECUBE |
| log |
| mysql |
| performance_schema |
| test |
+--------------------+
6 rows in set (0.00 sec)
mysql> use test;
Database changed
mysql> show tables;
Empty set (0.00 sec)
mysql>