除了 --datadir选项指定的恢复目标数据目录必须不存在或为空的要求之外，mysqlbackup--innodb_data_home_dir现在对、 --innodb_log_group_home_dir和 选项强制执行相同的规则 --innodb_undo_directory（该 --force选项不能用于覆盖对三个的要求选项）。

MySQL Enterprise Backup 4.1 无法备份之前由 MySQL Enterprise Backup 4.0 备份的 MySQL Server。这是由于backup_history查询表的方式所致，现在已修复。（缺陷号 29208386）

使用 Group Replication 集群时， mysqlbackup可能会在接近备份操作结束时意外退出，当时为了写入 backup_history表，它尝试使用未加密的连接连接到备份用户未登录的节点之一在之前。备份用户是用 caching_sha2_password plugin插件创建的，所以第一次连接服务器时必须加密连接登录；因此登录尝试失败， mysqlbackup无法处理该失败。通过此修复，在出现此类故障时，mysqlbackup 优雅地退出并警告备份操作已完成而没有更新备份历史记录。（漏洞#28893180）

使用命令恢复增量备份映像 copy-back-and-apply-log失败，mysqlbackup抱怨目标服务器的服务器存储库配置（包括，例如，值innodb_data_file_path）未知，除非配置明确提供给mysqlbackup。通过此修复，mysqlbackupbackup-my.cnf从已使用增量备份的基本备份恢复的文件中获取所需信息。（漏洞#28411028）

当用户错误地将源目录指定为恢复某些文件的目标目录（例如，将备份 --backup_innodb_data_home_dir值指定为恢复 --innodb_data_home_dir值）时，恢复操作可能会损坏备份。当命令选项使源文件路径和目标文件路径对于还原期间复制的任何文件相同时，此修复通过让 mysqlbackup抛出错误来防止出现此问题。（缺陷号 28376873）

在 FreeBSD 平台上，使用该 --show-progress选项不会使 mysqlbackup打印进度报告。（漏洞 #28350122）

恢复InnoDB加密表后，有时恢复后的服务器无法启动，或者启动后无法打开InnoDB加密表。

此修复不仅解决了上述问题，还解决了另外两个问题：无法还原包含行压缩的加密 InnoDB 表的备份，以及在中间创建加密 InnoDB 表时无法完成备份。备份操作。（漏洞 #28301281）

参考资料：另请参阅：Bug #28360241、Bug #27168458。

当 MySQL 服务器将系统变量设置解释 --innodb_checksum_algorithm=0 为意味着 --innodb_checksum_algorithm=crc32mysqlbackup操作（备份除外）在备份服务器上设置为配置选项时 失败--innodb_checksum_algorithm=0 。通过此修复，mysqlbackup现在 --innodb_checksum_algorithm=0 视为有效并将其解释为 --innodb_checksum_algorithm=crc32. （漏洞 #28295519）

Windows 版本的 MySQL Enterprise Backup 在调用时不显示其构建 ID。（漏洞#27916702）

mysqlbackup首次备份 4.1.2 或更高版本的 MySQL 服务器时，如果未ALTER将表的权限 授予连接到服务器mysql.backup_history_new的 MySQL 用户， 则会意外退出。mysqlbackup通过此修复，mysqlbackup可以在抛出正确错误后正常退出。

此外，现在 仅需要首次备份从 5.7.22 或更早版本升级且之前已由 MySQL Enterprise Backup 备份的 MySQL Server 时才需要和 CREATE、 、 INSERT和 的 DROP权限 。 （错误#27879530，错误#28546256）mysql.backup_history_oldCREATEINSERTDROPALTERmysql.backup_history_new

使用该--show-progress=table 选项时，mysqlbackup在错误日志中给出警告，提示操作接近尾声时与服务器的连接中止。这是因为用于写入backup_progress 表的服务器连接保持打开状态。通过此修复，连接在mysqlbackup 操作完成后正确关闭。（漏洞#27647283）

当涉及具有相对文件路径的单个表空间时，增量备份的还原操作失败。（漏洞#26442994）

当在备份操作期间使用选项 --only-innodb-with-frm或 --no-locking时，备份有时会失败， mysqlbackup抱怨复制页面中的最高 LSN 大于备份服务器上的最高 LSN。这是因为当使用上述任一选项时， mysqlbackup在复制重做日志之前没有执行日志刷新。通过此修复，始终执行日志刷新以防止错误。（漏洞#25412655）

部分备份有时会失败，因为全文索引文件的文件名与--include-tables选项提供的正则表达式匹配，然后这些文件被 mysqlbackup作为普通表空间文件处理。通过此修复， mysqlbackup从备份中排除任何全文索引文件。（缺陷号 25044900）

如果，当备份正在进行并且 mysqlbackup正在读取二进制日志（或中继日志）索引文件并且服务器试图修改索引文件（因为，例如，刚刚发生了日志刷新或日志清除），则二进制日志记录（或中继日志记录）已停止；服务器也会在 Windows 平台上意外退出。这是因为 mysqlbackup没有很好地处理文件共享冲突。通过此修复，mysqlbackup 现在使用本地文件系统 API 读取索引文件，该 API 可以优雅地处理文件共享冲突；还有， mysqlbackup现在将索引文件复制到其缓冲区中，然后将其关闭，而不是长时间保持打开状态，因此服务器可以更轻松地修改或删除索引文件。（错误#22914974，错误#26047119）