的--skip-binlog.和——skip-relaylog现在可以使用选项跳过在恢复期间将二进制日志和中继日志复制回服务器的操作。对于不希望这些日志出现在恢复的服务器的数据目录中的用户来说，这特别有用，因为恢复的服务器的数据目录总是指向该目录的位置mysqlbackup.无论备份服务器上的原始位置如何，都会恢复它们。（bug＃19887998）

MySQL Enterprise备份不再写入increntmental_base_lsn.列在mysql.backup_history.表创建增量备份时，由于该列不再被mysqlbackup.。注意，在MySQL Enterprise Backup的未来版本中，该列最终将从表中删除。(错误# 19548604)

的——力选项现在可以在恢复全备份期间使用，以覆盖非空目标目录中的现有数据。的描述——力选择细节。(错误# 19266491)

二进制日志文件和中继日志文件(在从服务器的情况下)在被包含在压缩备份中并在恢复期间解压缩时，将被压缩。(错误# 19149210)

如果自上次完全备份以来数据库没有更改，则在增量备份完成后的启动和结束LSN可能会对用户困惑。修复,mysqlbackup.只是报告说”找不到新的日志记录”在情况。（bug＃18399069）

MySQL Enterprise Backup现在支持从使用的备份恢复单个表时重命名移动式表空间(TTS)。的描述- 改名选择细节。

MySQL Enterprise Backup现在支持云备份和使用OpenStack对象存储还原（”迅速”）1.0。可以通过SWIFT自己的Tempauth身份验证系统或OpenStack Identity Service（Keystone）2.0来处理身份验证。已经引入了许多新命令选项以支持OpenStack对象存储;看云存储选项，有关详细信息。

微软的Windows操作系统:在Windows平台上，当符号链接涉及到文件路径参数时，如此选项- 留下武器或者- 留下镜像,mysqlbackup.失败，出现错误。修复,mysqlbackup.只要参数不涉及悬垂符号链接，就在这种情况下工作mysqlbackup.抛出错误，而不是在任何符号链接位置下创建任何目录或文件。(错误# 19608231)

当基本备份不包括二进制日志或中继日志文件时，使用应用 - 增量备份命令将失败，除非使用增量备份是创建的--skip-binlog.和——skip-relaylog选项。使用此修复程序，当二进制日志和中继日志的基本备份不包括这些日志时，将在增量备份期间自动跳过这些日志的复制。(错误# 20594802)

执行A.backup-and-apply-log然后一个复制后退和应用日志导致重做日志文件在还原过程中跳过，因此缺少还原的服务器。这是因为在这种非典型的操作序列中，运用原木方法中复制重做日志的步骤复制后退和应用日志跳过一步，作为一个运用原木操作已经被backup-and-apply-log步。此修复确保在这种情况下不跳过重做日志文件的复制。(错误# 20583014)

在乐观备份的第二阶段接近尾声时，mysqlbackup.重新扫描在备份的第一乐观阶段中已经复制的表，并尝试再次复制自第一次复制以来被修改的任何表;通过复制覆盖已复制的表的尝试导致了文件创建错误。有了这个修复，任何这样的表更改都会被正确地忽略，因为这些更改已经被记录在重做日志中，稍后将由运用原木操作。(错误# 20583014)

如果增量图像备份从单个表中包含大量页面，则使用该备份的增量备份还原复制后退和应用日志命令可能会失败。（bug＃20492274）

使用图像备份从图像备份中提取单个文件提取命令和——src-entry如果已将二进制日志文件包含在备份中，则会导致分段错误。（bug＃20458681）

一个复制后退和应用日志如果图像备份，则操作失败- Backup-INNODB_ *选项（例如，——backup_innodb_data_home_dir,——backup_innodb_log_group_home_dir， 和——backup_innodb_undo_directory)在手术中使用。使用此修复后，这些选项将被mysqlbackup.在操作期间。（bug＃20451354）

在从服务器上执行RESET SLAVE语句后，对从服务器的后续备份失败并出现错误，如mysqlbackup.无法从服务器复制中继日志文件。这是因为mysqlbackup.在从站重置后无法检测到当前中继日志的位置，这个修复可以确保mysqlbackup.知道如何做到这一点。（bug＃20180440，bug＃75074）

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

参考：这个问题是一个回归：bug＃19883801。

脱机备份失败，除非--skip-binlog.选项，因为复制二进制日志的默认动作失败。通过这个修复，二进制日志现在可以成功地包含在脱机备份中。(错误# 19941735)

参考：这个问题是一个回归：bug＃19883801。

创建完整备份时——无固定选项，mysqlbackup.日志含义二进制日志信息写入备份历史表失败backup_variables.txt.txt.文件。结果是，当创建一个基于完全备份的增量备份时，尝试将二进制日志文件从服务器复制到增量备份(这是MySQL企业备份自3.11.0以来的默认行为)将失败，导致增量备份停止。有了这个补丁，二进制日志信息在完全备份之后就不再丢失，因此增量备份就不再失败。”(错误# 19915713)

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

此外，在此修复程序中，只有在还原期间只复制了二进制日志索引文件中列出的二进制日志文件，以便未恢复已清除的二进制日志文件，甚至备份。（bug＃19849326）

什么时候mysqlbackup.遇到了腐败.frm备份期间的文件，它会抛出一个错误，试图继续备份，然后最终挂起。修复,mysqlbackup.只给出一个警告信息(”警告:在为备份添加清单信息时发生错误”)，然后像往常一样继续备份。(错误# 19608231)

尝试将非TTS备份还原到正在运行的服务器时，mysqlbackup.在不提供任何警告的情况下覆盖服务器上的数据。这种修复mysqlbackup.每当它找到目标数据目录是非空的时，终止一个非TTS完全备份的备份，然后发出消息——力如果用户希望覆盖原始数据，则应使用选项。

(错误# 19266491)

备份中包含的二进制日志和中继日志索引文件指向文件在备份服务器上的原始位置。这可能会阻止恢复的服务器正常启动。有了这个修复，索引文件中的日志文件路径将在备份期间被适当地更新，以指向备份目录中的文件位置。(错误# 19255992)

在压缩的第二阶段之后显示的压缩信息仅适用于备份的第二阶段。利用此修复，现在信息现在反映了对整个过程执行的总压缩，包括第一和第二阶段。（bug＃19200562）

的列表映像云备份的操作失败。这是因为操作需要在不缓冲的情况下传输数据，但是mysqlbackup.默认情况下正在以缓冲模式传输数据。这种修复mysqlbackup.只要Cloud Proxy支持HTTP系列听众，就可以下载无缓冲的操作的数据。（bug＃19162974）

使用恢复增量备份时使用复制后退和应用日志子命令，当在命令行选项中使用长文件路径时，操作失败。(错误# 18448617)