10bet网址
MySQL 8.0参考手册
相关的文档10bet官方网站 下载本手册
PDF(美国高级主任)- 41.1 mb
PDF (A4)- 41.2 mb
PDF (RPM)- 39.8 mb
HTML下载(TGZ)- 9.5 mb
HTML下载(Zip)- 9.6 mb
HTML下载(RPM)- 8.1 mb
手册页(TGZ)- 260.6 kb
手册页(Zip)- 371.7 kb
信息(Gzip)- 3.9 mb
信息(邮政编码)- 3.9 mb
本手册节选

15.18.2 InnoDB恢复

本节描述InnoDB复苏。主题包括:

时间点恢复

要恢复InnoDB数据库到现在的物理备份,你必须运行MySQL服务器启用二进制日志记录,甚至在进行备份之前。要在恢复备份之后实现时间点恢复,可以应用备份之后发生的二进制日志中的更改。看到第7.5节,“时间点(增量)恢复”

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

如果数据库损坏或发生磁盘故障,则必须使用备份执行恢复。在损坏的情况下,首先找到未损坏的备份。恢复基本备份之后,使用mysqlbinlog而且mysql以恢复备份之后发生的更改。

在数据库损坏的某些情况下,转储、删除和重新创建一个或几个损坏的表就足够了。您可以使用检查表语句来检查表是否已损坏检查表自然不能检测到每一种可能的腐败。

在某些情况下,明显的数据库页面损坏实际上是由于操作系统损坏了自己的文件缓存,而磁盘上的数据可能没有问题。最好先试着重启电脑。这样做可以消除似乎是数据库页面损坏造成的错误。如果MySQL仍然有启动困难,因为InnoDB一致性问题,请参见章节15.21.2,强制恢复InnoDB有关以恢复模式启动实例的步骤,该模式允许转储数据。

InnoDB崩溃恢复

要从意外的MySQL服务器退出中恢复,唯一的要求是重新启动MySQL服务器。InnoDB自动检查日志并执行数据库前滚到当前。InnoDB自动回滚崩溃时存在的未提交的事务。在恢复期间,mysqld显示类似这样的输出:

InnoDB: system表空间中的日志序列号664050266与ib_logfiles!日志序列号685111586不匹配!InnoDB: Database was not shutdown normal !InnoDB:启动崩溃恢复。InnoDB:使用'tablespaces.open. open. properties。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:在总共561887个行操作中,1个事务必须回滚或清理才能撤销InnoDB: Trx id计数器是4096…InnoDB: 8.0.1 started;InnoDB: rollback trx with id 3596, 561887 rows to undo .... /mysqld: ready for connections.... . log sequence number 713458156 InnoDB: Waiting for purge to start InnoDB:在后台启动未提交事务的回滚

InnoDB崩溃恢复包括以下几个步骤:

  • 表空间的发现

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

  • 重做日志应用程序

    重做日志应用程序在初始化期间执行,在接受任何连接之前。中的所有更改都被刷新缓冲池表空间ibdata *而且* .ibd在关闭或崩溃时,重做日志应用程序被跳过。InnoDB如果重做日志文件在启动时丢失,也会跳过重做日志应用程序。

    • 当前最大的自动递增计数器值每次改变时都被写入重做日志,这使得它是安全的。在恢复期间,InnoDB扫描重做日志以收集计数器值的更改,并将更改应用到内存中的表对象。

      有关如何InnoDB处理自动递增值,请参见章节15.6.1.6,InnoDB中的AUTO_INCREMENT处理,InnoDB AUTO_INCREMENT计数器初始化

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

    • 不建议删除重做日志以加速恢复,即使一些数据丢失是可以接受的。删除重做日志应该只考虑在完全关机后,使用innodb_fast_shutdown设置为01

  • 回滚不完整的交易

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

    不能取消正在回滚的事务。在极端情况下,当回滚事务预计将花费非常长的时间时,开始回滚可能会更快InnoDB与一个innodb_force_recovery设置3.或更高版本。看到章节15.21.2,强制恢复InnoDB

  • 改变缓冲合并

    从更改缓冲区应用更改(控件的部分系统表空间)到二级索引的叶页,因为索引页被读入缓冲池。

  • 清洗

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

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

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

在大多数情况下,即使MySQL服务器在大量活动中意外关闭,恢复过程也会自动发生,DBA不需要做任何操作。如果硬件故障或严重的系统错误损坏InnoDB数据,MySQL可能会拒绝启动。在这种情况下,请参见章节15.21.2,强制恢复InnoDB

有关二进制日志和的信息InnoDB崩溃恢复,请参见第5.4.4节“二进制日志”

崩溃恢复期间的表空间发现

如果在恢复过程中,InnoDB遇到从上次检查点开始写入的重做日志,必须将这些重做日志应用到受影响的表空间。在恢复期间识别受影响表空间的进程称为表空间的发现

表空间发现依赖于innodb_directories设置,该设置定义了在启动时扫描表空间文件的目录。的innodb_directories默认设置为NULL,但定义的目录innodb_data_home_dirinnodb_undo_directory,datadir总是附加到innodb_directories当InnoDb在启动时构建要扫描的目录列表。这些目录将被追加,而不管是否innodb_directories设置是显式指定的。表空间文件定义为绝对路径或位于附加到innodb_directories设置应添加到innodb_directories设置。如果之前没有发现重做日志中引用的表空间文件,则恢复将终止。