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

附录 B MySQL 企业备份的限制

请参阅 MySQL Enterprise Backup 8.0 Release Notes以获取mysqlbackup的已修复错误列表。以下是 MySQL Enterprise Backup 的限制列表:

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

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

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

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

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

  • 当在共享表空间中创建任何(或所有)分区时, 使用可传输表空间 (TTS) 备份分区表 将失败。

  • 如果任何分区是在备份服务器的数据目录之外创建的,则 恢复使用可传输表空间 (TTS) 备份的分区表 将失败。

  • 如果使用可传输表空间 (TTS) 备份包含全文搜索 (FTS) 索引的 表,则在恢复后,FTS 索引将损坏。用户将需要使用以下命令重新创建索引:

    mysql> ALTER TABLE mytable ENGINE = INNODB;

    然后,检查表是否不再有错误:

    mysql> CHECK TABLE mytable;

  • 在 MySQL 服务器上以 SQL 方式创建的表 不能使用可传输表空间 (TTS)ANSI_QUOTES进行备份 。

  • MySQL Enterprise Backup 不.pem将服务器中的文件包括到备份中。当启用 SSL 连接时,这些文件是服务器实例的一部分。

  • 在备份过程中,如果在备份过程中发出CREATE INDEX with语句ALGORITHM = INPLACE,由于该语句不会进入MySQL服务器的redo log(详见 Sorted Index Builds),所以不能记录在备份中,恢复备份时, mysqlbackup不会重新创建索引 。

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

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

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

  • 当mysqlbackup使用加密的 InnoDB 表 时,一些限制适用。有关详细信息,请参阅 此处的讨论

  • 如果服务器已启动,备份操作将失败 --innodb_undo_log_encrypt=ON

  • 如果重做日志页的校验和 在服务器上 被禁用(即,如果 --innodb_log_checksumsOFF或),备份操作可能会失败。 FALSE0

  • 对于 MySQL Enterprise Backup 8.0.19 及更高版本:在服务器上与备份并行发生 DDL 操作( CREATE TABLE RENAME TABLE DROP TABLE ALTER TABLE和映射到ALTER TABLE的操作,如 CREATE INDEX )是安全的操作只要:

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

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

  • 如果任何数据库的名称与任何撤消表空间的名称相同,则备份将失败。为使备份成功,数据库管理员应避免为任何数据库和撤消表空间赋予相同的名称(例如,使用默认的撤消表空间名称undo_001来命名数据库),或者应在备份前重命名数据库。