如果 mysqlbackupinnodb_checksum_algorithm命令行上提供的或 backup_innodb_checksum_algorithm 选项的值与服务器的不同， mysqlbackup 会给出一个警告，指出指定的校验和算法可能与服务器不兼容。从 3.12.2 开始，为了与 MySQL 服务器自 5.6.25 起处理校验和的方式保持一致， mysqlbackup对每个文件中的每一页数据给出单独的警告， 其中指定的校验和算法与使用的算法不匹配在服务器上。（漏洞 #22509993）.ibd

当该选项用于备份从属服务器时，MASTER_USER和 的 值MASTER_PORT现在包含在 从属信息文件 ( )的CHANGE MASTER TO语句中。（漏洞 #14213115）meta/ibbackup_slave_info--slave-info

当mysqlbackup遇到未知文件类型的文件并且其路径名包含 mysqlbackup无法转换为文件系统字符集的字符时，它会抛出错误。通过此修复， mysqlbackup在发出警告后继续运行。（缺陷号 22098742）

如果在备份过程快要结束时， mysqlbackup发现备份开始时的二进制日志文件已被清除，则备份失败。通过此修复，mysqlbackup现在忽略文件已被清除的事实，将日志位置重置为当前的二进制日志文件，并继续备份而不会引发任何问题。（漏洞 #21655145）

在备份期间，mysqlbackup默认执行 SQL 查询以获取要放入backup_history表中的存储引擎信息。由于查询会导致服务器上的所有表文件都被扫描，当服务器上有很多表时，会消耗大量的IO资源，有时会导致严重的性能问题。通过此修复，仅扫描备份中包含的表，从而减少服务器上的 IO 压力。（缺陷号 21098174）

创建压缩备份时， 如果服务器上的表在进程中间被删除，则mysqlbackup 会抛出错误。通过此修复，删除的表将被忽略（因为它不需要恢复）并且mysqlbackup完成而不会抛出错误。（缺陷号 21087079）

参考资料：另请参阅：错误 #18358912。

当备份花费很长时间执行并且二进制日志在过程中间轮换时， mysqlbackup丢失了它正在复制的二进制日志文件的踪迹，跳过倒数第二个日志文件并尝试复制最后一个文件两次；这导致文件创建错误，此时mysqlbackup 退出，但没有释放对数据库中表的锁定。有了这个修复，所有二进制日志文件现在都被正确复制，并且表上的锁像往常一样在备份过程结束时被释放。（缺陷号 20971763）

恢复增量备份映像时，如果备份中的二进制日志大于 16MB，恢复的二进制日志将损坏，因为mysqlbackup不断地用二进制日志内容覆盖同一个 16MB 的文件。通过此修复，二进制日志现在可以正确恢复，并且与备份服务器上的大小相同。（缺陷号 20915642）

如果在备份期间从从服务器中清除中继日志文件（例如，由于日志文件轮换），从服务器的备份将失败。通过此修复，即使 mysqlbackup发现中继日志文件丢失，备份也会继续。（错误#20769891、错误#76312、错误#21655314、错误#19255925）

当该--password选项在 copy-back-and-apply-log命令中不带参数使用时， mysqlbackup不会提示用户输入密码，而是从默认文件中获取密码，或者在默认文件中未指定值时将其视为空字符串。（缺陷号 20657939）

当mysqlbackuptrace消息级别 大于 “ 0 ”时，如果mysqlbackup的操作命令 无效或丢失，则会打印堆栈跟踪和一些错误消息，这使得mysqlbackup看起来像崩溃了。通过此修复，现在在堆栈跟踪之前显示一条新消息，以更好地解释情况。（缺陷号 20281022）

如果已经使用该 apply-incremental-backup命令将增量备份应用于目录备份，并且最新备份随后恢复到数据目录，则可以使用该 copy-back-and-apply-log命令将相同的增量备份再次恢复到数据目录，可能导致数据不一致。--force通过此修复，只有在使用该选项时才能重新应用增量数据 。如果没有该 --force选项， copy-back-and-apply-log如果增量备份是目录备份，命令将跳过应用日志操作，如果是映像备份，则抛出错误。（漏洞 #18004179）