Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

17.18.2 InnoDB 恢复

本节描述 InnoDB 恢复。主题包括:

点-in-Time 恢复

要将 InnoDB 数据库恢复到备份时的状态,您必须在备份之前启用二进制日志记录。然后,您可以应用二进制日志中的更改,以恢复到备份时的状态。见 第 9.5 节,“点-in-Time(增量)恢复”

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

如果您的数据库变得损坏或磁盘故障,您必须使用备份来恢复。在损坏的情况下,首先找到未损坏的备份。然后,使用 mysqlbinlogmysql 从二进制日志文件中恢复更改,以恢复到备份时的状态。

在某些数据库损坏的情况下,只需转储、删除和重新创建一个或多个损坏的表格。您可以使用 CHECK TABLE 语句来检查表格是否损坏,虽然 CHECK TABLE 无法检测所有可能的损坏类型。

在某些情况下,表面上的数据库页面损坏实际上是操作系统损坏了自己的文件缓存,而磁盘上的数据可能是正确的。最好首先尝试重新启动计算机。这可能会消除似乎是数据库页面损坏的错误。如果 MySQL 仍然由于 InnoDB 一致性问题而无法启动,请参阅 第 17.20.3 节,“强制 InnoDB 恢复”,了解如何在恢复模式下启动实例,以便转储数据。

InnoDB 崩溃恢复

要从意外的 MySQL 服务器退出恢复,只需重新启动 MySQL 服务器。InnoDB 将自动检查日志并将数据库恢复到当前状态。InnoDB 还将自动回滚崩溃时未提交的事务。

InnoDB 崩溃恢复 由多个步骤组成:

  • 表空间发现

    表空间发现是 InnoDB 用于识别需要 redo 日志应用的表空间的过程。见 崩溃恢复期间的表空间发现

  • redo 日志 应用

    redo 日志应用是在初始化期间执行的,之前不接受任何连接。如果所有更改都从缓冲池刷新到表空间(ibdata**.ibd 文件)中时,redo 日志应用将被跳过。InnoDB 还将跳过 redo 日志应用,如果 redo 日志文件在启动时丢失。

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

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

    • 当遇到索引树腐败时,InnoDB 将腐败标志写入重做日志,这使得腐败标志崩溃安全。InnoDB 也将内存腐败标志数据写入引擎专用系统表中,每个检查点。在恢复期间,InnoDB 从两个位置读取腐败标志并合并结果,然后标记内存表和索引对象为腐败。

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

  • 回滚 不完整的 事务

    不完整的事务是指在意外退出或 快速关闭 时活动的事务。回滚不完整事务所需的时间可能是事务活动前被中断的三到四倍,取决于服务器负载。

    您不能取消正在回滚的事务。在极端情况下,当回滚事务预计需要很长时间时,可以使用 InnoDBinnodb_force_recovery 设置为 3 或更高。请参阅 第 17.20.3 节,“强制 InnoDB 恢复”

  • 更改缓冲区 合并

    将更改从更改缓冲区(系统表空间的一部分)应用于辅助索引的叶页,随着索引页被读取到缓冲池中。

  • 清除

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

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

在 redo 日志应用程序后,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设置中。如果redo日志中引用的任何表空间文件在之前没有被发现,恢复将被终止。