使用开源级PXB（Percona Xtrabackup）进行数据库物理备份与恢复

上节介绍的MEB工具不仅功能强大、性能佳，而且适用场景也非常广泛。但是，MEB是企业级软件，这就意味着其需要付费才能使用。对于活跃于开源社区的用户而言，单为使用MEB付费可能有点令人难以接受。那市面上是否存在可以媲美或功能接近MEB的开源软件呢？本节将对标MEB，重点介绍作为开源解决方案的PXB，为大家提供更多选择。PXB软件介绍PXB概述PXB（Percona Xtrabackup）是一款开源的

li815517253

372人浏览 · 2022-11-15 15:33:48

li815517253 · 2022-11-15 15:33:48

PXB软件介绍

PXB概述

PXB（Percona Xtrabackup）是一款开源的备份工具，其支持InnoDB、MyISAM、XtraDB等存储引擎数据的在线热备。其特点是备份速度快，对InnoDB型业务数据几乎没有任何影响，对MyISAM型数据会暂时性锁表。通常，PXB软件部署包含三种常见方式，分别是RPM包、二进制包及源码编译安装等。PXB可提供在系统运行时执行的MySQL数据热备份的方法。它是一个免费的、在线的、开源的、完整的数据库备份解决方案，适用于MySQL所有版本的服务器。无论是7×24小时高负载的服务器，还是低事务量的环境，PXB都旨在使备份成为无缝的过程，并且基本上不会影响生产环境中服务器的性能。

PXB支持MySQL、MariaDB和Percona等数据库。PXB可以在备份结束时通过短暂的暂停写来备份以下存储引擎MyISAM、Merge和Archive，但不支持MyRocks或TokuDB存储引擎。由于MySQL 8.0在数据字典、重做日志和撤消日志中引入的更改与之前的版本不兼容，因此Percona XtraBackup 8.0目前还不能支持8.0之前的版本。因此，本节笔者将重点介绍PXB 8.0的前一个版本Percona XtraBackup 2.4.18。它既可以在MySQL 5.1、5.5、5.6和5.7服务器上备份InnoDB、XtraDB和MyISAM表中的数据，也可以在Percona服务器上备份XtraDB。

注意：innobackupex工具已经过期，Percona XtraBackup 2.4.18版本保留此程序主要是为了向下兼容，并在将来的版本中弃用，请使用XtraBackup工具执行数据的备份与恢复任务。

下载PXB介质包并安装

Percona Xtrabackup是Percona旗下的一款开源软件，直接登录Percona官网即可下载，下载界面如图6-2所示。

PXB备份工具的安装需要用到很多依赖包，其中，OS介质中默认不包含libev包，需要从开源RPM网站下载并安装。具体请在rpmfind.net的RPM资料库中找到Linux 7上额外的依赖包libev，点击下载并安装。参考链接：http://rpmfind.net/linux/rpm2html/search.php。

shell> yum install -y perl-Digest-MD5 perl-DBD-MySQL rsync

shell> rpm -ivh libev-4.15-3.el7.x86_64.rpm

shell> rpm -ivh percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm

创建PXB备份账户

PXB需要能够连接到MySQL并在服务器上执行操作。无论是使用XtraBackup还是InnoBackupex，都涉及两个参与者：操作系统账户和数据库账户。注意，即便操作系统账户和数据库账户可能拥有相同的用户名，它们也是不同层面的不同用户。XtraBackup的“--user”和“--password”选项可用于指定连接到MySQL服务器的数据库用户及其密码。对于复杂场景，必须指定正确的连接参数，以便XtraBackup与正确的MySQL实例进行通信。为了能够正常执行备份，还需要检查MySQL数据目录的读取和执行权限。

创建完整备份所需的最低的数据库账户权限示例代码如下：

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret';

mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';

mysql> FLUSH PRIVILEGES;

PXB工作原理概述

首先，我们需要了解PXB的工作原理。PXB大致可以分为三个阶段，分别是备份（backup）、准备（prepare）和恢复（copy-backup）。

1.备份阶段

PXB的备份与恢复功能主要是基于InnoDB的崩溃恢复功能。它会复制InnoDB数据文件，而这又会导致数据内部不一致的问题；然后，它会对文件执行崩溃恢复，使它们再次成为一致的、可用的数据库。InnoDB维护了一个重做日志，也称为事务日志。它记录了对InnoDB数据的每次更改。启动InnoDB时，它会检查数据文件和事务日志，并将提交的事务日志条目应用于数据文件，并对所有修改了数据但没有提交的事务执行撤消操作。

PXB在启动时会标记InnoDB日志序列号（LSN），然后复制数据文件。这个过程需要一些时间，因此如果文件正在进行更改，那么日志序列号将反映数据库处于不同时间点的状态。同时，PXB运行一个后台进程，该进程可用于监视事务日志文件，并从其中复制更改信息，并且需要不断地这样做。因为事务日志是以循环的方式编写的，并且可以在一段时间后重用PXB需要的事务日志记录，以记录自开始执行以来每次对数据文件所做的更改。

只有当PXB备份完所有InnoDB或XtraDB数据和日志后，才会对MyISAM和其他非InnoDB表进行锁定。PXB将在可用的地方使用备份锁，作为使用读锁刷新表的轻量级替代。PXB可以使用它来自动复制非InnoDB数据，以避免阻塞修改InnoDB表的DML查询。当服务器支持备份锁时，XtraBackup将首先复制InnoDB数据，运行用于备份的锁表，然后再复制MyISAM表和以“.frm”为后缀的文件。

接下来备份以.frm、.MRG、.MYD、.MYI、.TRG、.TRN、.ARM、.ARZ、.CSM、.CSV、.par和.opt为后缀的文件等。之后，XtraBackup将使用LOCK BINLOG进行备份，以阻止显示主或从状态报告的所有可能更改二进制日志的位置或Exec_Master_Log_Pos或Exec_Gtid_Set的操作。然后，XtraBackup将完成重做日志文件的复制，并获取二进制日志坐标。完成后，XtraBackup将解锁二进制日志和表。最后，二进制日志位置将打印为STDERR，如果一切正常，XtraBackup将退出并返回0。注意，XtraBackup的STDERR并不是可以写在任何文件中的。必须把它重定向到一个文件，例如，XtraBackup OPTIONS 2> backupout.log。

2.准备阶段

在准备阶段，PXB使用复制的事务日志文件对复制的数据文件执行崩溃恢复。完成此操作后，数据库就可以恢复和使用了。备份后的MyISAM和InnoDB表最终将保持一致，因为在准备过程之后，InnoDB的数据将前滚到备份完成的地方，而不是回滚到备份开始的地方。这个时间点与使用读锁刷新表相匹配，因此MyISAM数据和准备好的InnoDB数据是同步的。XtraBackup工具允许通过复制数据文件、复制日志文件和将日志应用于数据的各种组合来执行流备份和增量备份等操作。

3.恢复阶段

PXB的“--copy-back”或“--move-back”选项可用于XtraBackup恢复备份。XtraBackup读取my.cnf中的datadir、innodb_data_home_dir、innodb_data_file_path和innodb_log_group_home_dir，并检查是否存在目录。它首先会复制MyISAM表、索引等文件，然后是InnoDB表和索引，最后是日志文件。这些文件在复制时，将保留文件的属性，在启动实例之前，必须将文件的所有权更改为mysql，因为它们将由创建备份的用户所拥有。或者也可以使用XtraBackup的“--move-back”选项来恢复备份。这个选项类似于XtraBackup的“--copy-back”，唯一的区别是前者是将文件移动到目标位置，而不是复制文件。由于此选项会删除备份文件，因此必须谨慎使用。当没有足够的空闲磁盘空间来保存数据文件及其备份副本时，“--move-back”选项就会非常有用。

PXB备份与恢复示例

全局备份与恢复

（1）PXB全局备份

使用XtraBackup创建全量备份时，需要指定“--backup”选项来运行。不仅如此，还要通过“--target-dir”选项来指定备份数据的存储位置。如果目标目录不存在，则XtraBackup将会自动创建目标目录；如果目录确实存在且为空，则程序正常执行。同时，XtraBackup不会覆盖现有的文件。若检测到备份目录已存在文件，则程序执行中断并抛出错误代码17，提示文件已存在。在备份过程中，我们可以看到大量复制数据文件操作的输出，以及日志线程反复扫描日志文件并从中复制。备份的时间会受到数据库规模的影响，数据量越大，所用的时间就会越长。但是，在任何时候取消都是安全的，因为程序不会修改数据库。

创建备份目录并执行全量备份，命令如下：

shell> mkdir -p /backups/data/base

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--target-dir=/backups/data/base

...

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

200205 22:49:09 completed OK!

注意：该全量备份数据将存储在/backups/data中。如果指定了相对路径，则当前目录就是目标备份目录。日志复制线程每秒钟会检查一次事务日志，查看是否有任何新的日志记录需要复制，但是，日志复制线程可能会无法跟上事务日志的写入量，并且如果日志记录在读取之前已被覆盖，则会出现错误。

（2）PXB全局准备

在使用xtrabackup --backup选项对数据文件进行备份之后，就可以准备备份以便恢复了。在执行“--prepare”阶段之前，数据文件的时间点是不一致的，因为这些文件是在程序运行的不同时间点复制的，并且在复制的过程中它们可能已经被更改了。如果此时尝试使用这些数据文件启动InnoDB，程序就会检测到损坏并且自动崩溃，以防止服务在损坏的数据上运行。指定“--prepare”选项，通过准备阶段之后，就能恢复数据的一致性了，进而就可以在这些文件上运行InnoDB了。准备操作可以在任何服务器上运行，它并不是一定要位于源服务器，或者是还原到目标服务器上。准备阶段将使用内嵌的InnoDB和复制的日志文件对复制的数据文件执行崩溃恢复。

注意：在使用不同版本的Percona XtraBackup软件分别进行备份和准备操作时，需要注意不同版本之间的兼容性。

对全量备份执行准备操作，命令如下：

shell> xtrabackup --prepare --target-dir=/backups/data/base

...

InnoDB: Shutdown completed; log sequence number 934477864

200205 22:57:10 completed OK!

准备阶段成功完成后，我们将看到一条InnoDB关闭消息，其中，日志序列号（LSN）取决于系统。在备份的准备阶段，不建议中断XtraBackup进程，因为它可能会导致数据文件损坏或备份变得不可用等问题。如果准备过程中断，则不能保证备份的有效性。

注意：如果将该备份作为进一步增量备份的基础，那么在准备阶段，我们应该使用“--apply-log-only”选项，否则就会无法对其应用增量备份。

如果重复执行“--prepare”过程，则不会改变已经准备好的数据文件，但是我们能在输出中看到如下提示信息：

xtrabackup: This target seems to be already prepared.

xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.

（3）PXB全局恢复

只有当经过准备操作之后，备份的数据文件达到一个一致的状态，才能进行复制恢复。为了方便起见，这里可以使用XtraBackup的“--copy-back”选项，该选项可以将备份数据复制到目标服务器的相关位置。当然，如果目标服务器存储空间紧张，则可以使用XtraBackup的“--move-back”选项，把备份的数据移动到目标位置。在很多场景下，甚至都不需要调用XtraBackup程序，使用操作系统rsync或cp直接操作文件，即可实现恢复。

对全量备份执行复制恢复，命令如下：

shell> xtrabackup --defaults-group-suffix=@scenetmp \

--copy-back \

--target-dir=/backups/data/base

...

200205 23:02:30 [01] ...done

200205 23:02:30 completed OK!

注意：在恢复备份之前，datadir必须为空。另外，需要注意的是，XtraBackup无法还原到正在运行的mysqld实例的datadir（导入部分备份时除外）中。

PXB增量备份与恢复

XtraBackup和InnoBackupex工具都支持增量备份，可以通过复制自上次备份以来更改的数据来实现增量备份。增量备份之所以有效，是因为每个InnoDB页都包含了一个日志序列号（LSN），可以通过页的LSN来检查对应的页最近是否发生过变化。可以指定在不同的全量备份之间执行许多增量备份，并合理规划备份策略。例如，每周一次完全备份，每天一次增量备份，或者每天一次完全备份，每小时一次增量备份。

若有LSN比前一个全量或增量备份的LSN更新，则XtraBackup增量备份会复制该LSN的每个页。通常，有两种算法可用于实现要查找复制的页集。第一种算法比较常见，即通过扫描读取所有数据页并直接检查页面LSN，该方法几乎适用于所有场景。但是，如果当前数据库的规模很大，那么此方法的效率就会比较低。第二种方法比较高效，适用于Percona，即在Percona服务器上启用更改页跟踪技术，在页发生更改时，及时记录变更信息，并将这些信息写入一个单独紧凑的位图文件中。XtraBackup将使用该位图文件仅读取增量备份所需的数据页，这可能会节省许多读取请求。若XtraBackup能找到位图文件，则默认启用后一种算法。用户可以指定XtraBackup的“--incremental-force-scan”选项来强制读取所有页面，使位图数据可用。

增量备份过程并不是将当前数据文件与前一个备份的数据文件进行比较。当使用XtraBackup的“--incremental-lsn”选项来执行增量备份时，甚至都不需要以前的备份（如果知道它的LSN）。实际上，增量备份只是读取数据库的当前页，并将它们的LSN与上一次备份的LSN进行比较。并且，除此之外仍然需要基于一个完整的备份以恢复增量的更改。所以，如果没有完整的备份作为前提，增量备份就会毫无用处。

（1）执行增量备份

1）创建各级增量备份目录，命令如下：

shell> mkdir -p /backups/data/{inc1,inc2,inc<N>}

2）创建第一次增量备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--target-dir=/backups/data/inc1 \

--incremental-basedir=/backups/data/base

...

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

200206 15:14:17 completed OK!

3）创建第N次增量备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--target-dir=/backups/data/inc<N> \

--incremental-basedir=/backups/data/inc<N-1>

增量备份目录中包含的delta文件，例如，ibdata1.delta、db01/cons1.ibd.delta等，这些都代表了不同LSN之间的数据变更。

（2）执行全量与增量准备

增量备份与完全备份的准备操作是不一样的。在完全备份中，要使数据库保持一致，需要执行两种操作：从日志文件对数据文件重放已提交的事务，回滚未提交的事务。在准备增量备份时，必须跳过未提交事务的回滚，因为在备份时，未提交的事务可能正在进行中，它们很可能会在下一次增量备份中提交。所以，应使用XtraBackup的“--apply-log-only”选项来防止事务回滚。如果不使用该选项来防止回滚，那么增量备份将是无用的，因为事务回滚之后，就无法再应用进一步的增量备份了。

1）准备全量备份，命令如下：

shell> xtrabackup --prepare --apply-log-only --target-dir=/backups/data/base

此时，即使跳过了回滚阶段，这个备份实际上也可以安全地按原样恢复。但是如果直接对该备份进行复制恢复并启动MySQL，那么InnoDB将会检测到没有执行回滚阶段，从而自发地在后台执行崩溃恢复，并提示数据库没有正常关闭。

2）将第一个增量备份应用到完整备份，即准备第一个增量备份，命令如下：

shell> xtrabackup --prepare --apply-log-only \

--target-dir=/backups/data/base \

--incremental-dir=/backups/data/inc1

上述命令将把delta文件中的增量数据应用到/backups/data/base目录中的全量备份文件中，并前滚到增量备份的时间，再应用重做日志。注意，最后的数据是在base中，而不是在inc1目录中。并且不要使用相同的增量备份目录进行多次准备操作，因为PXB不支持使用相同的增量备份目录同时准备两个备份副本。

3）将第N个增量备份应用到完整备份，即准备第N个增量备份，命令如下：

shell> xtrabackup --prepare \

--target-dir=/backups/data/base \

--incremental-dir=/backups/data/inc<N>

XtraBackup的“--apply-log-only”选项，应在进行除最后一个增量之外的所有增量时使用。即使最后一步使用了XtraBackup的“--apply-log-only”选项，也没有特别大的关系。因为，备份数据仍然是一致的。但是在这种情况下，MySQL服务在启动时将会执行回滚操作。

PXB部分备份与恢复

XtraBackup支持在启用innodb_file_per_table选项时进行部分备份。创建部分备份有三种方法，具体如下。

1）用正则表达式匹配表名。

2）在文件中提供表名列表。

3）提供数据库列表。

注意：如果在备份期间删除了任何匹配的或列出的表，那么XtraBackup将会失败。但如果未匹配到指定的备份对象，则会正常跳过，且不会报错，这一点与MEB不一样。

要想实现单表或多表备份，需要指定“--tables”或“--tables-file”选项。其中，“--tables”选项值是一个正则表达式，其与完全限定的表名相匹配。而“--tables-file”选项则可以指定一个包含多个表名的文件，文件中的一行对应于一个表名。对于单表备份或多表备份的场景，PXB只备份文件中指定的表，并且要求名称是完全匹配的、区分大小写、没有模式或正则表达式匹配，同时表名也必须是完全限定的。

同理，要想实现单库备份或多库备份，需要指定“--databases”或“--databases-file”选项。其中，“--databases”选项接受以空格分隔的数据库列表，以及databasename[.tablename]格式的表。除了该列表之外，还要确保指定mysql、sys和performance_schema数据库。而“--databases-file”选项可以指定包含多个数据库的文件，以及databasename[.tablename]格式的表，文件中的一行对应于一个元素名。对于单库备份或多库备份的场景，PXB只备份文件中指定的库和表，同样也要求名称是完全匹配的、区分大小写，以及没有模式或正则表达式匹配。

（1）使用“--tables”选项备份单表或多表

1）单表备份。下面备份db01数据库中名称为cons1的大表，即单表备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--tables="^db01[.]cons1$" \

--target-dir=/backups/data/base

2）多表备份。下面备份db01数据库中名称为cons1、cons2和cons3的三张大表，即多表备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--tables="^db01[.](cons1|cons2|cons3)$" \

--target-dir=/backups/data/base

（2）使用“--tables-file”备份单表或多表

创建scene1_singletab.txt和scene1_multitabs.txt文件，分别包含单个或多个名称完全限定的表，命令如下：

shell> echo "db01.cons1" > ./scene1_singletab.txt

shell> echo "db01.cons1 db01.cons2 db01.cons3"|xargs -n1 > ./scene1_multitabs.txt

1）单表备份。下面备份db01数据库中名称为cons1的大表，即单表备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--tables-file=/backups/conf/scene1_singletab.txt \

--target-dir=/backups/data/base

2）多表备份。下面备份db01数据库中名称为cons1、cons2和cons3的三张大表，即多表备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--tables-file=/backups/conf/scene1_multitabs.txt \

--target-dir=/backups/data/base

（3）使用“--databases”备份单库或多库

1）单库备份。下面备份db01数据库，即单库备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--databases='mysql sys performance_schema db01' \

--target-dir=/backups/data/base

2）多库备份。下面备份db01、db02、db03数据库，即多库备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--databases='mysql sys performance_schema db01 db02 db03' \

--target-dir=/backups/data/base

注意：对于单库及多库场景的恢复，为了方便，在备份指定数据库的时候，还需要指定mysql、sys和performance_schema三个系统库，否则恢复之后，服务将无法正常启动。

（4）使用“--databases-file”备份单库或多库

创建scene1_singledb.txt和scene1_multidbs.txt文件，分别包含单个或多个名称完全限定的库，命令如下：

shell> echo "db01 mysql sys performance_schema"|xargs -n1 > ./scene1_singledb.txt

shell> echo "db01 db02 db03 mysql sys performance_schema"|xargs -n1 > ./scene1_multidbs.txt

1）单库备份。下面备份db01数据库，即单库备份，命令如下：

shell> xtrabackup --defaults-file=/etc/my.cnf --defaults-group-suffix=@scene01 \

--backup \

--databases-file=/backups/conf/scene1_singledb.txt \

--target-dir=/backups/data/base

2）多库备份。下面备份db01、db02、db03数据库，即多库备份，命令如下：

shell> xtrabackup --defaults-file=/etc/my.cnf --defaults-group-suffix=@scene01 \

--backup \

--databases-file=/backups/conf/scene1_multidbs.txt \

--target-dir=/backups/data/base

（5）使用“--prepare”和“--export”准备单表或多表

由于该操作对于单表和多表这两类场景都是一致的，因此这里统一给出下列示例。执行之后，每个InnoDB表都会对应生成.cfg、.exp、.frm、.ibd这4个文件。示例代码如下：

shell> xtrabackup --prepare --export --target-dir=/backups/data/base

注意：对于部分备份，在完成准备操作之后，不能像其他备份类型一样直接执行复制恢复，因为缺失了很多系统文件，需要使用MySQL的传输表空间（TTS）技术来处理独立的InnoDB表。部分备份这个环节，确实不如MEB来的方便，MEB可以直接指定“--use-tts”选项，支持将InnoDB表恢复到原实例或其他实例中。

（6）使用“--prepare”和“--copy-back”选项恢复单库或多库

单库或多库的准备与恢复操作可参考全局备份与恢复中的“PXB全局准备”与“PXB全局恢复”。由于备份中包含mysql、sys、performance_schema等系统库，因此恢复之后即可正常启动MySQL服务。

注意：PXB部分备份场景下，使用XtraBackup的“--prepare”选项时，我们将会看到关于不存在的表的警告。这是因为这些表存在于InnoDB的数据字典中，但是对应的“.ibd”文件却不存在。由于它们没有复制到备份目录中，因此这些表将从数据字典中删除。在复制恢复后再启动InnoDB时，它们将不再存在，且不会导致任何错误或警告被打印到日志文件中。

PXB压缩备份与恢复

PXB支持对本地备份或xbstream格式流备份的压缩和解压，并生成以“.qp”格式为后缀名的压缩备份文件，默认情况下可以实现47.9%左右的压缩。可以使用XtraBackup的quicklz压缩算法对所有数据执行压缩操作，包括事务日志文件和元数据文件，这是目前唯一受支持的算法。为了实现压缩备份，需要指定“--compress”选项。如果希望加快压缩速度，还可以使用“--compress-threads”选项启用并行压缩。

（1）全量并行压缩备份

全量并行压缩备份的命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--compress --compress-threads=4 \

--target-dir=/backups/data/base

PXB使用“--decompress”选项实现解压，推荐与“--parallel”选项一起使用，以提高解压的效率。该解压操作依赖qpress工具，其介质需要从第三方资源库中获取。笔者从www.quicklz.com网站中获取了已经编译好的基于Linux平台的qpress介质包，Windows平台也可以直接获取，其他平台则需要源码编译安装后再使用。其适用的压缩备份文件是qpress archive格式，而每一个由XtraBackup生成的*.qp文件本质上是一个单文件qpress归档，可以由qpress文件归档器提取和解压。这意味着*.qp压缩备份文件不需要像tar.gz一样解压缩整个备份来恢复单个表。

（2）安装qpress工具

安装qpress工具的命令如下：

shell> wget http://www.quicklz.com/qpress-11-linux-x64.tar

shell> tar -xvf qpress-11-linux-x64.tar

shell> mv qpress /usr/bin/

（3）并行解压缩并清理压缩文件

PXB不会自动删除压缩文件。若想清理这些压缩文件，可以使用XtraBackup的“--remove-original”选项。即使它们没有被删除，在使用XtraBackup的“--copy-back”或“--moving-back”选项进行恢复时，这些文件也不会被复制或移动到目标位置。

并行解密*.qp格式的压缩备份文件，命令如下：

shell> xtrabackup --target-dir=/backups/data/base \

--decompress \

--parallel=4 \

--remove-original

PXB加密备份与恢复

PXB支持对本地备份或xbstream流备份进行加密和解密，并通过libgcrypt库，生成以“.xbcrypt”格式为后缀名的加密备份文件。若要进行加密备份，则需要指定下列选项“--encrypt”“--encrypt-key”或“--encrypt-key-file”，其中“--encrypt-ke”和“--encrypt-key-file”选项是互斥的。关于加密选项的说明具体如下。

·--encrypt=ALGORITHM。目前支持的算法有：AES128、AES192和AES256。

·--encrypt-key=ENCRYPTION_KEY。使用适当长度的加密密钥，不建议使用此选项。因为以命令行方式对服务器进行访问是不受控制的，该密钥信息会被视为进程信息的一部分。

·--encrypt-key-file=KEYFILE。可以从中读取适当长度的原始密钥的文件的名称。该文件必须是一个简单的二进制（或文本）文件，其中包含了要使用的密钥。

（1）创建密钥或密钥文件

PXB的“--encrypt-key”和“--encrypt-key-file”选项均可用于指定加密密钥。可以使用openssl创建base64编码格式的随机密钥及密钥文件，创建过程具体如下。

1）创建随机密钥，命令如下：

shell> openssl rand -base64 24

ytU13u0bPFoX/K/uWlJQqoe9kBYEhQfL

2）创建随机密钥文件，命令如下：

shell> echo -n "ytU13u0bPFoX/K/uWlJQqoe9kBYEhQfL" > /backups/conf/keyfile

注意：使用文本编辑器或重定向模式创建keyfile，如果文本中包含换行回车符，则将导致密钥增大，进而导致密钥失效。

（2）创建全量加密备份

PXB在加密备份中引入了两个选项以加快加密速度，分别是“--encrypt-threads”和“--encrypt-chunk-size”。“--encrypt-threads”选项可用于实现多个线程的并行加密。“--encrypt-chunk-size”选项可用于为每个加密线程指定工作加密缓冲区的大小（以字节为单位，默认为64KB）。

1）使用“--encrypt-key”选项创建加密备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--target-dir=/backups/data/base \

--encrypt=AES256 \

--encrypt-key="ytU13u0bPFoX/K/uWlJQqoe9kBYEhQfL" \

--encrypt-threads=4

2）使用“--encrypt-key-file”选项创建加密备份，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--target-dir=/backups/data/base \

--encrypt=AES256 \

--encrypt-key-file=/backups/conf/keyfile \

--encrypt-threads=4

（3）并行解密备份

PXB可以通过“--decrypt”选项实现备份解密，与解压类似，备份解密同样不会自动删除加密文件。为清理备份目录，用户应该删除*.xbcrypt文件。PXB在2.4.6版本中引进了“--remove-original”选项，可以使用该选项在解密后删除加密文件。其中，“--parallel”和“--decrypt”选项可以配合使用，以用于同时解密多个文件。

1）指定密钥并行解密，命令如下：

shell> xtrabackup --decrypt=AES256 --encrypt-key="ytU13u0bPFoX/K/uWlJQqoe9kBYEhQfL" \

--target-dir=/backups/data/base \

--remove-original \

--parallel=4

2）指定密钥文件并行解密，命令如下：

shell> xtrabackup --decrypt=AES256 --encrypt-key-file=/backups/conf/keyfile \

--target-dir=/backups/data/base \

--remove-original \

--parallel=4

PXB流式备份与恢复

PXB的“--stream”选项，可用于以特定的流格式将所有备份文件传输到标准输出中。使用流传输数据，结合操作系统功能，可以实现从标准输出中获取输入，从而在远端存储上创建等效的tar或xbstream文件，这一点与MEB的基于映像文件流的备份功能类似。“--stream”选项支持两种格式，tar格式比较传统和简单，其支持对流传输的标准输出执行打包或压缩操作。而xbstream格式的功能相对来说则要强大很多，在启用压缩和加密功能的同时还支持流传输。

（1）基于“--stream=tar”场景的介绍

1）按需打包，方便备份管理。在源端执行全量流备份，并在目标主机上创建以“.tar”为后缀名的打包格式备份文件，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--stream=tar | \

sshpass -p Abcd321# ssh root@192.168.113.111 'cat > /backups/data/scene1_full01.tar'

2）按需压缩，节省磁盘空间。在源端执行全量流备份，并在目标主机上创建以“.gz”为后缀名的压缩格式备份文件，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--stream=tar | \

sshpass -p Abcd321# ssh root@192.168.113.111 'gzip > /backups/data/scene1_full01.tar.gz'

（2）基于“--stream=xbstream”场景的介绍

除了TAR格式之外，为了同时支持压缩、加密和流，PXB还引入了一种称为xbstream的自定义流格式。这需要克服一些传统归档格式的限制，如tar、cpio和其他不允许流动态生成文件的格式（例如，动态压缩文件）。与传统的流或归档格式相比，xbstream的其他优点包括：通过指定“--parallel”选项可以实现多个文件的并发传输，以及更紧凑的数据存储。

可以使用PXB对xbstream格式的流进行处理，其具有如下特点。

·“-x”选项可用于从标准输入读取的流中将文件提取到当前目录，除非使用“-C”选项另行指定。PXB的2.4.7版本实现了对使用“--parallel”选项进行并行提取的支持。

·“-C”选项可用于将命令行中指定的文件流传输到标准输出。

·“--decrypt=ALGO”选项可用于指定的xbstream在自动解密加密文件时提取输入流。此选项支持的值为：AES128、AES192和AES256。必须指定“--encrypt-key”或“--encrypt-key-file”选项才能提供加密密钥，但不能同时指定这两个选项。该选项已在PXB的2.4.7版本中实现。

·“--encrypt-threads”选项可用于指定并行数据加密的线程数，默认值为1。该选项已在PXB的2.4.7版本中实现。

·“--encrypt-key”选项可用于指定将要使用的加密密钥。不能与“--encrypt-key-file”选项一起使用，因为它们是互斥的。该选项已在PXB的2.4.7版本中实现。

·“--parallel”选项可用于指定并行数据解压或解密的线程数。

·“-C”选项可用于在处理文件流之前，将当前目录更改为指定的目录。

1）同时实现并行压缩和流传输。在源端执行全量压缩和流传输，并在目标端生成压缩备份文件，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--parallel=4 \

--compress --compress-threads=4 \

--stream=xbstream | \

sshpass -p Abcd321# ssh root@192.168.113.111 'xbstream -x --parallel=4 -C /

backups/data/base'

2）同时实现并行加密和流传输。在源端执行全量加密和流传输，并在目标端生成解密后的备份文件，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--parallel=4 \

--encrypt=AES256 \

--encrypt-key-file=/backups/conf/keyfile \

--encrypt-threads=4 \

--stream=xbstream | \

sshpass -p Abcd321# ssh root@192.168.113.111 'xbstream -x --parallel=4 \

--decrypt=AES256 --encrypt-key-file=/backups/conf/keyfile \

-C /backups/data/base'

以上示例中，xbstream程序在备份阶段已经完成了解密。如果没有解密，则需要在目标端对加密备份文件执行手动解密，详细操作请参考6.3.3节中的“并行解密备份”。

3）同时实现并行压缩、加密和流传输，命令如下：

shell> xtrabackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup \

--parallel=4 \

--compress --compress-threads=4 \

--encrypt=AES256 \

--encrypt-key-file=/backups/conf/keyfile \

--encrypt-threads=4 \

--stream=xbstream | \

sshpass -p Abcd321# ssh root@192.168.113.111 'xbstream -x --parallel=4 \

--decrypt=AES256 --encrypt-key-file=/backups/conf/keyfile \

-C /backups/data/base'

4）xbstream格式的特点如下。指定“--stream=xbstream”，再结合PXB的压缩和加密，这些特性就能够满足某些特定的业务场景需求了。其一，压缩之后再进行流传输，可以极大地节省网络带宽流量，非常适用于带宽资源比较紧张的场景；其二，加密之后再进行流传输，可以极大地保障文件流传输的安全性，非常适用于对数据网络传输有严格等级保护要求的场景。而这些都是tar格式的流传输所不具备的。当然，PXB还支持备份到云端，例如，亚马逊云、谷歌云等云存储端。但这需要PXB的xbcloud实用工具进行配合，限于篇幅，此处就不做扩展讲解了，若有兴趣请自行搜索相关资料。