重要更改： 新行（
start_time_utc、end_time_utc、consistency_time_utc和meb_version）被添加到backup_history表中。要影响此更改，在执行 3.12.4 版本的任何备份操作之前backup_history表的 ALTER 权限授予连接到 MySQL 服务器的用户mysqlbackup当备份服务器启用了 GTID 时， 有关已执行 GTID 的信息现在包含在 mysqlbackup输出和备份日志中。（缺陷号 25978803）
-
如果在备份过程中发生了利用 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）
一个新选项，
--skip-final-rescan使 mysqlbackup跳过在备份操作接近尾声时数据库被锁定后由 DDL 操作修改的 InnoDB 表的最终重新扫描。这可能会缩短锁定的持续时间并减少备份对服务器正常操作的影响。有关详细信息，请参阅说明--skip-final-rescan。（缺陷号 21094221）mysqlbackup 的输出（进入
stderr流和消息日志）现在已得到改进，包括mysqlbackup采取的所有步骤的时间戳和线程 ID ，以便为调试目的提供更多信息。（缺陷号 20142619）--include-tables当在备份操作期间没有与选项 指定的正则表达式匹配的表时， mysqlbackup 仍然创建一个备份，其中包含服务器上每个数据库的空文件夹。mysqlbackup--include-tables现在在选择没有要备份的表时抛出错误 。（漏洞 #18114353）-
在备份的最后阶段，当 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） -
为了最小化热备份对 MySQL 服务器的影响，缓冲池转储文件和一些元数据文件的复制现在在服务器实例锁定的备份的最后阶段之前执行。这样可以缩短锁定时间，减少备份对服务器正常运行的影响。
此外，为了最大限度地减少备份所用的资源，不再为部分备份和脱机备份执行缓冲池转储文件的复制，对于这些备份，缓冲池转储通常不是很有用。
当 MySQL 服务器将系统变量设置解释
--innodb_checksum_algorithm=0为意味着--innodb_checksum_algorithm=crc32mysqlbackup操作（备份除外）在备份服务器上设置为配置选项时 失败--innodb_checksum_algorithm=0。通过此修复，mysqlbackup现在--innodb_checksum_algorithm=0视为有效并将其解释为--innodb_checksum_algorithm=crc32. （漏洞 #28295519）在 macOS 上，如果未指定中继日志索引文件名，mysqlbackup无法正确确定中继日志文件名。（缺陷号 25574605）
ReleaseMySQL Enterprise Backup 的 RPM 包的编号始终 显示为“ 1 ” ，而不是为其构建包的 Linux 发行版的版本号。（缺陷号 25538798）当在备份操作期间使用选项
--only-innodb-with-frm或--no-locking时，备份有时会失败， mysqlbackup抱怨复制页面中的最高 LSN 大于备份服务器上的最高 LSN。这是因为当使用上述任一选项时， mysqlbackup在复制重做日志之前没有执行日志刷新。通过此修复，始终执行日志刷新以防止错误。（漏洞#25412655）-
mysqlbackup
--no-locking在使用该选项 创建完整映像备份时 ，未能将二进制日志信息写入备份历史表和 文件。结果是，当基于完整备份创建增量映像备份时，尝试将二进制日志文件从服务器复制到增量映像备份（这是默认行为）会失败，从而导致增量备份停止。通过此修复，完整备份后二进制日志信息不再丢失，因此增量映像备份不再失败。”（缺陷 #25296324）backup_variables.txt参考资料：另请参阅：Bug #19915713。
恢复从服务器的增量备份后，目标服务器备份目录下的文件夹
ibbackup_slave_info中缺少该文件。meta（缺陷号 25097753）mysqlbackup将带有错误信息的双条目记录到
backup_history乐观备份表中。（漏洞 #24502876）-
使用该选项的多源复制设置中的从属服务器备份
--slave-info失败。（漏洞 #24444950）参考资料：另请参阅：Bug #21830316。
尝试使用该
--skip-binlog选项从云恢复映像备份失败，并出现 “全局尾部魔法不匹配”错误。这是因为mysqlbackup无法从云中执行非顺序读取，并且由于跳过二进制日志而导致出现间隙。此修复确保 mysqlbackup可以执行此类读取。（缺陷号 23534700）-
如果
extract在备份期间 InnoDB 表空间文件的大小不断增加，并且mysqlbackup无法将正确的文件大小放入其文件头，则图像备份操作会因校验和不匹配错误而失败。（漏洞 #22905984）参考资料：此问题是 Bug #22613568 的回归。
在
apply-incremental-backup完整备份操作之后，mysqlbackup 将旧的而不是更新的二进制日志位置打印到输出流和消息日志文件。（缺陷 #22085034，缺陷 #78898）backup-and-apply-log在没有连接到 MySQL 服务器 的情况下运行 命令时， mysqlbackup 无法知道备份的正确二进制日志文件名和二进制日志位置；然而，在backup-and-apply-log操作结束时， mysqlbackup仍然打印出一些二进制日志文件名和位置的值，这些值本质上是随机的。（漏洞 #21623089）如果任何表名包含保留字或特殊字符，则在mysqlbackup 将
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK语句应用于所有非 InnoDB 表 时备份失败。这是因为mysqlbackup在发出语句时没有将表名括在反引号中，并且此修复确保完成了。（缺陷 #19709505，缺陷 #74144）--backup-to-image有时，命令 创建的映像备份中会丢失一些文件。这是由于内部竞争条件造成的，此修复程序消除了这种情况。（漏洞 #19600687）