MySQL 5.7版本说明
本节描述InnoDB复苏。主题包括:
要恢复InnoDB数据库到现在的物理备份，你必须运行MySQL服务器启用二进制日志记录，甚至在进行备份之前。要在恢复备份之后实现时间点恢复，可以应用备份之后发生的二进制日志中的更改。看到第7.5节，“时间点(增量)恢复”．
如果数据库损坏或发生磁盘故障，则必须使用备份执行恢复。在损坏的情况下，首先找到未损坏的备份。恢复基本备份之后，使用mysqlbinlog而且mysql以恢复备份之后发生的更改。
在数据库损坏的某些情况下，转储、删除和重新创建一个或几个损坏的表就足够了。您可以使用检查表语句来检查表是否已损坏检查表自然不能检测到每一种可能的腐败。
在某些情况下，明显的数据库页面损坏实际上是由于操作系统损坏了自己的文件缓存，而磁盘上的数据可能没有问题。最好先试着重启电脑。这样做可以消除似乎是数据库页面损坏造成的错误。如果MySQL仍然有启动困难，因为InnoDB一致性问题，请参见章节14.22.2，强制恢复InnoDB有关以恢复模式启动实例的步骤，该模式允许转储数据。
要从意外的MySQL服务器退出中恢复，唯一的要求是重新启动MySQL服务器。InnoDB自动检查日志并执行数据库前滚到当前。InnoDB自动回滚崩溃时存在的未提交的事务。在恢复期间,mysqld显示类似这样的输出:
InnoDB:日志扫描进展到检查点lsn 369163704 InnoDB:正在恢复:扫描到日志序列号374340608 InnoDB:正在恢复:扫描到日志序列号379583488 InnoDB:正在恢复:扫描到日志序列号384826368 InnoDB:正在恢复:扫描到日志序列号390069248 InnoDB:正在恢复:扫描到日志序列号395312128 InnoDB:正在恢复:扫描到日志序列号400555008 InnoDB:正在恢复:扫描到日志序列号405797888 InnoDB:正在恢复:扫描到日志序列号411040768 InnoDB:正在恢复:扫描到日志序列号414724794 InnoDB:数据库未正常关闭!InnoDB:启动崩溃恢复。InnoDB: 1个事务(s)必须回滚或清理总共518425行操作来撤销InnoDB: Trx id计数器是1792 InnoDB:开始应用一批日志记录到数据库…InnoDB:百分比的进展: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:运用批处理完成……InnoDB: rollback trx with id 1511,518425 rows to undo…InnoDB: 5.7.18 started;日志序列号414724794 ... ./mysqld: ready for connections。InnoDB崩溃恢复包括以下几个步骤:
表空间的发现
表空间发现过程
InnoDB用于识别需要重做日志应用程序的表空间。看到崩溃恢复期间的表空间发现．重做日志应用程序
重做日志应用程序在初始化期间执行，在接受任何连接之前。中的所有更改都被刷新缓冲池到表空间（
ibdata *而且* .ibd在关闭或崩溃时，重做日志应用程序被跳过。InnoDB如果重做日志文件在启动时丢失，也会跳过重做日志应用程序。不建议删除重做日志以加速恢复，即使一些数据丢失是可以接受的。删除重做日志应该只考虑在完全关机后，使用
innodb_fast_shutdown设置为0或1．关于这个过程的信息
InnoDB用于识别需要重做日志应用程序的表空间，请参见崩溃恢复期间的表空间发现．未完成事务是在意外退出或退出时处于活动状态的任何事务快速关闭．回滚未完成的事务所花费的时间可能是事务在被中断之前活动时间的三到四倍，具体取决于服务器负载。
不能取消正在回滚的事务。在极端情况下，当回滚事务预计将花费非常长的时间时，开始回滚可能会更快
InnoDB与一个innodb_force_recovery设置3.或更高版本。看到章节14.22.2，强制恢复InnoDB．改变缓冲合并
从更改缓冲区应用更改(控件的部分系统表空间)到二级索引的叶页，因为索引页被读入缓冲池。
删除活动事务不再可见的已删除标记的记录。
重做日志应用程序后面的步骤不依赖于重做日志(除了记录写入操作)，并且与正常处理并行执行。其中，只有未完成事务的回滚对崩溃恢复是特殊的。插入缓冲区合并和清除在正常处理期间执行。
应用重做日志后，InnoDB尽可能早地尝试接受连接，以减少停机时间。作为事故恢复的一部分，InnoDB回滚未提交或未提交的事务XA准备服务器退出时的状态。回滚由后台线程执行，与来自新连接的事务并行执行。在回滚操作完成之前，新连接可能会遇到与恢复的事务的锁定冲突。
在大多数情况下，即使MySQL服务器在大量活动中意外关闭，恢复过程也会自动发生，DBA不需要做任何操作。如果硬件故障或严重的系统错误损坏InnoDB数据，MySQL可能会拒绝启动。在这种情况下，请参见章节14.22.2，强制恢复InnoDB．
有关二进制日志和的信息InnoDB崩溃恢复，请参见第5.4.4节“二进制日志”．
如果在恢复过程中，InnoDB遇到从上次检查点开始写入的重做日志，必须将这些重做日志应用到受影响的表空间。在恢复期间识别受影响表空间的进程称为表空间的发现．
表空间发现是通过扫描重做日志从最后一个检查点到日志的末尾来执行的MLOG_FILE_NAME当表空间页被修改时写入的记录。一个MLOG_FILE_NAME记录包含表空间ID和文件名。
在启动时,InnoDB打开系统表空间和重做日志。如果上次检查点之后还有写重做日志记录，受影响的表空间文件将根据MLOG_FILE_NAME记录。
MLOG_FILE_NAME为所有持久表空间类型写入记录，包括“每表文件”表空间、通用表空间、系统表空间和undo log表空间。
基于redo -log的发现具有以下特点:
只有表空间
* .ibd访问自上次检查点以来修改的文件。表空间
* .ibd未附加到InnoDB实例在应用重做日志时被忽略。如果
MLOG_FILE_NAME系统表空间的记录与影响系统表空间数据文件名的服务器配置不匹配，在应用重做日志之前恢复失败并报错。如果日志扫描部分中引用的表空间文件缺失，则拒绝启动。
重做表空间丢失的日志
* .ibd只有当有文件删除重做日志记录(MLOG_FILE_DELETE)在日志里。例如，表重命名失败可能导致”失踪”* .ibd文件没有MLOG_FILE_DELETE记录。在这种情况下，可以手动重命名表空间文件并重新启动崩溃恢复，或者可以使用恢复模式重新启动服务器innodb_force_recovery选择。失踪* .ibd当服务器以恢复模式启动时，文件将被忽略。
基于redo日志的发现，在MySQL 5.7中引入，取代了在早期MySQL版本中用于构造数据库的目录扫描”空间id到表空间的文件名”应用重做日志所需的映射。