4.3.6 进行乐观备份

乐观备份是一种用于提高备份和恢复大型数据库性能的特性，其中只有少量表被频繁修改。

在对一个巨大的数据库（例如，以 TB 为单位）进行热备份时，备份过程中可能会在服务器上生成巨大的重做日志文件。由于重做日志文件的增长速度超过了 mysqlbackup 处理它们的速度 ，当mysqlbackup无法赶上重做日志周期并且 LSN 在被mysqlbackup读取之前被服务器覆盖时，备份操作实际上可能会失败。此外，为恢复准备备份apply-log的步骤 可能需要很长时间，因为 mysqlbackup有巨大的 ibbackup_logfile文件（从大重做日志文件创建）应用于备份。当备份和恢复过程中可用于读写重做日志的 I/O 资源不足时，问题会更加严重。

乐观备份通过将备份过程分为两个内部阶段来缓解这些问题，这两个阶段对用户是透明的：

  1. 乐观阶段：在第一阶段，备份过程中不太可能被修改的表（在下面称为“非活动表”，由用户使用 optimistic-time选项标识，或者通过排除，使用 optimistic-busy-tables选项标识）在没有备份的情况下进行备份锁定 MySQL 实例。并且因为这些表在备份完成之前不会被更改，所以重做日志、撤消日志和系统表空间 在这个阶段 不会被mysqlbackup备份。

  2. 正常阶段：在第二阶段，在第一阶段未备份的表（以下称为 “繁忙表”）正在以类似于在普通备份中处理它们的方式进行备份：InnoDB 文件首先复制，然后复制其他相关文件，并在锁定 MySQL 实例的情况下复制或处理。重做日志、撤消日志和系统表空间也在此阶段进行备份。

optimistic-time只要使用或 optimistic-busy-tables选项， 就会发生乐观备份 。有关如何使用这些选项，请参阅第 16.10 节“性能/可伸缩性/容量选项”中的详细说明。如果正如预期的那样，由 optimistic 选项标识的非活动表列表在备份期间没有改变（或者，即使它改变了很小的百分比），大多数用户会发现整体备份时间与普通备份相比显着减少备份，因为要备份的重做日志数据的大小将小得多。此外，备份的恢复时间也将减少，因为 apply-log由于较小的重做日志，操作会快得多。然而，如果事实证明在备份过程中标识的非活动表列表发生了很大一部分更改，则执行乐观备份的好处将变得有限，在最坏的情况下，乐观备份实际上可能需要更长的时间来执行和，对于单个文件的备份，与普通备份相比，备份的大小会更大。 因此，用户在尝试执行乐观备份 时应谨慎识别哪些表“不活动”，哪些表“繁忙” 。

笔记

不能为增量备份或使用可 传输表空间 (TTS)的备份执行乐观备份。

以下示例说明了如何进行乐观备份。

示例 4.25 使用选项的开放式备份 optimistic-time=YYMMDDHHMMSS

在本例中，将自2011年5月16日中午以来修改过的表视为繁忙表，并在乐观备份的正常阶段进行备份，其他所有表在乐观阶段进行备份： 

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516120000 backup-to-image

示例 4.26 使用选项的乐观备份optimistic-time=now

在此示例中，所有表都被视为非活动表并在乐观备份的乐观阶段进行备份： 

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup-to-image

示例 4.27 使用optimistic-busy-tables 选项的开放式备份

在此示例中，名称中mydatabase 带有前缀的mytables-表被视为繁忙表并在乐观备份的正常阶段进行备份，而所有其他表在乐观阶段进行备份： 

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*"  backup

当您同时使用optimistic-time和 optimistic-busy-tables选项并且它们在确定哪些表将成为繁忙表时发生冲突时， optimistic-busy-tables优先于 optimistic-time. 例如：

optimistic-busy-tables示例 4.28 同时使用和 optimistic-time选项的乐观和部分备份

在此示例中，名称中mydatabase 带有前缀的mytables-表被视为繁忙表并在正常阶段进行备份，即使它们自 2010 年 5 月 16 日以来未被修改，时间由 optimistic-time： 

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*"  \
--optimistic-time=100516 backup


一起使用乐观备份和乐观增量备份

通过在备份计划中同时使用乐观备份和 乐观增量备份，您可以加快大型数据库的备份速度，尤其是当自某个时间以来只有相对少量的表被修改并且没有多少表被频繁修改时. 下面是一个示例命令序列，说明了使用这两个功能的每周备份计划；它还包括将数据恢复到某一天的步骤。 

# A full optimistic backup performed on 2017/02/04, Sat, at 1130 PM.
# The --optimistic-time option is used to specify an optimistic time of 2016/08/16, 0800 PM 

mysqlbackup --defaults-file=/home/admin/my.cnf --optimistic-time=160816200000 \ 
  --backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
  --with-timestamp \
  backup-to-image   

# A sequence of optimistic incremental backups are then performed on each the following six days at 1130 PM
# On Sunday, 2017/02/05 
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
  --with-timestamp \
  backup-to-image
# On Monday, 2017/02/06
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
  --with-timestamp \
  backup-to-image
# On Tuesday, 2017/02/07
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
  --with-timestamp \
  backup-to-image
# On Wednesday, 2017/02/08
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702082330.bi \
  --with-timestamp backup-to-image
# On Thursday, 2017/02/09
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702092330.bi \
  --with-timestamp \
  backup-to-image
# On Friday, 2017/02/10
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702102330.bi \
  --with-timestamp \
  backup-to-image

# Another full optimistic backup is performed on Saturday, 2017/02/11
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516200000 \  
 --backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702112330.bi \
  --with-timestamp \
  backup-to-image

# Restore the database to its state at Tuesday, 2017/02/07, at 11:30 PM
# First, restore the full optimistic backup taken on the Saturday before, which was 2017/02/04:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \
  --with-timestamp \
  copy-back-and-apply-log
# Next, restore the optimistic incremental taken on the Sunday, Monday, and Tuesday that follow:  
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log