文档首页
MySQL 8.4 参考手册
相关文档 下载此手册
PDF (US Ltr) - 39.9Mb
PDF (A4) - 40.0Mb
手册页 (TGZ) - 258.5Kb
手册页 (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


17.18.2 InnoDB 恢复

本节介绍 InnoDB 恢复。主题包括

时间点恢复

要将 InnoDB 数据库从物理备份创建的时间恢复到当前时间,您必须使用二进制日志启用 MySQL 服务器,即使在进行备份之前也是如此。为了在恢复备份后实现时间点恢复,您可以应用备份后发生的二进制日志中的更改。请参阅 第 9.5 节,“时间点(增量)恢复”.

从数据损坏或磁盘故障中恢复

如果您的数据库已损坏或出现磁盘故障,则必须使用备份执行恢复。在损坏的情况下,首先找到一个未损坏的备份。恢复基本备份后,使用 mysqlbinlogmysql 从二进制日志文件进行时间点恢复,以恢复备份后发生的更改。

在某些数据库损坏的情况下,仅转储、删除和重新创建一个或多个损坏的表就足够了。您可以使用 CHECK TABLE 语句检查表是否损坏,尽管 CHECK TABLE 自然无法检测到所有可能的损坏类型。

在某些情况下,明显的数据页损坏实际上是由于操作系统损坏了自己的文件缓存造成的,而磁盘上的数据可能完好无损。最好先尝试重新启动计算机。这样做可能会消除看起来像是数据页损坏的错误。如果 MySQL 仍然因为 InnoDB 一致性问题而无法启动,请参阅 第 17.20.3 节,“强制 InnoDB 恢复”,了解在恢复模式下启动实例的步骤,这允许您转储数据。

InnoDB 崩溃恢复

要从 MySQL 服务器意外退出中恢复,唯一的要求是重新启动 MySQL 服务器。 InnoDB 会自动检查日志并执行数据库的向前滚动以达到当前时间。 InnoDB 会自动回滚崩溃时存在的未提交事务。

InnoDB 崩溃恢复 包括几个步骤

  • 表空间发现

    表空间发现是 InnoDB 用于识别需要重做日志应用的表空间的过程。请参阅 崩溃恢复期间的表空间发现.

  • 重做日志 应用

    重做日志应用在初始化期间执行,在接受任何连接之前执行。如果在关闭或崩溃时所有更改都已从 缓冲池 刷新到 表空间 (ibdata**.ibd 文件),则跳过重做日志应用。如果启动时缺少重做日志文件,InnoDB 也会跳过重做日志应用。

    • 每次自动递增计数器值更改时,都会将当前最大自动递增计数器值写入重做日志,使其具有崩溃安全功能。在恢复期间,InnoDB 会扫描重做日志以收集计数器值更改,并将更改应用于内存中的表对象。

      有关 InnoDB 如何处理自动递增值的更多信息,请参阅 第 17.6.1.6 节,“InnoDB 中的 AUTO_INCREMENT 处理”InnoDB AUTO_INCREMENT 计数器初始化.

    • 当遇到索引树损坏时,InnoDB 会将损坏标志写入重做日志,这使得损坏标志成为崩溃安全的。 InnoDB 还会在每个检查点将内存中的损坏标志数据写入引擎私有的系统表。在恢复期间,InnoDB 会从这两个位置读取损坏标志,并在将内存中的表和索引对象标记为损坏之前合并结果。

    • 即使可以接受一些数据丢失,也不建议删除重做日志以加快恢复速度。只有在干净关闭后,将 innodb_fast_shutdown 设置为 01,才应考虑删除重做日志。

  • 回滚 未完成的 事务

    未完成的事务是指在意外退出或 快速关闭 时处于活动状态的任何事务。回滚未完成的事务所需的时间可能是事务在被中断之前处于活动状态时间的 3 或 4 倍,具体取决于服务器负载。

    您无法取消正在回滚的事务。在极端情况下,如果回滚事务预计会花费很长时间,那么启动 InnoDB 时将 innodb_force_recovery 设置为 3 或更大可能更快。请参阅 第 17.20.3 节,“强制 InnoDB 恢复”.

  • 变更缓冲区 合并

    将变更缓冲区(系统表空间的一部分)中的更改应用到二级索引的叶页面,因为索引页面被读取到缓冲池。

  • 清除

    删除对活动事务不再可见的已标记为删除的记录。

重做日志应用之后的步骤不依赖于重做日志(除了用于记录写入之外),并且与正常处理并行执行。其中,只有未完成事务的回滚对于崩溃恢复是特殊的。插入缓冲区合并和清除在正常处理期间执行。

重做日志应用之后,InnoDB 会尽早尝试接受连接,以减少停机时间。作为崩溃恢复的一部分,InnoDB 会回滚在服务器退出时未提交或处于 XA PREPARE 状态的事务。回滚由一个后台线程执行,该线程与来自新连接的事务并行执行。在回滚操作完成之前,新连接可能会遇到与已恢复的事务的锁冲突。

在大多数情况下,即使 MySQL 服务器在繁忙活动中意外终止,恢复过程也会自动发生,DBA 不需要进行任何操作。如果硬件故障或严重系统错误损坏 InnoDB 数据,MySQL 可能会拒绝启动。在这种情况下,请参阅 第 17.20.3 节,“强制 InnoDB 恢复”.

有关二进制日志和 InnoDB 崩溃恢复的信息,请参阅 第 7.4.4 节,“二进制日志”.

崩溃恢复期间的表空间发现

如果在恢复期间,InnoDB 遇到自上次检查点以来写入的重做日志,则必须将重做日志应用于受影响的表空间。在恢复期间识别受影响的表空间的过程被称为 表空间发现.

表空间发现依赖于 innodb_directories 设置,该设置定义了在启动时扫描以查找表空间文件的目录。 innodb_directories 的默认设置为 NULL,但由 innodb_data_home_dirinnodb_undo_directorydatadir 定义的目录始终附加到 innodb_directories 参数值,当 InnoDB 构建一个目录列表以在启动时扫描时。无论是否显式指定了 innodb_directories 设置,都会附加这些目录。使用绝对路径定义的或位于附加到 innodb_directories 设置的目录之外的表空间文件应添加到 innodb_directories 设置中。如果之前没有发现重做日志中引用的任何表空间文件,则恢复将终止。