If, during crash recovery,
redo logs written since the last checkpoint, the redo logs must be
applied to the affected tablespaces. The process that identifies
affected tablespaces is referred to as tablespace
Prior to MySQL 5.7.5, tablespace files were referenced in redo
logs by a
space_id, which is a numeric
identifier. In the file system, however,
tablespaces are known by a
*.ibd file name,
which required that
InnoDB construct a
“space_id-file name” map in order to apply redo logs.
To construct the map,
InnoDB traversed the data
directory, reading the first page of each
file. This process could result in unnecessary downtime for MySQL
instances with numerous
In MySQL 5.6.6, the introduction of support for the
DIRECTORY clause for
tablespaces further complicated tablespace discovery. The
DATA DIRECTORY enhancement introduced
.isl files as placeholders that point to the
*.ibd files stored outside of
the MySQL data directory.
In MySQL 5.7.5, instead of reading the first page of all
$datadir/*/*.ibd files and checking the
$datadir/*/*.isl files before
applying redo logs, InnoDB uses a new redo log record type to
identify the file-per-table tablespaces that have been modified
since the last checkpoint. An
record, which contains the tablespace
and file name, is written to the redo log when a tablespace page
is modified. The benefits of
redo log records include:
Elimination of file system scans prior to redo log application. The
MLOG_FILE_NAMEredo log record provides the information necessary to identify and locate tablespaces that have changed since the last checkpoint.
*.ibdfiles modified since the last checkpoint are accessed.
*.ibdfiles that are not attached to the
InnoDBinstance are ignored when redo logs are applied.
InnoDBno longer silently discards redo log records for missing
*.ibdfiles unless there is an
MLOG_FILE_DELETErecord in the redo log. For example, if a file rename fails, resulting in a “missing”
*.ibdfile, you can manually rename the file and restart crash recovery. Missing
*.ibdfiles are ignored in
During recovery, the redo log is read from the last checkpoint to the detected logical end of the log. If tablespace files that are referenced in the scanned portion of the redo log are missing, startup is refused.
Failure scenarios related to inconsistent
*.islfiles are eliminated.
*.islfiles are now only used after redo log apply, when opening tables.
In MySQL 5.7.6, two tablespace discovery searches were added with
the introduction of
InnoDB general tablespaces.
The first search traverses
SYS_TABLESPACESand related entries in
SYS_DATAFILES, in the internal data dictionary. All previously created general tablespaces are opened, including general tablespaces that are empty.
The second search traverses
SYS_TABLES, in the internal data dictionary. For tables with a SPACE ID greater than 0, the SPACE ID is looked up in
SYS_DATAFILESto ensure that the tablespace is opened.