MYSQL存储引擎InnoDB（八十二）：InnoDB恢复

时间点恢复

要将数据库从进行物理备份时恢复到现在，您必须在启用二进制日志记录的情况下运行MySQL服务器，甚至在进行备份之前也是如此。若要在还原备份后实现时间点恢复，可以应用进行备份后发生的二进制日志中的更改。

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

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

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

在某些情况下，明显的数据库页损坏实际上是由于操作系统损坏了自己的文件缓存，并且磁盘上的数据可能没问题。最好先尝试重新启动计算机。这样做可以消除看似数据库页损坏的错误。

InnoDB崩溃恢复

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

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

1、表空间发现

表空间发现是InnoDB用于标识需要重做日志应用程序的表空间的过程。

2、重做日志应用程序

重做日志应用程序是在初始化期间接受任何连接之前执行的。如果在关闭或崩溃时所有更改都从缓冲池刷新到表空间，那么将跳过重做日志应用程序。 如果在启动时缺少重做日志文件，会跳过重做日志应用程序。

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

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

不建议删除重做日志以加快恢复速度，即使某些数据丢失是可以接受的。只有在干净关机后，才应考虑删除重做日志。

3、回滚未完成的事务

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

您无法取消正在回滚的事务。

4、更改缓冲区合并

将更改缓冲区（系统表空间的一部分）中的更改应用于二级索引的叶页，因为索引页被读入缓冲池。

5、清除

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

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

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

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