[官翻]mysqlbackup的乐观备份

1. 乐观备份可以用来提升备份和恢复体量比较大的数据库（只有少量的表经常变更）的性能。
   2)在大型数据库的热备份过程中（例如，以TB为单位），当备份进行时，可能会在服务器上生成巨大的重做日志文件。由于重做日志文件的增长速度快于mysqlbackup处理的速度，因此当mysqlbackup无法赶上重做日志周期，并且LSN在被mysqlbackup读取之前被服务器覆盖时，备份操作实际上可能会失败。此外，准备恢复备份的apply-log步骤可能需要很长时间，因为mysqlbackup有大量的ibbackup_logfile文件（从大型重做日志文件创建）要应用于备份。在备份和恢复过程中，当可用于读取和写入重做日志的I/O资源稀缺时，问题会加剧。
2. 乐观备份通过将备份过程分为两个内部阶段来缓解问题，这两个阶段对用户是透明的：
   a. 乐观阶段：在第一阶段，备份过程中不太可能修改的表（以下称为“inactive tables”，由用户使用optimistic-time选项标识，或者排除使用optimistic-busy-tables选项标识）将在MySQL实例上不加任何锁的情况下进行备份。由于这些表在备份完成之前不会更改，因此在这个阶段，mysqlbackup不会备份redo log、undo log和系统表空间。
   b. 正常阶段：在第二阶段中，第一阶段未备份的表（以下称为“busy tables”）的备份方式与普通备份中的处理方式类似：首先复制InnoDB文件，然后复制其他相关文件，并在不同时间对数据库应用各种锁进行复制或处理。redo log、undo log和系统表空间在这个阶段被备份
3. 只要使用 optimistic-time或者 optimistic-busy-tables选项，就会进行乐观备份。如果如预期的那样，乐观选项标识的inactive table列表在备份过程中没有更改（或者，即使更改了很小的百分比），大多数用户会发现，与普通备份相比，总体备份时间显著缩短，因为要备份的重做日志数据的大小要小得多。此外，备份的恢复时间也将减少，因为由于重做日志较小，apply-log操作将更快。但是，如果发现在备份过程中，所标识的非活动表的列表有很大一部分发生了更改，则执行乐观备份的好处将变得有限，而且在最坏的情况下，乐观备份实际上可能需要更长的时间才能执行。对于单个文件备份，与普通备份相比，备份的大小会更大。因此，用户在尝试执行乐观备份时，应小心识别哪些表“inactive”，哪些表“busy”。
4. 注意：
   a. 对于增量备份或使用可传输表空间（TTS）的备份，不能执行乐观备份。
   b. 不要在服务器上与乐观备份并行执行DDL操作，否则备份将失败。
5. 使用optimistic-time=YYMMDDHHMMSS选项的乐观备份（自2011年5月16日中午起修改的表被视为busy tables，并在乐观备份的正常阶段进行备份，所有其他表都在乐观阶段进行备份：）
   mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516120000
   --backup-image= --backup-dir= backup-to-image
6. 使用optimistic-time=now选项的乐观备份（所有表被标识为inactive tables并在乐观备份的乐观阶段备份）
   mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=now \
   --backup-image= --backup-dir= backup-to-image
7. 使用optimistic-busy-tables选项的乐观备份
   mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase.mytables-.*"
   --backup-image= --backup-dir= backup
8. 使用ptimistic-busy-tables和 optimistic-time 选项的乐观部分备份（mydatabase中名称中以mytables为前缀的表被视为繁忙表，并在正常阶段进行备份，即使自2010年5月16日（乐观时间指定的时间）以来未进行过修改：）
   mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase.mytables-.*"
   --optimistic-time=100516 --backup-image= --backup-dir= backup
   注意：如果同时使用ptimistic-busy-tables和optimistic-time选项，并且它们在确定哪些表是繁忙表时发生冲突，则ptimistic-busy-tables优先于optimistic-time。
9. 使用乐观备份和乐观增量备份
   通过在备份计划中同时使用乐观备份和乐观增量备份，您可以加快大型数据库的备份速度，尤其是当自某个时间以来只有相对较少的表被修改，并且没有多少表被频繁修改时。

# 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=/home/dbadmin/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================
# 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