Understanding InnoDB REDO Log Recovery Process

InnoDB relies on REDO logs to restore data after an unexpected shutdown. The recovery begins by locating the latest checkpoint information stored in the first two pages of the log files ( LOG_CHECKPOINT_1 and LOG_CHECKPOINT_2 ) and determining the starting LSN for recovery.

From the checkpoint LSN, InnoDB scans the log files in 2 MB chunks. The scanning loop reads each log block, strips the header and trailer, and feeds the raw log records to the parser. The core scanning function is recv_group_scan_log_recs , which repeatedly calls recv_scan_log_recs to process a block of log data.

During parsing, recv_parse_log_recs extracts individual log records, identifies their type, tablespace ID, page number, and body, and groups them into mini‑transactions (MTRs). Complete MTRs are recognized by the MLOG_MULTI_REC_END marker.

Each parsed record is stored in a recv_t structure and placed into a hash table keyed by tablespace and page number. If a hash bucket for a page does not exist, recv_get_fil_addr_struct creates a new recv_addr_t entry and inserts it with HASH_INSERT . All records for the same page are linked in order, preserving LSN sequence.

When the hash table is sufficiently populated, recv_apply_hashed_log_recs iterates over every bucket, fetches the corresponding page from the buffer pool (or reads it from disk), and applies the stored REDO records in order. After all pages are processed, the system flushes the buffer pool to ensure that the applied changes are persisted.

The article also notes that because records for a single page are stored together and ordered, the REDO apply phase could be parallelized by assigning different hash buckets to separate threads, potentially improving recovery speed for large log files.