MySQL企业备份简介
MySQL备份的最佳实践，并记录了如何使用MySQL Enterprise Backup功能来实现这些实践。教你：
为什么备份很重要。
组成MySQL数据库的文件及其所扮演的角色。
如何在备份期间保持数据库运行。
如何最大程度地减少备份作业的时间，CPU开销和存储开销。通常，最小化这些方面中的一个会增加另一个方面。
灾难袭来时如何还原数据。您将学习如何验证备份以及如何进行恢复，以便在压力下保持冷静和自信。
使用备份数据进行日常管理和部署新服务器的其他方式。
备份类型
各种备份技术的分类范围从热（最理想）到冷（最具破坏性）。您的目标是在备份过程中保持数据库系统以及关联的应用程序和网站的运行和响应。
数据库运行时执行热备份。这种类型的备份不会阻止正常的数据库操作。它甚至可以捕获备份过程中发生的更改。由于这些原因，当数据库“ 增长 ”时，热备份是可取的：当数据足够大以至于备份需要大量时间，并且数据对于企业非常重要，因此您必须捕获每一个最后的更改而无需采取任何措施您的应用程序，网站或Web服务处于脱机状态。
MySQL Enterprise Backup对所有InnoDB表进行热备份。最后，使用热备份技术备份MyISAM和其他非InnoDB表 ：数据库继续运行，但是在备份的那个阶段系统处于只读状态。
您也可以在数据库停止时执行冷备份。为了避免服务中断，通常需要从复制从属服务器执行这种备份，可以在不关闭整个应用程序或网站的情况下停止复制。
记住要点
要在热备份阶段备份尽可能多的数据，您可以将InnoDB指定为新表的默认存储引擎，或将现有表转换为使用InnoDB存储引擎。（在MySQL 5.5及更高版本中，InnoDB现在是新表的默认存储引擎。）
在热备份和热备份期间，将通过数据库连接自动检索有关数据库结构的信息。对于冷备份，必须通过配置文件或命令行选项指定文件位置。
mysqlbackup客户端
使用MySQL Enterprise Backup产品时，主要是使用mysqlbackup客户端。使用它可以执行不同类型的备份和还原操作，以及由备份脚本执行的其他任务，例如为每个备份创建带时间戳的子目录，压缩备份数据以及将备份数据打包到单个文件中，以便于进行操作。转移到另一台服务器。
备份性能和容量注意事项概述
在您的备份策略中，性能和存储空间是关键方面。您希望备份快速完成，而数据库服务器上的CPU开销很小。您还希望备份数据紧凑，因此您可以随时保留多个备份以立即还原。将备份数据传输到其他系统应该快速便捷。所有这些方面均由mysqlbackup 命令的选项控制。
有时，您必须平衡各种开销-CPU周期，存储空间和网络流量。始终要注意在计划的维护期间或灾难发生时恢复数据所需的时间。例如，以下是一些MySQL企业备份关键功能要考虑的因素：
并行备份 是MySQL Enterprise Backup 3.8的默认设置，与以前的MySQL Enterprise Backup版本相比，性能有了很大的提高。读取，处理和写入是所有MEB操作的主要子操作。例如，在备份操作中，MySQL Enterprise Backup首先从磁盘读取数据，然后处理该数据，将数据写入磁盘，然后再次读取数据以进行验证。MySQL Enterprise Backup确保这些子操作彼此独立并并行运行以提高性能。读取，处理和写入子操作使用相同类型的多个线程并行执行：多个读取线程，多个处理线程和多个写入线程，导致更好的性能。当RAID阵列既用作源设备又用作目标设备时，对于可并行使用更多CPU周期的压缩备份，性能提高通常会更大。
并行备份使用块级并行性，使用16MB的块。不同的线程可以在单个文件中读取，处理和写入不同的16MB块。无论实例包含单个巨大的系统表空间还是许多较小的表空间（由在该innodb_file_per_table模式下创建的.ibd文件表示）， 并行备份都可以提高操作性能 。
增量备份比完全备份要快，可以节省数据库服务器上的存储空间，还可以节省网络流量以在另一台服务器上传输备份数据。增量备份需要进行其他处理才能使备份准备好还原，您可以在其他系统上执行此备份，以最大程度地减少数据库服务器上的CPU开销。
压缩备份节省InnoDB表的存储空间，并节省网络流量以在另一台服务器上传输备份数据。与未压缩的备份相比，它们确实增加了更多的CPU开销。在还原过程中，您需要同时压缩和未压缩的数据，因此请考虑此额外的存储空间和解压缩数据的时间。
除了压缩InnoDB表中的数据外，压缩备份还跳过InnoDB表空间文件中未使用的空间。未压缩的备份包括此未使用的空间。
如果空间有限，或者您的存储设备（例如磁带）便宜，大但又很慢，则性能和空间注意事项有所不同。您不想避免最快的备份，而是要避免在数据库服务器上存储备份数据的中间副本。MySQL Enterprise Backup可以生成单文件备份，并将该文件直接流式传输到其他服务器或设备。由于备份数据永远不会保存到本地系统，因此可以避免数据库服务器上的空间开销。您还可以避免保存一组备份文件，然后将它们捆绑到归档文件中以传输到另一台服务器或存储设备的性能开销。有关详细信息，请参见 第4.3.5.1节“将备份数据流式传输到另一个设备或服务器”。
将备份数据流式传输到磁带时，通常不压缩备份，因为执行压缩的数据库服务器上的CPU开销比磁带设备上的额外存储空间昂贵。将备份数据流式传输到另一台服务器时，您可能会在原始服务器或目标服务器上进行压缩，具体取决于哪台服务器具有更多的备用CPU容量以及压缩可以节省多少网络流量。或者，您可以将备份数据保留在目标服务器上未压缩的位置，以便随时可以恢复。
对于灾难恢复，当恢复数据的速度至关重要时，您可能希望已准备好关键数据并对其进行了未压缩的压缩，因此恢复操作涉及的步骤尽可能少。
在灾难恢复期间，速度至关重要。例如，尽管使用mysqldump 命令执行的逻辑备份可能与使用物理备份的逻辑备份大约花费相同的时间 （至少对于小型数据库而言），但是MySQL Enterprise Backup的还原操作通常更快。将实际数据文件复制回数据目录可避免插入行和更新索引的开销，这些开销是由于从输出中重播SQL语句而产生的。 mysqldump
为了使对Linux和Unix系统上的服务器性能的影响最小化，MySQL Enterprise Backup通过使用posix_fadvise()系统调用来写入备份数据，而不将其存储在操作系统的磁盘缓存中 。通过防止对备份数据进行大的一次性读取操作来防止频繁访问的数据从磁盘缓存中清除，此技术将备份操作后的任何速度减到最小。
备份文件
DBA和开发工作通常涉及逻辑结构，例如表，行，列，数据字典等。对于备份，您必须了解文件如何表示这些结构的物理细节。
表1.1 MySQL企业备份输出目录中的文件
文件名，格式或扩展名 |
与原始数据文件的关系 |
笔记 |
|---|---|---|
ibdata* |
InnoDB系统表空间，包含多个InnoDB表和关联的索引。 |
由于备份过程中原始文件可能会更改，因此该 apply-log步骤会将相同的更改应用于相应的备份文件。 |
*.ibd |
InnoDB每表文件表空间，每个表空间包含一个InnoDB表和关联的索引。 |
用于使用innodb_file_per_table 选项创建的表 。由于备份过程中原始文件可能会更改，因此apply-log步骤会将相同的更改应用于相应的备份文件。 |
*.ibz |
来自MySQL数据目录的InnoDB数据文件的压缩形式。 |
.ibd在压缩备份中生成 而不是文件。ibdata* 代表InnoDB系统表空间的文件在压缩备份中也收到此扩展名。 .ibz在，或 步骤期间apply-log， 这些文件未压缩。 copy-backcopy-back-and-apply-log |
*.frm |
保留有关所有MySQL表的元数据。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.MYD |
MyISAM表数据。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.MYI |
MyISAM索引数据。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.CSM |
CSV表的元数据。 |
这些文件被复制而没有更改。mysqlbackup创建的 backup_history和 backup_progress表 使用CSV格式，因此备份始终包括一些具有此扩展名的文件。 |
*.CSV |
CSV表的数据。 |
这些文件被复制而没有更改。mysqlbackup创建的 backup_history和 backup_progress表 使用CSV格式，因此备份始终包括一些具有此扩展名的文件。 |
*.MRG |
MERGE存储引擎对其他表的引用。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.TRG |
触发参数。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.TRN |
触发名称空间信息。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.opt |
数据库配置信息。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.par |
分区表的定义。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.ARM |
存档存储引擎元数据。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
*.ARZ |
存档存储引擎数据。 |
复制这些文件时，数据库将进入只读状态。这些文件被复制而没有更改。 |
backup-my.cnf |
记录用于指定布局以及有关MySQL数据文件的其他重要信息的配置参数。 |
在备份过程中创建的文件，它包含了描述像备份数据的关键参数 innodb_data_file_path， innodb_log_file_size， innodb_log_files_in_group，等等。它还可能包含其他InnoDB参数，例如，innodb_data_home_dir 以及 innodb_undo_directory 是否在备份期间使用了某些 备份存储库选项。 mysqlbackup使用存储在此文件中的参数来了解备份的结构并执行各种操作。您可能需要向mysqlbackup提供其中一些参数 如果目标服务器和备份的配置不同，则在还原过程中 启动mysqld时启动目标服务器。有关详细信息，请参见第4.2.3节“还原数据库”中的讨论 。 |
ibbackup_ibd_files |
.ibd在增量备份期间 记录文件名及其空间ID。 |
该文件是在增量备份期间创建的。在还原过程中，文件中的信息用于从完全备份中删除表，该完全备份在完全备份时间和增量备份时间之间已被删除。 |
ibbackup_logfile |
ib_logfile*MySQL数据目录中文件的 压缩版本 。 |
InnoDB日志文件（ib_logfile*）是固定大小的文件，在数据库运行期间会不断更新。出于备份目的，仅需要在备份过程中提交的更改。这些更改记录在中 ibbackup_logfile，并ib_logfile*在apply-log阶段用于重新创建文件。 |
ibbackup_redo_log_only |
ibbackup_logfile为该--incremental-with-redo-log-only 选项 创建的增量备份，而不是创建 的 。 |
|
ib_logfile* |
在初始备份之后的阶段中，由mysqlbackup在 备份目录中创建 apply-log。 |
这些文件不是从原始数据目录复制的，而是apply-log 在初始备份之后的阶段中，使用ibbackup_logfile 文件中记录的更改在备份目录中重新创建 的。 |
*.bl |
备份服务器 中每个.isl文件的重命名版本 。 |
.isl当您InnoDB 使用语法指定表的位置时，将创建 一个文件CREATE TABLE ... DATA DIRECTORY = ...，其作用类似于指向表空间文件的符号链接。（有关详细信息，请参见从 外部创建表。） 在 操作过程中，.bl文件可能会或可能不会转回.isl文件copy-back。如果指定的目录在还原备份的服务器上不存在，则 mysqlbackup尝试创建它。如果无法创建目录，则还原操作将失败。因此，如果您想使用DATA DIRECTORY子句以将表放在不同的位置或还原到具有无法创建相应目录的不同文件结构的服务器，请.bl在还原之前编辑文件以指向目标服务器上确实存在的目录。 如果.bl文件指向的目标服务器上的目录 已经包含.ibd文件，--force 则在还原备份时需要该 选项。 |
带时间戳的目录，例如 2011-05-26_13-42-02 |
由--with-timestamp选项创建 。所有备份文件都放在此子目录中。 |
使用该--with-timestamp选项可以轻松地将多个备份数据保留在同一主备份目录下。 |
datadir 目录 |
一个子目录，用于存储原始MySQL实例中的数据文件和数据库子目录。 |
在备份目录下由mysqlbackup创建 。 |
二进制日志文件 |
服务器的二进制日志文件，默认情况下包含在备份中（使用该--use-tts 选项创建备份时除外 ）。它们允许拍摄服务器的快照，因此可以将服务器克隆到其确切状态。使用完全备份作为基础，增量备份中包含的二进制日志文件可用于时间点恢复（PITR），该时间点恢复将数据库恢复到上一次备份后某个时间点的状态。完整备份。有关详细信息，请参见 第5.3节“时间点恢复”。 | 保存在datadir备份目录下的目录下。使用该 --skip-binlog选项可排除备份中的二进制日志。对于MySQL 5.5及更早版本以及所有脱机备份--log-bin-index ，如果选项与默认值不同，请使用 选项指定列出所有使用的二进制日志文件的MySQL服务器上索引文件的绝对路径，对于mysqlbackup查找二进制日志文件并将其包括在备份中。索引文件本身（二进制日志文件的位置已正确更新以指向备份目录中文件的位置）已包含在datadir目录下的备份中。 二进制日志文件.bz包含在压缩备份中后，将被压缩并与扩展名一起保存 。 当二进制日志文件和索引文件包含在备份中时，在还原操作期间始终将其复制到还原的服务器的数据目录中。使用该--skip-binlog选项可跳过二进制日志的恢复。 笔记
|
中继日志文件 |
中继从属服务器的日志文件，默认情况下，这些日志文件包括在从属服务器的备份中（使用该--use-tts选项创建备份时除外）。它们的包含节省了从属服务器还原时从主控服务器获取中继日志所需的时间和资源。 | 保存在datadir备份目录下的目录下。使用该 --skip-relaylog选项在备份中排除中继日志。对于脱机备份，请使用该--relay-log-index 选项在列出所有使用的中继日志文件的MySQL服务器上指定索引文件的绝对路径（如果与该选项的默认值不同），用于mysqlbackup查找中继日志文件并将其包括在备份中。索引文件本身（带有正确更新的中继日志文件的位置，以指向备份目录中文件的位置）包含在该datadir目录下的备份中。 中继日志文件.bz包含在压缩备份中后，将被压缩并与扩展名一起保存 。 中继日志文件和索引文件（包括在备份中时）在还原操作期间始终复制到还原的服务器的数据目录中。使用该 --skip-relaylog选项可跳过中继日志的还原。 |
| * .bz | 压缩的二进制日志或中继日志文件。 | 二进制日志和中继日志文件.bz包含在压缩备份中后，将被压缩并与扩展名一起保存。它们在还原过程中被解压缩。 |
| 从属状态日志文件 | 通常，它们通常名为master.info和 relay-log.info，它们默认包含在复制设置中的从属数据库的备份中。有关详细信息，请参见从站状态日志。 | 保存在datadir备份目录下的目录下。对于脱机备份，请使用--master-info-file 和--relaylog-info-file 选项指定信息文件的绝对路径（如果它们与选项的默认值不同），以便mysqlbackup查找那些文件并将其包括在备份中。 --skip-relay-log 使用 该选项时，在备份或还原期间将跳过这些文件的复制。 |
备用图片文件 |
该backup-to-image命令生成的单文件备份 ，其名称由--backup-image 选项指定 。 |
如果您的备份数据目录仅由零字节文件组成，并且在顶层目录中具有单个巨型数据文件，则您将具有单文件备份。您可以移动映像文件而不会丢失或损坏其中的内容，然后使用该选项使用mysqlbackup将其解压缩，并 使用该 extract选项指定相同的映像名称--backup-image 。尽管备份目录中存在一些额外的文件，例如 backup-my.cnf和 meta子目录，但是这些文件也包含在映像文件中，不需要随其一起移动。 |
datadir目录（即 ） 下的子目录中的任何其他文件 backup-dir/datadir/subdir |
从MySQL数据目录下的数据库子目录复制。 |
默认情况下，MySQL数据目录下子目录中所有无法识别的文件都会复制到备份中。要省略此类文件，请指定 --only-known-file-types 选项。 注意 此行为有一些限制。见讨论 这里的 附录B，MySQL企业备份的局限。 |
meta 目录 |
一个子目录，用于存储带有有关备份的元数据的文件。 |
在备份目录下由mysqlbackup创建 。下面列出的所有文件都在meta子目录中。 |
backup_variables.txt |
包含有关备份的重要信息。仅供 mysqlbackup使用。 |
mysqlbackup在初始备份之后的操作（例如，apply-log阶段或restore阶段）期间会查询并可能更新此文件。 |
image_files.xml |
包含由backup-to-image 或backup-dir-to-image 选项生成的单文件备份中存在的所有文件（自身除外）的列表 。有关此文件的详细信息，请参见 第11.4节“使用MySQL Enterprise Backup清单”。 |
生成后，此文件在任何阶段都不会被修改。 |
backup_create.xml |
列出创建备份的命令行参数和环境。有关此文件的详细信息，请参见 第11.4节“使用MySQL Enterprise Backup清单”。 |
创建该文件后，将不会对其进行修改。您可以通过指定--disable-manifest 选项来防止生成此文件 。 |
backup_content.xml |
备份数据的文件和数据库定义的基本元数据。它还包含备份服务器上定义的所有插件的详细信息，用户应通过这些信息确保在目标服务器上以相同的方式定义相同的插件以进行还原。有关此文件的详细信息，请参见 第11.4节“使用MySQL Enterprise Backup清单”。 |
该文件一旦创建就不会被修改。您可以通过指定--disable-manifest 选项来防止生成此文件 。 |
comments.txt |
由--comments 或--comments-file选项产生。 |
您指定了注释以记录此备份作业的目的或特殊注意事项。 |
backup_gtid_executed.sql |
表示备份来自启用了GTID的服务器。 |
GTID是MySQL 5.6和更高版本中的复制功能。有关详细信息，请参见使用全局事务标识符进行复制。当备份服务器GTIDs启用使用 mysqlbackup，命名的文件 backup_gtid_executed.sql是在创建meta文件夹备份目录下。在从属服务器上还原备份数据后，编辑并执行此文件；有关详细信息，请参见 第6.1节“设置新的复制从属”。 |
| server-my.cnf | 包含设置为非默认值的备份服务器的全局变量的值。使用此文件或server-all.cnf启动目标服务器进行还原。 |
期间copy-back或 copy-back-and-apply-log 操作中， 服务器存储库选项值（例如， --datadir， --innodb_data_home_dir如果该命令使得通过命令选项改变才能使它们在该文件中，等）被修改。但是，在 apply-incremental-backup 操作过程中，已经保存在文件中的值优先，并且不会被命令提供的选项值修改。 警告 当使用文件重新启动的目标服务器，更改参数一样--tmpdir， --general-log等等，以及使用绝对文件路径的任何全局变量，以避免目标服务器的错误文件位置的意外使用。 |
| server-all.cnf | 包含备份服务器的所有全局变量的值。使用此文件或 server-my.cnf启动目标服务器进行还原。 |
期间copy-back或 copy-back-and-apply-log 操作中， 服务器存储库选项值（例如， --datadir， --innodb_data_home_dir如果该命令使得通过命令选项改变才能使它们在该文件中，等）被修改。但是，在 apply-incremental-backup 操作过程中，已经保存在文件中的值优先，并且不会被命令提供的选项值修改。 警告 当使用文件重新启动的目标服务器，更改参数一样--tmpdir， --general-log等等，以及使用绝对文件路径的任何全局变量，以避免目标服务器的错误文件位置的意外使用。 |
InnoDB数据
始终备份由InnoDB存储引擎管理的数据。备份的与InnoDB相关的主要数据文件包括 ibdata *文件 （代表系统表空间，还可能代表某些用户表的数据），任何 .ibd文件（其中包含来自每个文件的用户表创建的数据）。 表设置已启用），以及从ib_logfile *文件提取的数据 （表示备份运行时发生的更改的重做日志信息），这些数据存储在新的备份文件 ibbackup_logfile中。
如果使用压缩备份功能，则 .ibd文件将以其压缩形式重命名为.ibz files。
原始复制的文件形成 原始备份，在准备好还原之前需要进行进一步处理。然后，您运行Apply步骤，该步骤将根据文件中记录的更改更新备份文件，从而 ibbackup_logfile生成 准备好的备份。此时，备份数据对应于单个时间点。现在可以将文件还原到其原始位置，或用于其他用途，例如测试，报告或部署为复制从属。
要将InnoDB表恢复到原始状态，还必须具有相应的.frm文件以及备份数据。否则，如果 自备份以来有人在运行ALTER TABLE或执行了DROP TABLE语句，则表定义可能会丢失或过时 。默认情况下， mysqlbackup.frm在备份操作期间自动复制 文件，并在还原操作期间恢复文件。
来自MyISAM和其他存储引擎的数据
mysqlbackup还备份与MyISAM表关联的 .MYD文件， .MYI文件和 .frm文件。备份的具有其他扩展名的文件显示在此列表中。
注意
尽管MySQL Enterprise Backup可以备份非InnoDB数据（如MYISAM表），但是要备份的MySQL服务器必须支持InnoDB（即，如果使用--innodb=OFF 或 --skip-innodb 选项启动服务器，则备份过程将失败 ），并且该服务器必须至少包含一个InnoDB表。
MyISAM表和这些其他类型的文件不能以与InnoDB表相同的非阻塞方式进行备份。使用热备份 技术来备份它们：在备份这些表时可以防止对这些表进行更改，这可能会使数据库暂时无响应，但是在备份过程中无需关闭。
注意
为避免在繁忙数据库备份期间出现并发问题，可以使用--only-innodb或 --only-innodb-with-frm 选项仅备份InnoDB表和关联的数据。
备份中包含的生成文件
备份数据包括在备份过程中生成的一些新文件。这些文件用于控制以后的任务，例如验证和还原备份数据。备份过程中生成的文件包括：
meta/backup_create.xml：列出创建备份的命令行参数和环境。
meta/backup_content.xml：备份数据的文件和数据库定义的基本元数据。
backup-my.cnf：记录适用于备份的关键配置参数。mysqlbackup在操作期间将读取这些配置参数， 例如 apply-log以确定备份数据的结构。还可以在还原操作期间检查这些参数是否与目标服务器的配置兼容。
server-my.cnf：包含设置为非默认值的备份服务器的全局变量的值。
server-all.cnf：包含备份服务器的所有全局变量的值。
单文件备份
根据您的工作流程，您可能希望执行单文件备份而不是目录备份，因为目录备份会为原始服务器实例上的每个文件生成一个单独的文件。单文件备份更易于传输到其他系统，进行压缩和解压缩。它还有助于防止错误地删除构成备份一部分的单个文件。完全还原与多文件备份一样快。还原单个文件可能比多文件备份要慢。
还原数据库概述
要启动还原过程，请使用或 命令运行 mysqlbackup客户端 。您可以为具有多个数据库的MySQL服务器还原所有数据，每个数据库包含多个表。对于使用可传输表空间（TTS）创建的备份（即使用该选项创建的备份 ），您还可以选择还原选定的数据库，表或同时还原两者。 copy-backcopy-back-and-apply-log--use-tts
要修复诸如数据损坏之类的问题，您可以将数据还原到原始服务器计算机上的原始位置。您可能会还原到其他服务器计算机或其他位置，以使用主服务器中的数据设置新的复制从属服务器，或克隆数据库以进行报告。
摘自：https://dev.mysql.com/doc/mysql-enterprise-backup/
结束语