How Redo Logs Safeguard Your Database: The Hidden ‘Airbag’ Behind Transaction Durability

Redo Log Basics: The Database “Airbag”

InnoDB’s redo log is a set of redo logs that record only the final state of data changes, not the operations themselves. It guarantees the durability of transactions (the D in ACID) by ensuring that once a transaction is marked as successful, its changes are recoverable even if the database crashes before the data is flushed to disk.

Redo Log Working Principle: How Logs Record and Flow

When a transaction modifies data, the redo log records the page number and the final value of the changed field. For example, updating a user’s balance from 800 to 1000 creates a log entry like “in page X, user A’s balance is now 1000”. The log is first stored in the redo log buffer in memory.

During commit, the buffer is flushed to disk – a process called “flushing”. The database only returns a success response to the client after the redo log has been safely written to disk, ensuring that the transaction is durable even if the in‑memory data has not yet been synchronized.

If a transaction is rolled back, its redo log entries are marked as “uncommitted” and later discarded; the undo log is used to revert any changes that might have been replayed.

Log Generation – Record Only the Result

Focus on final state , not the execution steps, allowing fast recovery.

Use data page as the smallest unit , recording page location and final value.

Log Buffering – In‑Memory Storage and Controlled Flushing

The redo log buffer groups entries by transaction ID, enabling efficient batch flushing. Flushing occurs in three scenarios: (1) explicit commit, (2) periodic background thread (≈1 s), and (3) when buffer usage exceeds a threshold (≈85%).

Circular Storage – Write‑Ahead Logging with Dual Pointers

Redo logs are stored in a set of files forming a circular buffer. A write‑pos pointer marks where new logs are written, while a checkpoint pointer marks the boundary of obsolete logs that have already been applied to data files. The region between checkpoint and write‑pos contains valid logs.

When write‑pos catches up to checkpoint, the system pauses new writes and advances checkpoint to free space.

Sequential Disk Writes – Overcoming Random‑Write Bottlenecks

Redo logs are written sequentially, allowing the disk head to move continuously and achieve higher throughput compared to random writes of data pages.

Core Scenario: Recovering Data After a Crash

After a crash, the database performs three steps:

Select valid logs : ignore logs before checkpoint and focus on the region between checkpoint and write‑pos.

Replay logs in order : apply each log’s precise page and value to restore changes that were not yet flushed to data files.

Combine with undo log : identify uncommitted transactions and roll back their changes using the undo log, ensuring no “half‑finished” data remains.

For example, if transaction T2 deducted 100 from user B’s balance but was not committed, its redo log may have been flushed. During recovery, the redo log would first apply the deduction, then the undo log would detect T2’s uncommitted status and revert the balance back to the original value.

Write at the End

Redo logs act as a safety cushion that balances performance and reliability: they record only the final state, use in‑memory buffering for speed, employ circular storage with dual pointers to manage space, and write sequentially to avoid disk bottlenecks. Together with the undo log, they ensure that a crashed database can recover to a consistent state without data loss.

UPDATE user SET balance = 1000 WHERE id = 1