MySQL Enterprise Backup 4.1发行说明/ MySQL Enterprise Backup 4.1.3 (2019-02-15)

MySQL Enterprise Backup 4.1.3变更(2019-02-15)

添加或更改的功能

错误修复

  • MySQL Enterprise Backup 4.1备份之前已经用MySQL Enterprise Backup 4.0备份过的MySQL服务器失败。这是由于backup_history表被查询,现在已被修复。(错误# 29208386)

  • 使用组复制集群时,mysqlbackup方法时,可能会在备份操作快结束时意外退出backup_history表时,它尝试使用未加密的连接连接到备份用户以前未登录的某个节点。属性创建备份用户时发生caching_sha2_password插件插件,这样当它第一次连接到服务器时,必须使用加密连接登录;尝试登录失败,并且mysqlbackup无法处理失败。在这种情况下,mysqlbackup优雅地退出,并警告备份操作已完成,不更新备份历史记录。(错误# 28893180)

  • 使用命令恢复增量备份映像copy-back-and-apply-log命令失败mysqlbackup服务器存储库配置(包括,例如,的值innodb_data_file_path)对于目标服务器来说是未知的,除非显式地向其提供配置mysqlbackup.有了这个解决方案,mysqlbackup方法获取所需的信息backup-my.cnf已使用增量备份的基本备份还原的文件。(错误# 28411028)

  • 当用户错误地将源目录指定为恢复某些文件的目标目录(例如,指定了备份的目录)时,还原操作可能会破坏备份——backup_innodb_data_home_dir值与还原值相同——innodb_data_home_dir值)。此修复程序通过使用mysqlbackup当命令选项使恢复期间的任何文件复制的源文件路径和目标文件路径相同时,抛出错误。(错误# 28376873)

  • 在FreeBSD平台上,使用——取得进展期权没有做出mysqlbackup打印进度报告。(错误# 28350122)

  • 加密的InnoDB表恢复后,有时会导致恢复后的服务器无法启动,或者服务器启动后无法打开加密的InnoDB表。

    此补丁不仅解决了上述问题,还解决了另外两个问题:恢复包含行压缩的加密InnoDB表的备份失败,以及在备份操作中创建加密InnoDB表时无法完成备份。(错误# 28301281)

    参考:参见Bug #28360241, Bug #27168458。

  • 而MySQL服务器解释系统变量设置——innodb_checksum_algorithm = 0意味着——innodb_checksum_algorithm = crc32,一个mysqlbackup操作(备份除外)失败时——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 Server时,如果出现异常退出改变特权mysql.backup_history_new表没有被授予MySQL用户mysqlbackup连接到服务器。有了这个解决方案,mysqlbackup在抛出适当的错误后优雅地退出。

    此外,创建插入,下降上的特权mysql.backup_history_old而且创建插入下降,改变上的特权mysql.backup_history_new现在只需要第一次备份从5.7.22或更早版本升级的MySQL服务器,并且之前已经通过MySQL企业备份备份。(Bug #27879530, Bug #28546256)

  • ——表示进度=表选项被使用,mysqlbackup在操作接近结束时,在错误日志中对终止的服务器连接发出警告。这是因为与服务器的连接用于写入backup_progress桌子还空着。使用此修复程序,连接将在mysqlbackup操作结束。(错误# 27647283)

  • 当涉及到具有相对文件路径的单个表空间时,增量备份的恢复操作失败。(错误# 26442994)

  • 当期权——only-innodb-with-frm——无固定在备份操作期间使用,备份有时会失败mysqlbackup抱怨复制页面中的最高LSN比备份服务器上的大。这是因为mysqlbackup使用上述任一选项时,在复制重做日志之前未执行日志刷新。使用此修复程序,始终执行日志刷新以防止错误。(错误# 25412655)

  • 类提供的正则表达式匹配全文索引文件的文件名,因此部分备份有时会失败——包括表格选项,然后将这些文件作为普通表空间文件处理mysqlbackup.有了这个解决方案,mysqlbackup从备份中排除任何全文索引文件。(错误# 25044900)

  • 如果,当备份正在进行时mysqlbackup正在读取二进制日志(或中继日志)索引文件,并且服务器试图修改索引文件(例如,因为刚刚发生了日志刷新或日志清除),二进制日志记录(或中继日志记录)停止;在Windows平台上,服务器也会意外退出。这是因为mysqlbackup没有处理好文件共享违规。有了这个解决方案,mysqlbackup现在使用本地文件系统API读取索引文件,这将优雅地处理文件共享违规;同时,mysqlbackup现在将索引文件复制到它的缓冲区中,然后关闭它,而不是让它长时间打开,这样服务器就可以更容易地修改或删除索引文件。(Bug #22914974, Bug #26047119)