InnoDB恢复

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

• 时间点恢复
• 从数据损坏或磁盘故障中恢复
• InnoDB崩溃恢复
• 故障恢复期间的表空间发现

时间点恢复

为了InnoDB从进行物理备份时开始将数据库恢复到现在，即使在进行备份之前，也必须运行启用了二进制日志记录的MySQL服务器。要在还原备份后实现时间点恢复，您可以应用备份完成后二进制日志中的更改。请参见“使用二进制日志进行时间点（增量）恢复”。

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

如果数据库损坏或发生磁盘故障，则必须使用备份执行恢复。如果发生损坏，请首先找到未损坏的备份。还原基本备份后，使用mysqlbinlog和mysql从二进制日志文件中进行时间点恢复，以还原进行备份后发生的更改。

在某些数据库损坏的情况下，足以转储，删除和重新创建一个或几个损坏的表。您可以使用该CHECK TABLE语句检查表是否损坏，尽管CHECK TABLE自然无法检测到每种可能的损坏。

在某些情况下，明显的数据库页面损坏实际上是由于操作系统损坏了其自己的文件缓存而造成的，磁盘上的数据可能还可以。最好先尝试重新启动计算机。这样做可以消除似乎是数据库页面损坏的错误。如果MySQL由于InnoDB一致性问题而无法启动，请，以在恢复模式下启动实例的步骤，该模式允许您转储数据。

InnoDB崩溃恢复

要从MySQL服务器崩溃中恢复，唯一的要求是重新启动MySQL服务器。InnoDB自动检查日志并执行数据库前滚到现在的操作。InnoDB自动回滚崩溃时存在的未提交的事务。在恢复期间，mysqld显示类似于以下的输出：

InnoDB: The log sequence number 664050266 in the system tablespace does not match 
the log sequence number 685111586 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Using 'tablespaces.open.2' max LSN: 664075228
InnoDB: Doing recovery: scanned up to log sequence number 690354176
InnoDB: Doing recovery: scanned up to log sequence number 695597056
InnoDB: Doing recovery: scanned up to log sequence number 700839936
InnoDB: Doing recovery: scanned up to log sequence number 706082816
InnoDB: Doing recovery: scanned up to log sequence number 711325696
InnoDB: Doing recovery: scanned up to log sequence number 713458156
InnoDB: Applying a batch of 1467 redo log records ...
InnoDB: 10%
InnoDB: 20%
InnoDB: 30%
InnoDB: 40%
InnoDB: 50%
InnoDB: 60%
InnoDB: 70%
InnoDB: 80%
InnoDB: 90%
InnoDB: 100%
InnoDB: Apply batch completed!
InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 561887 row 
operations to undo
InnoDB: Trx id counter is 4096
...
InnoDB: 8.0.1 started; log sequence number 713458156
InnoDB: Waiting for purge to start
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Rolling back trx with id 3596, 561887 rows to undo
...
./mysqld: ready for connections....

InnoDB崩溃恢复包括几个步骤：

• 表空间发现

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

• 重做日志应用

  重做日志应用程序是在初始化期间执行的，然后接受任何连接。如果在关闭或崩溃时将所有更改从缓冲池刷新到表空间（ibdata*和*.ibd文件），则将跳过重做日志应用程序。InnoDB如果启动时缺少重做日志文件，还将跳过重做日志应用程序。

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

    有关如何InnoDB处理自动递增值的更多信息，请参见“ InnoDB中的AUTO_INCREMENT处理”和 InnoDB AUTO_INCREMENT计数器初始化。

  • 遇到索引树损坏时，InnoDB将损坏标志写入重做日志，这会使损坏标志崩溃安全。InnoDB还将内存损坏标志数据写入每个检查点上的引擎专用系统表。在恢复期间，InnoDB在将内存表和索引对象标记为已损坏之前，从两个位置读取损坏标志并合并结果。
  • 不建议删除重做日志以加快恢复速度，即使有些数据丢失是可以接受的。仅应在将innodb_fast_shutdown设置为0或干净关闭后，再考虑删除重做日志1。

• 回滚未完成的交易

  不完整的事务是在崩溃或快速关闭时处于活动状态的任何事务。回滚不完整的事务所花费的时间可能是事务在被中断之前处于活动状态的时间的三到四倍，具体取决于服务器负载。

  您无法取消正在回滚的事务。在极端情况下，当预计回滚事务将花费非常长的时间时，从或更大InnoDB的innodb_force_recovery设置开始可能会更快3。

• 更改缓冲区合并

  将更改从更改缓冲区（系统表空间的一部分）应用于辅助索引的叶页，因为将索引页读取到缓冲池中。

• 清除

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

重做日志应用程序之后的步骤不依赖于重做日志（除了记录写操作以外），并且与常规处理并行执行。其中，只有回滚不完整的事务才是崩溃恢复所特有的。插入缓冲区合并和清除在正常处理期间执行。

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

在大多数情况下，即使在繁忙的活动中MySQL服务器被意外杀死，恢复过程也会自动发生，并且不需要DBA采取任何措施。如果硬件故障或严重的系统错误损坏了InnoDB数据，MySQL可能会拒绝启动。在这种情况下，

有关二进制日志和InnoDB崩溃恢复的信息，请参见“MySQL服务器二进制日志”。

故障恢复期间的表空间发现

如果在恢复过程中InnoDB遇到自上一个检查点以来写入的重做日志，则必须将重做日志应用于受影响的表空间。在恢复过程中标识受影响的表空间的过程称为表空间发现。

表空间发现依赖于该innodb_directories设置，该设置定义了在启动时要扫描的目录空间文件。由innodb_data_home_dir，，innodb_undo_directory和定义的目录datadir将自动附加到innodb_directories参数值，而不管是否innodb_directories显式配置了该选项。使用绝对路径定义的表空间文件或位于自动附加到该innodb_directories设置的目录之外的表空间文件应添加到该innodb_directories设置。如果以前未发现重做日志中引用的任何表空间文件，则恢复将终止。