Two logs, two jobs
InnoDB durability and transaction control rest on two distinct logs that are easy to confuse.
The redo log
The redo log is a fixed size circular file recording physical changes to pages. On commit InnoDB flushes the relevant redo records to disk so the change survives a crash even if the dirty data page has not been written yet. This is the write ahead log principle: log first, apply the page later.
- It enables fast commits because sequential log writes are cheap compared to random page writes.
- After a crash, recovery replays redo to bring data files forward to the last committed state.
The undo log
The undo log stores the prior versions of rows a transaction modified. It serves two purposes:
- Rollback restores rows to their pre transaction values if the transaction aborts.
- MVCC uses undo to reconstruct older row versions for snapshots that other transactions still see.
Working together
A commit makes redo durable; the undo records for that transaction can be purged once no snapshot needs them. A crash replays redo and then rolls back transactions that never committed.
Key idea
The redo log is a write ahead log that makes commits durable and replays after a crash, while the undo log holds prior row versions for rollback and MVCC snapshots.