1.2备份类型概述

在制定备份策略时,性能和存储空间是关键考虑因素。您希望备份能够快速完成,数据库服务器上的CPU开销尽可能小。您还希望备份数据是紧凑的,这样您就可以随时保留多个备份,以便随时恢复。将备份数据传输到另一个系统应该是快速和方便的。在这样的考虑下,不同的数据库备份策略通常会给您带来不同的优势,因为在选择特定策略时需要做出不同的权衡。为了选择最适合您需求的策略,您必须了解MySQL企业备份可以执行的每种备份的性质,本节将对此进行简要概述。

根据服务中断的级别进行备份

根据备份期间数据库操作中断的方式,备份被分类为热,温暖,

  • 极低到低水平的破坏:一个热备份在数据库运行时执行的备份。这种类型的备份不会阻塞正常的数据库操作。它甚至捕获备份发生时发生的更改。与其他备份类型相比,它对数据库服务器造成的干扰最小,当您希望避免使应用程序、网站或web服务脱机时,它是理想的备份选项。然而,在恢复热备份之前,需要一个额外的过程来准备备份,以使其一致(即,正确地反映备份完成时数据库的状态)。看到第5.1.7节,“高级:准备和恢复目录备份”更多的解释。

    当连接到运行中的MySQL服务器时,MySQL Enterprise Backup会对InnoDB表执行热备份。

  • 中至高级别中断:一个热备份在数据库处于只读状态时执行的备份。这种类型的备份在备份过程中阻止对表的任何写操作,但仍然允许对表进行读取。

    当连接到一个正在运行的MySQL服务器时,MySQL企业备份使用热备份在所有InnoDB表都已经用热备份方法。因此,为了在热备份阶段备份尽可能多的数据,你应该将InnoDB指定为新表的默认存储引擎(从MySQL 5.5开始一直是默认设置),或者将现有表转换为使用InnoDB存储引擎。

  • 高到非常高的破坏水平:一个冷备份在数据库停止时创建的备份。它不仅对数据库服务造成了极大的干扰,而且还使MySQL Enterprise Backup的许多特性无法使用(例如,通过数据库连接自动检索数据库结构信息的能力,因此它们不必通过配置文件或命令行选项提供给MySQL Enterprise Backup)。

    为了避免服务中断,您通常会在副本上执行冷备份,可以在不关闭整个应用程序或网站的情况下停止该备份。

根据是备份所有数据,还是只备份最近的更改来进行备份

根据您希望将所有数据包含到备份中还是只包含最近的更改,以及根据从何时开始的最近更改,您可以执行完全备份、差异备份或增量备份。三种类型的备份对CPU开销和磁盘空间有不同级别的要求,因此适用于不同的情况:

  • 一个完全备份方法排除了某些表的情况除外部分备份选项).

  • 一个微分备份包括自上次完全备份以来对数据的所有更改。它比完全备份快,节省数据库服务器上的存储空间,并在将备份传输到另一台服务器时节省网络流量。但是,它需要额外的处理以使备份为恢复做好准备,您可以在不同的系统上执行此操作,以最小化数据库服务器上的CPU开销。

  • 一个增量备份包括自上次备份以来对数据的所有更改。与完全备份相比,它提供了与差异备份类似的优势,而且通常通过进一步减小备份大小而获得更大的优势。但是,在执行恢复之前,可能还需要对更长的备份系列进行更多准备。

压缩和未压缩备份

备份压缩节省了将备份数据传输到另一个服务器的存储空间和网络流量。压缩确实增加了一些CPU开销,但是开销与算法相关,对于MySQL Enterprise Backup使用的默认算法来说是相当低的。此外,压缩通常会大大减少IO开销,这可能会缩短恢复时间,特别是对于较慢的IO设备。但是,在恢复过程中,您需要时间进行解压,同时还需要存储空间用于压缩和解压数据。因此,在考虑是否创建压缩备份时,要考虑恢复期间所需的额外存储空间和额外时间。

当将备份数据流传输到另一个服务器时,您可能希望在原始服务器或目标服务器上压缩备份,这取决于哪个服务器有更多的空闲CPU容量以及压缩可以节省多少网络流量。

有关涉及备份和恢复性能的技术和权衡的更多信息,请参见第十一章,MySQL企业备份的性能考虑