Understanding MySQL Crash Recovery and the Role of Redo Logs

MySQL crash recovery is essentially a forced shutdown process that relies on Redo logs to restore dirty pages to their state before the crash.

The recovery described here covers the server layer and InnoDB , based on MySQL 8.0.29 source code.

1. Overview

During a normal shutdown MySQL performs cleanup tasks such as undo log cleaning and change buffer merging, controlled by the innodb_fast_shutdown variable. In a crash these tasks are skipped and must be performed on the next startup, which is the crash recovery process.

2. Doublewrite (Two‑Write) Mechanism

When MySQL crashes, the Redo log attempts to rescue the world by restoring dirty pages that were not flushed to disk. This requires the pages to be intact; otherwise the doublewrite buffer is used.

All data pages (system tablespace, file‑per‑table tablespace, and undo tablespace) are collectively referred to as data pages .

The doublewrite process writes each dirty page first to an in‑memory buffer and then to a dblwr file before the page is flushed to the tablespace.

The doublewrite feature is controlled by the innodb_doublewrite system variable, which defaults to ON .

[csch@csch /usr/local/mysql_8_0_29/data] ls -l | grep dblwr
-rw-r----- 1 csch staff 192K 8 27 12:04 #ib_16384_0.dblwr
-rw-r----- 1 csch staff 8.2M 8  1 16:29 #ib_16384_1.dblwr

3. Recovering Data Pages

Applying Redo logs (section 3.4) requires first locating the last checkpoint LSN (section 3.1) and repairing any corrupted pages (section 3.2).

3.1 Locate last_checkpoint_lsn

The first four blocks of each Redo log file are reserved; the checkpoint LSN is stored in block 2 or 4 of the first Redo log file, depending on whether the checkpoint number is even or odd.

Each Redo‑log block is 512 bytes.

3.2 Repair Corrupted Pages

All pages from the doublewrite file are loaded into memory, then compared with the file header and trailer fields ( FILE_PAGE_LSN , FILE_PAGE_SPACE_OR_CHECKSUM ) to detect corruption. If corruption is detected, the doublewrite copy is used to restore the page.

3.3 Read Redo Logs

Reading starts from last_checkpoint_lsn in 64 KB chunks, validates each block, and copies the payload (496 bytes) into a 2 MB parsing buffer.

The parsed logs are stored in a two‑level hash table keyed by tablespace ID and page number, with each entry holding a linked list of Redo log records ordered by LSN.

3.4 Apply Redo Logs

Pages are asynchronously pre‑read in batches of up to 32 pages, loaded into the buffer pool, and Redo records whose start_lsn is greater than or equal to the page's FILE_PAGE_LSN are applied.

4. Delete Undo Tablespaces

If innodb_undo_log_truncate is ON and the undo tablespace exceeds innodb_max_undo_log_size (default 1 GB), InnoDB truncates it to the initial 16 MB size. The truncation is marked by a undo_*_trunc.log file.

[csch@csch /usr/local/mysql_8_0_29/data] ls -l | grep undo
-rw-r----- 1 csch staff 16M 8 27 12:04 undo_001
-rw-r----- 1 csch staff 16M 8 27 12:04 undo_002
-rw-r--r-- 1 csch staff 16K 6 22 12:36 undo_1_trunc.log

5. Initialize Transaction Subsystem

InnoDB reads undo tablespaces, extracts rollback segments, iterates over undo slots, and builds the transaction list, handling active, prepared, and committed‑in‑memory transactions.

6. Rebuild Undo Tablespaces

When a truncation was interrupted, the undo tablespace file is recreated (starting at 16 MB) and a new trunc.log file is written with the magic number 76845412 to indicate completion, after which the log file is removed.

7. Process Transactions

7.1 Clean Up Committed Transactions

Insert‑undo segments are either cached or freed, the transaction is removed from the read‑write list, and its state is set to TRX_STATE_NOT_STARTED .

7.2 Roll Back Uncommitted DDL Transactions

Even though DDL appears auto‑committed to users, InnoDB can roll back unfinished DDL transactions during recovery.

7.3 Roll Back Uncommitted DML Transactions

Active ( TRX_STATE_ACTIVE ) transactions are rolled back; the detailed rollback algorithm is omitted here.

7.4 Handle PREPARE Transactions

Prepared transactions ( TRX_STATE_PREPARED ) are committed if their XID appears in the last binlog file (detected via XID_EVENT ), otherwise they are rolled back.

8. Summary

Redo logs restore dirty pages after a crash, using the doublewrite buffer to repair corrupted pages before applying the logs.

Undo tablespaces are truncated or rebuilt as needed, and all incomplete transactions are either committed or rolled back to guarantee consistency.

9. Related Articles

Redo Log Generation and Writing

Undo Log Storage Structure for Lock‑Free Concurrent Writes

MySQL Two‑Phase Commit