本节介绍InnoDB恢复。主题包括：
要将InnoDB数据库从进行物理备份时恢复到现在，您必须在启用二进制日志记录的情况下运行 MySQL 服务器，甚至在进行备份之前。要在还原备份后实现时间点恢复，您可以应用备份后发生的二进制日志中的更改。请参阅
第 7.5 节，“使用二进制日志进行时间点（增量）恢复”。
如果您的数据库损坏或发生磁盘故障，您必须使用备份执行恢复。在损坏的情况下，首先找到一个没有损坏的备份。恢复基本备份后，使用mysqlbinlog和 mysql从二进制日志文件进行时间点恢复，以恢复备份后发生的更改。
在某些数据库损坏的情况下，转储、删除和重新创建一个或几个损坏的表就足够了。您可以使用该
CHECK TABLE语句来检查表是否已损坏，但CHECK
TABLE自然无法检测到每一种可能的损坏。您可以使用表空间监视器来检查表空间文件中文件空间管理的完整性。
在某些情况下，明显的数据库页面损坏实际上是由于操作系统损坏了它自己的文件缓存，而磁盘上的数据可能是好的。最好先尝试重新启动计算机。这样做可能会消除看似数据库页面损坏的错误。InnoDB如果 MySQL 由于一致性问题
仍然无法启动，请参阅第 14.21.2 节，“强制 InnoDB 恢复”以了解以恢复模式启动实例的步骤，这允许您转储数据。
要从意外的 MySQL 服务器退出中恢复，唯一的要求是重新启动 MySQL 服务器。
InnoDB自动检查日志并将数据库前滚到现在。
InnoDB自动回滚崩溃时存在的未提交事务。在恢复期间，mysqld显示类似于以下的输出：
InnoDB: Log scan progressed past the checkpoint lsn 430875675
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 436118528
InnoDB: Doing recovery: scanned up to log sequence number 441361408
InnoDB: Doing recovery: scanned up to log sequence number 446604288
InnoDB: Doing recovery: scanned up to log sequence number 451847168
InnoDB: Doing recovery: scanned up to log sequence number 457090048
InnoDB: Doing recovery: scanned up to log sequence number 462332928
InnoDB: Doing recovery: scanned up to log sequence number 467575808
InnoDB: Doing recovery: scanned up to log sequence number 472818688
InnoDB: Doing recovery: scanned up to log sequence number 478061568
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 483304448
InnoDB: Doing recovery: scanned up to log sequence number 488547328
InnoDB: Doing recovery: scanned up to log sequence number 493790208
InnoDB: Doing recovery: scanned up to log sequence number 496426509
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1441473 row operations to undo
InnoDB: Trx id counter is 2304
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
...
InnoDB: Waiting for purge to start
Starting in background the rollback of uncommitted transactions
InnoDB: Rolling back trx with id 2022, 1441473 rows to undo
...
InnoDB: 5.6.36 started; log sequence number 496426509
...
./mysqld: ready for connections.InnoDB
崩溃恢复过程
包括
几个步骤：
重做日志应用
重做日志应用程序是第一步，在接受任何连接之前的初始化期间执行。 如果在关闭或崩溃时所有更改都从 缓冲池刷新到 表空间 （
ibdata*和文件），则跳过重做日志应用程序。如果重做日志文件在启动时丢失，也会跳过重做日志应用程序。*.ibdInnoDB不建议删除重做日志来加速恢复，即使一些数据丢失是可以接受的。删除重做日志只应在干净关闭后考虑，
innodb_fast_shutdown设置为0或1。未完成的事务是在意外退出或快速关闭 时处于活动状态的任何事务 。回滚未完成事务所需的时间可能是事务中断前活动时间的三到四倍，具体取决于服务器负载。
您不能取消正在回滚的事务。在极端情况下，当回滚事务预计需要特别长的时间时，从或更大
InnoDB的innodb_force_recovery设置开始可能会更快。3请参阅 第 14.21.2 节，“强制 InnoDB 恢复”。更改缓冲区 合并
将更改缓冲区（ 系统表空间的一部分）中的更改应用到二级索引的叶页，因为索引页被读取到缓冲池。
删除对活动事务不再可见的已删除标记的记录。
重做日志应用程序之后的步骤不依赖于重做日志（记录写入除外）并且与正常处理并行执行。其中，只有未完成事务的回滚是崩溃恢复所特有的。插入缓冲区合并和清除在正常处理期间执行。
重做日志应用后，InnoDB尝试尽早接受连接，以减少停机时间。作为崩溃恢复的一部分，InnoDB回滚XA
PREPARE服务器退出时未提交或处于状态的事务。回滚由后台线程执行，与来自新连接的事务并行执行。在回滚操作完成之前，新连接可能会遇到与已恢复事务的锁定冲突。
在大多数情况下，即使 MySQL 服务器在繁重的活动中意外终止，恢复过程也会自动发生，无需 DBA 采取任何措施。如果硬件故障或严重的系统错误损坏了
InnoDB数据，MySQL 可能会拒绝启动。在这种情况下，请参阅第 14.21.2 节，“强制 InnoDB 恢复”。
有关二进制日志和
InnoDB崩溃恢复的信息，请参阅
第 5.4.4 节，“二进制日志”。