xtrabackup备份软件

ゝ一纸荒年。 2022-05-10 07:00 284阅读 0赞

percona公司官网 [https://www.percona.com/][https_www.percona.com]  
![在这里插入图片描述][70]

#### Xtrabackup介绍 ####

Xtrabackup是由percona开源的免费数据库热备份软件，它能对InnoDB数据库和XtraDB存储引擎的数据库非阻塞地备份（对于MyISAM的备份同样需要加表锁）；mysqldump备份方式是采用的逻辑备份，其最大的缺陷是备份和恢复速度较慢，如果数据库大于50G，mysqldump备份就不太适合。  
Xtrabackup安装完成后有4个可执行文件，其中2个比较重要的备份工具是innobackupex、xtrabackup

*  1）xtrabackup 是专门用来备份InnoDB表的，和mysql server没有交互；
 *  2）innobackupex 是一个封装xtrabackup的Perl脚本，支持同时备份innodb和myisam，但在对myisam备份时需要加一个全局的读锁。
 *  3）xbcrypt 加密解密备份工具
 *  4）xbstream 流传打包传输工具，类似tar
 *  5）物理备份工具，在同级数据量基础上，都要比逻辑备份性能好的多，特别是在数据量较大的时候，体现的更加明显。

#### Xtrabackup优点 ####

*  1）备份速度快，物理备份可靠
 *  2）备份过程不会打断正在执行的事务（无需锁表）
 *  3）能够基于压缩等功能节约磁盘空间和流量
 *  4）自动备份校验
 *  5）还原速度快
 *  6）可以流传将备份传输到另外一台机器上
 *  7）在不增加服务器负载的情况备份数据
 *  8）物理备份工具，在同级数据量基础上，都要比逻辑备份性能要好的多。几十G到不超过TB级别的条件下。但在同数据量级别，物理备份恢复数据上有一定优势。

#### 备份原理 ####

拷贝数据文件、拷贝数据页

###### 对于innodb表可以实现热备。 ######

*  (1)在数据库还有修改操作的时刻，直接将数据文件备走，此时，备份走的数据对于当前mysql来讲是不一致的。
 *  (2)将备份过程中的redo和undo一并备走。
 *  (3)为了恢复的时候，只要保证备份出来的数据页lsn能和redo lsn匹配，将来恢复的就是一致的数据。redo应用和undo应用。

###### 对于myisam表实现自动锁表拷贝文件。 ######

备份开始时首先会开启一个后台检测进程，实时检测mysql redo的变化，一旦发现有新的日志写入，立刻将日志记入后台日志文件xtrabackup\_log中，之后复制innodb的数据文件一系统表空间文件ibdatax，复制结束后，将执行flush tables with readlock,然后复制.frm MYI MYD等文件，最后执行unlock tables,最终停止xtrabackup\_log

#### xtrabackup的安装 ####

###### 安装依赖关系 ######

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
    yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL

###### 下载软件包，并安装软件 ######

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm
    yum -y install percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

针对centos6.5环境下安装xtrabackup报错Requires:libev.so

下载libev
    wget ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm
    安装:
    rpm -ivh libev-4.15-1.el6.rf.x86_64.rpm 
    #重新安装
    yum -y install percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

#### xtrabackup实践操作 ####

全量备份与恢复  
这一阶段会启动xtrabackup内嵌的innodb实例，回放xtrabackup日志xtrabackup\_log，将提交的事务信息变更应用到innodb数据/表空间，同时回滚未提交的事务(这一过程类似innodb的实例恢复）。恢复过程如下图：  
![在这里插入图片描述][70 1]

###### 备份 ######

创建备份目录

mkdir  /backup -p

进行第一次全量备份

innobackupex --defaults-file=/etc/my.cnf --user=root --password=123 --socket=/application/mysql/tmp/mysql.sock --no-timestamp /backup/xfull
    #针对某些库备份：
    innobackupex --defaults-file=/etc/my.cnf --user=root --password=123   --databases="test1 test2 test3"  --no-timestamp /backup/xfull

###### 恢复前准备 ######

恢复数据前的准备(合并xtabackup\_log\_file和备份的物理文件)

innobackupex --apply-log --use-memory=32M /backup/xfull/

查看合并后的 checkpoints 其中的类型变为 full-prepared 即为可恢复。

[root@db02 full]# cat xtrabackup_checkpoints 
    backup_type = full-prepared
    from_lsn = 0
    to_lsn = 4114824
    last_lsn = 4114824
    compact = 0
    recover_binlog_info = 0

破坏数据库数据文件

[root@db02 full]# cd /application/mysql/data/
    [root@db02 data]# ls
    auto.cnf  db02.pid  ibdata2      mysql             mysql-bin.index     world
    clsn      haha      ib_logfile0  mysql-bin.000001  oldboy
    db02.err  ibdata1   ib_logfile1  mysql-bin.000002  performance_schema
    [root@db02 data]# \rm -rf ./* 
    [root@db02 data]# ls
    [root@db02 data]# killall mysql

###### 恢复方法 ######

方法一:直接将备份文件复制回来

cp -a /backup/full/ /application/mysql/data
    chown -R mysql.mysql /application/mysql/data

方法二:使用innobackupex命令进行恢复(推荐)

[root@db02 mysql]# innobackupex --copy-back /backup/xfull
    [root@db02 mysql]# chown -R mysql.mysql /application/mysql/

说明：无论使用那种恢复方法都要恢复后需改属组属主，保持与程序一致。

[root@db02 data]# cd /application/mysql/data/
    [root@db02 data]# ls
    clsn     ibdata2      ibtmp1  performance_schema            xtrabackup_info
    haha     ib_logfile0  mysql   world
    ibdata1  ib_logfile1  oldboy  xtrabackup_binlog_pos_innodb

启动是数据库

[root@db02 data]#  /etc/init.d/mysqld start

#### 增量备份与恢复 ####

innobackupex增量备份过程中的"增量"处理，其实主要是相对innodb而言，对myisam和其他存储引擎而言，它仍然是全拷贝(全备份)

“增量"备份的过程主要是通过拷贝innodb中有变更的"页”（这些变更的数据页指的是"页"的LSN大于xtrabackup\_checkpoints中给定的LSN）。增量备份是基于全备的，第一次增备的数据必须要基于上一次的全备，之后的每次增备都是基于上一次的增备，最终达到一致性的增备。增量备份的过程如下，和全备的过程很类似，区别仅在第2步。  
![在这里插入图片描述][70 2]

###### 增量备份从哪增量？ ######

基于上一次的备份进行增量。  
redo默认情况下是一组两个文件，并且有固定大小。其使用的文件是一种轮询使用方式，他不是永久的，文件随时可能被覆盖。  
注意：千万不要在业务繁忙时做备份。

##### 备份什么内容 #####

1、可以使用binlog作为增量  
2、自带的增量备份，基于上次备份后的变化的数据页，还要备份在备份过程中的undo、redo变化

###### 怎么备份 ######

1、先进行第一次全备

innobackupex  --user=root --password=123 --no-timestamp /bakcup/xfull

对原库做了修改，修改了小红那行然后commit。  
2、再进行增量备份

innobackupex --user=root --password=123  --incremental --no-timestamp --incremental-basedir=/backup/xfull/  /backup/xinc1

###### 怎么恢复 ######

![在这里插入图片描述][70 3]  
1、先应用全备日志（–apply-log，暂时不需要做回滚操作–redo-only）

innobackupex --apply-log --redo-only /backup/xfull/

2、合并增量到全备中（一致性的合并）

innobackupex --apply-log --incremental-dir=/backup/xinc1 /backup/xfull/
    innobackupex --apply-log /backup/xfull

3、合并完成进行恢复  
方法一:直接将备份文件复制回来

cp -a /backup/full/ /application/mysql/data
    chown -R mysql.mysql /application/mysql/data

方法二:使用innobackupex命令进行恢复(推荐)

[root@db02 mysql]# innobackupex --copy-back /backup/xfull
    [root@db02 mysql]# chown -R mysql.mysql /application/mysql/

说明：无论使用那种恢复方法都要恢复后需改属组属主，保持与程序一致。

#### 数据库备份策略 ####

每周的周日进行一次全备；周一到周六每天做上一天增量，每周轮询一次。

xfull       --apply-log --redo-only   保证last-lsn=周一增量开始lsn
    xinc1        合并周一的增量到全备，并apply-log --redo-only  保证last-lsn=周二增量开始lsn
    xinc2        合并周二的增量到全备，并apply-log --redo-only  保证last-lsn=周三增量开始lsn
    xinc3       合并周三的增量到全备，并apply-log --redo-only  保证last-lsn=周四增量开始lsn
    xinc4       合并周四的增量到全备，并apply-log --redo-only  保证last-lsn=周五增量开始lsn
    xinc5       合并周五的增量到全备，并apply-log --redo-only  保证last-lsn=周六增量开始lsn
    xinc6        合并周六的增量到全备，--apply-log  准备恢复即可

#### 真实生产实战案例分析 ####

背景：某物流公司网站核心系统，数据量是220G，每日更新量100M-200M  
备份方案： xtrabackup全备+增量  
备份策略（crontab）：  
1、周六 晚上0点全备

0 0 * * 6 zjs_full.sh

2、周一至周五、周日 是增量，基于上一天增量

0 1 * * 0-5 zjs_inc.sh

###### 故障场景： ######

周三的时候，下午两点，开发人员误删除了一张表zjs\_base，大约10G。  
项目职责：

1.  指定恢复方案、利用现有备份;
2.  恢复误删除数据;
3.  制定运维、开发流程规范。

###### 恢复流程： ######

*  a) 准备上周六全备。
 *  b) 合并周日、周一 、周二增量。
 *  c) 在测试库恢复以上数据，数据的目前状态应该周三凌晨1:00
 *  d) 需要恢复的数据状态是，下午2点钟左右
 *  e) 从1点开始的binlog恢复到删除之前转台
 *  f) 导出删除的表zjs\_base，恢复到生产库，验证数据可用性、完整性。
 *  g) 启动应用连接数据库。  
    总结：经过30分钟将误删表恢复了。服务总共停止40分钟。

#### 故障恢复小结 ####

###### 恢复思路： ######

1、首先确保断开所有应用，保证数据的安全。  
2、检查用于恢复的备份存在吗。  
3、设计快速、安全恢复简单方案，制定突发问题解决办法。

###### 具体恢复流程： ######

*  1、准备上周六全备，并–apply-log --redo-only
 *  2、合并增量，周日、周一 、周二 --apply-log --redo-only 周三 --apply-log
 *  3、在测试库恢复以上数据，数据的目前状态应该周三凌晨1:00
 *  4、需要恢复的数据状态是，下午2点钟左右，删除zjs\_base之前的数据状态从1点开始的binlog恢复到删除之前的那个events的position。
 *  5、导出删除的表zjs\_base，恢复到生产库，验证数据可用性、完整性。
 *  6、启动应用连接数据库。

##### 确定恢复所需时间 #####

恢复窗口要多长？----> 预计3小时  
和你恢复+验证+意外情况有关。  
业务停多长时间？----> 6小时？或者更多？更少？

#### 【模拟】生产事故恢复 ####

数据创建阶段  
1、创建备份需要的目录

mkdir full  inc1 inc2

2、周日全备

innobackupex --user=root --password=123 --no-timestamp /backup/xbackup/full/

3、模拟数据变化

use oldboy
    create table test(id int,name char(20),age int);
    insert into test values(8,'outman',99);
    insert into test values(9,'outgirl',100);
    commit;

4、周一增量备份

innobackupex --user=root --password=123 --incremental --no-timestamp --incremental-basedir=/backup/xbackup/full/ /backup/xbackup/inc1

5、模拟数据变化

use oldboy
    insert into test values(8,'outman1',119);
    insert into test values(9,'outgirl1',120);
    commit;

6、周二的增量备份

innobackupex --user=root --password=123 --incremental --no-timestamp --incremental-basedir=/backup/xbackup/inc1 /backup/xbackup/inc2

1.  再插入新的行操作

use oldboy
    insert into test values(10,'outman2',19);
    insert into test values(11,'outgirl2',10);
    commit;

#### 模拟误操作事故 ####

模拟场景，周二下午2点误删除test表

use oldboy;
        drop table test;

#### 准备恢复数据 ####

1.准备xtrabackup备份，合并备份

innobackupex --apply-log --redo-only /backup/xbackup/full
    innobackupex --apply-log --redo-only --incremental-dir=/backup/xbackup/inc1 /backup/xbackup/full
    innobackupex --apply-log  --incremental-dir=/backup/xbackup/inc2 /backup/xbackup/full
    innobackupex --apply-log /backup/xbackup/full

2．确认binlog起点，准备截取binlog。

cd /backup/xbackup/inc2/
     cat xtrabackup_binlog_info 
     mysql-bin.000001    1121

3.截取到drop操作之前的binlog

mysqlbinlog  --start-position=1121 /tmp/mysql-bin.000003 
        找到drop之前的event和postion号做日志截取，假如 1437
        mysqlbinlog  --start-position=1121 --stop-position=1437    /tmp/mysql-bin.000003 >/tmp/incbinlog.sql

4．关闭数据库、备份二进制日志

/etc/init.d/mysqld stop
    cd /application/mysql/data/
    cp mysql-bin.000001 /tmp

5.删除MySQL所有数据

cd /application/mysql/data/
    rm -rf *

#### 恢复数据 ####

1．将全量备份的数据恢复到数据目录下

innobackupex --copy-back /backup/xbackup/full/
    chown -R mysql.mysql /application/mysql/data/
    /etc/init.d/mysqld start

2.恢复binlog记录

set sql_log_bin=0
    source /tmp/incbinlog.sql

#### xtarbackup导出 ####

(1)“导出”表 导出表是在备份的prepare阶段进行的，因此，一旦完全备份完成，就可以在prepare过程中通过–export选项将某表导出了：

innobackupex --apply-log --export /path/to/backup

此命令会为每个innodb表的表空间创建一个以.exp结尾的文件，这些以.exp结尾的文件则可以用于导入至其它服务器。  
(2)“导入”表 要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入：

mysql> CREATE TABLE mytable (...)  ENGINE=InnoDB;

然后将此表的表空间删除：

mysql> ALTER TABLE mydatabase.mytable  DISCARD TABLESPACE;

接下来，将来自于“导出”表的服务器的mytable表的mytable.ibd和mytable.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：(记得改权限)

mysql> ALTER TABLE mydatabase.mytable  IMPORT TABLESPACE;

#### 示例: ####

innobackupex --user=root --password=123 --no-timestamp /backup/xbackup/full/

进入到全备的数据库目录下

[root@db02 haha]# ls
    db.opt  PENALTIES.frm  PENALTIES.ibd  PLAYERS.frm  PLAYERS.ibd
    [root@db02 haha]# pwd
    /backup/xbackup/full/haha

导出表

[root@db02 haha]# innobackupex --apply-log --export /backup/xbackup/full/  
    [root@db02 haha]# ls
    db.opt         PENALTIES.exp  PENALTIES.ibd  PLAYERS.exp  PLAYERS.ibd
    PENALTIES.cfg  PENALTIES.frm  PLAYERS.cfg    PLAYERS.frm

创建出同结构表

CREATE TABLE `PLAYERS` (
      `PLAYERNO` int(11) NOT NULL,
      `NAME` char(15) NOT NULL,
      `INITIALS` char(3) NOT NULL,
      `BIRTH_DATE` date DEFAULT NULL,
      `SEX` char(1) NOT NULL,
      `JOINED` smallint(6) NOT NULL,
      `STREET` varchar(30) NOT NULL,
      `HOUSENO` char(4) DEFAULT NULL,
      `POSTCODE` char(6) DEFAULT NULL,
      `TOWN` varchar(30) NOT NULL,
      `PHONENO` char(13) DEFAULT NULL,
      `LEAGUENO` char(4) DEFAULT NULL,
      PRIMARY KEY (`PLAYERNO`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8

复制恢复数据到库下

[root@db02 haha]# cp  PLAYERS.ibd  PLAYERS.exp  /application/mysql/data/backup/
    cp: overwrite `/application/mysql/data/backup/PLAYERS.ibd'? y

恢复数据

mysql> ALTER TABLE backup.PLAYERS  DISCARD TABLESPACE;
    Query OK, 0 rows affected (0.00 sec)

#### innobackupex参数说明 ####

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>参数说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>–compress</td> 
   <td>该选项表示压缩innodb数据文件的备份。</td> 
  </tr> 
  <tr> 
   <td>–compress-threads</td> 
   <td>该选项表示并行压缩worker线程的数量。</td> 
  </tr> 
  <tr> 
   <td>–compress-chunk-size</td> 
   <td>该选项表示每个压缩线程worker buffer的大小，单位是字节，默认是64K。</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>–encrypt</td> 
   <td>该选项表示通过ENCRYPTION_ALGORITHM的算法加密innodb数据文件的备份，目前支持的算法有ASE128,AES192,AES256。</td> 
  </tr> 
  <tr> 
   <td>–encrypt-threads</td> 
   <td>该选项表示并行加密的worker线程数量。</td> 
  </tr> 
  <tr> 
   <td>–encrypt-chunk-size</td> 
   <td>该选项表示每个加密线程worker buffer的大小，单位是字节，默认是64K。</td> 
  </tr> 
  <tr> 
   <td>–encrypt-key</td> 
   <td>该选项使用合适长度加密key，因为会记录到命令行，所以不推荐使用。</td> 
  </tr> 
  <tr> 
   <td>–encryption-key-file</td> 
   <td>该选项表示文件必须是一个简单二进制或者文本文件，加密key可通过以下命令行命令生成：openssl rand -base64 24。</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>–include</td> 
   <td>该选项表示使用正则表达式匹配表的名字[db.tb]，要求为其指定匹配要备份的表的完整名称，即databasename.tablename。</td> 
  </tr> 
  <tr> 
   <td>–user</td> 
   <td>该选项表示备份账号。</td> 
  </tr> 
  <tr> 
   <td>–password</td> 
   <td>该选项表示备份的密码。</td> 
  </tr> 
  <tr> 
   <td>–port</td> 
   <td>该选项表示备份数据库的端口。</td> 
  </tr> 
  <tr> 
   <td>–host</td> 
   <td>该选项表示备份数据库的地址。</td> 
  </tr> 
  <tr> 
   <td>–databases</td> 
   <td>该选项接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开；如：“xtra_test dba_test”，同时，在指定某数据库时，也可以只指定其中的某张表。如：“mydatabase.mytable”。该选项对innodb引擎表无效，还是会备份所有innodb表。此外，此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象。</td> 
  </tr> 
  <tr> 
   <td>–tables-file</td> 
   <td>该选项表示指定含有表列表的文件，格式为database.table，该选项直接传给–tables-file。</td> 
  </tr> 
  <tr> 
   <td>–socket</td> 
   <td>该选项表示mysql.sock所在位置，以便备份进程登录mysql。</td> 
  </tr> 
  <tr> 
   <td>–no-timestamp</td> 
   <td>该选项可以表示不要创建一个时间戳目录来存储备份，指定到自己想要的备份文件夹。</td> 
  </tr> 
  <tr> 
   <td>–ibbackup</td> 
   <td>该选项指定了使用哪个xtrabackup二进制程序。IBBACKUP-BINARY是运行percona xtrabackup的命令。这个选项适用于xtrbackup二进制不在你是搜索和工作目录，如果指定了该选项,innoabackupex自动决定用的二进制程序</td> 
  </tr> 
  <tr> 
   <td>–slave-info</td> 
   <td>该选项表示对slave进行备份的时候使用，打印出master的名字和binlog pos，同样将这些信息以change master的命令写入xtrabackup_slave_info文件。可以通过基于这份备份启动一个从库。</td> 
  </tr> 
  <tr> 
   <td>–safe-slave-backup</td> 
   <td>该选项表示为保证一致性复制状态，这个选项停止SQL线程并且等到show status中的slave_open_temp_tables为0的时候开始备份，如果没有打开临时表，bakcup会立刻开始，否则SQL线程启动或者关闭知道没有打开的临时表。如果slave_open_temp_tables在–safe-slave-backup-timeount （默认300秒）秒之后不为0，从库sql线程会在备份完成的时候重启。</td> 
  </tr> 
  <tr> 
   <td>–kill-long-queries-timeout</td> 
   <td>该选项表示从开始执行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的这些查询之间等待的秒数。默认值为0，不会kill任何查询，使用这个选项xtrabackup需要有Process和super权限。</td> 
  </tr> 
  <tr> 
   <td>–kill-long-query-type</td> 
   <td>该选项表示kill的类型，默认是all，可选select。</td> 
  </tr> 
  <tr> 
   <td>–ftwrl-wait-threshold</td> 
   <td>该选项表示检测到长查询，单位是秒，表示长查询的阈值。</td> 
  </tr> 
  <tr> 
   <td>–ftwrl-wait-query-type</td> 
   <td>该选项表示获得全局锁之前允许那种查询完成，默认是ALL，可选update。</td> 
  </tr> 
  <tr> 
   <td>–galera-info</td> 
   <td>该选项表示生成了包含创建备份时候本地节点状态的文件xtrabackup_galera_info文件，该选项只适用于备份PXC。</td> 
  </tr> 
  <tr> 
   <td>–stream</td> 
   <td>该选项表示流式备份的格式，backup完成之后以指定格式到STDOUT，目前只支持tar和xbstream。</td> 
  </tr> 
  <tr> 
   <td>–defaults-file</td> 
   <td>该选项指定了从哪个文件读取MySQL配置，必须放在命令行第一个选项的位置。</td> 
  </tr> 
  <tr> 
   <td>–defaults-extra-file</td> 
   <td>该选项指定了在标准defaults-file之前从哪个额外的文件读取MySQL配置，必须在命令行的第一个选项的位置。一般用于存备份用户的用户名和密码的配置文件。</td> 
  </tr> 
  <tr> 
   <td>----defaults-group</td> 
   <td>该选项表示从配置文件读取的组，innobakcupex多个实例部署时使用。</td> 
  </tr> 
  <tr> 
   <td>–no-lock</td> 
   <td>该选项表示关闭FTWRL的表锁，只有在所有表都是Innodb表并且不关心backup的binlog pos点，如果有任何DDL语句正在执行或者非InnoDB正在更新时（包括mysql库下的表），都不应该使用这个选项，后果是导致备份数据不一致，如果考虑备份因为获得锁失败，可以考虑–safe-slave-backup立刻停止复制线程。</td> 
  </tr> 
  <tr> 
   <td>–tmpdir</td> 
   <td>该选项表示指定–stream的时候，指定临时文件存在哪里，在streaming和拷贝到远程server之前，事务日志首先存在临时文件里。在使用参数stream=tar备份的时候，你的xtrabackup_logfile可能会临时放在/tmp目录下，如果你备份的时候并发写入较大的话 xtrabackup_logfile可能会很大(5G+)，很可能会撑满你的/tmp目录，可以通过参数–tmpdir指定目录来解决这个问题。</td> 
  </tr> 
  <tr> 
   <td>–history</td> 
   <td>该选项表示percona server 的备份历史记录在percona_schema.xtrabackup_history表。</td> 
  </tr> 
  <tr> 
   <td>–incremental</td> 
   <td>该选项表示创建一个增量备份，需要指定–incremental-basedir。</td> 
  </tr> 
  <tr> 
   <td>–incremental-basedir</td> 
   <td>该选项表示接受了一个字符串参数指定含有full backup的目录为增量备份的base目录，与–incremental同时使用。</td> 
  </tr> 
  <tr> 
   <td>–incremental-dir</td> 
   <td>该选项表示增量备份的目录。</td> 
  </tr> 
  <tr> 
   <td>–incremental-force-scan</td> 
   <td>该选项表示创建一份增量备份时，强制扫描所有增量备份中的数据页。</td> 
  </tr> 
  <tr> 
   <td>–incremental-lsn</td> 
   <td>该选项表示指定增量备份的LSN，与–incremental选项一起使用。</td> 
  </tr> 
  <tr> 
   <td>–incremental-history-name</td> 
   <td>该选项表示存储在PERCONA_SCHEMA.xtrabackup_history基于增量备份的历史记录的名字。Percona Xtrabackup搜索历史表查找最近（innodb_to_lsn）成功备份并且将to_lsn值作为增量备份启动出事lsn.与innobackupex–incremental-history-uuid互斥。如果没有检测到有效的lsn，xtrabackup会返回error。</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>–incremental-history-uuid</td> 
   <td>该选项表示存储在percona_schema.xtrabackup_history基于增量备份的特定历史记录的UUID。</td> 
  </tr> 
  <tr> 
   <td>–close-files</td> 
   <td>该选项表示关闭不再访问的文件句柄，当xtrabackup打开表空间通常并不关闭文件句柄目的是正确的处理DDL操作。如果表空间数量巨大，这是一种可以关闭不再访问的文件句柄的方法。使用该选项有风险，会有产生不一致备份的可能。</td> 
  </tr> 
  <tr> 
   <td>–compact</td> 
   <td>该选项表示创建一份没有辅助索引的紧凑的备份。</td> 
  </tr> 
  <tr> 
   <td>–throttle</td> 
   <td>该选项表示每秒IO操作的次数，只作用于bakcup阶段有效。apply-log和–copy-back不生效不要一起用。</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

转载：[https://www.cnblogs.com/clsn/p/8138015.html\#auto\_id\_35][https_www.cnblogs.com_clsn_p_8138015.html_auto_id_35]

[https_www.percona.com]: https://www.percona.com/
[70]: /images/20220510/87d48a25bf0d4488b97379798d00b033.png
[70 1]: /images/20220510/4ac9714cb3d74ed3b59f341aff092320.png
[70 2]: /images/20220510/3078a0365ebd45de8e9690e6aeb68ea0.png
[70 3]: /images/20220510/13b45391e74a46fbb38fc4aa4a4df252.png
[https_www.cnblogs.com_clsn_p_8138015.html_auto_id_35]: https://www.cnblogs.com/clsn/p/8138015.html#auto_id_35