MySQL Enterprise Backup 4.1 发行说明  /  MySQL Enterprise Backup 4.1.5 的变化 (2022-10-11)

MySQL Enterprise Backup 4.1.5 的变化 (2022-10-11)

添加或更改的功能

  • 重要更改: 对于copy-back-and-apply-log和除 之外 的其他单文件操作backup-to-image,当为 --backup-image选项指定相对路径时, mysqlbackup将路径作为相对于 运行mysqlbackup命令的当前工作目录的路径。(缺陷号 29128662)

  • --rename选项现在适用于完全和部分恢复:

    (缺陷号 31947026)

  • 当使用 、 或 的服务器keyring_filekeyring_encrypted_file备份 keyring_aws时,如果它不包含任何加密的 InnoDB 表,则密钥环文件不包含在备份中。例如,当mysqlbackup用于服务器升级时,这会产生问题,在这种情况下,密钥环文件不会在此过程中保留。当上述密钥环插件在服务器上处于活动状态时,mysqlbackup现在总是查找密钥环数据文件并复制它。(缺陷号 31820564)

  • 加密的 InnoDB 表现在可以包含在使用可 传输表空间 (TTS)的部分备份和恢复中。(缺陷号 31796017)

  • 该文件backup_gtid_executed.sql未包含在使用 GTID 的副本服务器的 TTS 备份中。只要 --slave-info使用该选项,该文件现在就会包含在 TTS 备份中。(缺陷号 30925447)

  • 如果在上次备份(增量备份所基于的)期间在服务器上禁用二进制日志记录,则增量备份失败,但随后在尝试增量备份之前启用了二进制日志记录。这是因为 mysqlbackup没有执行增量备份所需的二进制日志信息。通过此修复,当 mysqlbackup所基于的备份不包括二进制日志时,它会跳过复制二进制日志以进行增量备份。

    此外,当将不包含二进制日志的增量备份还原到服务器上时,mysqlbackup 会通过添加扩展名来重命名任何已经还原到服务器上的二进制日志文件.old--skip-binlog 当使用该选项恢复增量备份时,也会发生同样的事情。(缺陷号 30043100)

  • 当备份正在进行时清除二进制或中继日志文件时,备份现在会失败;当发现服务器上缺少二进制日志文件时,它也会失败 mysqlbackup(但是,如果中继日志文件丢失,备份将继续)。(缺陷号 29269039)

  • --incremental-base选项现在接受一个新值 , 这使得创建差异备份history:last_full_backup变得容易 。详见说明 。 --incremental-base

修正错误

  • 在 Windows 平台上,如果 --backup-dir没有为该extract命令指定选项, mysqlbackup 会意外退出。通过此修复,在这种情况下会抛出错误。(漏洞#34522095)

  • 在 Windows 平台上,当使用未使用插件的加密 InnoDB 表备份服务器时, 当mysqlbackup命令的or 选项 包含空格或尾部反斜杠keyring_encrypted_file时,操作失败。(缺陷号 33085629)--defaults-file--backup-dir

  • 当加密的 InnoDB 表在操作前被刷新然后删除backup-and-apply-log 时,操作可能会因Keyring service not initialized错误而失败。这是因为虽然加密表未包含在备份中,但备份中包含的重做日志片段可能包含对表的更改,并且应用日志操作无法应用更改,因为密钥环服务从未初始化过。通过此修复,mysqlbackup在这种情况下初始化密钥环服务。(缺陷号 32461308)

  • 如果备份涉及使用除 以外的任何密钥环插件加密的 InnoDB 表keyring_encrypted_file,但已禁用 SSL 以连接到服务器,则备份操作将以信号 6 终止。这是因为密钥环迁移过程需要 SSL,这是备份操作的一部分。通过此修复,在密钥环迁移开始之前,mysqlbackup 会检查服务器上是否已启用 SSL,如果未启用则抛出正确的错误。(缺陷号 32434668)

  • 压缩备份的还原或验证操作因unexpected end of file错误而失败。(缺陷号 32163271)

  • 在恢复使用完全锁定(即使用 )的 TTS 备份期间忽略了 --include-tables和 选项。(缺陷号 31947026)--exclude-tables--use-tts=with-full-locking

  • 对于具有完全锁定 ( ) 的 TTS 备份, 该--compress选项将被忽略,从而生成非压缩备份。(缺陷号 31913304)backup-and-apply-log operation--use-tts=with-full-locking

  • 当由于使用该 --compress-method选项而导致压缩备份的还原失败时, mysqlbackup不会打印有意义的错误消息。通过此修复,错误消息指示该选项与操作不兼容。(缺陷号 31861826)

  • 将排除的表存储在外部表空间中的部分备份操作失败,并抱怨 .ibd文件太大。这是因为对涉及的 .isl 文件处理不当,此补丁已纠正该问题。(缺陷号 31724848)

  • 如果备份服务器未.ibd用作 InnoDB 表空间的扩展,则压缩备份的还原失败。(缺陷号 31596356)

  • 在备份操作期间,如果mysqlbackup 查询服务器状态变量失败 Innodb_buffer_pool_dump_status,它会忽略错误然后挂起。(缺陷号 31445204)

  • 如果增量备份所基于的完整备份是使用该 --skip-relaylog选项创建的,但增量备份是在未使用该选项的情况下创建的,则增量备份的还原会失败。(缺陷号 31124611)

  • 当通过媒体管理软件 (MMS) 备份到磁带时,mysqlbackup0000-00-00 00:00:00始终为 备份服务器上的表中的操作条目设置默认值file_creation_time和 值。如果备份由于某些原因失败,这些零值将被写入表中。如果稍后 以NO_ZERO_DATENO_ZERO_IN_DATE SQL 模式查询该表 ,则服务器返回。有了这个修复,在备份失败的情况下,mysqlbackupfile_expiry_timebackup_sbt_historybackup_sbt_historyERROR 1194 (HY000): Table 'backup_sbt_history' is marked as crashed and should be repaired将备份期间的当前时间写入这些值,因此时间值永远不会为零。(缺陷号 30275637)

  • 在一次backup-and-apply-log操作中,即使在操作的备份阶段结束后,与服务器的连接仍保持打开状态。通过此修复,当操作进入应用日志阶段时连接将关闭,以释放资源。(缺陷号 30012743)

  • 当尝试恢复由更高版本的mysqlbackup创建的备份时,操作失败,mysqlbackup给出一条神秘消息。通过此修复,错误消息清楚地说明问题与版本不兼容有关。(缺陷号 29873900)

  • 恢复使用该选项创建的备份时 --incremental-with-redo-log-only ,恢复的服务器上缺少二进制日志,因此无法启动服务器。(漏洞#29861999)

  • 当涉及加密的 InnoDB 表并且使用了该 --skip-unused-pages选项时,备份失败。(漏洞#29861298)

  • 当使用命令创建压缩备份 backup-and-apply-log然后使用 copy-back-and-apply-log命令恢复时,恢复的服务器中缺少重做日志,导致服务器启动时出现 InnoDB 错误。(漏洞#29851603)

  • 当该--skip-binlog选项用于 TTS 备份的还原操作时,操作失败。通过此修复,该选项在这种情况下被忽略。(漏洞#29813666)

  • 当该--compress-method选项设置为none时,如预期的那样,备份在没有压缩的情况下完成,但 mysqlbackup.ibz打印了错误的压缩信息,并以扩展名保存了 InnoDB 表空间文件 。通过此修复,mysqlbackup所描述的行为不再发生在这种情况下。(漏洞#29806518)

  • --compress-level选项占用了一个值,而不是在没有选项的情况下使用该选项时 0的默认值 。通过此修复,选项的默认值始终有效(对于适用的压缩方法)。(漏洞#29806518)1--compress-method--compress

  • 当要备份的服务器有 时 super_read_only=ONmysqlbackup--no-history-logging发出警告,即使该选项已经与备份命令一起使用,也无法记录备份操作 。此补丁删除了不必要的警告。(漏洞 #29742011)

  • 如果使用该选项,则backup-and-apply-logTTS 备份操作失败 。--compress(漏洞#29639871)

  • 在部分备份期间,当两种类型的表空间都存在于服务器上时,mysqlbackup错误地 处理了一些存储在数据目录下的表,就好像它们存储在外部表空间中一样。(缺陷号 29590235)

  • 当备份服务器包含分区表且分区存储在不同目录中并且在进行增量备份之前重命名该表时,如果在表名称更改后没有更改任何分区,则增量备份的还原失败。这是因为 mysqlbackup在还原后没有 .isl为所有表分区重新创建所有文件,此修复程序纠正了该问题。(漏洞#29297920)

  • 当服务器为 64 位且mysqlbackup 为 32 位时(反之亦然),包含加密 InnoDB 表的服务器的备份失败。这是由于在这种情况下处理密钥环文件的方式,已通过此补丁修复。(漏洞 #29292085)

  • 在包含使用 MySQL 企业透明数据加密 (TDE) 加密的 InnoDB 表的 EL7 平台上创建的备份无法恢复到 Solaris 平台上的服务器。这是因为在这种情况下,备份的源平台和目标平台使用了不同的字节顺序格式,导致从备份中加载加密密钥很困难。此修复通过为不同的系统架构添加检测和转换实用程序来防止该问题。(缺陷号 28569367)

  • 使用backup-and-apply-log- 选项运行的操作-compress在错误的时间打印了错误的压缩信息。使用此补丁,压缩完成后会打印正确的信息。(缺陷号 28428760)

  • backup-dir-to-image如果备份服务器使用密钥环插件而不是keyring_encrypted_file用于 InnoDB 表加密,则使用目录备份命令 创建的备份映像的还原操作失败 。这是因为 backup-dir-to-image操作错误处理keyring_kef了备份中的文件,此补丁修复了该问题。(漏洞#27874581)

  • innodb_data_file_path在完全备份和增量备份之间 更改服务器上的系统变量 导致增量备份不可恢复, mysqlbackup在这种情况下成功完成了增量备份。通过此修复,在这种情况下会抛出错误,以避免创建不可恢复的增量备份。(漏洞#27580477)

  • 在增量备份期间,即使是未更改的表也会被 mysqlbackup复制到输出消息中。有了这个修复,消息说正在检查表格。(漏洞#27576904)

  • 备份操作后,条目 在文件中innodb_buffer_pool_filename出现了两次。backup-my.cnf(漏洞#27217884)

  • 对压缩目录备份的apply-log操作在备份目录中创建了额外的 .ibd文件。(缺陷号 26920318)