1.3.1 备份中包含的文件类型

下表显示了单文件备份映像或目录备份中包含的不同类型的文件。如果是单文件备份, 可以使用或 命令将 文件解压到备份目录 结构中查看文件。extractimage-to-backup-dir

表 1.1 备份中的文件类型

文件名、模式或扩展名

与原始数据文件的关系

笔记

ibdata*

InnoDB 系统表空间,包含多个 InnoDB 表和相关索引。

由于在备份过程中原始文件可能会更改,因此该 apply-log步骤会将相同的更改应用于相应的备份文件。

*.ibd

一个 InnoDB 表空间,它可以是 (a) file-per-table 表 空间,包含单个 InnoDB 表和相关索引,或 (b) file-per-table 外部表空间,位于服务器数据目录之外,包含单个InnoDB 表和关联索引,或 (c) 通用表空间,包含一个或多个表及其索引。

由于在备份过程中原始文件可能会更改,因此应用日志步骤会将相同的更改应用于相应的备份文件。

*.ibz

来自 MySQL 数据目录的 InnoDB 数据文件的压缩形式。

生成而不是.ibd压缩备份中的文件。代表 InnoDB 系统表空间的ibdata* 文件也在压缩备份中接收此扩展名。

.ibz文件在 、apply-logcopy-back步骤 copy-back-and-apply-log 期间解压缩。

*.frm

保存所有 MySQL 表的元数据。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.MYD

MyISAM 表数据。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.MYI

MyISAM 索引数据。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.CSM

CSV 表的元数据。

这些文件未经修改地复制。mysqlbackup创建 的 backup_history和 表使用 CSV 格式,因此备份总是包含一些具有此扩展名的文件。 backup_progress

*.CSV

CSV 表的数据。

这些文件未经修改地复制。mysqlbackup创建 的 backup_history和 表使用 CSV 格式,因此备份总是包含一些具有此扩展名的文件。 backup_progress

*.MRG

MERGE 存储引擎对其他表的引用。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.TRG

触发器参数。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.TRN

触发名称空间信息。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.opt

数据库配置信息。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.par

分区表的定义。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.ARM

ARCHIVE 存储引擎表元数据。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

*.ARZ

ARCHIVE 存储引擎表数据。

复制这些文件时,数据库处于只读状态。这些文件未经修改地复制。

backup-my.cnf

记录指定布局的配置参数和有关 MySQL 数据文件的其他重要信息。

该文件是在备份期间创建的,它包含描述备份数据的关键参数,如 innodb_data_file_pathinnodb_log_file_sizeinnodb_log_files_in_group等。它还可能包含其他 InnoDB 参数 innodb_data_home_dir , 例如是否在备份期间使用了 innodb_undo_directory 某些 备份存储库选项。mysql备份使用存储在此文件中的参数来了解备份的结构并执行各种操作。如果目标服务器和备份的配置不同,您可能需要在恢复期间 向mysqlbackup提供其中一些参数, 并在启动目标服务器时向mysqld提供这些参数。有关详细信息,请参阅 第 4.2.4 节“恢复数据库”中的讨论。

ibbackup_ibd_files

记录.ibd增量备份时的文件名及其空间ID。

该文件是在增量备份期间创建的。在还原期间,文件中的信息用于从完整备份中删除在完整备份时间和增量备份时间之间删除的表。

ibbackup_logfile

ib_logfile*MySQL 数据目录 中文件的压缩版本 。

InnoDB 日志文件 ( ib_logfile*) 是固定大小的文件,在数据库运行期间不断更新。出于备份目的,只需要在备份过程中提交的更改。这些更改记录在 中 ,并用于在应用日志阶段 ibbackup_logfile重新创建文件。ib_logfile*

ibbackup_redo_log_only

Created 而不是 用于使用该 选项 ibbackup_logfile进行的增量备份 。--incremental-with-redo-log-only

ib_logfile*

在初始备份后的阶段 由mysqlbackup在 备份目录中创建 。apply-log

这些文件不是从原始数据目录复制的,而是在 apply-log初始备份后的阶段使用 ibbackup_logfile文件中记录的更改在备份目录中重新创建的。

*.bl

来自备份服务器 的每个 .isl 文件的重命名版本。

当您 使用语法.isl指定表的位置(有关详细信息,请参阅 外部创建表)或将表放入 通用表空间(仅适用于 MySQL 5.7 及更高版本;有关详细信息,请参阅 通用表空间)时,将创建一个文件。该 文件就像一个指向表空间文件的符号链接。这些 文件可能会也可能不会在或 InnoDBCREATE TABLE ... DATA DIRECTORY = ....isl.bl.islcopy-backcopy-back-and-apply-log 手术。如果指定的目录在恢复备份的服务器上不存在, mysqlbackup 会尝试创建它。如果无法创建目录,则还原操作失败。因此,如果您想使用该 DATA DIRECTORY子句将表放在不同的位置或恢复到具有不同文件结构的服务器(其中无法创建相应的目录),请 .bl在恢复之前编辑文件以指向目标上确实存在的目录服务器。

还原使用可传输表空间 (TTS) 创建的备份时 ,如果文件指向的目标服务器上的.bl 目录已经包含 .ibd 文件,则 --force还原备份时需要该选项。

带时间戳的目录,例如 2011-05-26_13-42-02

--with-timestamp选项创建。所有备份文件都放在这个子目录中。

使用该--with-timestamp选项可以轻松地将多组备份数据保存在同一个主备份目录下。

datadir目录

存储原始 MySQL 实例中的数据文件和数据库子目录的子目录。

mysqlbackup在备份目录下创建。

二进制日志文件

来自服务器的二进制日志文件,默认情况下包含在备份中(使用 --use-tts选项创建备份时除外)。它们允许拍摄服务器的快照,因此可以将服务器克隆到它的确切状态。使用完整备份作为基础,增量备份中包含的二进制日志文件可用于时间点恢复 (PITR),它将数据库恢复到上次备份后某个时间点的状态完整备份。有关详细信息,请参见第 5.2 节 “时间点恢复”

保存在datadir备份目录下。MySQL 服务器上索引文件的副本,其中列出了所有已使用的二进制日志文件,二进制日志文件的位置已正确更新以指向文件在备份中的位置,也包含在备份中datadir目录。使用该 --skip-binlog选项从备份中排除二进制日志。

对于离线备份,使用该 --log-bin-index选项指定索引文件在MySQL服务器上的绝对路径,列出所有使用的二进制日志文件,如果与该选项的默认值不同,则mysqlbackup查找二进制日志文件和将它们包含在备份中。

对于 4.1.2 版及更高版本:默认情况下,二进制日志文件和索引文件将还原到它们在备份服务器上找到的相同位置。使用该--log-bin 选项为二进制日志指定不同的目标位置。使用 --skip-binlog选项跳过二进制日志的恢复。

对于 4.1.1 版及更早版本: 二进制日志文件和索引文件将还原到还原服务器的数据目录。使用 --skip-binlog选项跳过二进制日志的恢复。

.bz当包含在压缩备份中时, 二进制日志文件被压缩并以扩展名保存 。

笔记
  • 如果您正在备份的服务器上缺少任何二进制日志文件,您应该使用该 --skip-binlog选项来避免mysqlbackup为丢失的文件抛出错误。

  • --use-tts如果使用选项或选项 ,则不会将二进制日志文件复制到增量备份 --start-lsn 中。要包括增量备份所涵盖期间的二进制日志文件,请不要使用该 --use-tts选项,而应 --start-lsn使用该 选项,它为mysqlbackup--incremental-base 提供必要的信息确保上一次备份的二进制日志数据与本次增量备份不存在差距。

中继日志文件

来自副本服务器的中继日志文件,默认情况下包含在副本服务器的备份中(使用--use-tts 选项创建备份时除外)。它们的包含节省了在恢复副本时从源获取中继日志所需的时间和资源。

保存在datadir备份目录下的目录下。副本服务器上的索引文件副本列出了所有已使用的中继日志文件,中继日志文件的位置已正确更新以指向文件在备份目录中的位置,也包含在备份中,在下面datadir 目录。使用该 --skip-relaylog选项从备份中排除中继日志。

对于离线备份,使用 --relay-log-index选项指定索引文件在MySQL服务器上的绝对路径,列出所有使用的中继日志文件,如果与选项的默认值不同,则mysqlbackup查找中继日志文件和将它们包含在备份中。

对于 4.1.2 版及更高版本:默认情况下,中继日志文件和索引文件将恢复到它们在备份副本服务器上找到的相同位置。使用该 --relay-log选项为中继日志指定不同的目标位置。使用--skip-relaylog 选项跳过中继日志的恢复。

对于 4.1.1 及更早版本: 中继日志文件和索引文件将还原到还原服务器的数据目录。使用 --skip-relaylog选项跳过中继日志的恢复。

The relay log files are compressed and saved with the .bz extension when being included in a compressed backup.

*.bzCompressed binary log or relay log files.

The binary log and relay log files are compressed and saved with the .bz extension when being included in a compressed backup. They are decompressed during a restore.

*.bkt (for release 4.1.0, or release 4.1.1 and later working with MySQL 5.7.20 and earlier)Transfer file created for an encrypted InnoDB table during backup .It contains the reencrypted tablespace key and other information related to the encryption. See Chapter 6, Working with Encrypted InnoDB Tables for detail.
encrypted keyring data file (for release 4.1.1 and later working with MySLQ 5.7.21 and later)

For a server using the keyring_encrypted_file plugin, the file specified by the keyring_encrypted_file_data option on the server is copied over into the backup with its original name under the meta folder.

对于使用非 keyring 插件的服务器 keyring_encrypted_file,文件名为keyring_kef,保存在meta文件夹下。

包含用于 InnoDB 表加密的主密钥的加密文件。有关详细信息,请参阅第 6 章,使用加密的 InnoDB 表
复制元数据存储库文件通常命名为master.inforelay-log.info,它们默认包含在复制设置中的副本数据库备份中。有关详细信息,请参阅 复制元数据存储库

Saved under the datadir directory under the backup directory. For an offline backup, use the--master-info-file and --relaylog-info-file options to specify the absolute paths of the information files, if they are different from the default values of the options, for mysqlbackup to find those files and include them in the backups.

The copying of these files are skipped during a backup or a restore when the --skip-relay-log option is used.

Backup image file

A single-file backup produced by the backup-to-image option, with a name specified by the --backup-image option.

You can move the image file without losing or damaging the contents inside it, then unpack it with mysqlbackup using the extract command and specifying the same image name with the --backup-image option. Although some extra files such as backup-my.cnf and the meta subdirectory are present in the backup directory, these files are also included in the image file and do not need to be moved along with it.

Any other files in subdirectories under the datadir directory (that is, under backup-dir/datadir/subdir)

Copied from the database subdirectories under the MySQL data directory.

By default, any unrecognized files in subdirectories under the MySQL data directory are copied to the backup. To omit such files, specify the --only-known-file-types option.

Note

Some limitations apply to this behavior. See the discussion here in Appendix B, Limitations of MySQL Enterprise Backup.

meta directory

A subdirectory that stores files with metadata about the backup.

Created under the backup directory by mysqlbackup. All files listed below go inside the meta subdirectory.

backup_variables.txt

Holds important information about the backup. For use by mysqlbackup only.

mysqlbackup consults and possibly updates this file during operations after the initial backup, such as the apply-log phase or the restore phase.

image_files.xml

Contains the list of all the files (except itself) that are present in the single-file backup produced by the backup-to-image or backup-dir-to-image options. For details about this file, see Section 13.4, “Using the MySQL Enterprise Backup Manifest”.

This file is not modified at any stage once generated.

backup_create.xml

Lists the command line arguments and environment in which the backup was created. For details about this file, see Section 13.4, “Using the MySQL Enterprise Backup Manifest”.

This file is not modified once it is created. You can prevent this file from being generated by specifying the --disable-manifest option.

backup_content.xml

Essential metadata for the files and database definitions of the backup data. It also contains details of all the plugins defined on the backed-up server, by which users should make sure the same plugins are defined in the same manner on the target server for restoration. For details about this file, see Section 13.4, “Using the MySQL Enterprise Backup Manifest”.

This file is not modified once created. You can prevent this file from being generated by specifying the --disable-manifest option.

comments.txt

Produced by the --comments or --comments-file option.

The comments are specified by you to document the purpose or special considerations for this backup job.

backup_gtid_executed.sql

Signifies the backup came from a server with GTIDs enabled.

GTIDs are a replication feature in MySQL 5.6 and higher. See Replication with Global Transaction Identifiers for details. When you back up a server with GTIDs enabled using mysqlbackup, the file named backup_gtid_executed.sql is created in the meta folder under the backup directory. Edit and execute this file after restoring the backup data on a replica server; see Section 7.1, “Setting Up a New Replica” for details.

server-my.cnf

Contains values of the backed-up server's global variables that are set to non-default values. Use this file or server-all.cnf to start the target server for restoration.

During a copy-back or copy-back-and-apply-log operation, the server repository options values (e.g., --datadir, --innodb_data_home_dir, etc.) in the file are modified if the command makes changes to them through the command options. However, during an apply-incremental-backup operation, the values already saved in the file take precedence and they are not modified by the option values supplied through the command.

Warning

When using the file to restart the target server, change parameters like --tmpdir, --general-log, etc., and any global variable that uses an absolute filepath to avoid the accidental usage of the wrong file locations by the target server.

server-all.cnf

Contains values of all the global variables of the backed-up server. Use this file or server-my.cnf to start the target server for restoration.

During a copy-back or copy-back-and-apply-log operation, the server repository options values (e.g., --datadir, --innodb_data_home_dir, etc.) in the file are modified if the command makes changes to them through the command options. However, during an apply-incremental-backup operation, the values already saved in the file take precedence and they are not modified by the option values supplied through the command.

Warning

When using the file to restart the target server, change parameters like --tmpdir, --general-log, etc., and any global variable that uses an absolute filepath to avoid the accidental usage of the wrong file locations by the target server.

ib_buffer_pool

The file produced on the server when innodb_buffer_pool_dump_at_shutdown (enabled by default on MySQL 5.7.7 and after) or innodb_buffer_pool_dump_now is enabled. It holds the list of tablespace IDs and page IDs of the server's buffer pool.

实际的文件名可能不同,因为它可以由服务器的系统变量配置 innodb_buffer_pool_filename

使用 MySQL 服务器 5.7.7 及之后的默认设置 ( innodb_buffer_pool_load_at_startup=ON),目标服务器在启动期间将使用此文件恢复备份服务器的缓冲池状态。有关详细信息,请参阅 保存和恢复缓冲池状态