使用Mysql 企业级 MEB 进行数据库物理备份与恢复

在免费下载并使用的 MySQL 开源社区版本中，默认并不包含 MEB （ MySQL Enterprise Backup ， MySQL 企业版备份工具）物理热备工具，因为它是一款 Oracle 自研的企业级软件，用户需要付费才能使用。该工具功能强大，能够为 MySQL 数据库全局、增量、部分、流、压缩和加密备份与恢复等场景提供优秀的解决方案。对于甲骨文公司的付费用户而言，使用 MEB 工具来满足企业自身的备份与恢复需求，不失为一种明智的选择。

1.1 MEB 软件介绍

MEB 可用于提供在线的、非阻塞的企业级多平台热备份，包括 Linux 、 Windows 、 Mac 和 Solaris 。虽然 MySQL 企业备份工具可以备份非 Innodb 数据（如 MYISAM 表），但是要备份的 MySQL 服务器实例必须支持 InnoDB 。若备份任务是使用 “--innodb=OFF” 或 “--skip-innodb” 选项启动的，那么备份进程将会失败，服务器必须包含至少一个 InnoDB 表。 MyISAM 表和其他类型的文件不能像 InnoDB 表那样以非阻塞的方式进行备份，备份时将处于温备的模式。这就意味着在备份这些表时，与这些对象相关的 DML 业务将被锁定并等待。

1. 下载 MEB 软件安装包并安装

MEB 是 Oracle 旗下的一款企业级软件，要想下载该软件安装包，就必须开通 MOS （ MY ORACLE SUPPORT ）账号，并且拥有相应的下载权限。在 MOS 站点下载 MEB 软件安装包的截图如图 6-1 所示。

下载并安装 MEB ，命令如下：

shell> unzip p29358807_410_Linux-x86-64.zip

shell> md5sum meb-4.1.3-linux-glibc2.12-x86-64bit.tar.gz

shell> tar zxvf meb-4.1.3-linux-glibc2.12-x86-64bit.tar.gz

shell> cd meb-4.1.3-linux-glibc2.12-x86-64bit

shell> ./bin/mysqlbackup --version

MySQL Enterprise Backup version 4.1.3 Linux-4.1.12-37.4.1.el6uek.x86_64-x86_64

...

注意：不同的 MEB 版本需要与不同的 MySQL 版本严格对应。

MySQL Enterprise Backup 8.0 only supports MySQL 8.0.

MySQL Enterprise Backup 4.1.3 only supports MySQL 5.7.

MySQL Enterprise Backup 3.12.4 only supports MySQL 5.6 and earlier.

2. 创建 MEB 备份账户

通常，用户都会选择使用 MySQL 系统账户 root@localhost 来进行备份。如果企业对账户的使用设置了严格的管控和限制，就需要创建最小权限的备份账户，以执行备份任务。创建 MEB 备份账户的命令如下：

mysql> CREATE USER 'mysqlbackup'@'localhost' IDENTIFIED BY 'Abcd321#';

mysql> GRANT RELOAD ON . TO 'mysqlbackup'@'localhost';

mysql> GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO

'mysqlbackup'@'localhost';

mysql> GRANT CREATE, INSERT, SELECT, DROP, UPDATE, ALTER ON mysql.backup_history

TO 'mysqlbackup'@'localhost';

mysql> GRANT REPLICATION CLIENT ON . TO 'mysqlbackup'@'localhost';

mysql> GRANT SUPER ON . TO 'mysqlbackup'@'localhost';

mysql> GRANT PROCESS ON . TO 'mysqlbackup'@'localhost';

mysql> GRANT SELECT ON performance_schema.replication_group_members TO

'mysqlbackup'@'localhost';

注意：如果使用的是多主组复制设置，那么请确保所有的主节点都授予了这些权限。

3.MEB 配置文件和参数

MEB 既可以在命令行上指定选项，也可以在选项文件中作为配置参数指定。将数据库配置信息传递给 mysqlbackup 的首选方法是使用 “--default-file” 选项，如果使用了该选项，则它必须是 MEB 命令中出现的第一个选项。通常， MEB 遵循以 MySQL 的风格来处理配置选项，即将 [mysqlbackup] 和 [client] 组作为命令行选项进行传递。运行 mysqlbackup 时指定的任何命令行选项都将覆盖配置文件中的值，对于重复的选项，应以最后读取的值为准。 MEB 还可以读取 [mysqld] 组中的选项，在无法连接到 MySQL 实例时，检测与源库相关的参数。在 mysqlbackup 选项名称中，连字符（ - ）和下划线（ _ ）可以互换使用，类似于使用相同约定的 mysqld 参数。

MEB 程序需要根据如下优先级读取需要备份的 MySQL 数据的位置。

1 ）正在运行的 MySQL 实例的连接信息。

2 ）在 mysqlbackup 命令行上指定的参数。

3 ） MySQL 配置文件（默认情况下是指 Unix 上的 my.cnf 和 Windows 上的 my.ini ）。

1.2 MEB 备份与恢复示例

1.2.1 全局备份与恢复

基于 MEB 实现全局（实例级）的备份和恢复，通常有三个阶段，分别是 备份 （backup） 、日志应用 （apply log） 和复制恢复 （copy back） 。 在备份阶段，程序首先会发起多个后台线程，最先记录备份开始时的 LSN （ Log Sequence Number ，日志序列号），然后开始复制共享系统表空间文件、 Undo 和所有 InnoDB 类型文件，完成之后会持有短暂的全局锁，这期间会复制所有非 InnoDB 类型的文件并记录数据页中最新的 LSN ，然后将备份期间产生的数据变更信息写入 ibbackup_logfile 文件，同时记录二进制日志的文件名和位置（如果当前实例中已开启了二进制日志特性），以便部署和复制，此日志输出格式为 MEB__backup.log 。日志应用阶段，基于现有备份片（ Backup Pieces ），程序可根据备份时记录的最新 LSN 解析 ibbackup_logfile 文件，并批量应用日志记录，以保证数据的一致性，此日志的输出格式为 MEB__apply_log.log ；复制恢复阶段，程序依次将共享系统表空间文件， Undo 、 InnoDB 类型文件，非 InnoDB 类型和 Redo 文件等复制到目标位置，此日志的输出格式为 MEB__copy_back.log 。当三个阶段的操作均成功完成，就可以启动该备份恢复的实例，对外提供服务了。

MEB 全局备份有两种实现方式，既可以将 MySQL 实例备份到指定目录，也可以将其备份到单个映像文件中。

目录备份与恢复

1 ）备份全局实例到指定目录。创建与备份相关的目录结构，命令如下：

shell> mkdir -p /backups/{data,tmpdata,conf}

shell> chown -R mysql:mysql /backups

mysqlbackup 启动联机热备时，可以通过 “--host”“--user” 和 “--password” 选项建立与 MySQL 实例的连接，以便获取与备份相关的信息并记录到相关的备份文件中。并在首次执行备份时，在 MySQL 系统库下自动创建 backup_history 和 backup_progress 两张表，以记录备份任务执行的相关信息，包括备份的时间、类型、格式、 LSN 、二进制日志位置、执行状态、错误信息、锁定时间和备份执行各阶段的状态等。

注意：在选项文件 [client] 组中指定连接选项，若 password 选项值包含了特殊字符，则需要加上单引号，否则调用 mysqlbackup 程序时会报连接失败的错误。

执行全局备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-dir=/backups/data --with-timestamp backup

...

IMPORTANT: Please check that mysqlbackup run completes successfully.

At the end of a successful 'backup' run mysqlbackup

prints "mysqlbackup completed OK!".

...

mysqlbackup completed OK!

为了方便起见，可以使用 “--with-timestamp” 选项在备份目录下创建以时间戳命名的唯一子目录，以保存备份数据，该方式允许删除和归档超过一定时间的备份数据。使用目录备份时，若未指定 “--with-timestamp” 选项，则需要为每个备份作业指定一个唯一的目录。

2 ）全局备份应用日志记录，命令如下：

shell> ./mysqlbackup --backup-dir=/backups/data/2020-01-21_10-45-39 apply-log

...

IMPORTANT: Please check that mysqlbackup run completes successfully.

At the end of a successful 'apply-log' run mysqlbackup

prints "mysqlbackup completed OK!".

...

mysqlbackup completed OK!

3 ）全局备份复制恢复至目标位置（原地恢复）。首先，创建临时实例 scenetmp 数据目录，命令如下：

shell> mkdir -p /mysql/product/scenetmp/{data,log,binlog,relaylog,redo,undo, mysql-files}

然后，在选项文件 /etc/my.cnf 中添加临时实例 [mysqld@scenetmp] 和 [mysqlbackup@scenetmp] 选项组，命令如下：

shell> cp /etc/my.cnf /etc/my.cnf.bak && vi /etc/my.cnf

[mysqld@scenetmp]

datadir=/mysql/product/scenetmp/data

innodb_log_group_home_dir=/mysql/product/scenetmp/redo

innodb_log_files_in_group=3

innodb_log_file_size=1073741824

innodb_undo_directory=/mysql/product/scenetmp/undo

innodb_data_file_path=ibdata1:500M:autoextend

[mysqlbackup@scenetmp]

log-bin=/mysql/product/scenetmp/binlog/mysql-binlog

relay-log=/mysql/product/scenetmp/relaylog/mysql-relay-bin

注意：此处需将 log-bin 和 relay-log 选项配置在 [mysqlbackup@scenetmp] 模块下，否则程序会读取 backup_variables.txt 文件，默认是将二进制日志文件和中继日志文件复制至原实例对应的位置，而该位置已存在相关文件，从而最终导致恢复失败。如果未做特殊说明， MEB 章节示例中的 scenetmp 实例配置都将复用此处的设置。

执行全局复制恢复，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-dir=/backups/data/2020-01-21_10-45-39 copy-back

...

IMPORTANT: Please check that mysqlbackup run completes successfully.

At the end of a successful 'backup' run mysqlbackup

prints "mysqlbackup completed OK!".

...

mysqlbackup completed OK!

4 ）启动目标实例。修改 scenetmp 实例数据目录及文件的用户、属组及权限，命令如下：

shell> chown -R mysql:mysql /mysql/product/scenetmp

shell> chmod -R 750 /mysql/product/scenetmp

启动 scenetmp 实例，命令如下：

shell> systemctl start mysqld@scenetmp

映像备份与恢复

1.2.2 增量备份与恢复

MEB 增量备份概述

1 ）增量备份与差异备份。 MEB 支持增量备份和差异备份，而差异备份又被视为增量备份的一个特例，以全备为基础。每个差异备份均包括自上次执行完整备份以来对数据所做的所有更改；每个增量备份只包括自上次备份以来所做的更改，该备份本身可以是完整备份或增量备份，增量备份系列中的第一个备份总是一个差异备份，但是在此之后，每个增量备份只包含自上次增量备份以来所做的更改。在创建增量备份时，必须向 mysqlbackup 指定上一次完全备份或增量备份的时间点，使用 “--incremental-base” 选项可以从存储在前一个备份目录或服务器上的元数据中自动派生并读取必要的日志序列号（ LSN ）。当然，也可以使用 “--start-lsn” 选项指定一个显式的 LSN 值，为 mysqlbackup 提供之前的完整备份或增量备份结束时的 LSN 。

2 ）非传统增量备份技术。使用 MEB 增量备份特性，必须指定 “--incremental” 或 “--incremental-with-redo-log-only” 选项。与 “--incremental” 选项相比， “--incremental-with-redo-log-only” 的特点体现在以下三个方面。

· 对 InnoDB 表的更改是根据 InnoDB 重做日志的内容确定的。因为重做日志文件有一个预先知道的固定大小，相比于通过扫描 InnoDB 表空间文件来定位更改的页，读取更改所需的 I/O 更少，这取决于数据库的大小、 DML 活动的数量和重做日志文件的大小。

· 由于重做日志文件是循环利用的，所以当新的 DML 操作发生时，旧的更改记录将被覆盖。必须根据 Redo 日志文件的大小、组数和生成的重做数据量，进行合理的计算和预测，制定新的可靠的增量备份计划。否则，重做日志无法保留足够长的时间来记录自上一个增量备份以来的所有更改。在这种情况下， mysqlbackup 将很快确定它无法继续执行，同时还将返回一个错误。如果 Redo 日志文件记录的自上一次备份以来的变更被新的变更信息覆盖了，则需要使用 “--incremental” 选项执行增量备份。

· 这种类型的增量备份不像标准的增量备份（启用 “--incremental” 选项）那样可以容忍较低的 “--start-lsn” 值。例如，不能在执行完整备份后，使用相同的 “--start-lsn” 选项值执行一系列的基于 “--incremental-with-redo-log-only” 选项的备份。

注意：为了确保连续增量备份之间的 LSN 值完全匹配，建议 “--incremental-with-redo-log-only” 选项始终与 “--incremental-base” 选项一起使用。

如果用户将 “--incremental-with-redo-log-only” 选项作为增量备份的策略，则需要判断该类型的增量备份对于特定的 MySQL 实例是否适用，我们可从以下几个方面进行评估。

· 计算 InnoDB 重做日志文件中的数据变化有多快。定期检查 LSN ，以确定在若干小时或几天的时间内累积了多少重做数据。

· 比较重做日志量累计的速度和重做日志文件的大小。使用这个比率来查看进行增量备份的频率，以降低备份失败的可能性，因为历史数据变更在重做日志中可能已经被覆盖了。

· 使用 “--incremental” 和 “--incremental-with-redo-log-only” 选项对增量备份时间进行基准测试，以确认重做日志备份技术是否比传统增量备份方法执行得更快、开销更小。在具有较大数据量和工作负载的 MySQL 服务器上进行测试，例如，如果存在大量的重做日志文件，那么在增量备份过程中读取它们所需要的时间，可能与使用传统增量技术读取 InnoDB 数据文件所需要的时间一样长。相反，如果数据量很大，那么读取所有数据文件以查找少量更改页的效率，可能远低于处理小得多的重做日志文件。

3 ）增量备份注意事项。

· 增量备份特性主要用于 InnoDB 表，其检测的是 InnoDB 数据文件中页级别的变化，而不是表行。由于要对已更改的每个页都进行备份。因此，增量备份方式节省的空间和时间与更改的 InnoDB 行或列的百分比并不完全是成比例的。

· 对于非 InnoDB 文件，如果该文件与上一次备份相比发生了变化，那么整个文件都将包含在增量备份中，相当于全量备份，这意味着与使用 InnoDB 表的情况相比，备份资源的节省并不是那么显著。

· 不能使用 “--compress” 选项执行增量备份。

· 当基于使用 “--no-lock” 选项创建的备份（完整的或增量的）进行增量备份时，注意要使用 “--skip-binlog” 选项来跳过对二进制日志的备份，因为在这种情况下， mysqlbackup 将无法获得二进制日志信息。

· 若使用 “--start-lsn” 选项，则程序不会将二进制日志文件复制到增量备份中。在增量备份期间，若要包含二进制日志文件，可以使用 “--increment- base” 选项，该选项可以为 mysqlbackup 提供必要的信息，以确保前一次备份中包含的二进制日志数据与当前增量备份之间不存在差异。

4 ）全扫描与乐观扫描。如果用户最终选择使用基于 “--incremental” 的传统增量备份方式，则需要为该选项设置 full-scan （全扫描）或 optimistic （乐观扫描）。在未显式指定选项值的情况下，程序默认会自动设置为 full-scan ，即扫描 MySQL 服务器数据目录中的所有 InnoDB 数据文件，查找自上次备份以来发生了更改的页，然后保存这些页，我们称之为全扫描增量备份。若自上一次备份之后，数据库没有发生大量变更，那么这种备份可能就不是很有效了。另一方面，乐观增量备份只会扫描 InnoDB 数据文件中自上次备份以来修改过的页，从而节省一些进行不必要扫描的时间。虽然乐观增量备份可以缩短备份时间，但也存在如下局限性。

· 由于该特性利用了服务器数据目录中文件的修改时间，因此自上一次备份以来，以下两个条件必须保持不变：其一，服务器上的系统时间；其二，数据目录的位置。否则，备份可能会失败，或者可能会产生不一致的增量备份。

· 使用 “--incremental-with-redo-log-only” 无法执行乐观增量备份，因为程序读取的是重做日志文件，而不是扫描数据目录中的文件。

· 如果使用的是 “--start-lsn” 选项，那么即使指定了 “--incremental=optimistic” ，程序也会执行全扫描，因为在这种情况下，它不能确定之前备份的时间点是否一致，因此没有时间框架来确定最近哪些文件被修改过。

上文介绍过如何仅使用重做日志来创建增量备份和乐观增量备份，这两种方式效率虽高，但是也需要事先对特定实例配置和依赖环境做好评估。 Oracle 的块跟踪技术会极大地提高增量备份恢复的效率。下面将基于 “--incremental=full-scan” 的标准增量备份方式，给出增量场景下的各类最佳实践。

映像文件增量备份

在映像文件增量备份方式中， mysqlbackup 会读取 mysql.backup_history 表中最近一次成功备份的 LSN ，并在此基础上执行增量备份操作。

1 ）执行全量备份，详细操作请参考全局备份与恢复中的 “ 映像备份与恢复 ” 。

2 ）第一次增量备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--incremental \

--incremental-base=history:last_backup \

--backup-dir=/backups/data \

--backup-image=incremental_image1.bi \

--with-timestamp \

backup-to-image

3 ）第 N 次增量备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--incremental \

--incremental-base=history:last_backup \

--backup-dir=/backups/data \

--backup-image=incremental_image.bi \

--with-timestamp \

backup-to-image

映像文件增量恢复

1 ）首先，需要恢复完整备份，详细操作请参考全局备份与恢复中的 “ 映像备份与恢复 ” 相关内容。

2 ）恢复第一次增量备份，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-image=incremental_image1.bi \

--backup-dir=/backups/data/2020-01-31_22-51-11 \

--incremental \

copy-back-and-apply-log

3 ）恢复第 N 次增量备份，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-image=incremental_image.bi \

--backup-dir=/backups/data/ \

--incremental \

copy-back-and-apply-log

目录方式增量备份

对于目录方式增量备份，需要使用 “--incremental-base=dir:directory_path” 来指定前一个备份的目录，程序将根据前一个备份的元数据确定增量备份的起点。

1 ）执行全量备份，详细操作请参考全局备份与恢复中的 “ 目录备份与恢复 ” 。

2 ）第一次增量备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--incremental \

--incremental-base=dir:/backups/data/2020-02-01_00-10-30 \

--incremental-backup-dir=/backups/data \

--with-timestamp \

backup

3 ）第 N 次增量备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--incremental \

--incremental-base=dir:/backups/data/ \

--incremental-backup-dir=/backups/data \

--with-timestamp \

backup

目录方式增量恢复

1 ）同样，首先需要恢复完整备份，详细操作请参考全局备份与恢复中的 “ 目录备份与恢复 ” 。

2 ）恢复第一次增量备份，命令如下：

shell> ./mysqlbackup --incremental-backup-dir=/backups/data/2020-02-01_00-15-25 \

--backup-dir=/backups/data/2020-02-01_00-10-30 \

apply-incremental-backup

3 ）恢复第 N 次增量备份，命令如下：

shell> ./mysqlbackup --incremental-backup-dir=/backups/data/ \

--backup-dir=/backups/data/2020-02-01_00-10-30 \

apply-incremental-backup

4 ）将备份复制至目标位置，详细操作请参考 “ 目录备份与恢复 ” 。

注意：增量目录备份也可以使用 copy-back-and-apply-log 命令来恢复，与映像文件恢复的方式一致，其可以简化恢复流程。

对于增量备份，除了上面介绍的两种方式之外，还可以通过指定 “--start-lsn” 选项来进行。

1.2.3 部分备份与恢复

MEB 部分备份概述

1 ）部分备份新选项。 MEB 自 3.10 版本起就为部分备份引入了两个关键的新选项： “--include-tables” 和 “--exclude-tables” 。这两个新选项可用于替换旧的选项 “--include”“--databases”“--databases-list-file” 和 “--only-innodb-with-frm” 。这些旧选项与新选项不兼容，并且在未来发布的版本中将被弃用。默认情况下， MySQL 数据目录及其子目录下的所有文件都包含在备份中，并且此备份包括来自所有的 MySQL 存储引擎及第三方存储引擎，甚至该目录中的所有非数据库文件的数据。本节将重点介绍如何利用这些新选项实现部分备份。

2 ）部分备份选型。 MEB 有多种方式用于创建不同类型的部分备份，具体如下。

·“--include-tables” 选项用于按名称包含特定的表， “--exclude-tables” 选项用于按名称排除特定的表。每个表都将根据 “--include-tables” 或 “--exclude-tables” 选项指定的正则表达式进行检查，如果正则表达式匹配表的完全限定名，则其会包含或排除该表作为备份。使用的正则表达式语法是 POSIX 1003.2 标准中指定的扩展形式， RE2 正则表达式库已经实现了这些选项。

·“--only-innodb” 选项用于包括部分或全部 InnoDB 表，但不包括其他表类型。

·“--only-known-file-types” 选项用于删除存在于 MySQL 数据目录中，但实际上并不属于 MySQL 实例的文件。

· 上述选项可组合使用以实现多种选择效果。

·“--use-tts” 与 “--include-tables” 或 “--exclude-tables” （或两者都使用）选项组合可用于使用传输表空间（ Transportable TableSpace ， TTS ）备份选择的 InnoDB 表。

通常，部分备份比完全备份更难恢复，因为备份数据可能不包括组成完整 MySQL 实例所需的重要部分。因为 InnoDB 系统表空间保存了一个实例的所有数据库中关于 InnoDB 表的元数据，所以在一个包含其他数据库的服务器上恢复部分备份，可能会导致系统失去对其他数据库中 InnoDB 表的跟踪。这就要求在一个新的 MySQL 服务器实例上恢复部分备份，而不需要保存任何其他 InnoDB 表。

3 ）使用 TTS 备份。 MEB 在 3.11 版本之后引入了指定 “--use-tts” 选项创建的备份，该技术支持选择性恢复数据。这为软件错误或人为误操作等故障场景，提供了很好的解决方案。用户可以快速地从历史备份中恢复一些有问题的表，以保障业务的连续性。在选择性数据还原中， “--include-tables=REGEX1” 或 “--exclude-tables=REGEX2” 选项可用于指定要从 TTS 备份中还原的表的名称，其中， REGEX1 和 REGEX2 表示正则表达式。如果表的完全限定名匹配 REGEX1 而不匹配 REGEX2 ，则从 TTS 备份中恢复表。选择性还原不会覆盖服务器上现有的任何表。因此，用户应该首先删除或重命名将要从备份中恢复到服务器上的相关表。

下面来看一下 TTS 的优势、限制与要求。

“--use-tts” 选项可用于启用 InnoDB 表的选择性备份。其将与 “--include-tables” 和 “--exclude-tables” 选项一起使用，以用于选择由正则表达式指定备份的 InnoDB 表。

使用 TTS 进行备份具有如下优点。

· 备份可以恢复到不同的服务器。

· 系统表空间没有备份，因此节省了磁盘空间和 I/O 资源。

· 表的数据一致性由 MySQL 企业版备份工具（ MEB ）统一管理。

同时，该选项还存在一些限制，具体如下。

· 分区表的备份和恢复只支持 MySQL 5.7.4 及以上版本。此外，不能选择单个分区进行备份或恢复，由 “--include-tables” 和 “--exclude-tables” 选项指定的表进行全表备份或恢复。

· 只能备份存储在独立表空间中的表，即启用 innodb_file_per_table 选项创建的表。

· 无法备份非 InnoDB 表。

· 对于部分备份，不包含加密的 InnoDB 表。

· 不能用于增量备份。

· 备份的内容不包括二进制日志或中继日志。

对于使用 TTS 创建的备份，还有一些特殊的要求，具体如下：

· 目标服务器 MySQL 服务必须要正在运行。在恢复期间，需要执行 SQL 语句。

· 需要确保将连接 MySQL 的参数（端口号、套接字名称等）作为 mysqlbackup 的命令行选项，或者是在默认文件的 [client] 部分指定。

· 目标服务器使用的页大小必须与备份服务器上使用的页大小相同。

· 若与表对应的表空间文件的 InnoDB 文件格式与目标服务器系统变量 innodb_file_format 的值不一致，则默认恢复将会失败。需要指定 “--force” 选项，临时修改 innodb_file_format 变量来绕过。

注意：在全锁定模式下创建的 TTS 备份无法进行选择性恢复（ --use-tts=with-full-locked ）。选择性恢复仅支持在以最小锁定模式（ --use-tts=with-minimum-locking ）创建的 TTS 备份时才是有效的，这是 TTS 备份的默认模式。

备份单个或多个数据库

1 ）备份单库并过滤多表。对 db01 数据库中的所有表进行备份，但不包括名称为 cons1 、 cons2 和 cons3 的三张大表，即单库备份，命令如下：

shell> su -l mysql

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_singledb.mbi \

--backup-dir=/backups/data \

--include-tables="^db01\." \

--exclude-tables="^db01\.(cons1|cons2|cons3)$" \

--with-timestamp \

--use-tts \

backup-to-image

注意：基于 mysqlbackup 的部分备份和恢复，需要在 mysql 操作系统账户下进行。若使用超级系统账户 root ，则在未进行额外处理的情况下，恢复将以失败告终。

2 ）备份多库并过滤多表。对 db01 、 db02 和 db03 三个数据库中的所有表进行备份，但不包括名称为 db01.cons1 、 db02.cons2 和 db03.cons3 的三张大表，即多库备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_multidbs.mbi \

--backup-dir=/backups/data \

--include-tables="^(db01|db02|db03)\." \

--exclude-tables="^db01\.cons1$|^db02\\.cons2$|^db03\.cons3$" \

--with-timestamp \

--use-tts \

backup-to-image

恢复单个或多个数据库

1 ）恢复单库。对 db01 数据库中的所有表进行恢复，但不包括名称为 cons1 、 cons2 和 cons3 的三张大表，即单库恢复，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scenetmp/data/mysql.sock \

--backup-image=scene1_singledb.mbi \

--backup-dir=/backups/data/2020-02-01_22-29-20 \

--datadir=/mysql/product/scenetmp/data/ \

--include-tables="^db01\." \

copy-back-and-apply-log

2 ）恢复多库。对 db01 、 db02 和 db03 三个数据库中的所有表进行恢复，但不包括名称为 db01.cons1 、 db02.cons2 和 db03.cons3 的三张大表，即多库恢复，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scenetmp/data/mysql.sock \

--backup-image=scene1_multidbs.mbi \

--backup-dir=/backups/data/2020-02-01_22-42-07 \

--datadir=/mysql/product/scenetmp/data/ \

--include-tables="^(db01|db02|db03)\." \

copy-back-and-apply-log

备份单表或多表

1 ）备份单表。对 db01 数据库中名称为 cons1 的大表进行备份，即单表备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_singletab.mbi \

--backup-dir=/backups/data \

--include-tables="^db01\.cons1$" \

--with-timestamp \

--use-tts \

backup-to-image

2 ）备份多表。对 db01 数据库中名称为 cons1 、 cons2 和 cons3 的三张大表进行备份，即多表备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_multitabs.mbi \

--backup-dir=/backups/data \

--include-tables="^db01\.(cons1|cons2|cons3)$" \

--with-timestamp \

--use-tts \

backup-to-image

注意： MEB 从 3.12.1 版本开始，部分备份选项支持空格或破折号等特殊字符。

恢复单表或多表

1 ）恢复单表。首先，需要模拟即将要恢复的表因出现异常而导致数据不可用或数据丢失的问题，再进行单表恢复，命令如下：

mysql> alter table db01.cons1 rename to db01.cons1_bak;

恢复 db01 数据库中名称为 cons1 的大表，即单表恢复，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_singletab.mbi \

--backup-dir=/backups/data/2020-02-02_00-54-13 \

--datadir=/mysql/product/scene1/data/ \

--include-tables="^db01\.cons1$" \

copy-back-and-apply-log

2 ）恢复多表。同理，首先需要模拟即将要恢复的一组表因出现异常而导致数据不可用或数据丢失的问题，再进行多表恢复，命令如下：

mysql> alter table db01.cons1 rename to db01.cons1_bak;

mysql> alter table db01.cons2 rename to db01.cons2_bak;

mysql> alter table db01.cons3 rename to db01.cons3_bak;

恢复 db01 数据库中名称为 cons1 、 cons2 和 cons3 的三张大表，即多表恢复，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_multitabs.mbi \

--backup-dir=/backups/data/2020-02-02_01-09-09 \

--datadir=/mysql/product/scene01/data/ \

--include-tables="^db01\.(cons1|cons2|cons3)$" \

copy-back-and-apply-log

注意：在多表恢复的场景下，如果存在具有外键约束的表，则需要注意规避外键约束重名的因素，否则恢复将会失败。

本节给出的基于部分备份最佳实践的所有案例，都是基于 “--use-tts” 选项。的确，在传输表空间特性未封装进 mysqlbackup 之前，部分备份恢复功能的实用性其实是很差的，因为它的恢复流程比全局备份要更加困难。但 MEB 3.11 以上版本实现了 TTS （传输表空间）功能，该功能为用户的日常运维提供了一把利器，实现了事半功倍的效果。与 “--use-tts” 选项搭配使用的 “--include-tables” 和 “--exclude-tables” 选项功能同样也是十分强大的，这两个选项的值都是使用正则表达式来表示，对备份和恢复的对象进行过滤和排除，几乎能够满足日常所有场景的需求。

1.2.4 流式备份与恢复

为了降低或限制 MySQL 服务器上的存储开销，可以选择将备份数据通过流的方式传输到其他服务器，而不必存储在本地。 mysqlbackup 的 backup-to-image 命令，可用于将映像文件备份发送到标准输出，用户可以选择不使用 “--backup-image” 选项，或者指定 “--backup-image=-” 使数据被更加明显地发送到标准输出。在流备份的场景下，若与系统工具（如管道、 ssh 和 ftp 等）结合使用，则能够实现从标准输出获取输入，同时在远端存储上创建等效的文件。还可以选择直接在远端系统上存储映像备份，甚至使用另一端的 copy-back-and-apply-log 命令调用 mysqlbackup ，将备份复制恢复到远端的指定位置。

全局映像文件流备份与恢复

1 ）安装 sshpass 软件。采用流式备份需要提前配置源端和目标端 SSH 互信，以便在备份时可以实现免密传输。若有环境或其他限制，则可以考虑使用 sshpass 工具在调用 SSH 时，传入远端服务器账户和密码，打通 SSH 传输通道。在开源社区下载源码，并进行编译和安装，命令如下：

shell> wget http://sourceforge.net/projects/sshpass/files/sshpass/1.05/sshpass-1.05.tar.gz

shell> tar zxvf sshpass-1.05.tar.gz

shell> cd sshpass-1.05/

shell> yum install -y gcc

shell> ./configure

shell> make && make install

2 ）通过流方式在目标主机上创建映像文件备份。在源端执行备份操作，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=- \

--backup-dir=/backups/tmpdata \

--with-timestamp \

backup-to-image | \

sshpass -p Abcd321# ssh root@192.168.113.111 'cat > /backups/data/scene1_

full01.img'

注意： SSH 可以用另一个通信协议（如 ftp ）代替， cat 可以用另一个命令代替（例如， dd 或 tar ，用于正常的归档）。

3 ）映像文件应用日志及恢复。在目标端创建数据目录，并执行日志记录应用和数据库文件复制恢复，命令如下：

shell> mkdir -p /mysql/product/scene1/{data,log,binlog,relaylog,redo,undo,mysql-files}

shell> ./mysqlbackup --defaults-group-suffix=@scene1 \

--backup-image=/backups/data/scene1_full01.img \

--backup-dir=/backups/tmpdata/$(dir=date +"%Y-%m-%d_%H-%M-%S" && mkdir /

backups/tmpdata/$dir && echo $dir) \

copy-back-and-apply-log

全局映像文件流备份与恢复优化

将上述 “ 全局映像文件流备份与恢复 ” 中的备份和恢复流程整合成一个任务，并在源端直接执行，几乎可以减少一半左右物理 I/O 的读写。压缩与解压的方式，可以充分发挥服务器 CPU 和存储的性能，以减少对网络带宽的冲击，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=- \

--backup-dir=/backups/tmpdata \

--with-timestamp \

--compress \

backup-to-image | \

sshpass -p Abcd321# ssh root@192.168.113.111 'mysqlbackup --defaults-group-suffix=@scene1 \

--uncompress \

--backup-image=- \

--backup-dir=/backups/tmpdata/$(dir=date +"%Y-%m-%d_%H-%M-%S" && mkdir /backups/tmpdata/$dir && echo $dir) \

copy-back-and-apply-log'

全局目录流备份与恢复

1 ）源端创建全局目录备份。详细操作请参考全局备份与恢复中的 “ 目录备份与恢复 ” 。

2 ）全局目录备份流处理与恢复。在源端执行下列任务，将备份目录作为单个备份文件进行流处理，然后直接在目标端恢复：

shell> ./mysqlbackup --backup-image=- \

--backup-dir=/backups/data/2020-02-02_04-49-55 \

backup-dir-to-image | \

sshpass -p Abcd321# ssh root@192.168.113.111 'mysqlbackup --defaults-group-suffix=@scene1 \

--backup-image=- \

--backup-dir=/backups/tmpdata/$(dir=date +"%Y-%m-%d_%H-%M-%S" && mkdir /backups/tmpdata/$dir && echo $dir) \

copy-back-and-apply-log'

流备份恢复技术的特点与优势

流技术非常适用于跨服务器的备份恢复场景，而无需担心源端存储空间。既可以将重要的生产数据通过网络存储在远端，也可以使用该方式在目标服务器上定期进行备份恢复演练，以应对出现的极端情况。将 MySQL 备份数据流传输到另一个设备或服务器场景的方法非常多，原理都是相通的。同时，流技术也支持将数据备份到磁带或云存储中

1.2.5 压缩备份与恢复

MEB 压缩特性可以节省大量的存储空间，并显著降低 I/O 开销。使用 mysqlbackup 的 “--compress” 选项来压缩 InnoDB 备份数据文件，意味着可以保留更多的备份数据集，或者节省备份数据的传输时间。此外，由于 I/O 减少，压缩通常可以实现更快的备份。注意，备份压缩特性只适用于 InnoDB 表。在备份期间对 InnoDB 表空间文件进行压缩之后，默认会生成以 “.ibz” 为后缀的扩展名。但是，即使指定了 “--compress” 选项，程序也不会尝试压缩 MySQL 服务器上已经压缩过的表（压缩表），从而规避在不能节省额外磁盘空间的情况下浪费 CPU 资源，不过这类表空间文件在备份时也是以 “.ibz” 为扩展名来保存的。 “--compression-method” 选项可用于帮助用户选择 ZLIB 或 LZMA 压缩算法。 “--compression-level” 选项可用于指定所需的压缩级别。而二进制日志和中继日志文件在压缩备份时，是以 “.bz” 为扩展名进行压缩和保存的，只能对完整备份使用 “--compress” 选项，而不能对增量备份使用。

全量压缩备份

1 ）创建全局压缩映像备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data \

--compress --compress-level=5 --compress-method=zlib\

--with-timestamp \

backup-to-image

2 ）创建全局压缩目录备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-dir=/backups/data \

--compress --compress-level=5 --compress-method=zlib\

--with-timestamp \

backup

注意：当 InnoDB 表空间文件中有未使用的空间时，在未使用压缩选项进行备份时，会复制整个文件，而执行压缩备份正好可以避免这些未使用空间的存储开销。

解压缩与恢复

1 ）映像备份解压缩与恢复，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data/2020-02-02_06-56-29 \

--uncompress \

copy-back-and-apply-log

2 ）目录备份解压缩与恢复，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-dir=/backups/data/2020-02-02_07-05-47 \

--uncompress \

copy-back-and-apply-log

MEB 压缩技术的特点与优势

MEB 支持全量压缩，压缩级别有 0 到 9 ，共计 10 个级别。当 “--compress-level” 选项值为 0 时，表示不压缩；为 1 时，表示压缩速度最快；为 9 时，表示压缩比最高。同时，该程序支持多种压缩算法，例如， LZ4 、 zlib 和 LZMA ，默认的压缩算法是 LZ4 。使用 LZ4 压缩算法处理压缩的开销非常低，该算法适用于从更快的磁盘系统转移到可能更慢的存储。因此，建议用户尽量使用 LZ4 压缩算法而不是不进行任何压缩，因为基于 LZ4 的备份通常能在更短的时间内完成。尽管如此，我们还是要在用户自身环境中进行充分测试，以确定什么才是最有效的方法。需要注意的是，只有使用 zlib 和 LZMA 算法，指定压缩级别才有意义。压缩比并不是越高越好，这里涉及了用时间换取空间的概念，应当找一个适配业务场景的恰当设置。

1.2.6 加密备份与恢复

为了增强备份数据的安全性， MEB 为映像备份提供了加密服务。 MEB 可以使用软件自带的加密格式实现加密功能，这意味着其只有使用自己的程序才能解密。并且该程序可以使用高级加密标准（ Advanced Encryption Standard ， AES ）块密码在 CBC 模式下进行加密，密钥字符串为 64 个十六进制数字，由用户自己提供。该加密方式要求必须使用相同的密钥才能解密，而创建密钥的方式通常有两种。其一，将 64 个随机的十六进制数组合在一起，就可以实现手动创建密钥；其二，由 shasum （或者在平台上运行用于哈希计算的类似程序，例如， OpenSSL ）提供一个关键字来生成密钥。

创建加密密钥

使用 OpenSSL 工具随机生成十六进制格式的备份加密密钥，并重定向至密钥文件，命令如下：

shell> openssl rand -hex 32 > /backups/conf/keyfile

shell> cat /backups/conf/keyfile

bf989d87a3a5dcf9a0525dc2ce4b515ea1f28da1b8adeb723250432fee7df468

创建加密备份

1 ）使用 “--encrypt” 和 “--key” 选项创建加密备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data \

--encrypt --key=bf989d87a3a5dcf9a0525dc2ce4b515ea1f28da1b8adeb723250432fee7df468 \

--with-timestamp \

backup-to-image

2 ）使用 “--encrypt” 和 “--key-file” 选项创建加密备份，命令如下：

shell> ./mysqlbackup -uroot -p --socket=/mysql/product/scene1/data/mysql.sock \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data \

--encrypt --key-file=/backups/conf/keyfile \

--with-timestamp \

backup-to-image

以上两种加密方式虽有不同，但效果一致。因为不管是通过 “--key” 选项还是 “--key-file” 选项指定，最终的密钥都是一致的。笔者更推荐使用密钥文件（ “--key-file” ）方式。

解密与恢复

1 ）使用 “--decrypt” 和 “--key” 选项实现解密与恢复，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data/2020-02-02_08-42-54 \

--decrypt --key=bf989d87a3a5dcf9a0525dc2ce4b515ea1f28da1b8adeb723250432fee7df468 \

copy-back-and-apply-log

2 ）使用 “--decrypt” 和 “--key-file” 选项实现解密与恢复，命令如下：

shell> ./mysqlbackup --defaults-group-suffix=@scenetmp \

--backup-image=scene1_full01.mbi \

--backup-dir=/backups/data/2020-02-02_08-45-59 \

--decrypt --key-file=/backups/conf/keyfile \

copy-back-and-apply-log

同样，指定 “--key” 和 “--key-file” 都可以实现解密恢复。值得注意的是，在对映像文件进行验证、提取或进行其他操作时，必须指定解密密钥相关的操作才能正常执行。