关于如何为MySQL Enterprise Backup的云操作配置SSL主机身份验证，有两个增强:

中两个新选项的描述云存储选项更多信息。(错误# 22761313)

mysqlbackup用于在备份操作结束时关闭所有表之前，将所有数据从缓冲区缓存同步到硬盘。然而，对于存储设备速度较慢的系统和具有大量表的数据库，同步将显著增加备份时间。为了缩短这些情况和其他情况的备份时间，从这个版本开始，不再自动执行同步。希望在备份结束时执行同步的用户必须使用new——free-os-buffers选择。(错误# 22561345)

MySQL企业备份现在支持多源复制设置中的从服务器备份。(Bug #21830316, Bug #22283631)

为了避免在从机上临时表仍然打开的情况下完成从机上的备份，这会导致恢复后的从机上处于不一致的复制状态，mysqlbackup现在有一个新的机制来确保在完成从备份之前所有临时表都已经关闭。看到基于语句的复制(SBR)从机上的临时表获取详细信息。一个新的选择，——safe-slave-backup-timeout，已创建用于指定时间mysqlbackup将等待所有临时表在超时前关闭。(错误# 19158516)

的压缩选项现在可以和backup-and-apply-log创建已准备并压缩的目录备份的操作;然后可以使用复制回去操作和——解压选择。(错误# 18913565)

在一次copy-back-and-apply-log或者一个复制回去操作,mysqlbackup对象的指定值innodb_log_files_in_group而且innodb_log_file_size选项与备份中记录的选项相匹配backup-my.cnf文件，并在值不匹配时抛出错误。这样可以防止mysqlbackup使用错误的参数恢复备份，这将导致无法启动恢复的服务器。(错误# 14751027)

值MASTER_USER而且MASTER_PORT都包含在将master更改为从信息文件中的语句(元/ ibbackup_slave_info)当——slave-info选项用于备份从服务器。(错误# 14213115)

微软的Windows操作系统:在Windows平台上，mysqlbackup崩溃而不是优雅地退出时——datadir选项未指定复制回去或copy-back-and-apply-log操作。(错误# 22069093)

一个运用原木操作失败时，重命名表语句应用于备份，即使重命名的表已经包含在备份中。此修复程序通过使mysqlbackup忽略”脏”(中间)当(a)新的表名已经被使用，或者(b)如果表空间没有用旧的表名加载到内存中时的日志记录。(错误# 23068440)

如果在备份期间有不断增长的大数据文件，增量或压缩备份可能会失败，并出现文件结束错误。这是因为，随着数据文件的扩展，写入过程改变了文件的大小，从而混淆了相同文件的读取过程。有了这个修复，文件大小和关于它们的信息现在被正确处理。(错误# 23048004)

参考文献:此问题是Bug #19149210的回归。

恢复云备份有时会失败错误18:传输部分文件．这是因为mysqlbackup为部分下载的REST请求创建了错误的范围头。10bet手机中文版(错误# 23035334)

mysqlbackup系统崩溃时验证对包含撤消表空间但不包含系统表空间的增量备份执行了操作。这是因为mysqlbackup没有正确处理undo表空间的数据文件，此修复程序纠正了这一错误。(错误# 22960185)

方法恢复压缩映像备份copy-back-and-apply-log命令失败”错误:InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for redo log record…．”这是因为没有加载undo表空间，导致对它们的日志操作失败。此修复确保了加载undo表空间。(错误# 22914556)

如果一个表在备份操作期间被重命名，它有时会被复制到备份中两次，一次是在旧表名下，另一次是在新表名下。这是因为mysqlbackup，当检查在备份过程中已更改的表时，只检查其.ibd文件的名字。通过这个修复，表空间ID也会被检查，这样重命名的表就会被识别为这样的表，而不会被复制两次。(错误# 22859445)

有时，在单文件备份期间，当数据文件的大小不断增长时，可能会产生一个损坏的映像备份，导致后续的映像备份命令(例如，验证或或向后复制运用原木)失败。这是由于图像文件头中的文件大小与磁盘上的实际文件大小不匹配，现在通过这个修复程序防止了这种情况。(错误# 22613568)

离线备份有时会失败，偶尔会出现崩溃mysqlbackup．(错误# 22595461)

对于从服务器的备份，存储在文件中的主服务器二进制日志的文件名和启动复制的二进制日志位置backup_varaibles.txt备份为masterlog_file而且masterlog_pos，当一个运用原木或copy-back-and-apply-log操作已应用于备份。(错误# 22329306)

当mysqlbackup遇到一个未知文件类型的文件，它的路径名包含的字符mysqlbackup无法转换为文件系统字符集，因此抛出错误。有了这个修复，mysqlbackup在发出警告后继续执行任务。(错误# 22098742)

如果在备份过程快结束时，mysqlbackup发现备份开始时的二进制日志文件已被清除。有了这个修复，mysqlbackupNow忽略文件已被清除的事实，将日志位置重置为当前的二进制日志文件，并继续进行备份而不引发任何问题。(错误# 21655145)

在备份期间，mysqlbackup默认情况下，执行一个SQL查询来获取存储引擎信息backup_history表格由于该查询导致扫描服务器上的所有表文件，当服务器上有许多表时，它会消耗大量IO资源，有时会导致严重的性能问题。通过此修复，只有备份中包含的表被扫描，从而减少了服务器上的IO压力。(错误# 21098174)

在创建压缩备份时，mysqlbackup如果在进程中间删除服务器上的表，则抛出错误。通过此修复，删除的表将被忽略(因为它不需要恢复)和mysqlbackup结束时不抛出错误。(错误# 21087079)

参考文献:参见Bug #18358912。

验证备份映像和backup-to-image临时文件夹剩余的操作(/ tmp)。(错误# 20912357)

类启动过的服务器备份失败——log-bin选项，然后在没有它的情况下重新启动。这是因为mysqlbackup，在服务器上看到旧的二进制日志索引文件，徒劳地查找当前的二进制日志文件，报告找不到它们，然后退出。有了这个修复，mysqlbackup检查服务器是否启用了二进制日志记录;如果不是，mysqlbackup然后跳过将二进制日志复制到备份中。(错误# 20873010)

如果在备份期间，中继日志文件从从服务器被清除(例如，由于日志文件旋转)，则从服务器的备份将失败。有了这个修复，备份即使继续mysqlbackup发现丢失的中继日志文件。(Bug #20769891, Bug #76312, Bug #21655314, Bug #19255925)

当跟踪水平的mysqlbackupMessages大于”0，”如果操作命令为mysqlbackup无效或丢失时，打印了堆栈跟踪和一些错误消息，这使它看起来像mysqlbackup已经崩溃了。有了这个修复，现在在堆栈跟踪之前会显示一条新消息，以更好地解释情况。(错误# 20281022)

方法将增量备份应用于目录备份apply-incremental-backup命令并将最新备份恢复到数据目录，则可以将相同的增量备份再次恢复到数据目录copy-back-and-apply-log命令，可能导致数据不一致。使用此修复程序，增量数据只能在——力选项。没有——力选项时,copy-back-and-apply-log如果增量备份是目录备份，则跳过apply日志操作，如果是映像备份则抛出错误。(错误# 18004179)