-
如果在备份过程中发生了利用 MySQL 服务器 在线 DDL 功能的 DDL 操作，则备份会损坏 。这是因为mysqlbackup不支持服务器功能——现在仍然不支持。此修复程序通过让mysqlbackup在备份开始时 将服务器的系统变量
old_alter_table变为 “ 1 ”（如果它是 “ 0 ” ）来避免错误，以便使用旧的表复制方法处理备份期间发生的任何 DDL 操作。 mysqlbackup然后将变量转回 “ 0 ”接近备份操作结束。重要的请注意，在mysqlbackup 意外退出且未
old_alter_table恢复为原始值的情况下，用户必须在服务器上手动将值恢复为 “ 0 ”，以便将服务器恢复为原始配置。如果语句“ Server system variable 'old_alter_table' was set to '0'”，则应执行此操作。Setting it to '1' ” 出现在mysqlbackup的早期输出中，但是语句“ Setting server system variable 'old_alter_table' back to '0' ”在mysqlbackup退出之前不会出现 。（漏洞#25217215）
MySQL Enterprise Backup 现在支持该
--ssl-mode选项，使您能够指定与服务器的连接的安全状态。 它取代了现在已弃用的客户端--ssl和 选项。--ssl-verify-server-cert详见 MySQL 5.7参考手册--ssl-mode对该选项 的描述。（缺陷号 23508228）一个新选项，
--skip-final-rescan使 mysqlbackup跳过在备份操作接近尾声时数据库被锁定后由 DDL 操作修改的 InnoDB 表的最终重新扫描。这可能会缩短锁定的持续时间并减少备份对服务器正常操作的影响。有关详细信息，请参阅说明--skip-final-rescan。（缺陷号 21094221）mysqlbackup 的输出（进入
stderr流和消息日志）现在已得到改进，包括mysqlbackup采取的所有步骤的时间戳和线程 ID ，以便为调试目的提供更多信息。（缺陷号 20142619）-
在备份的最后阶段，当 MySQL Enterprise Backup 尝试使用语句暂时将数据库置于只读状态
FLUSH TABLES WITH READ LOCK以复制非 InnoDB 文件时，如果同时在服务器上运行长查询，则FLUSH TABLES WITH READ LOCK语句可能需要很长时间才能完成，从而阻止进一步的查询并最终导致服务器宕机。现在可以使用 一个新的mysqlbackup选项 来指定 FLUSH TABLES WITH READ LOCK 语句的超时时间（以秒为单位）。
--lock-wait-timeout如果超时，则语句失败并释放表上的锁，以便可以执行被锁阻止的查询。mysqlbackup 然后重试语句并继续备份。默认值为--lock-wait-timeout60 [秒]。（漏洞 #14339483） -
该
backup_history表现在包括以下新列：start_time_utcend_time_utcconsistency_time_utcmeb_version
现在已经为 MySQL Enterprise Backup 实施了一整套退出代码。此外，新的mysqlbackup命令
print-message为新选项提供的任何给定退出代码返回退出消息--error-code。有关详细信息，请参阅 MySQL Enterprise Backup的退出代码。为了提高热备份的性能， mysqlbackup
FLUSH TABLES WITH READ LOCK现在通过在使用 语句锁定数据库之前调整 MyISAM 密钥缓存的大小来缩短备份的最后阶段。调整大小会触发 MyISAM 键缓存的刷新，从而减少运行FLUSH TABLES WITH READ LOCK语句所需的时间。之后 MyISAM 密钥缓存大小将更改回其原始值。现在可以使用多个工作线程并行执行应用日志操作，这可以提高操作的性能。可以使用该
--process-threads选项指定要使用的线程数。将重做日志文件复制到备份中的速度更快，在某些情况下缩短了整体备份时间，并降低了备份失败的可能性，因为重做日志文件在复制之前已被覆盖。
MySQL Enterprise Backup 现在支持乐观增量备份，mysqlbackup只扫描那些自上次备份以来修改过的InnoDB 数据文件，然后将它们保存到增量备份中。它可能使增量备份更快，并通过指定
--incremental=optimistic. 有关详细信息，请参阅全扫描与乐观增量备份。-
为了最小化热备份对 MySQL 服务器的影响，缓冲池转储文件和一些元数据文件的复制现在在服务器实例锁定的备份的最后阶段之前执行。这样可以缩短锁定时间，减少备份对服务器正常运行的影响。
此外，为了最大限度地减少备份所用的资源，不再为部分备份和脱机备份执行缓冲池转储文件的复制，对于这些备份，缓冲池转储通常不是很有用。
ReleaseMySQL Enterprise Backup 的 RPM 包的编号始终 显示为“ 1 ” ，而不是为其构建包的 Linux 发行版的版本号。（缺陷号 25538798）如果在创建备份期间删除了任何表，然后使用相同的名称重新创建了不止一次，则
apply-logor 操作失败。apply-incremental-backup（漏洞 #25334929）-
mysqlbackup
--no-locking在使用该选项 创建完整映像备份时 ，未能将二进制日志信息写入备份历史表和 文件。结果是，当基于完整备份创建增量映像备份时，尝试将二进制日志文件从服务器复制到增量映像备份（这是默认行为）会失败，从而导致增量备份停止。通过此修复，完整备份后二进制日志信息不再丢失，因此增量映像备份不再失败。”（缺陷 #25296324）backup_variables.txt参考资料：另请参阅：Bug #19915713。
-
备份操作有时会因复制的重做日志损坏而失败，而损坏的发生是因为未为 mysqlbackup激活重做日志的校验和验证。此修复程序恢复了校验和功能，以便
innodb_log_checksums=ON在备份服务器上执行验证。当大量重做日志数据验证失败时，mysqlbackup 会尝试从服务器重新读取数据。但是离线备份不做redo log checksum校验，
innodb_log_checksums在备份过程中服务器上关闭该值在线备份失败。（缺陷号 25057394） mysqlbackup将带有错误信息的双条目记录到
backup_history乐观备份表中。（漏洞 #24502876）-
使用该选项的多源复制设置中的从属服务器备份
--slave-info失败。（漏洞 #24444950）参考资料：另请参阅：Bug #21830316。
如果备份服务器配置
innodb_undo_tablespaces为非零，则在备份期间，mysqlbackup发出关于缓存中已存在的表空间的无意义警告消息。此修复程序删除了这些消息。（漏洞 #24400230）在对具有加密 InnoDB 表的备份执行
apply-logor 操作期间，如果未为使用的选项指定值，则操作失败，并抱怨未指定加密密码。通过此修复， mysqlbackup在相同情况下会要求用户提供加密密码。（漏洞#24364442）copy-back-and-apply-log--encrypt-password备份包含其数据目录之外的表空间的服务器的应用日志操作失败。这是因为这些表空间与数据目录中的表空间不同， 在应用日志操作开始之前没有被mysqlbackup加载。此修复可确保加载所有表空间。（漏洞 #22026145）
backup-and-apply-log在没有连接到 MySQL 服务器 的情况下运行 命令时， mysqlbackup 无法知道备份的正确二进制日志文件名和二进制日志位置；然而，在backup-and-apply-log操作结束时， mysqlbackup仍然打印出一些二进制日志文件名和位置的值，这些值本质上是随机的。（漏洞 #21623089）