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