10bet网址
MySQL企业备份4.0用户指南
相关的文档10bet官方网站 下载本手册
PDF(美国Ltr)- 1.2 mb
PDF (A4)- 1.2 mb


4.3.3执行差异备份/增量备份

假设MySQL服务器上的大部分数据随着时间的推移保持不变,您可以通过每次不备份服务器上的所有数据而只备份随时间发生的数据更改来提高速度并减少定期备份所需的存储空间。为此,在进行包含所有数据的完全备份后,您可以执行以下操作之一:

  • 执行一系列差异备份。每一个微分备份包括自执行最后一次完全备份以来对数据所做的所有更改。将数据恢复到(例如,时间)为止t在美国,您只需首先恢复完全备份,然后在此基础上恢复不同时间的差异备份t

  • 执行一系列增量备份。每一个增量备份只包括上一次备份以来的更改,上一次备份本身可以是完全备份或增量备份。增量系列中的第一个备份总是差分备份;但是在此之后,每个增量备份只包含自上次增量备份以来所做的更改。因此,后续的增量备份通常比差异备份的大小更小,并且更快;这允许您非常频繁地进行增量备份,然后允许您在必要时将数据库恢复到更精确的时间点。但是,使用增量备份恢复数据可能需要更长的时间和更多的工作:通常,恢复数据到(例如)时间t,首先恢复完全备份,然后逐个恢复增量备份,直到完成时间t的增量备份。

MySQL企业备份支持增量备份和差异备份。您应该根据您拥有多少存储空间、您必须能够多快地恢复数据等因素来决定采用哪种备份策略。

MySQL企业备份将差异备份视为以完全备份为基础的增量备份的一种特殊情况。要创建差异备份,只需遵循下面执行增量备份的说明,并确保使用下面描述的方法指定完全备份作为增量备份的基础;您还应该忽略仅适用于处理多个增量备份的任何说明。

看到第15.7节“增量备份选项”的描述mysqlbackup用于增量备份的选项。通过以下选项之一启用增量备份:——增量而且——incremental-with-redo-log-only选择。看到仅使用重做日志创建增量备份因为他们的不同。

创建增量备份时,必须指示mysqlbackup上一次全量备份或增量备份的时间点。为方便起见,您可以使用——incremental-base选项自动派生必要的日志序号(LSN)从存储在以前备份目录或服务器上的元数据中获取。方法指定显式LSN值——start-lsn选项,提供给mysqlbackup以前的完全备份或增量备份的结束LSN(参见增量备份的其他注意事项的某些限制——start-lsn选项)。

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

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

——incremental-with-redo-log-only可能会带来一些好处——增量创建增量备份选项:

  • 的内容决定了对InnoDB表的更改InnoDB重做日志.因为重做日志文件有一个你预先知道的固定大小,所以从它们中读取更改比扫描InnoDB表空间文件来定位更改的页面需要更少的I/O,这取决于你的数据库的大小、DML活动的数量和重做日志文件的大小。

  • 因为重做日志文件作为一个循环缓冲区,旧的更改记录被覆盖为新的DML操作发生时,您必须按照可预测的时间表进行新的增量备份,该时间表由日志文件的大小和为您的工作负载生成的重做数据量决定。否则,在这种情况下,重做日志可能无法回溯到足够远的时间来记录自上一次增量备份以来的所有更改mysqlbackup将迅速确定它不能继续并返回一个错误。您的备份脚本应该能够捕获该错误,然后使用——增量选项。

    例如:

    • 要计算重做日志的大小,可以发出以下命令显示变量'innodb_log_file%'然后,根据输出,乘以innodb_log_file_size的值设置innodb_log_files_in_group.要计算物理级别的重做日志大小,请查看datadir目录,并计算出与模式匹配的文件的大小ib_logfile *

    • InnoDB的LSN值对应写入重做日志的字节数。当需要查看某个时间点的LSN时,可以使用该命令显示引擎innodb状态看看下面日志标题。在规划备份策略时,定期记录LSN值,并从当前值中减去较早的值,以计算每小时、每天等产生多少重做数据。

    在MySQL 5.5之前,通常的做法是保持重做日志相当小,以避免在MySQL服务器被杀死而不是正常关闭时花费很长的启动时间。用MySQL 5.5及以上版本,性能为崩溃恢复有显著改善,如优化InnoDB配置变量,所以你可以让你的重做日志文件更大,如果这有助于你的备份策略和数据库工作负载。

  • 这种类型的增量备份对过低的备份并不宽容——start-lsn价值观为标准——增量选择是。例如,不能先进行完全备份,然后再进行一系列备份——incremental-with-redo-log-only所有备份都使用相同的——start-lsn价值。确保将上一次备份的精确结束LSN指定为下一次增量备份的开始LSN;不要使用任意值。

    请注意

    为确保连续增量备份之间的LSN值完全匹配,建议始终使用——incremental-base选项时使用——incremental-with-redo-log-only选择。

  • 要判断这种类型的增量备份对于特定的MySQL实例是否实用和有效:

    • 测量InnoDB重做日志文件中数据变化的速度。检查LSN周期性地确定重做数据在某几个小时或几天的过程中累积了多少。

    • 比较重做日志的累积速率和重做日志文件的大小。使用这个比率来查看执行增量备份的频率,以避免备份失败的可能性,因为在重做日志中没有可用的历史数据。例如,如果你每天产生1GB的重做日志数据,而你的重做日志文件的总大小是7GB,你将安排增量备份比每周一次更频繁。您可以每一两天执行一次增量备份,以避免在突然的大量更新产生比平时更多的重做日志数据时出现潜在问题。

    • 方法对增量备份时间进行基准测试——增量而且——incremental-with-redo-log-only选项,以确认重做日志备份技术是否比传统的增量备份方法执行得更快,开销更小。结果可能取决于数据的大小、DML活动的数量和重做日志文件的大小。在具有实际数据量和实际工作负载的服务器上进行测试。例如,如果你有巨大的重做日志文件,在增量备份过程中读取它们所花费的时间可能与使用传统增量技术读取InnoDB数据文件所花费的时间一样长。相反,如果你的数据量很大,读取所有的数据文件来寻找少数被更改的页面,可能比处理小得多的重做日志文件效率更低。

增量备份的其他注意事项

增量备份特性主要针对InnoDB表,或只读或很少更新的非InnoDB表。的级别检测更改页面在InnoDB中数据文件,与表行相反;修改过的每个页面都有备份。因此,节省的空间和时间与更改的InnoDB行或列的百分比并不完全成正比。

对于非InnoDB文件,如果该文件自上次备份以来发生了更改,则整个文件都包含在增量备份中,这意味着与InnoDB表相比,节省的备份资源不那么显著。

方法不能执行增量备份——压缩选择。

方法创建的备份(完全或增量)的基础上进行增量备份时——无固定选项,使用——skip-binlog选项来跳过二进制日志的备份,因为二进制日志信息将不可用mysqlbackup在那种情况下。

方法将不会将二进制日志文件复制到增量备份中——start-lsn选项。若要包含增量备份所涵盖期间的二进制日志文件,请使用——incremental-base选项,它提供必要的信息mysqlbackup确保前一次备份中包含的二进制日志数据与当前增量备份之间不存在空白。

增量备份示例

此示例使用mysqlbackup对MySQL服务器进行增量备份,包括所有数据库和表。我们展示了两个备选方案,一个使用的是——incremental-base选项,另一个使用——start-lsn选择。

——incremental-base选项,您不必跟踪一个备份和下一个备份之间的LSN值。相反,您可以只指定前一次备份的备份目录(完全备份或增量备份)和mysqlbackup根据前一个备份的元数据确定此备份的起点。因为您需要一组已知的目录名,所以您可能希望在自己的备份脚本中使用硬编码的名称或生成名称序列,而不是使用——with-timestamp选择。

注意,即使上一次备份是单个文件,您仍然可以使用——incremental-base通过指定dir:directory_path控件提供的临时目录的位置——backup-dir选项:

作为指定的替代方案——incremental-base= dir:directory_path,你可以看出来mysqlbackup查询。end_lsn珍惜从最后成功开始non-TTS备份根据《backup_history表在服务器上使用——incremental-base=历史:last_backup(这要求最后的备份是用mysqlbackup连接到服务器)。

你也可以使用——start-lsn选项指定应该从何处开始增量备份。需要记录上一次上报的备份的LSNmysqlbackup备份结束时:

mysqlbackup:能够解析到lsn 2654255716的日志

号码也记录在元/ backup_variables.txt指定的文件夹中的文件——backup-dir备份过程中。然后供给那个数字给mysqlbackup使用——start-lsn选择。增量备份然后包括所有更改指定的LSN。

使用。创建增量备份映像——start-lsn选项,使用以下命令,指定with——incremental-backup-dir备份目录,在本例中,它是一个存放备份元数据和一些临时文件的目录:

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

在下面的例子中,因为——备份映像如果不提供待创建映像文件的完整路径,则在——incremental-backup-dir

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

在下面的例子中,——incremental-base =历史:last_backup选项,给定whichmysqlbackup获取最后一个成功的(非tts)完全或部分备份的LSNmysql.backup_history表,并在此基础上执行增量备份。

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

高级:使用以下命令创建增量目录备份——incremental-base——start-lsn选项:

Mysqlbackup——defaults-file=/home/dbadmin/my.cnf——incremental \——increment -base=dir:/incr-backup/wednesday \——increment -backup-dir=/incr-backup/thursday \ backup . conf

保持备份计划:

  • 按照由数据库活动日期或数量决定的定期计划,进行更多的增量或差异备份。

  • 可选地,周期性地通过取满,未压缩的压缩备份。通常,当您可以归档和清除最旧的备份数据时,就会发生这个里程碑。

有关如何使用增量备份恢复数据库,请参见第5.1.3节“恢复增量备份”