使用 Percona XtraBackup 配置增量 MySQL 备份

Percona XtraBackup (PXB) 是对 MySQL、MariaDB 和 Percona Server 实例执行非阻塞、热备份的行业标准。虽然全量备份至关重要，但对于大型数据库而言，需要一种高效的策略来最大程度地减少停机时间和存储使用量。增量备份通过仅捕获自上次成功备份以来发生的数据更改，提供了这种效率。

本指南探讨了如何利用 PXB 来实施稳健的增量备份策略。我们将涵盖核心概念、执行连续增量快照所需的必要命令，以及成功恢复所需的多步骤过程。

理解 Percona XtraBackup 的增量机制

PXB 依赖于 InnoDB 存储引擎的内部工作原理，特别是使用日志序列号 (LSN) 来跟踪更改。每个 InnoDB 页面都带有 LSN 标记。当 PXB 执行增量备份时，它只记录那些其 LSN 大于上次备份时记录的 LSN 的页面。

至关重要的是，增量备份需要一个全量基础备份来建立起点。所有后续的增量备份都会被链接起来，引用紧邻的前一个备份（可以是基础备份或另一个增量备份）。

关键文件和概念

LSN（日志序列号）： 用于确定更改开始和结束位置的标记。
xtrabackup_checkpoints：在每次备份期间创建的文件，包含 to_lsn（备份结束时达到的 LSN）以及，对于增量备份，包含 from_lsn（起始 LSN）。
--incremental-basedir：在增量运行时使用的关键标志，指向 PXB 指向上一个备份的目录（这决定了起始 LSN）。

步骤 1：执行全量基础备份

在进行任何增量快照之前，必须创建一个完整、一致的基础备份。这为整个备份链奠定了基础。

我们首先定义目录结构：

# 定义全量备份的基础目录
BASE_DIR="/data/backups/2023-10-01_FULL"

# 创建目录
mkdir -p $BASE_DIR

# 执行全量备份
xtrabackup --backup \n  --target-dir=$BASE_DIR \n  --user=root --password=secret_password \n  --datadir=/var/lib/mysql

# 验证全量备份的 LSN
cat $BASE_DIR/xtrabackup_checkpoints | grep 'to_lsn'

注意： 开始备份过程时，target-dir 必须为空或不存在。始终使用具有适当权限的凭据（例如 RELOAD、LOCK TABLES、PROCESS、SUPER 权限）。

步骤 2：进行第一次增量备份

要执行第一次增量备份，我们必须使用 --incremental-basedir 标志引用全量基础备份目录。PXB 将读取基础备份中的 to_lsn，并且只复制自该点以来发生更改的页面。

# 定义第一次增量备份的目录
INCREMENTAL_1_DIR="/data/backups/2023-10-02_INC1"

# 执行增量备份，引用全量基础备份
xtrabackup --backup \n  --target-dir=$INCREMENTAL_1_DIR \n  --incremental-basedir=/data/backups/2023-10-01_FULL \n  --user=root --password=secret_password

步骤 3：链接后续增量备份

对于任何后续的增量备份（INC2、INC3 等），--incremental-basedir 必须指向紧邻的前一个增量备份目录。

如果我们想基于自 INC1 以来发生的变化来创建 INC2：

# 定义第二次增量备份的目录
INCREMENTAL_2_DIR="/data/backups/2023-10-03_INC2"

# 执行增量备份，引用上一个增量备份 (INC1)
xtrabackup --backup \n  --target-dir=$INCREMENTAL_2_DIR \n  --incremental-basedir=/data/backups/2023-10-02_INC1 \n  --user=root --password=secret_password

这种链接会一直持续，只要您保持顺序不中断。如果链条中的任何一个环节断裂（即目录丢失），恢复过程将会失败。

恢复：应用增量更改

恢复增量备份集是一个多步骤过程，涉及按顺序将更改应用于基础备份。与全量备份不同，增量备份不能直接复制到数据目录。

恢复阶段 1：准备基础备份

首先，必须准备基础备份。这通常在一个临时暂存区域中完成，以确保数据安全。

准备基础备份时，PXB 执行两个基本操作：
1. 应用已提交的事务（重做日志）。
2. 回滚未提交的事务。

我们使用 --prepare 标志，但关键是添加 --apply-log-only 标志。这可以防止 PXB 回滚未提交的事务，因为后续的增量日志需要这些事务片段才能完成恢复。

# 定义暂存目录
RESTORE_TARGET="/data/restore_staging"

# 将全量基础备份文件复制到暂存区域
rsync -avr /data/backups/2023-10-01_FULL/ $RESTORE_TARGET

# 准备基础备份，使其可用于增量操作
xtrabackup --prepare --target-dir=$RESTORE_TARGET --apply-log-only

# 查找确认信息：'completed OK!'

恢复阶段 2：按顺序应用增量备份

接下来，按它们被拍摄的确切时间顺序应用每个增量备份。每个命令都必须引用暂存目录（当前正在修改的基础备份），并使用指向特定增量快照的 --incremental-dir 标志。

# 应用增量 1
xtrabackup --prepare --target-dir=$RESTORE_TARGET \n  --incremental-dir=/data/backups/2023-10-02_INC1 \n  --apply-log-only

# 应用增量 2
xtrabackup --prepare --target-dir=$RESTORE_TARGET \n  --incremental-dir=/data/backups/2023-10-03_INC2 \n  --apply-log-only

# ... 继续处理所有需要的增量 ...

恢复阶段 3：最终准备

一旦应用了最后一个所需的增量快照，请运行最终准备步骤，不要使用 --apply-log-only 标志。这允许 PXB 执行最终清理，回滚在整个备份序列中仍未提交的任何事务，从而达到一致状态。

# 最终准备（无 --apply-log-only）
xtrabackup --prepare --target-dir=$RESTORE_TARGET

# 重要提示：查找指示“xtrabackup: Recovery completed OK!”的最终确认信息

恢复阶段 4：将数据复制回 MySQL

成功准备后，暂存目录 ($RESTORE_TARGET) 中的数据是一致的，可供 MySQL 服务器使用。

停止 MySQL 服务。
确保 MySQL 数据目录为空或已备份（可选：如果允许，使用 --move-back 选项，但对于恢复而言，--copy-back 更安全）。
使用 xtrabackup --copy-back 移动文件。
修复权限。
重新启动 MySQL。

# 停止 MySQL 服务
service mysql stop

# 将准备好的文件复制回 MySQL 数据目录
xtrabackup --copy-back --target-dir=$RESTORE_TARGET

# 确保文件所有权正确
chown -R mysql:mysql /var/lib/mysql

# 启动 MySQL
service mysql start

增量备份管理的最佳实践

自动化和脚本编写

增量备份策略在完全自动化时最为有效。脚本应自动管理 LSN 链接，动态识别要用于 --incremental-basedir 标志的最新备份目录。

保留策略

增量链可能会变得非常长，导致恢复变慢。一种常见的最佳实践是祖父-父辈-子辈 (GFS) 策略或差异增量备份（其中所有增量都引用全量基础备份）。定期执行新的全量备份来滚动更新链条，从而启动一个新的、较短的链条。

压缩和限速

对于非常繁忙的服务器，请考虑在备份阶段使用 --throttle 选项来限制 I/O 操作。使用 --compress 来减小备份大小，这对增量备份生成的小型数据集非常有益。

# 带有压缩和限速的示例
xtrabackup --backup \n  --target-dir=$INCREMENTAL_3_DIR \n  --incremental-basedir=$INCREMENTAL_2_DIR \n  --compress \n  --throttle=100

使用 Percona XtraBackup 配置 MySQL 增量备份