Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 37.5Mb
PDF (A4) - 37.5Mb
PDF (RPM) - 37.0Mb
EPUB - 10.5Mb
HTML Download (TGZ) - 10.3Mb
HTML Download (Zip) - 10.3Mb
HTML Download (RPM) - 9.0Mb
Eclipse Doc Plugin (TGZ) - 11.2Mb
Eclipse Doc Plugin (Zip) - 13.4Mb
Man Pages (TGZ) - 203.9Kb
Man Pages (Zip) - 309.1Kb
Info (Gzip) - 3.4Mb
Info (Zip) - 3.4Mb
Excerpts from this Manual

MySQL 5.7 Reference Manual  /  ...  /  Tablespace Discovery During Crash Recovery

15.18.2 Tablespace Discovery During Crash Recovery

If, during crash recovery, InnoDB encounters 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 discovery.

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, file-per-table 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 *.ibd file. This process could result in unnecessary downtime for MySQL instances with numerous *.ibd files.

In MySQL 5.6.6, the introduction of support for the CREATE TABLE DATA DIRECTORY clause for file-per-table tablespaces further complicated tablespace discovery. The DATA DIRECTORY enhancement introduced .isl files as placeholders that point to the location of *.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 contents of $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 MLOG_FILE_NAME record, which contains the tablespace space_id and file name, is written to the redo log when a tablespace page is modified. The benefits of MLOG_FILE_NAME redo log records include:

  • Elimination of file system scans prior to redo log application. The MLOG_FILE_NAME redo log record provides the information necessary to identify and locate tablespaces that have changed since the last checkpoint.

  • Only *.ibd files modified since the last checkpoint are accessed.

  • *.ibd files that are not attached to the InnoDB instance are ignored when redo logs are applied.

  • InnoDB no longer silently discards redo log records for missing *.ibd files unless there is an MLOG_FILE_DELETE record in the redo log. For example, if a file rename fails, resulting in a missing *.ibd file, you can manually rename the file and restart crash recovery. Missing *.ibd files are ignored in innodb_force_recovery mode.

  • 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 *.isl files are eliminated. *.isl files 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_TABLESPACES and 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_DATAFILES to ensure that the tablespace is opened.

User Comments
Sign Up Login You must be logged in to post a comment.