4.3.3 制作差异备份或增量备份_MySQL 企业备份用户指南（版本 8.0.31）

MySQL 企业备份用户指南（版本 8.0.31） / 第二部分使用 MySQL 企业备份 / 第 4 章备份数据库服务器 / 4.3 备份场景和示例 / 4.3.3 制作差异备份或增量备份

4.3.3 制作差异备份或增量备份

假设你的 MySQL 服务器上的大部分数据随着时间的推移保持不变，你可以提高速度并减少定期备份所需的存储空间，方法是每次不备份服务器上的所有数据，而只备份对随时间发生的数据。为此，在首先制作包含所有数据的完整备份后，您可以执行以下操作之一：

执行一系列差异备份。 每个差异备份都包括自上次执行完整备份以来对数据所做的所有更改。例如，要将数据恢复到 time t，您只需首先恢复完整备份，然后在其之上恢复 time 的差异备份 t。
执行一系列增量备份。 每次增量备份仅包括自上次备份以来的更改，上次备份本身可以是完整备份或增量备份。增量系列中的第一个备份始终是差异备份；但在那之后，每个增量备份只包含自上次增量备份以来所做的更改。因此，每个后续的增量备份通常比差异备份更小，而且制作起来更快；这允许您进行非常频繁的增量备份，然后使您能够在必要时将数据库还原到更精确的时间点。但是，使用增量备份恢复数据可能需要更长的时间和更多的工作：一般来说，t，从恢复全量备份开始，然后逐个恢复增量备份，直到完成时间t的增量备份。

MySQL Enterprise Backup 支持增量备份和差异备份。您应该通过查看诸如您拥有多少存储空间、您必须能够以多快的速度恢复数据等因素来决定采用哪种备份策略。

MySQL Enterprise Backup 将差异备份视为以完整备份为基础的增量备份的特例。要创建差异备份，只需按照以下说明执行增量备份，并确保指定完整备份作为增量备份的基础；您还应该忽略任何仅适用于处理多个增量备份的说明。

笔记

对于 MySQL Enterprise Backup 8.0.17 及更高版本，您可以使用该选项轻松创建差异备份 --incremental-base=history:last_full_backup。

有关用于增量备份的mysqlbackup选项的描述，请参阅第 20.7 节，“增量备份选项” 。使用以下两个选项之一启用增量备份：和选项。有关它们的区别，请参阅仅使用重做日志创建增量备份。--incremental--incremental-with-redo-log-only

创建增量备份时，必须向 mysqlbackup指示上一次完全备份或增量备份的时间点。为方便起见，您可以使用该选项从存储在先前备份目录或服务器上的元数据中--incremental-base自动派生必要的日志序列号(LSN)。或者，您可以使用该选项指定一个明确的 LSN 值 --start-lsn，向 mysqlbackup提供来自先前完整或增量备份的结束 LSN（有关使用该选项时适用的一些限制，请参阅增量备份的其他注意事项 --start-lsn）。

要准备要恢复的备份数据，您可以将所有增量备份与原始完整备份结合起来。通常，您会在指定的时间段后执行新的完整备份，之后您可以丢弃较旧的增量备份数据。

仅使用重做日志创建增量备份

与创建增量备份的选项相比，这--incremental-with-redo-log-only 可能会带来一些好处：--incremental

InnoDB 表的更改是根据InnoDB 重做日志的内容确定的。由于重做日志有一个您事先知道的最大大小，具体取决于数据库的大小、DML 活动的数量和重做日志的大小，通常需要较少的 I/O 来读取重做中的更改log 而不是扫描 InnoDB 表空间文件以定位更改的页面。
对于 MySQL 8.0.30 及更高版本：重做日志的维护方式已更改。系统变量， innodb_redo_log_capacity现在控制重做日志文件占用的磁盘空间量。如果重做日志文件占用的空间小于的值 innodb_redo_log_capacity，则脏页从缓冲池刷新到表空间数据文件的积极性较低，从而允许重做日志文件占用的磁盘空间增长得更快。如果重做日志文件占用的空间接近指定值，则更积极地刷新脏页，从而使重做日志文件占用的磁盘空间保持在指定限制内。看配置重做日志容量（MySQL 8.0.30 或更高版本）了解详细信息。
按照现在重做日志的维护方式，更有可能在启动仅使用重做日志的增量备份时，存储自上次备份以来数据库更改的重做日志文件已经处理完毕，不再可用。为了防止这种情况，您应该mysqlbackup在创建要包含在重做日志中的任何数据之前，通过以下 UDF 命令向服务器注册（创建备份的 MySQL 用户）作为重做日志的外部使用者仅增量备份：
```
DO innodb_redo_log_consumer_register();
```
这可以防止 InnoDB 删除或回收包含mysqlbackup 尚未备份的事务的重做日志文件。在每次仅重做日志增量备份后，运行以下 UDF 以前进到新的 LSN 检查点，以便服务器现在可以处理mysqlbackup不再需要的重做日志文件：
```
DO innodb_redo_log_consumer_advance($lsn);
```
$lsn是完成的增量备份中包含的最高 LSN 值。
上述步骤假设启动DO innodb_redo_log_consumer_register();UDF 的连接会话在基本备份或最后一次增量备份与最新的仅重做日志增量备份之间保持打开状态。帮助确保这一点的一种方法是让服务器在同一台机器上生成一个特殊的客户端，该客户端通过例如 Unix 套接字（如果它是 Unix 机器）通过启动 UDF 的连接会话连接到服务器，并且是然后在需要时保持打开状态。mysqlbackup该设置将提供一个稳定的连接会话，以作为重做日志的使用者保留。
对于 MySQL 8.0.29 及更早版本：由于重做日志文件充当循环缓冲区，随着新 DML操作的发生，旧更改的记录将被覆盖，因此您必须按照日志大小规定的可预测计划进行新的增量备份文件和为您的工作负载生成的重做数据量。否则，重做日志可能无法回溯到足以记录自上次增量备份以来的所有更改，在这种情况下mysqlbackup将很快确定它无法继续并返回错误。您的备份脚本应该能够捕获该错误，然后使用该 --incremental选项执行增量备份。
例如：
- 要计算重做日志的大小，请发出命令 SHOW VARIABLES LIKE 'innodb_log_file%'并根据输出将 innodb_log_file_size 设置乘以的值 innodb_log_files_in_group。要计算物理级别的重做日志大小，请查看datadirMySQL 实例的目录并汇总与模式匹配的文件的大小ib_logfile*。
- InnoDB LSN值对应于写入重做日志的字节数。要在某个时间点检查 LSN，请发出命令 SHOW ENGINE INNODB STATUS并查看 LOG标题下的内容。在规划备份策略时，定期记录 LSN 值，并从当前值中减去较早的值，以计算每小时、每天等生成了多少重做数据。
--start-lsn这种类型的增量备份不像标准--incremental选项那样容忍太低的值。例如，您不能进行完整备份，然后 --incremental-with-redo-log-only 使用相同的--start-lsn 值进行一系列备份。确保将上一次备份的精确结束LSN指定为下一次增量备份的开始LSN；不要使用任意值。

笔记

为确保 LSN 值在连续增量备份之间完全匹配，建议您在使用该 --incremental-base选项时始终使用该 --incremental-with-redo-log-only 选项。
判断这种增量备份对于特定的MySQL实例是否实用和高效：
- 测量 InnoDB 重做日志文件中数据变化的速度。定期检查LSN 以确定在几个小时或几天内累积了多少重做数据。
- 将重做日志累积的速率与重做日志容量进行比较，并使用该比率查看进行增量备份的频率。例如，如果您每天生成 1GB 的重做日志数据，并且您的重做日志容量的组合大小（ innodb_redo_log_capacity 对于 MySQL Server 8.0.30 及更高版本由指定，或者是 {value of innodb_log_files_in_group * value of innodb_log_file_size} 对于 MySQL Server 8.0.29 及更早版本）是 7GB，您将安排比每周一次更频繁的增量备份。您可能每隔一两天执行一次增量备份，以避免在突然更新产生比平时更多的重做日志数据时出现潜在问题。
- 基准增量备份时间同时使用 --incremental和 --incremental-with-redo-log-only 选项，以确认重做日志备份技术是否比传统的增量备份方法执行得更快并且开销更少。结果可能取决于数据的大小、DML 活动的数量以及重做日志的容量。在具有实际数据量和实际工作负载的服务器上进行测试。例如，如果您有巨大的重做日志文件，在增量备份过程中读取它们可能需要与使用传统增量技术读取 InnoDB 数据文件一样长的时间。反之，如果你的数据量很大，
- 当您仅使用重做日志执行增量备份时，不支持备份压缩（即使用压缩选项）。如果备份压缩对您很重要，请不要使用该 --incremental-with-redo-log-only 选项。

使用页面跟踪的增量备份

对于 MySQL Enterprise Backup 8.0.18 及更高版本： mysqlbackup支持使用 MySQL Server 的页面跟踪功能创建增量备份， mysqlbackup通过该功能在 InnoDB 数据文件中查找自上次备份以来已修改的更改页面，然后复制它们。通常，如果数据库中的大部分数据未被修改，使用页面跟踪的增量备份比 mysqlbackup执行的其他类型的增量备份更快。使用此功能需要在进行增量备份的基本备份之前在服务器上完成以下操作：

通过在连接到服务器的mysqlmysqlbackup客户端上运行以下命令来安装 MySQL Enterprise Server 8.0 安装附带的组件：
```
INSTALL COMPONENT "file://component_mysqlbackup";
```
使用以下函数启动页面跟踪：
```
SELECT mysqlbackup_page_track_set(true);
```
此函数返回从其开始跟踪已更改页面的 LSN 值：
```
SELECT mysqlbackup_page_track_get_start_lsn();
```
您可以使用以下功能停止页面跟踪：
```
SELECT mysqlbackup_page_track_set(false);
```

笔记

前面提到的有关页面跟踪的功能需要BACKUP_ADMIN权限才能运行。

当在--incremental没有指定任何值的情况下使用该选项时，mysqlbackup 使用页面跟踪功能执行增量备份。用户还可以指定 --incremental=page-track让 mysqlbackup使用页面跟踪功能。但是，使用页面跟踪功能进行增量备份的先决条件是：

页面跟踪在服务器上正常运行，并且SELECT mysqlbackup_page_track_set(true)在创建基本备份之前已启用（使用）；如果不是这种情况， mysqlbackup在时抛出错误 --incremental=page-track，或者在未指定时执行全扫描增量备份 --incremental。
修改页数小于总页数的50%；如果不是这种情况， mysqlbackup在时抛出错误 --incremental=page-track，或者在未指定时执行全扫描增量备份 --incremental。

笔记

mysqlbackup需要启动时有足够的内存来处理内存中所有被跟踪的页面。如果内存不足， mysqlbackup会抛出一个错误然后退出。以下是确保操作有足够内存的一些准则：

该 --limit-memory选项的默认值 400 [MB] 允许 mysqlbackup处理大约 800GB 的更改数据。根据您的数据大小调整选项的值。
页面跟踪功能使用为mysqlbackup配置的内存缓冲区对页面进行排序。通过以下步骤确定页面排序所需的缓冲区数：
- 在运行增量备份之前，在服务器上执行以下查询以确定 end_lsn基本备份：
```
SELECT end_lsn FROM mysql.backup_history WHERE exit_state = 'SUCCESS' 
AND backup_type != 'TTS' AND server_uuid = @@server_uuid 
ORDER BY end_time DESC, end_lsn DESC LIMIT 0,1;
```
- 在服务器上运行以下查询以获取自创建基本备份以来更改的页面数（如果返回负值则重试查询）：
```
SELECT mysqlbackup_page_track_get_changed_page_count(<the above end_lsn>, 0);
```
- 每个更改的页面在排序缓冲区中需要 8 个字节。所以，将 changed_page_count上一步得到的值乘以8，得到排序缓冲区需要的字节数。
- 每个缓冲区有 16 兆字节（16777216 字节）。因此，将上一步计算的排序缓冲区所需的字节数除以 16777216，并将结果四舍五入为下一个整数，得到排序所需的缓冲区数。
- 确保该选项的值 --number-of-buffers不小于您在上一步中计算的所需排序缓冲区的数量。请记住，在进行此计算时可能会创建更多已更改的页面，因此您可能希望为 mysqlbackup提供更多额外的缓冲区。
400MB的默认内存限制应该能够支持最多25个缓冲区（最多18个缓冲区仅用于云备份）；如果您需要比通过更改 --limit-memory选项的值更多的缓冲区增加内存限制。

对于 MySQL Enterprise Backup 8.0.28 及更高版本：页面跟踪在服务器的数据目录下创建一个文件，用于收集有关已更改页面的信息。该文件不断增长，直到停止页面跟踪。如果服务器停止并重新启动，则会创建一个新的页面跟踪文件，但旧文件会保留并继续增长，直到页面跟踪被明确停用。使用类似于以下的一系列 SQL 语句，您可以清除不再需要的任何旧页面跟踪数据：

SELECT mysqlbackup_page_track_set(false); 
SELECT mysqlbackup_page_track_purge_up_to(9223372036854775807);
/* Supply to he loadable function the LSN up to which you want to 
purge page tracking data. 9223372036854775807 is the highest possible LSN, 
which causes all page tracking files to be purged.*/
SELECT mysqlbackup_page_track_set(true);

例如，这可以在每次完整备份之前运行。

全扫描与乐观增量备份

当该--incremental选项设置为时full-scan，mysqlbackup 执行全扫描增量备份，其中它扫描服务器数据目录中的所有 InnoDB 数据文件以查找自上次备份以来已更改的页面，然后复制这些页面。当自上次备份以来修改的表不多时，全扫描增量备份可能效率不高。

另一方面，乐观增量备份仅扫描自上次备份以来已修改的 InnoDB 数据文件中的更改页，从而节省了一些不必要的扫描时间。可以通过指定执行乐观增量备份 --incremental=optimistic。虽然乐观增量备份可能会缩短备份时间，但它有以下限制：

由于此功能利用了服务器数据目录中文件的修改时间，因此自上次备份以来有两件事必须保持不变：(1) 服务器上的系统时间，以及 (2) 数据目录的位置。否则，备份可能会失败，或者可能会生成不一致的增量备份。
无法使用执行乐观增量备份 --incremental-with-redo-log-only，为此mysqlbackup读取重做日志文件而不是扫描数据目录中的文件。
如果--start-lsn使用该选项，则即使 --incremental=optimistic 指定也会执行完整扫描，因为在这种情况下， mysqlbackup无法确定先前备份一致的时间点，因此没有时间范围来确定最近修改了哪些文件.

对于这些和其他不需要乐观增量备份的情况，执行全扫描增量备份，或使用页面跟踪的增量备份（对于 MySQL Enterprise Backup 8.0.18 及更高版本）。有关mysqlbackup执行乐观增量备份所需的权限，请参阅第 4.1.2 节，“将 MySQL 权限授予备份管理员” 。另请参阅同时使用乐观备份和乐观增量备份，了解如何在备份计划中同时使用这两个功能。

对于 MySQL Enterprise Backup 8.0.17 及更早版本，全扫描备份是增量备份的默认方法，如果没有为指定值，则使用该方法 --incremental。

增量备份的其他注意事项

增量备份功能主要用于 InnoDB 表，或只读或很少更新的非 InnoDB 表。增量备份检测InnoDB 数据文件中页面级别的更改，而不是表行；已更改的每个页面都已备份。因此，空间和时间的节省与更改的 InnoDB 行或列的百分比不完全成比例。

对于非 InnoDB 文件，整个文件始终包含在增量备份中，这意味着与 InnoDB 表的情况相比，备份资源的节省并不显着。

--start-lsn如果使用该选项，则不会将二进制日志文件复制到增量备份中。要包括增量备份所涵盖期间的二进制日志文件，请改用该 --incremental-base选项，它为 mysqlbackup提供必要的信息，以确保上一次备份中包含的二进制日志数据与当前增量备份之间不存在间隙。

增量备份示例

这些示例使用mysqlbackup对 MySQL 服务器进行增量备份，包括所有数据库和表。我们展示了两种选择，一种使用 --incremental-base选项，另一种使用--start-lsn选项。

使用该--incremental-base选项，您不必跟踪一个备份和下一个备份之间的 LSN 值。相反，您可以执行以下操作之一：

告诉mysqlbackup使用或（对于 8.0.17 及更高版本）从服务器上的表中记录end_lsn的最后一次成功的非 TTS 备份中查询值。backup_history--incremental-base=history:last_backuphistory:last_full_backup
Advanced：对于目录备份，用指定上一次备份（完整或增量）的目录， mysqlbackup将根据之前备份的元数据确定本次备份的起点。因为您需要一组已知的目录名称，所以您可能希望使用硬编码名称或在您自己的备份脚本中生成一系列名称，而不是使用该选项。如果您上次备份是单个文件，您仍然可以使用来提供您在上次备份期间随选项 --incremental-base=dir:directory_path--with-timestamp--incremental-base=dir:directory_path--backup-dir

在以下示例中， --incremental-base=history:last_backup 使用了选项，假设mysqlbackup从表中获取最后一次成功（非 TTS）完整或部分备份的 LSN，并mysql.backup_history基于该选项执行增量备份。

mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
  --incremental --incremental-base=history:last_backup \
  --backup-dir=/home/dbadmin/temp_dir \
  --backup-image=incremental_image1.bi \
   backup-to-image

在下面的示例中，将执行与上一个示例类似但本质上是乐观的增量备份。

mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/dbadmin/temp_dir \
  --backup-image=incremental_image1.bi 
   backup-to-image

Advanced：使用以下命令使用选项创建增量目录备份；备份保存在指定的位置： --incremental-base=dir:directory_path--incremental-backup-dir

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup

您还可以使用该--start-lsn 选项来指定增量备份应该从哪里开始。你必须在备份结束时记录 mysqlbackup报告的先前备份的 LSN ：

mysqlbackup: Was able to parse the log up to lsn 2654255716

该号码也记录在备份期间meta/backup_variables.txt指定的文件夹中的文件中。然后使用该选项--backup-dir将该数字提供给 mysqlbackup 。--start-lsn然后增量备份包括指定 LSN 之后的所有更改。

要使用该选项创建增量备份映像 --start-lsn，请使用以下命令，指定--backup-dir备份目录，在本例中，该目录用于存储备份元数据和一些临时文件：

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --backup-dir=/incr-tmp \
  --backup-image=/incr-backup/incremental_image.bi \
  backup-to-image

但在下面的示例中，由于 --backup-image没有提供要创建的映像文件的完整路径，因此增量备份映像是在指定的文件夹下创建的 --backup-dir：

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --backup-dir=/incr-images \
  --backup-image=incremental_image1.bi \
  backup-to-image

维护备份计划：

根据日期或数据库活动量确定的定期计划，进行更多的增量或差异备份。
或者，通过进行完整、未压缩或压缩的备份，定期重新开始循环。通常，这个里程碑发生在您可以存档和清除最旧的备份数据时。