MySQL 8.4 Release Notes
本节描述了InnoDB的恢复。主题包括：This section describes InnoDB recovery. Topics
include:
要将 InnoDB 数据库从创建物理备份的时间恢复到当前状态，必须在进行备份之前就启用 MySQL 服务器的二进制日志。为了在还原备份后实现时间点恢复，可以应用备份创建后在二进制日志中发生的更改。请参见 第 9.5 节，“时间点（增量）恢复”。To recover an InnoDB database to the present
from the time at which the physical backup was made, you must
run MySQL server with binary logging enabled, even before taking
the backup. To achieve point-in-time recovery after restoring a
backup, you can apply changes from the binary log that occurred
after the backup was made. See
Section 9.5, “Point-in-Time (Incremental) Recovery”.
如果您的数据库损坏或发生磁盘故障，您必须使用备份进行恢复。在出现数据损坏时，首先找到未损坏的备份。恢复基础备份后，使用mysqlbinlog和mysql对二进制日志文件进行时间点恢复，以恢复备份之后发生的更改。If your database becomes corrupted or disk failure occurs, you must perform the recovery using a backup. In the case of corruption, first find a backup that is not corrupted. After restoring the base backup, do a point-in-time recovery from the binary log files using mysqlbinlog and mysql to restore the changes that occurred after the backup was made.
在某些数据库损坏的情况下，仅转储、删除并重新创建一个或几个损坏的表就足够了。你可以使用 CHECK TABLE 语句来检查表是否损坏，尽管 CHECK
TABLE 自然不能检测所有可能类型的损坏。In some cases of database corruption, it is enough to dump,
drop, and re-create one or a few corrupt tables. You can use the
CHECK TABLE statement to check
whether a table is corrupt, although CHECK
TABLE naturally cannot detect every possible kind of
corruption.
在某些情况下，表面上的数据库页损坏实际上是由于操作系统破坏了自身的文件缓存，而磁盘上的数据可能是正常的。最好先尝试重启计算机。这样做可能会消除看似数据库页损坏的错误。如果 MySQL 仍然由于 InnoDB 一致性问题而难以启动，请参见 第 17.20.3 节，“强制 InnoDB 恢复”，了解在恢复模式下启动实例的步骤，这允许你导出数据。In some cases, apparent database page corruption is actually due
to the operating system corrupting its own file cache, and the
data on disk may be okay. It is best to try restarting the
computer first. Doing so may eliminate errors that appeared to
be database page corruption. If MySQL still has trouble starting
because of InnoDB consistency problems, see
Section 17.20.3, “Forcing InnoDB Recovery” for steps to start the
instance in recovery mode, which permits you to dump the data.
要从意外的 MySQL 服务器退出中恢复，唯一的要求是重启 MySQL 服务器。InnoDB 会自动检查日志，并将数据库向前滚动到当前状态。InnoDB 会自动回滚在崩溃时存在的未提交事务。To recover from an unexpected MySQL server exit, the only
requirement is to restart the MySQL server.
InnoDB automatically checks the logs and
performs a roll-forward of the database to the present.
InnoDB automatically rolls back uncommitted
transactions that were present at the time of the crash.
InnoDB 崩溃恢复 包括几个步骤：InnoDB
crash recovery
consists of several steps:
表空间发现Tablespace discovery
表空间发现是
InnoDB用来识别需要应用重做日志的表空间的过程。请参见 崩溃恢复期间的表空间发现。Tablespace discovery is the process thatInnoDBuses to identify tablespaces that require redo log application. See Tablespace Discovery During Crash Recovery.重做日志的应用在初始化期间执行，在接受任何连接之前进行。如果在关闭或崩溃时，所有更改都已从 缓冲池 刷写到 表空间（
ibdata*和*.ibd文件），则会跳过重做日志应用。如果启动时缺少重做日志文件，InnoDB也会跳过重做日志应用。Redo log application is performed during initialization, before accepting any connections. If all changes are flushed from the buffer pool to the tablespaces (ibdata*and*.ibdfiles) at the time of the shutdown or crash, redo log application is skipped.InnoDBalso skips redo log application if redo log files are missing at startup.每当自增计数器的值发生变化时，当前的最大自增计数器值都会写入重做日志，从而使其具有崩溃安全性。在恢复过程中，
InnoDB会扫描重做日志以收集计数器值的变化，并将这些变化应用到内存中的表对象。The current maximum auto-increment counter value is written to the redo log each time the value changes, which makes it crash-safe. During recovery,InnoDBscans the redo log to collect counter value changes and applies the changes to the in-memory table object.有关
InnoDB如何处理自增值的更多信息，请参见第 17.6.1.6 节，“InnoDB 中的 AUTO_INCREMENT 处理”，以及InnoDB AUTO_INCREMENT 计数器初始化。For more information about howInnoDBhandles auto-increment values, see Section 17.6.1.6, “AUTO_INCREMENT Handling in InnoDB”, and InnoDB AUTO_INCREMENT Counter Initialization.在遇到索引树损坏时，
InnoDB会将损坏标志写入重做日志，这使得损坏标志具备崩溃安全性。InnoDB还会在每个检查点将内存中的损坏标志数据写入引擎专用系统表。在恢复过程中，InnoDB会从这两个位置读取损坏标志并合并结果，然后将内存中的表和索引对象标记为损坏。When encountering index tree corruption,InnoDBwrites a corruption flag to the redo log, which makes the corruption flag crash-safe.InnoDBalso writes in-memory corruption flag data to an engine-private system table on each checkpoint. During recovery,InnoDBreads corruption flags from both locations and merges results before marking in-memory table and index objects as corrupt.即使可以接受部分数据丢失，也不建议删除重做日志来加快恢复速度。只有在干净关闭后，并且将
innodb_fast_shutdown设置为0或1时，才应考虑删除重做日志。Removing redo logs to speed up recovery is not recommended, even if some data loss is acceptable. Removing redo logs should only be considered after a clean shutdown, withinnodb_fast_shutdownset to0or1.
回滚 未完成的 事务Roll back of incomplete transactions
未完成的事务是指在意外退出或快速关闭时仍处于活动状态的任何事务。回滚未完成事务所需的时间可能是事务在被中断前活动时间的三到四倍，这取决于服务器负载。Incomplete transactions are any transactions that were active at the time of unexpected exit or fast shutdown. The time it takes to roll back an incomplete transaction can be three or four times the amount of time a transaction is active before it is interrupted, depending on server load.
您无法取消正在回滚的事务。在极端情况下，当预计回滚事务需要非常长的时间时，启动
InnoDB并设置innodb_force_recovery为3或更高可能更快。参见 第 17.20.3 节，“强制 InnoDB 恢复”。You cannot cancel transactions that are being rolled back. In extreme cases, when rolling back transactions is expected to take an exceptionally long time, it may be faster to startInnoDBwith aninnodb_force_recoverysetting of3or greater. See Section 17.20.3, “Forcing InnoDB Recovery”.更改缓冲区 合并Change buffer merge
将更改缓冲区（属于 系统表空间）中的更改应用到二级索引的叶子页，当索引页被读取到缓冲池时执行。Applying changes from the change buffer (part of the system tablespace) to leaf pages of secondary indexes, as the index pages are read to the buffer pool.
删除那些已经标记为删除且对活跃事务不可见的记录。Deleting delete-marked records that are no longer visible to active transactions.
随后的步骤在重做日志应用之后进行，这些步骤不依赖于重做日志（除了用于记录写入操作）并且与正常处理并行进行。在这些步骤中，只有未完成事务的回滚是崩溃恢复中特有的。插入缓冲合并和清除操作是在正常处理期间进行的。The steps that follow redo log application do not depend on the redo log (other than for logging the writes) and are performed in parallel with normal processing. Of these, only rollback of incomplete transactions is special to crash recovery. The insert buffer merge and the purge are performed during normal processing.
在重做日志应用之后，InnoDB 会尽早尝试接受连接，以减少停机时间。作为崩溃恢复的一部分，InnoDB 会回滚在服务器退出时未提交或处于 XA
PREPARE 状态的事务。回滚由后台线程执行，与来自新连接的事务并行进行。在回滚操作完成之前，新连接可能会与已恢复的事务发生锁冲突。After redo log application, InnoDB attempts
to accept connections as early as possible, to reduce downtime.
As part of crash recovery, InnoDB rolls back
transactions that were not committed or in XA
PREPARE state when the server exited. The rollback is
performed by a background thread, executed in parallel with
transactions from new connections. Until the rollback operation
is completed, new connections may encounter locking conflicts
with recovered transactions.
在大多数情况下，即使 MySQL 服务器在繁忙活动中意外被终止，恢复过程也会自动进行，DBA 无需采取任何操作。如果硬件故障或严重的系统错误破坏了 InnoDB 数据，MySQL 可能会拒绝启动。在这种情况下，请参阅 第 17.20.3 节，“强制 InnoDB 恢复”。In most situations, even if the MySQL server was killed
unexpectedly in the middle of heavy activity, the recovery
process happens automatically and no action is required of the
DBA. If a hardware failure or severe system error corrupted
InnoDB data, MySQL might refuse to start. In
this case, see Section 17.20.3, “Forcing InnoDB Recovery”.
有关二进制日志和 InnoDB 崩溃恢复的信息，请参阅 第 7.4.4 节，“二进制日志”。For information about the binary log and
InnoDB crash recovery, see
Section 7.4.4, “The Binary Log”.
如果在恢复过程中，InnoDB 遇到自上次检查点以来写入的重做日志，则必须将这些重做日志应用到受影响的表空间。恢复过程中识别受影响表空间的过程被称为 表空间发现。If, during recovery, InnoDB encounters redo
logs written since the last checkpoint, the redo logs must be
applied to affected tablespaces. The process that identifies
affected tablespaces during recovery is referred to as
tablespace discovery.
表空间发现依赖于 innodb_directories 设置，该设置定义了启动时扫描表空间文件的目录。innodb_directories 的默认设置为 NULL，但由 innodb_data_home_dir、innodb_undo_directory 和 datadir 所定义的目录始终会被追加到 innodb_directories 参数值中，当 InnoDB 构建启动时扫描的目录列表时。无论是否显式指定了 innodb_directories 设置，这些目录都会被追加。使用绝对路径定义或位于附加到 innodb_directories 设置之外的目录中的表空间文件，应添加到 innodb_directories 设置中。如果 redo 日志中引用的任何表空间文件以前未被发现，则恢复将终止。Tablespace discovery relies on the
innodb_directories setting,
which defines the directories to scan at startup for tablespace
files. The innodb_directories
default setting is NULL, but the directories defined by
innodb_data_home_dir,
innodb_undo_directory, and
datadir are always appended to
the innodb_directories argument
value when InnoDB builds a list of directories to scan at
startup. These directories are appended regardless of whether an
innodb_directories setting is
specified explicitly. Tablespace files defined with an absolute
path or that reside outside of the directories appended to the
innodb_directories setting
should be added to the
innodb_directories setting.
Recovery is terminated if any tablespace file referenced in a
redo log has not been discovered previously.