MySQL备份与恢复

1.1.        备份基础知识 为什么要备份 ?

²   完整系统恢复需要 ：如果系统发生故障，则拥有系统的备份至关重要，因为可以恢复系统。实施怎样的备份和恢复策略取决于被恢复数据要达到的完整性和时效性。

²   审计功能需要 ：对于某些系统及关联的流程，可能需要审计或分析独立于主生产环境的环境中的数据。可以使用备份创建这样一个独立的环境。

²   常规 DBA 任务 ：在需要执行常见的 DBA 任务时使用备份。例如，将数据从一个系统传输到另一个系统，根据特定的生产服务器状态创建开发服务器，或者将系统的特定部分恢复到用户出错前的某个状态。

  备份类型一：

热备份 ：备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。

冷备份 ：备份在用户不能访问数据时进行，因此无法读取或修改数据。脱机备份会阻止执行任何使用数据的活动。这类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受在一段较长的时间里锁定或完全阻止用户访问数据。

温备份 ：备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。   备份类型二：

磁盘备份： 可以使用复制或 RAID 镜像之类流程，或者使用 DRBD 之类的外部应用程序，将数据直接备份到其他磁盘。这些技术提供实时（或几乎实时）备份，以及快速恢复数据的方法。

二进制日志备份： 二进制日志记录对数据的修改。因此，二进制日志对恢复自上次完整备份以来发生的事件很有用。备份二进制日志的优点是其中包含了各个时间对数据所做的所有更改的记录，而不是数据的快照。可以按顺序创建多个二进制日志备份。根据修改的数据量以及完成完整备份的频率，决定要在备份之间创建的二进制日志备份的数量。二进制日志的不足之处是必须恢复自序列中最后一次完整备份以来创建的所有按顺序的二进制日志。此外，从系统故障中恢复的速度可能会很慢，具体取决于必须恢复的二进制日志的数量。

逻辑 / 文本备份 ：可以使用 mysqldump 进行完整数据转储。这些数据转储基于特定的时间点，但是是所有备份副本中速度最慢的。使用 mysqldump 的优点是所创建的文件是简单的 SQL 脚本，其中包含可在 MySQL 服务器上运行的语句。不足之处在于 mysqldump 会在转储过程中锁定表，这会阻止用户在备份过程中读写文件。

  备份类型三：

Ø   逻辑备份

Ø   物理备份

Ø   基于快照的备份

Ø   基于复制的备份

Ø   增量备份

下面分别详细介绍备份类型三种的 5 中备份方式；

1.1.1.       逻辑备份

逻辑备份将数据库的内容转储到文本文件中。这些文本文件包含 SQL 语句，因此可移植性很好。这些 SQL 语句包含重建 MySQL 数据库和表所需的全部信息。可以使用该文本文件在运行不同体系结构的其他主机上重新装入数据库。

在创建逻辑备份时， MySQL 服务器必须处于运行状态，因为服务器在创建文件时要读备份的表的结构和内容，然后将结构和数据转换为 SQL 语句。其他应用程序可以在逻备份过程中执行读取操作。

采用逻辑备份时，可以备份本地和远程的 SQL 服务器。只能在本地 MySQL 服务器上执行其他类型的备份（物理备份）。

逻辑备份的速度通常比物理备份慢。这是因为 MySQL 服务器必须读取表并解释其内容。然后，将表内容转换成磁盘文件，或者将语句发送给客户机程序，由客户机程序将语句写出。在恢复过程中，逻辑备份速度比物理备份慢。这是因为恢复的方法执行单个 CREATE 和 INSERT 语句来重新创建每个备份表和行。

1.1.2.       物理备份

物理备份生成数据库文件的完整副本，可以使用标准命令进行备份，如 tar 、 cp 、 cpio 、 rsync 或 xcopy ；恢复时可以在不同的计算机体系结构间恢复，但必须恢复到同一个数据库引擎；比逻辑备份和恢复的速度快；物理备份是 MySQL 数据库文件的二进制副本。这些副本以完全相同的格式保留数据库， MySQL 本身就采用这种格式将这些副本存储在磁盘上。因为是原始数据库文件的完整副本，因此物理备份的大小与原始数据库文件完全相同。原始二进制备份的速度比逻辑备份快，因为该过程是简单的文件复制，不需要了解文件的内部结构。但是，如果使用物理备份将数据库传输到采用不同体系结构的其他计算机，则文件必须是二进制可移植文件。因为物理备份是数据库文件位的完整表现形式，因此必须将其恢复到使用相同数据库引擎的 MySQL 服务器。在从 InnoDB 表恢复原始 MySQL 备份时，会在目标服务器上保留一个 InnoDB 表。

数据库文件在备份期间不能有更改，要实现这一点的方法取决于存储引擎，对于 InnoDB 需要关闭 MySQL 服务器，对于 MyISAM 锁定表以允许读取，但不允许更改；也可以使用快照、复制或专有方法实现；采用二进制备份方法时，必须确保在备份进行期间服务器不修改文件。可以通过各种方法做到这一点。有一种方法是关闭 MySQL 服务器，然后再进行备份。这种方法有明显的不足之处。对于某些存储引擎，更好的办法是暂时锁定数据库，进行备份，然后再将数据库解锁。也可以使用快照、复制或专有方法，最大限度地减小对 MySQL 和应用程序的影响。

1.1.3.       基于快照的备份

基于快照的备份使用 MySQL 外部的快照功能。例如，如果 MySQL 数据库和二进制日志在具有相应文件系统的 LVM2 逻辑卷上，则可创建快照副本。基于快照的备份最适合 InnoDB 之类的事务引擎。可以为 InnoDB 表执行热备份；对于其他引擎，可以执行温备份。

快照备份是可伸缩的，因为执行快照所需的时间不会随数据库大小的增长而增加。事实上，从应用程序的角度来看，备份期限几乎是零。但是，创建快照后，基于快照的备份几乎总是包括一个物理备份。

1.1.4.       基于复制的备份

MySQL 可以支持单向异步复制，即一台服务器作为 master ，而一台或多台其他服务器作为 slave 。通过使用副本或 slave 而不是 master ，可以使用复制来执行备份。这样做的优势是备份操作不会影响 master 的性能。缺点是成本较高，因为必须购买额外的硬件和网络带宽。此外，由于复制固有的延迟特性， slave 的数据库副本包含一个相对于 master 延迟的数据版本。

1.1.5.       增量备份

备份只是在损失或损坏后进行数据恢复所需的组件之一。另一个组件是二进制日志，其中包含了数据更改的记录。要恢复数据库，可使用备份将数据恢复到其在备份时的状态。在恢复了备份之后，需应用二进制日志的内容以应用自备份创建以来的所有数据更改。要确保为所有 MySQL 服务器启用二进制日志记录。必须拥有 SUPER 权限才能设置此变量。如果在没有 SUPER 权限的情况下尝试设置此变量，将出现以下错误：

ERROR 1227 (42000): Access denied; you need the SUPER privilege for this operation