MySQL 8.0版本说明
MySQL 8.0源代码文档10bet官方网站
本节描述InnoDB复苏。主题包括:
恢复一个InnoDB从做物理备份的时间到现在，您必须运行MySQL服务器，启用二进制日志记录，甚至在进行备份之前。要在恢复备份之后实现时间点恢复，可以应用备份之后发生的二进制日志中的更改。看到第7.5节，“时间点(增量)恢复”．
如果数据库损坏或发生磁盘故障，则必须使用备份执行恢复。在损坏的情况下，首先找到一个没有损坏的备份。恢复基本备份之后，使用mysqlbinlog而且mysql恢复备份之后发生的更改。
在某些数据库损坏的情况下，转储、删除和重新创建一个或几个损坏的表就足够了。您可以使用检查表语句来检查表是否已损坏检查表自然不能发现每一种可能的腐败。
在某些情况下，明显的数据库页面损坏实际上是由于操作系统损坏了它自己的文件缓存，磁盘上的数据可能没有问题。最好先重新启动计算机。这样做可以消除似乎是数据库页面损坏的错误。如果MySQL仍然无法启动，因为InnoDB一致性问题,看到第15.21.2节“强制InnoDB恢复”有关以恢复模式启动实例的步骤，该模式允许您转储数据。
要从意外的MySQL服务器退出中恢复，唯一的要求是重新启动MySQL服务器。InnoDB自动检查日志并将数据库前滚到当前。InnoDB自动回滚崩溃时存在的未提交事务。在恢复期间,mysqld显示类似这样的输出:
InnoDB:系统表空间中日志序列号664050266不匹配ib_logfiles中日志序列号685111586 !InnoDB:数据库没有正常关闭!InnoDB:正在启动崩溃恢复。InnoDB:使用“tablespaces.open。2' max LSN: 664075228 InnoDB:正在恢复:扫描到日志序列号690354176 InnoDB:正在恢复:扫描到日志序列号695597056 InnoDB:正在恢复:扫描到日志序列号700839936 InnoDB:正在恢复:扫描到日志序列号706082816 InnoDB:正在恢复:扫描到日志序列号711325696 InnoDB:正在恢复:扫描到日志序列号713458156 InnoDB:应用批量1467重做日志记录…InnoDB: 10% InnoDB: 20% InnoDB: 30% InnoDB: 40% InnoDB: 50% InnoDB: 60% InnoDB: 70% InnoDB: 80% InnoDB: 90% InnoDB: 100% InnoDB:应用批量完成!InnoDB: 1个事务必须回滚或清理，总共561887行操作才能撤销InnoDB: Trx id计数器为4096…InnoDB: 8.0.1开始;InnoDB: rollback trx with id 3596, 561887 rows to undo .... /mysqld: ready for connections.... . log序列号713458156InnoDB崩溃恢复包括以下几个步骤:
表空间的发现
表空间发现的过程
InnoDB用于识别需要应用重做日志的表空间。看到在崩溃恢复期间发现表空间．重做日志应用程序
在接受任何连接之前，在初始化期间执行重做日志应用程序。方法刷新所有更改缓冲池到表空间（
ibdata *而且* .ibd在关闭或崩溃时，重做日志应用程序将被跳过。InnoDB如果启动时重做日志文件丢失，也会跳过重做日志应用程序。当前的最大自动增量计数器值在每次改变时都被写入重做日志，这使它具有崩溃安全性。在恢复期间,
InnoDB扫描重做日志以收集计数器值的变化，并将这些变化应用到内存中的表对象。更多信息
InnoDB处理自动递增值，请参见第15.6.1.6节“InnoDB中的AUTO_INCREMENT处理”,InnoDB AUTO_INCREMENT计数器初始化．遇到索引树损坏时，
InnoDB写一个损坏标志到重做日志，这使损坏标志崩溃安全。InnoDB还将内存中的损坏标志数据写入每个检查点上的引擎私有系统表。在恢复期间,InnoDB在将内存中的表和索引对象标记为损坏之前，从两个位置读取损坏标志并合并结果。不建议删除重做日志来加速恢复，即使一些数据丢失是可以接受的。删除重做日志应该只考虑在完全关闭后，使用
innodb_fast_shutdown设置为0或1．
不完全事务是在意外退出时处于活动状态的任何事务快速关闭．根据服务器负载的不同，回滚未完成事务所需的时间可能是事务中断前活动时间的三到四倍。
您不能取消正在回滚的事务。在极端情况下，当回滚事务预计要花费特别长的时间时，可能会更快地开始
InnoDB与一个innodb_force_recovery设置3.或更高版本。看到第15.21.2节“强制InnoDB恢复”．改变缓冲合并
从更改缓冲区应用更改(部分系统表空间)到二级索引的叶页，因为索引页被读到缓冲池。
删除已删除标记的记录，这些记录对活动事务不再可见。
重做日志应用后的步骤不依赖于重做日志(除了记录写入操作)，而是与正常处理并行执行。其中，只有不完全事务的回滚对崩溃恢复是特殊的。插入缓冲区合并和清除是在正常处理期间执行的。
在应用重做日志后，InnoDB试图尽早接受连接，以减少停机时间。作为坠机恢复的一部分，InnoDB回滚未提交或处于的事务XA准备说明服务器退出的时间。回滚由后台线程执行，与来自新连接的事务并行执行。在回滚操作完成之前，新的连接可能会遇到与恢复的事务的锁定冲突。
在大多数情况下，即使MySQL服务器在大量活动中意外关闭，恢复过程也会自动进行，DBA不需要做任何操作。如果硬件故障或严重的系统错误损坏InnoDBMySQL可能会拒绝启动。在这种情况下，参见第15.21.2节“强制InnoDB恢复”．
有关二进制日志和InnoDB崩溃恢复,看第5.4.4节“二进制日志”．
如果,在复苏,InnoDB遇到从上一个检查点开始写入的重做日志时，必须将重做日志应用到受影响的表空间中。在恢复期间识别受影响表空间的进程称为表空间的发现．
表空间的发现依赖于innodb_directories设置，该设置定义在启动时扫描表空间文件的目录。的innodb_directories默认设置为NULL，但定义的目录innodb_data_home_dir，innodb_undo_directory,datadir总是附加在innodb_directories参数值，当InnoDb在启动时构建一个要扫描的目录列表时。这些目录被追加，而不管是否有innodb_directories设置是显式指定的。类中附加的目录之外定义的表空间文件innodb_directories设置应添加到innodb_directories设置。如果之前没有发现重做日志中引用的表空间文件，则恢复将终止。