The Log: What every software engineer should know about real-time data's unifying abstraction explains why logs matter: they give systems a durable record and an order for replay.
In MySQL, InnoDB's redo log stores redo log records for changes that may not have reached the data files yet. With MySQL's default full-ACID setting, innodb_flush_log_at_trx_commit=1, InnoDB writes the transaction's redo log records and flushes the redo log at commit.
START TRANSACTION;
-- Generate redo records
UPDATE users
SET plan = 'pro'
WHERE id = 42;
-- Flush the log
COMMIT;After a crash, InnoDB recovery applies redo during initialization before accepting connections. Recovery starts from a checkpoint and replays durable redo in increasing Log Sequence Number (LSN) order to bring data files forward. Transactions that had not committed are rolled back as part of recovery, and that rollback can continue after the server is available.
In the demo below, Account A and Account B already exist because their earlier insert records happened before the checkpoint and their pages made it into the data files. Recovery starts from that checkpointed data-file image, so the visible redo log only shows records newer than the checkpoint.
Commit log rebuilds the served state
After each log record is applied, the JSON shows the current state of the database.