和选项现在可用于在恢复期间跳过将二进制日志--skip-binlog和 --skip-relaylog中继日志复制回服务器。这对于不希望这些日志出现在还原服务器的数据目录中的用户特别有用，因为这始终是 mysqlbackup将它们还原到的位置，而不管它们在备份服务器上的原始位置。（漏洞#19887998）

MySQL Enterprise Backup 在创建增量备份时不再写入 表中的incremental_base_lsn列 ，因为mysqlbackupmysql.backup_history不再使用该列 。请注意，在 MySQL Enterprise Backup 的未来版本中，该列最终将从表中删除。（漏洞 #19548604）

--force现在可以在完整备份的还原过程中使用 该选项来覆盖非空目标目录中的现有数据。有关详细信息，请参阅 --force选项的说明。（漏洞 #19266491）

二进制日志文件和中继日志文件（在从属服务器的情况下）现在在包含在压缩备份中时被压缩，并在还原期间解压缩。（漏洞 #19149210）

如果自上次完整备份以来数据库没有发生任何变化，增量备份完成后报告的开始和结束 LSN 可能会让用户感到困惑。有了这个修复，mysqlbackup在这种情况下简单地报告 “没有找到新的日志记录”。（漏洞 #18399069）

当从使用可传输表空间 (TTS) 创建的备份还原单个表时，MySQL Enterprise Backup 现在支持表重命名 。有关详细信息，请参阅 --rename选项的说明。

MySQL Enterprise Backup 现在支持使用 OpenStack 对象存储（ “ Swift ”）1.0 进行云备份和恢复。身份验证可以通过 Swift 自己的 TempAuth 身份验证系统或 OpenStack Identity Service (Keystone) 2.0 来处理。引入了许多新的命令选项来支持 OpenStack 对象存储；有关详细信息，请参阅 云存储选项。

Microsoft Windows：--backup-dir在 Windows 平台上，当符号链接包含在诸如或 类的选项的文件路径参数中时 --backup-image， mysqlbackup失败并出现错误。有了这个修复，只要参数不涉及悬挂符号链接，mysqlbackup 就可以在这种情况下工作，在这种情况下， mysqlbackup会抛出错误，而不是在任何符号链接位置下创建任何目录或文件。（漏洞 #19608231）

当基本备份不包括二进制日志或中继日志文件时，使用该 apply-incremental-backup命令使用后续增量备份更新基本备份将失败，除非增量备份是使用 --skip-binlog和 --skip-relaylog选项创建的。通过此修复，当基本备份不包含这些日志时，二进制日志和中继日志的复制会在增量备份期间自动跳过。（缺陷号 20594802）

执行 abackup-and-apply-log 然后执行 acopy-back-and-apply-log 导致重做日志文件在还原过程中被跳过，因此在还原的服务器上丢失。这是因为在这个非典型的操作序列中， 跳过了步骤apply-log中的步骤（通常复制重做日志的 步骤），因为该步骤已经执行了一个操作 。此修复可确保在这种情况下不会跳过重做日志文件的复制。（缺陷号 20583014）copy-back-and-apply-logapply-logbackup-and-apply-log

在乐观备份的第二阶段接近尾声时， mysqlbackup重新扫描已经在第一乐观备份阶段复制的表，并尝试再次复制自第一次复制以来修改过的任何表；这种通过重新复制覆盖已复制表的尝试导致了文件创建错误。通过此修复，任何此类表更改都将被正确忽略，因为更改已记录在重做日志中，稍后将由 apply-log操作处理。（缺陷号 20583014）

如果增量映像备份包含来自单个表的大量页面，则使用该copy-back-and-apply-log命令恢复增量备份可能会失败。（缺陷号 20492274）

如果二进制日志文件已包含在备份中，则使用extract命令和 选项 从映像备份中提取单个文件 会导致分段错误。--src-entry（缺陷号 20458681）

如果在操作过程中使用了选项（例如 、 和 ） ，copy-back-and-apply-log则映像备份操作失败 。有了这个修复，这些选项在操作期间被mysqlbackup忽略。（缺陷号 20451354）--backup-innodb_*--backup_innodb_data_home_dir--backup_innodb_log_group_home_dir--backup_innodb_undo_directory

在从服务器上执行 RESET SLAVE 语句后，从服务器的后续备份失败并出现错误，因为 mysqlbackup无法从服务器复制中继日志文件。这是因为mysqlbackup 在 slave 重置后无法检测到当前中继日志的位置，并且此修复确保 mysqlbackup知道如何执行此操作。（缺陷 #20180440，缺陷 #75074）

在还原脱机映像备份期间， master.info和 relay-log.info文件有时不会复制到目标服务器上的数据目录中。（漏洞#19973192）

参考资料：此问题是 Bug #19883801 的回归。

除非使用该选项，否则脱机备份失败 --skip-binlog，因为复制二进制日志的默认操作失败。通过此修复，二进制日志现在可以成功地包含在脱机备份中。（漏洞#19941735）

参考资料：此问题是 Bug #19883801 的回归。

使用 --no-locking选项创建全量备份时， mysqlbackup未能将二进制日志信息写入备份历史表和 backup_variables.txt文件。结果是，在基于全量备份创建增量备份时，尝试将二进制日志文件从服务器复制到增量备份中（从 3.11.0 开始，这是 MySQL Enterprise Backup 的默认行为）会失败，导致增量备份停止。通过此修复，完整备份后二进制日志信息不再丢失，因此增量备份不再失败。”（缺陷 #19915713）

如果服务器上的二进制日志文件在进行备份时被删除，则备份失败，因为 mysqlbackup找不到要复制到备份中的二进制日志文件。通过修复， mysqlbackup继续完成备份操作，即使一些二进制日志文件已被删除，除了增量备份的情况（备份仍然会失败）。

此外，通过此修复，在还原期间仅将二进制日志索引文件中列出的二进制日志文件复制回服务器，因此不会还原已清除的二进制日志文件，即使已备份。（漏洞 #19849326）

当mysqlbackup在备份期间遇到损坏的 .frm文件时，它抛出一个错误，试图继续备份，然后最终挂起。通过此修复，mysqlbackup仅给出一条警告消息 ( “ WARNING: An error occurred while adding manifest information for backup” )，然后照常继续备份。（漏洞 #19608231）

当尝试将非 TTS 备份恢复到正在运行的服务器时， mysqlbackup覆盖了服务器上的数据，没有给出任何警告。此修复程序使 mysqlbackup在发现目标数据目录为非空时终止非 TTS 完整备份的还原并出现错误，然后发出一条消息，指出 --force如果用户希望覆盖原始数据，则应使用该选项。

（漏洞 #19266491）

备份中包含的二进制日志和中继日志索引文件指向文件在备份服务器上的原始位置。这可能会阻止恢复的服务器正常启动。通过此修复，索引文件中的日志文件路径在备份期间得到正确更新，以指向文件在备份目录中的位置。（漏洞 #19255992）

第二阶段压缩后显示的压缩信息，乐观备份仅针对第二阶段备份。通过此修复，信息现在反映了为整个过程执行的总压缩，包括第一阶段和第二阶段。（漏洞 #19200562）

对云备份的list-image操作失败。这是因为该操作需要无缓冲传输数据，但mysqlbackup 默认以缓冲模式传输数据。此修复使mysqlbackup无需缓冲即可为操作下载数据——只要云代理支持 HTTP 范围听众，这是可能的。（漏洞#19162974）

在 Windows 平台上使用子命令恢复增量备份 copy-back-and-apply-log时，在命令行选项中使用长文件路径时操作失败。（漏洞#18448617）