MySQL 企业备份用户指南（版本 8.0.31）  / 第四部分附录  /  附录 B MySQL 企业备份的限制

附录 B MySQL 企业备份的限制

请参阅 附录 D 中的 MySQL Enterprise Backup 版本历史，MySQL Enterprise Backup 发行说明以获取已修复的 mysqlbackup错误列表。以下是 MySQL Enterprise Backup 的限制列表：

  • MySQL 5.6 及更高版本中的组提交功能更改了InnoDB 重做日志的刷新操作频率，这可能会影响与表中备份数据关联的时间点InnoDB。有关详细信息，请参阅 第 C.5 节，“特定 MySQL 版本的兼容性说明”。

  • 在某些情况下，非事务性表（例如 MyISAM表）的备份可能包含其他未提交的数据。如果 关闭自动提交InnoDB，并且在同一个事务中同时修改了表和非事务表，则可以在更新二进制日志位置之前将数据写入非事务表。提交事务时更新二进制日志位置，但立即写入非事务数据。如果在此类事务打开时进行备份，则备份数据包含对非事务表所做的更新。

  • 如果mysqlbackupkill -9进程被 Unix命令等 中断，FLUSH TABLES WITH READ LOCK操作可能会继续运行。在这种情况下，使用KILL QUERY来自mysql 命令行的语句来终止该FLUSH TABLES WITH READ LOCK语句。FLUSH TABLES如果操作因长时间运行的查询或事务而停止，则更有可能发生此问题。有关备份时间和性能的指南，请参阅 第 7.1 节“优化备份性能”。

  • 不要在备份操作进行时运行DDL 操作（例如， ALTER TABLE、TRUNCATE TABLE、 OPTIMIZE TABLE、或 ）。生成的备份可能会损坏。 REPAIR TABLERESTORE TABLECREATE INDEX

  • 表中的engines列 mysql.backup_history未正确反映备份数据库的存储引擎。

  • 由于在备份运行时在服务器上生成巨大的重做日志文件，具有大量写入工作负载（例如，每分钟千兆字节的数量级）的大型数据库的热备份可能需要很长时间才能完成。但是，当频繁修改的是数据库中相对较小的表子集时，可以使用乐观备份功能来提高性能并减少备份大小以及备份和恢复时间。有关详细信息，请参阅 第 4.3.6 节，“进行乐观备份”。

  • 由于 InnoDB 存储引擎的已知问题（请参阅 MySQL Bug System 上的 Bug#72851），无法使用 MySQL Enterprise Backup 3.9.0 或更高版本还原来自 MySQL 服务器 5.6.10 及更早版本的压缩 InnoDB 表。

  • 虽然可以使用 MySQL Enterprise Backup 备份到网络附加存储 (NAS) 设备或从中恢复，但由于可能出现的网络问题，备份的一致性以及备份或恢复操作的性能可能会受到影响。

  • 当使用可传输表空间 (TTS) 为包含 Antelope 和 Barracuda 文件格式混合的表的服务器创建备份时，不要对表应用完全锁定（即，不要指定 --use-tts=with-full-locking）。相反，只需指定--use-tts或 --use-tts=with-minimum-locking，这两者都会对表应用最小锁定（错误号 20583946）。

  • 在MySQL服务器上以 ANSI_QUOTESSQL模式创建的表不能使用TTS备份。

  • 当服务器数据目录的子目录下存在无法识别的文件类型的文件时，除非 使用该选项，否则将由mysqlbackup备份。--only-known-file-types但是，如果文件名没有扩展名，则会导致mysqlbackup在尝试将备份恢复到服务器时抛出错误。

  • 如果在 mysqlbackup备份该表时服务器上的表被删除， mysqlbackup会抛出错误并退出。

  • 使用 MySQL Enterprise Backup 3.12.2 的离线备份有时会失败，mysqlbackup偶尔会崩溃。

  • macOS 和 Windows 平台以及 Linux 平台上不支持 MySQL Enterprise Backup 的云操作，当通用 Linux 构建用于服务器和 MySQL Enterprise Backup 时（即，当服务器和 MySQL Enterprise Backup 都使用通用安装时） Linux 压缩包）。

  • 将--src-entry选项与extract云备份命令一起使用将导致命令失败。云备份只能完整提取。

  • 由于一些问题，MySQL Enterprise Backup 3.12 目前不支持使用 Amazon S3 进行云备份和恢复。

  • 当通用表空间与数据库的系统表空间具有相同的基本名称（通常是ibdata1）并且存在于与其相同的目录（通常是服务器的数据目录）中时，压缩目录备份将失败。在相同情况下创建的压缩单文件备份将损坏，并且无法恢复。为避免此问题，服务器管理员不应将系统表空间和具有相同基本名称的通用表空间放在同一目录中；如果这是不可避免的，请不要对数据库执行压缩备份。

  • 当使用其源服务器也属于单独的组复制设置的复制设置时，随着时间的推移，从源服务器或副本创建一致的备份，但不是同时从两者创建备份。否则，源和副本生成的值会发生冲突 id，导致备份失败。