Percona XtraBackup2.4.28中文文档+使用案例

一、Percona XtraBackup文档

本文档是Percona XtraBackup 2.4.28版本。
使用案例：mysql5.7全量备份恢复和部分数据库和数据表备份恢复

Percona XtraBackup是一个针对基于MySQL的服务的开源热备份实用程序，它在备份期间不会锁定数据库。可以备份MySQL 5.1、5.5、5.6和5.7服务器上的InnoDB、XtraDB和MyISAM表上的数据，以及具有XtraDB的Percona服务数据.

注意：在Percona XtraBackup 2.1版本中，已经删除了对InnoDB 5.1内置程序的支持

无论是24x7高负载服务还是低事务量提交的环境，Percona XtraBackup备份是一个无缝过程，不对生产环境中服务器的性能产生影响(备份的盘和mysql使用数据盘不是同一块，且是在不使用压缩参数的情况下)。

重要：Percona XtraBackup2.4不支持对MySQL 8.0的性能服务器或Percona XtraDB集群8.0中创建的数据库进行备份。对8.0版本的数据库使用Percona XtraBackup 8.0。

二、介绍

2.1关于Percona XtraBackup

Percona XtraBackup是世界上唯一的开源的、免费的MySQL热备份软件，可以为InnoDB和XtraDB数据库执行非阻塞备份。使用Percona XtraBackup，可以实现以下好处：

• 可靠且快速地完成备份
• 备份期间不中断事务处理
• 节省磁盘空间和网络带宽
• 自动备份校验
• 备份和恢复时间快

支持InnoDB、Percona XtraDB Cluster和HailDB存储引擎的非阻塞备份。此外，Percona Xtrabackup可以通过在备份结束时短暂暂停写操作来备份以下存储引擎： MyISAM，Merge , 和 Archive ,包括分区表、触发器和数据库选项。

在复制非InnoDB数据时InnoDB表仍然被锁。启用Percona XtraDB Cluster页面变更跟踪的Percona服务支持快速增量备份。

重要：Percona Xtrabackup 2.4只支持Percona XtraDB Cluster5.7。Percona Xtrabackup2.4不支持MyRocks存储引擎或TokuDB存储引擎。Percona Xtrabackup与MariaDB 10.3及更高版本不兼容。

Percona的企业级商业MySQL支持合同包括对Percona快速备份的支持。建议支持关键的生产部署。

2.1.1 Percona Xtrabackup有哪些特性？

不中断数据库服务完成InnoDB的热备

• 对MySQL进行增量备份
• MySQL数据备份到另一台服务器可以采用流压缩技术
• 在线完成MySQL服务器之间表迁移
• 可以简单地创建新的MySQL replication复制副本
• 备份MySQL期间不增加MySQL服务器负载
• 在Percona Server 5.6+中备份锁是一种轻量级的替代FLUSH TABLES WITH READ LOCK方案。Percona Xtrabackup使用它自动复制非InnoDB数据，以避免阻止修改InnoDB表的DML查询
• Percona Xtrabackup根据IOPS操作数进行限流(throttling)
• Percona Xtrabackup会跳过辅助索引页，并在准备好完整的备份时重新创建它们
• Percona Xtrabackup可以在任意的InnoDB版本的完整备份中导出单个表
• Percona XtraBackup导出的表可以导入到Percona Server 5.1, 5.5 or 5.6+, or MySQL5.6+.

2.2 Percona XtraBackup如何运行

Percona Xtrabackup是基于InnoDB的崩溃恢复功能。它复制InnoDB数据文件，这会导致数据内部不一致；但是它能对文件执行崩溃恢复，使它再次成为一致的、可用的数据库。

这是因为InnoDB维护一个redo log，也称为事务日志。它包含了对InnoDB数据进行的每次变更记录。当InnoDB启动时，它会检查数据文件和事务日志，并执行两个步骤。将已提交的事务日志项应用到数据文件，并对已修改数据但未提交的任何事务执行撤消操作。

Percona XtraBackup在启动时记住日志序号（LSN）并复制数据文件。这个过程持续一段时间，此时数据文件时时发生变化，这个过程反映数据库在不同时间点的状态。同时Percona XtraBackup运行一个后台进程，监视事务日志文件，并从中复制更改。Percona XtraBackup自开始执行以来对数据文件的每次更改都需要进行事务日志记录。

在Percona Server 5.6+中备份锁是一种轻量级的替代FLUSH TABLES WITH READ LOCK方案。 Percona XtraBackup使用此功能自动复制非InnoDB数据，以避免阻止修改InnoDB表的DML查询。当服务支持备份锁时，xtrabackup将首先复制InnoDB数据，运行LOCK TABLES FOR BACKUP，并复制MyISAM表和.frm文件。一旦完成，将开始备份。它将备份.frm , .MRG , .MYD , .MYI , .TRG , .TRN , .ARM , .ARZ , .CSM , .CSV , .par , and .opt 等文件

注意：锁定只对MyISAM和其他非InnoDB表进行锁定，并且只有在Percona Xtrabackup备份完所有InnoDB/XtraDB数据和日志才能进行。Percona XtraBcackup将使用备份锁，作为可用的轻量级替代FLUSH TABLES WITH READ LOCK。此特性可在MySQL 5.6+的性能服务器中使用。Percona XtraBackup使用此功能自动复制非InnoDB数据，以避免阻止修改InnoDB表的DML查询。

在此之后，Xtrabackup将使用LOCK BINLOG FOR BACKUP ，以阻止可能改变二进制日志位置或Exec_Master_Log_Pos或Exec_Gtid_Set（即与复制副本上的源二进制日志坐标对应的当前SQL线程状态）的所有操作。然后xtrabackup将完成REDO日志文件的复制，并获取二进制日志坐标。在这一切完成后，xtrabackup将解锁二进制日志和表。

最后，二进制日志位置将被打印到STDERR，Xtrabackup退出，如果一切正常，则返回0。

请注意，Xtrabackup的STDERR没有写入到任何文件中。这时将其重定向到一个文件，例如，xtrabackup OPTIONS 2 > backupout.log。这将在备份的目录中创建文件。

在准备阶段，Percona XtraBackup使用复制的事务日志文件对复制的数据文件执行崩溃恢复。完成之后，数据库做好恢复和使用的准备。

备份的MyISAM和InnoDB表最终将相互一致，因为在准备（恢复）过程之后，InnoDB的数据被恢复到备份完成的点，而不是备份开始的时间点数据。这个时间点与使用FLUSH TABLES WITH READ LOCK相匹配，因此MyISAM数据和准备的InnoDB数据是同步的。

xtrabackup和innobackupex工具都提供了许多在前面的解释中没有提到的特性。每个工具的功能将在手册中进行更详细的解释。不过，简而言之，这些工具允许使用复制数据文件、复制日志文件以及将日志应用到数据中的各种组合来进行流式备份和增量备份等操作。

2.2.1 恢复备份

要使用xtrabackup恢复备份，可以使用 xtrabackup --copy-back 或者xtrabackup --move-back选项

xtrabackup从my.cnf文件读取datadir , innodb_data_home_dir , innodb_data_file_path , innodb_log_group_home_dir 变量并检查这些目录是否存在。

xtrabackup将复制MyISA表、索引等( .frm , .MRG , .MYD , .MYI , .TRG , .TRN , .ARM , .ARZ , .CSM , .CSV , par和.opt 文件)首先复制InnoDB表接下来是索引，最后是日志文件。在复制文件属性时保留文件的属性，在启动数据库服务器之前，必须将文件的所有权更改为mysql。

或者xtrabackup --move-back选项可用于恢复备份。这个选项类似于xtrabackup --copy-back，唯一的区别是，它不复制文件，而是将它们移动到目标位置。由于此选项会删除备份文件，因此请谨慎使用它。在没有足够的空闲磁盘空间来同时容纳数据文件及其备份副本时可以使用该参数。

三、安装

3.1 安装Percona XtraBackup

​
1. 安装Percona XtraBackup。可以在Percona的官方网站下载安装。

安装yum源

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

#安装XtraBackup 2.4版本的

yum install -y percona-xtrabackup-24.x86_64

#安装解压缩命令

yum install -y qpress

​

四、备份方案

4.1.1 全备

创建备份，使用xtrabackup --backup选项运行。还需要指定一个xtrabackup --target-dir选项，即存储备份的位置，如果InnoDB数据或日志文件没有存储在同一目录中，可能也需要指定这些文件的位置。如果目标目录不存在，则xtrabackup将创建它。如果该目录确实存在且为空，xtrabackup将运行成功。xtrabackup不会覆盖目录中的文件。会直接运行失败：错误码17，文件已存在。

启动备份进程：

xtrabackup --backup --target-dir=/data/backups/

这将把备份存储在/data/backups/上。如果指定了一个相对路径，则目标目录将相对于当前目录。

在备份过程中，会看到大量显示正在复制的数据文件的输出，以及日志文件线程重复扫描日志文件并从其中复制。下面是一个例子，显示了日志线程在后台扫描日志，以及一个处理ibdata1文件的文件复制线程：

160906 10:19:17 Finished backing up non-InnoDB tables and files
160906 10:19:17 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '62988944'
xtrabackup: Stopping log copying thread.
.160906 10:19:18 >> log scanned up to (137343534)
160906 10:19:18 Executing UNLOCK TABLES
160906 10:19:18 All tables unlocked
160906 10:19:18 Backup created in directory '/data/backups/'
160906 10:19:18 [00] Writing backup-my.cnf
160906 10:19:18 [00] ...done
160906 10:19:18 [00] Writing xtrabackup_info
160906 10:19:18 [00] ...done
xtrabackup: Transaction log of lsn (26970807) to (137343534) was copied.
160906 10:19:18 completed OK!

注意：日志复制线程每秒检查事务日志是否有任何新的日志记录写需要复制。可能出现日志复制线程可能无法跟上写的数量的事务日志，就会出现日志记录在写之前被读取的错误

备份完成后，目标目录将包含以下文件，假设有一个InnoDB表test.tbl1，并且正在使用MySQL的innodb_file_per_table选项

 ls -lh /data/backups/
total 182M
drwx------ 7 root root 4.0K Sep 6 10:19 .
drwxrwxrwt 11 root root 4.0K Sep 6 11:05 ..
-rw-r----- 1 root root 387 Sep 6 10:19 backup-my.cnf
-rw-r----- 1 root root 76M Sep 6 10:19 ibdata1
drwx------ 2 root root 4.0K Sep 6 10:19 mysql
drwx------ 2 root root 4.0K Sep 6 10:19 performance_schema
drwx------ 2 root root 4.0K Sep 6 10:19 sbtest
drwx------ 2 root root 4.0K Sep 6 10:19 test
drwx------ 2 root root 4.0K Sep 6 10:19 world2
-rw-r----- 1 root root 116 Sep 6 10:19 xtrabackup_checkpoints
-rw-r----- 1 root root 433 Sep 6 10:19 xtrabackup_info
-rw-r----- 1 root root 106M Sep 6 10:19 xtrabackup_logfile

备份可能需要多长时间，这取决于数据库的大小。在任何时候取消都是安全的，因为它不会修改数据库。

4.1.2 准备备份

 在使用xtrabackup --backup选项进行备份之后，首先需要prepare后才可以恢复它。数据文件在准备好之前时间点是不一致，因为它们在程序运行的不同时间被复制，并且在运行时可能会被更改。如果尝试用这些数据文件启动InnoDB，它将检测到损坏并导致MySQL自身崩溃防止在损坏的数据上运行。xtrabackup --prepare步骤使文件在一瞬间完全一致，因此可以运行InnoDB。

可以在任何计算机上运行准备操作；它不需要在原来服务器或要还原的服务器上。可以将备份复制到一个实用程序服务器，并在那里进行prepare。

注意：可以prepare a backup使用旧的Percona XtraBackup版本创建的备份，反之亦然。在不受支持的服务器版本上prepare a backup时，应该使用支持该服务器版本的最新的Perconax备份版本来完成。例如，如果有使用Percona XtraBackup1.6创建的MySQL 5.0的备份，则不支持prepare a backup，因为在Percona XtraBackup2.1中删除了对MySQL 5.0的支持。相反，应该使用2.0系列中的最新版本。

在prepare操作过程中，xtrabackup启动其中嵌入的一种修改的InnoDB（链接的库）。这些修改操作对于禁用InnoDB的标准安全检查是必要的。比如日志文件大小不正确，将不适用备份。这些修改仅适用于xtrabackup二进制文件；不需要使用修改后的InnoDB来使用xtrabackup进行备份。

prepare步骤使用此嵌入式InnoDB使用复制的日志文件对复制的数据文件执行崩溃恢复。

准备步骤非常简单：只需运行xtrabackup --prepare选项，并告诉它准备哪个目录。例如，准备之前执行的备份运行：

xtrabackup --prepare --target-dir=/data/backups/

当这完成时，应该看到InnoDB关闭，消息如下，其中LSN的值将取决于服务器系统

InnoDB: Shutdown completed; log sequence number 137345046 160906 11:21:01 completed OK!

以下所有准备都不会改变已经准备好的数据文件，将看到输出说：

xtrabackup: This target seems to be already prepared. xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.

不建议在prepare备份时中断xtrabacckup进程，因为这可能会导致数据文件损坏，而备份将无法使用。如果prepare过程被中断，则不能保证备份的有效性。

注意：如果希望将备份作为进一步增量备份的基础，则在准备备份时应该使用--apply log-only的选项，否则将无法对其应用增量备份。

4.1.3 恢复备份

备份需要在恢复之前准备好了。

xtrabackup --copy-back --target-dir=/data/backups/

如果不想保存备份，可以使用xtrabackup --move-back选项，该选项将备份的数据移动到datadir

如果不想使用上述任何选项，还可以另外使用rsync或cp来恢复文件。

注意： 在还原备份之前，datadir目录必须为空。同样需要注意的是，在执行还原之前，需要关闭MySQL服务器。无法恢复到正在运行的mysqld实例的datadir

可用于恢复备份的rsync命令的示例如下所示：

rsync -avrP /data/backup/ /var/lib/mysql/

应该检查已恢复的文件是否具有正确的所有权和权限。

chown -R mysql:mysql /var/lib/mysql

数据现在已恢复，可以启动服务器。

注意： 当启用 relay-log-info-repository=TABLE时，从备份中恢复的实例在错误日志中出现如下错误：

text 2019-08-09 12:40:02 69297

[ERROR] Failed to open the relay log '/data/mysql-relay-bin.004349' (relay_log_pos 5534092)004349‘（relay_log_pos 5534092）

为了避免这个类[[型的问题，请在更改主服务器到之前启用relay_log_recovery或执行 RESET SLAVE prior to CHANGE MASTER TO 备份了中继日志信息，但是创建了一个新的中继日志，这在恢复过程中产生不匹配

4.2 增量备份

xtrabackup工具和innobackupex 工具都支持增量备份。增量备份只备份自上次备份以来已发生更改的数据。

可以在每次完整备份之间进行多个增量备份。例如，可以每周进行一次完整备份，每天进行一次增量备份，或者每天进行一次完整备份，每小时进行一次增量备份。

增量备份很有效，因为每个InnoDB页面都包含一个日志序列号（LSN）。LSN是整个数据库的系统版本号。每个页面的LSN显示了最近是如何更改的。

增量备份复制比之前增量备份或完整备份的更新的LSN的页面。有两种算法用于查找要复制的此类页面集。

• • 第一种可适用于所有服务器类型和版本，通过读取所有数据页面直接获取页面LSN。
  • 第二种可适用于MySQL的Percona服务器，启用服务器上更改的页面追踪功能，将在变更时注意页面。

这些信息将被写在一个紧凑的独立的位图文件中。xtrabackup二进制文件使用该文件只读取增量备份所需的数据页。此特性可能会节省许多读取请求。如果xtrabackup二进制文件找到了位图文件，则默认启用后一种算法。如果位图数据可用就可以指xtrabackup --incremental-force-scan读取所有的页。

重要：增量备份不会将数据文件与以前备份的数据文件进行比较。因此，在部分备份之后运行增量备份可能会导致数据不一致。增量备份将读取这些页面，并将其LSN与上次备份的LSN进行比较。必须有一个完整的备份才能恢复增量更改。如果没有完整的备份作为基础，增量备份是无用的。如果知道它的LSN，可以使用--incremental-lsn选项来执行增量备份，而不使用以前的备份

4.2.1 创建增量备份

若要进行增量备份，请像往常一样首先进行完全备份。

xtrabarckup将一个名为xtrabackup_checkpoints的文件写入备份的目标目录。此文件包含一个显示to_lsn的行，它是在备份结束时数据库的LSN。使用以下命令创建完整的备份：

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

如果你看一下xtrabackup_checkpoints文件，你应该会看到类似的内容，这取决于你的LSN number：

backup_type = full-backuped from_lsn = 0 to_lsn = 1626007 last_lsn = 1626007 compact = 0 recover_binlog_info = 1

现在有了一个完整的备份，可以基于其进行增量备份。使用以下命令：

xtrabackup --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base

/data/backups/inc1

目录现在应该包含增量文件，如ibdata1.delta和test/ table1.ibd.delta。这些变化代表了自LSN 1626007以来的变化。如果检查此目录中的xtrabackup_checkpoints文件，应该会看到类似的内容：

backup_type = incremental 
from_lsn = 1626007 
to_lsn = 4124244 
last_lsn = 4124244 
compact = 0 
recover_binlog_info = 1

from_lsn是备份的起始LSN，对于增量备份，它必须与前一个基本备份的to_lsn（如果是最后一个检查点）相同。

现在可以使用此目录作为另一个增量备份的基础：

xtrabackup --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1

此文件夹还包含xtrabackup_checkpoints：

backup_type = incremental 
from_lsn = 4124244 
to_lsn = 6938371 
last_lsn = 7110572 
compact = 0 
recover_binlog_info = 1

注意：在这种情况下，可以看到to_lsn（最后一个检查点LSN）和last_lsn（最后一个复制的LSN）之间存在差异，这意味着在备份过程中服务器上存在一些写操作。

4.2.2 准备增量备份

对增量备份的准备步骤与完全备份不同。在完全备份中，将执行两个操作以使数据库一致：从日志文件对数据文件重放已提交的事务，以及未提交的事务回滚。

在准备增量备份时，必须跳过未提交事务的回滚，因为在备份时未提交的事务可能正在进行中，而且它们很可能会在下一次增量备份中提交。因此需要使用 --apply-log-only选项来防止回滚阶段。

注意：如果不使用xtrabackup --apply-log-only选项来防止回滚阶段，那么增量备份是无用的。回滚事务后，将无法应用进一步的增量备份。

从创建的完整备份开始，可以准备它，然后将增量差异应用于它。回想一下，有以下备份：

/data/backups/base 
/data/backups/inc1 
/data/backups/inc2

要准备基本备份，需要运行xtrabackup –prepare 像往常一样进行准备，但要防止进行回滚阶段：

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

输出应以类似如下的文本结尾：

InnoDB: Shutdown completed; log sequence number 1626007 161011 12:41:04 completed OK!

日志序列号应该与之前看到的基本备份的to_lsn相匹配。

注意：即使备份跳过回滚阶段，此操作也是安全的。如果您恢复它并启动MySQL，InnoDB会检测到回滚阶段没有执行，它将在后台这样做。此操作与启动时的崩溃恢复相同。此外，MySQL会通知您数据库没有正常关闭

要将第一次增量备份应用于完整备份，请运行以下命令：

xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1

这将增量文件应用于/data/backups/base中的文件，这些文件将mysql数据恢复到增量备份1的时间。然后，它会像往常一样将重做日志应用到结果中。最终数据位于/data/backups/base ,中，而不是增量目录中。应该看到一个类似的输出：

incremental backup from 1626007 is enabled.
xtrabackup: cd to /data/backups/base
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(4124244)
...
xtrabackup: page size for /tmp/backups/inc1/ibdata1.delta is 16384 bytes
Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1...
...
161011 12:45:56 completed OK!

同样，LSN应该与之前对第一次增量备份的检查中看到的匹配。如果从/data/backups/base中恢复文件，则应在第一次增量备份时看到数据库的状态

警告：Percona Xtrabackup不支持使用相同的增量备份目录来准备两个备份副本。不要多次运行xtrabackup --prepare 使用相同的增量备份目录（--incremental-dir ）

准备第二次增量备份的过程类似：将增量应用于（修改的）基础备份，然后将其数据及时向前滚动到第二次增量备份的点：

xtrabackup --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2

注意：xtrabackup --apply-log-only 应该在合并除最后一个增量以外的所有增量时使用。这就是为什么上一行不包含 --apply-log-only的选项。即使在最后一步中使用了 --apply-log-only，备份仍然是一致的，但在这种情况下，服务器将执行回滚阶段。

一旦准备好，增量备份与完整备份相同，可以以同样的方式恢复。

4.3 压缩备份

Percona Xtrabackup支持压缩备份：本地或流式备份可以使用xbstream进行压缩或解压缩。

4.3.1创建压缩备份

为了进行压缩备份，需要使用xtrabackup –compress 选项：

xtrabackup --backup --compress --target-dir=/data/compressed/

xtrabackup --compress使用qpress工具，可以通过percona-release 工具安装，如下所示：

$ sudo percona-release enable tools 
$ sudo apt update 
$ sudo apt install qpress

如果要加快压缩速度，可以使用并行压缩，这可以通过xxtrabackup –compress-threads 选项来启用。下面的示例将使用四个线程进行压缩(使用压缩线程会消耗服务器的cpu资源)：

xtrabackup --backup --compress --compress-threads=4 --target-dir=/data/compressed/

输出应该是这样的

170223 13:00:38 [01] Compressing ./test/sbtest1.frm to /tmp/compressed/test/sbtest1.frm.qp
170223 13:00:38 [01] ...done
170223 13:00:38 [01] Compressing ./test/sbtest2.frm to /tmp/compressed/test/sbtest2.frm.qp
170223 13:00:38 [01] ...done
...
170223 13:00:39 [00] Compressing xtrabackup_info
170223 13:00:39 [00] ...done
xtrabackup: Transaction log of lsn (9291934) to (9291934) was copied.
170223 13:00:39 completed OK!

准备备份

在准备备份之前，必须解压缩所有文件。Percona XtraBackup已经实现了xtrabackup --decompress选项，可用于解压缩备份

xtrabackup --decompress --target-dir=/data/compressed/

注意：xtrabackup --parallel 可以与xtrabackup --decompress选项来同时解压多个文件

Percona XtraBackup 不会自动删除压缩的文件。要清理备份目录，请使用 xtrabackup --remove-original 选项。如果没有删除文件，则不会复制或移动到数据根，如果使用xtrabackup --copy-back ，或 xtrabackup --move-back

当文件未压缩时，您可以使用xtrabackup --prepare 选项准备备份：

xtrabackup --prepare --target-dir=/data/compressed/

检查是否确认信息

InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 9293846 170223 13:39:31 completed OK!

现在，/data/compressed/的文件已经准备好被服务器使用了。

Restoring the backup

xtrabackup有一个xtrabackup --copy-back选项，该选项可执行恢复到服务器数据根的备份操作：

xtrabackup --copy-back --target-dir=/data/backups/

该选项将所有与数据相关的文件复制回服务器的datadir，由服务器的my.cnf配置文件决定。检查输出的最后一行以获得成功消息

170223 13:49:13 completed OK!

复制数据后，验证文件权限。需要调整这些权限。例如，以下命令会更改文件位置的所有者

chown -R mysql:mysql /var/lib/mysql

现在，datadir包含了恢复的数据。准备好启动该服务器了。

五、用户手册

Percona XtraBackup is a set of following tools:

• innobackupex
  • innobackupex是xtrabackup的符号链接。innobackupex仍然像2.2版本一样支持所有特性和语法，但现在已经弃用，并将在下一个主要版本中删除。
• xtrabackup
  • 一个已编译的C二进制文件，它提供了使用MyISAM、InnoDB和XtraDB表备份整个MySQL数据库实例的功能。
• xbcrypt
  • 用于加密和解密备份文件的实用程序。
• xbstream
  • 允许从xbstream格式进行流媒体和提取文件的实用程序
• xbcloud
  • 用于从/上云下载和上传完整或部分xbstream存档的实用程序。

六、高级特性

虽然xtrabackup不会阻塞数据库的操作，但任何备份都会为正在备份的系统添加负载。

在没有太多空闲I/O容量的系统上，限制xtrabackup读取和写数据的速率可能会有所帮助。可以使用xtrabackup --throttle选项来实现这一点。此选项限制每秒复制的块的数量。块的大小为10 MB。

下图显示了当xtrabackup --throttle被设置为1时，限制是如何工作的。

默认情况下，没有限制，xtrabackup尽可能地读写数据。如果对IOPS设置过于严格的限制，备份可能会变慢，从而永远不会赶上InnoDB正在编写的事务日志，备份可能永远不会完成。

七、XtraBackup案例

7.1、全量备份案例

前提准备工作：

操作前确保本地目录和远程目录有足够的备份空间可以存放数据

以下是使用Percona XtraBackup对MySQL中指定的InnoDB表进行备份的步骤

1. 安装Percona XtraBackup。可以在Percona的官方网站下载安装。

安装yum源

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

#安装XtraBackup 2.4版本的

yum install -y percona-xtrabackup-24.x86_64

#安装解压缩命令

yum install -y qpress

2、多线程备份，可提前执行备份，备份后将数据文件传输到新服务器上(该备份操作会消耗cpu和io资源)

cd /hskj/tmp
​​​​​​​time xtrabackup --backup --datadir=/hskj/mysql/ --target-dir=/hskj/tmp/full --compress --parallel=6 --compress-threads=6 --user=root --password=

#13G 32s ，压缩目录后是3.1G

#同步第一次全备份的数据到新数据库主机，主要是两个机房之间的传输带宽，参数设置80M

cd /hskj/tmp 
rsync -vzrtp -P --bwlimit=800000 -e "/usr/bin/ssh -p 10020 -o StrictHostKeyChecking=no" full root@123.60:/hskj/tmp

这条命令的意思是使用xtrabackup进行备份，备份的数据将存储到/data/backup/full目录下，数据库的用户是root，密码是your_password。

3. 增量备份，在正式迁移期间执行增量的同步数据

time xtrabackup --backup --target-dir=/hskj/tmp/incr --incremental-basedir=/hskj/tmp/full/ --compress --parallel=4 --compress-threads=4 --user=root --password= #39s

#同步增量的数据到新数据库主机

cd /hskj/tmp 
time rsync -vzrtp -P --bwlimit=800000 -e "/usr/bin/ssh -p 10020 -o StrictHostKeyChecking=no" incr root@123.60.:/hskj/tmp

这条命令的意思是使用xtrabackup进行增量备份，备份的数据将存储到/hskj/tmp/incr目录下，增量备份的基础数据是/hskj/tmp/full/，数据库的用户是root，密码是your_password

4. 数据恢复

#新服务器上执行操作，确保对应的临时数据目录有足够的空间

首先要进行数据准备，步骤如下：

time xtrabackup --decompress --parallel=4 --target-dir=/hskj/tmp/full --decompress-threads=6 
time xtrabackup --decompress --parallel=4 --target-dir=/hskj/tmp/incr --decompress-threads=6

#至于多线程，XtraBackup确实支持多线程备份，但在`--prepare`阶段，即使使用多线程，也不会加速过程，因为它主要是CPU密集型的。

time xtrabackup --prepare --apply-log-only --use-memory=32G --target-dir=/hskj/tmp/full

#增量文件的准备

time xtrabackup --prepare --use-memory=32G --target-dir=/hskj/tmp/full/ --incremental-dir=/hskj/tmp/incr

5、然后进行数据恢复，步骤如下：

#注意核实要操作的数据库主机

systemctl stop mysqld
cd /hadata/; mv mysql mysql_old
time xtrabackup --copy-back --target-dir=/hskj/tmp/full --parallel=12 --user=root --password=
chown -R mysql. /hadata/mysql/
mkdir /hadata/mysql/tmp
chown mysql. /hadata/mysql/tmp
systemctl start mysqld
systemctl status mysqld

6、验证数据

文本对比数据库表大小是否一致：

在线文本比较工具，文字、代码差异查看工具， - 在线工具-wetools.com微工具

7.2、同步部分库和部分数据表

优化方案：

1. mysql和performance_schema库必须要带
2. --compress --parallel=6 --compress-threads=6业务高峰期减少这两个参数的数值，避免消耗过多的cpu资源
3. 备份盘最好是单独的数据盘，备份期间io会瞬间打满，影响正常业务
4. rsync数据同步是使用单线程CPU，cpu性能越差，同步效率就越低

案例数据耗时分说明：

数据操作耗时：

ssd盘

240G数据压缩后83G，约13分钟--提前做

数据同步80G 的100M带宽 传输时间60分钟--提前做(可以使用rsync多线程)

凌晨正式开始操作耗时：35分钟

云平台的ssd盘

full解压：20分钟--全量数据提前解压--可提前做

full准备阶段：2分钟

full导入阶段：37分钟

1、多线程备份，可提前执行备份，备份后将数据文件传输到新服务器上。--databases指定同步的数据库--tables-file指定同步的表数据

cd /hskj/tmp 
time xtrabackup --backup --datadir=/hskj/mysql/ --databases="mysql performance_schema" --tables-file=/hskj/tmp/prod-table.txt --target-dir=/hskj/tmp/full --compress --parallel=6 --compress-threads=6 --user=root --password=

命令的意思是使用xtrabackup进行备份，备份的数据将存储到/hskj/tmp/full目录下，数据库的用户是root，密码是your_password。

#同步第一次全备份的数据到新数据库主机，主要是两个机房之间的传输带宽，参数设置80M，可以通过新加油包提高传输速度

cd /hskj/tmp 
rsync -vzrtp -P --bwlimit=800000 -e "/usr/bin/ssh -p 10020 -o StrictHostKeyChecking=no" full root@123.9:/hskj/tmp

2. 增量备份，在正式迁移期间执行增量的同步数据

time xtrabackup --backup --target-dir=/hskj/tmp/incr --incremental-basedir=/hskj/tmp/full/ --databases="mysql performance_schema" --tables-file=/hskj/tmp/prod-table.txt --compress --parallel=4 --compress-threads=4 --user=root --password=

命令的意思是使用xtrabackup进行增量备份，备份的数据将存储到/hskj/tmp/incr目录下，增量备份的基础数据是/hskj/tmp/full/，数据库的用户是root，密码是your_password

#同步增量的数据到新数据库主机

cd /hskj/tmp time rsync -vzrtp -P --bwlimit=800000 -e "/usr/bin/ssh -p 10020 -o StrictHostKeyChecking=no" incr root@123.60.9:/hskj/tmp

3. 数据恢复

#新服务器上执行操作，确保对应的临时数据目录有足够的空间

首先要进行数据准备，步骤如下：

time xtrabackup --decompress --parallel=4 --target-dir=/hskj/tmp/full --decompress-threads=6 
time xtrabackup --decompress --parallel=4 --target-dir=/hskj/tmp/incr --decompress-threads=6

#至于多线程，XtraBackup确实支持多线程备份，但在`--prepare`阶段，即使使用多线程，也不会加速过程，因为它主要是CPU密集型的。

time xtrabackup --prepare --apply-log-only --use-memory=32G --target-dir=/hskj/tmp/full

#增量文件的准备

time xtrabackup --prepare --use-memory=32G --target-dir=/hskj/tmp/full/ --incremental-dir=/hskj/tmp/incr

然后进行数据恢复，步骤如下：

 systemctl stop mysqld
 cd /hadata/; mv mysql mysql_old
 time xtrabackup --copy-back --target-dir=/hskj/tmp/full --parallel=12 --user=root --password=
 chown -R mysql. /hadata/mysql/
 mkdir /hadata/mysql/tmp
 chown mysql. /hadata/mysql/tmp
 systemctl start mysqld
 systemctl status mysqld

撒花！
码字整理不易，感谢各位大佬支持↓↓↓↓↓↓↓↓↓↓↓

​​​​​​​