Transaction Log (Write-Ahead Log)

A transaction log records durable information about state changes so a system can reconstruct committed or recoverable transaction state after a crash. In distributed systems, logs are commonly used alongside replication or coordination mechanisms, but a transaction log alone does not make a distributed transaction atomic.

A transaction log is an append-oriented record of changes or transaction decisions that must survive a process or machine failure. The key durability rule behind a Write-Ahead Log (WAL) is that the relevant log record is persisted before the corresponding data change is considered safely durable.

During normal operation, a transaction can generate log records describing actions such as inserts, updates, deletes, or transaction state transitions. The database can later use these records to reconstruct state, redo committed work, or undo work that was not committed, depending on its recovery design.

After a crash, recovery examines the durable log rather than assuming that in-memory state or partially written data is reliable. This allows the system to distinguish durable transaction decisions from operations that may have been interrupted. Exact recovery algorithms differ between database systems.

In distributed transactions, a log can also persist protocol state such as a participant's decision or prepared state. This is important for protocols such as two-phase commit, where a participant may need durable evidence of its state after restarting. The log supplies durability for the participant's local decision; it does not by itself provide agreement among all participants.

Key points

• A WAL persists required log records before treating related data changes as durable.
• Logs provide crash-recovery information that can survive process or machine failure.
• Recovery can use log records to redo durable work and/or undo incomplete work.
• Distributed transaction protocols may log prepared and committed states.
• A transaction log is a recovery mechanism, not by itself a distributed consensus or atomic-commit protocol.

Interview questions

What is a transaction log and why is it useful?

A transaction log is a durable record of transaction-related changes and state transitions. It lets the database recover after a crash without relying on volatile memory. With WAL, the required log information is persisted before the associated data change is considered safely durable. Recovery can then use the log to restore a consistent state.

Explain the write-ahead logging rule.

Write-ahead logging requires the relevant log record to reach the required durable state before the corresponding modified data is allowed to be treated as durable. This ordering ensures that recovery has enough information to repair or reproduce the data change after a crash. The exact definition of stable storage and flushing depends on the storage system and database implementation. The important invariant is the dependency between durable log records and durable data.

How does a transaction log help after a crash?

After a crash, volatile memory may contain neither a complete transaction state nor the final contents of modified pages. Recovery reads the durable log to determine which operations or decisions were recorded before the failure. Depending on the recovery design, it can redo changes that need to be reflected in the data files and undo changes belonging to transactions that did not complete. The log therefore provides a durable basis for reconstructing a consistent database state.

How is a transaction log used in two-phase commit?

A participant in two-phase commit may persist protocol state such as the prepared state and its eventual commit decision. If the participant crashes and restarts, the durable log gives it evidence of what state it had reached before the failure. This matters because a participant cannot safely assume that volatile memory still contains its previous protocol state. The log provides local durability, while the two-phase commit protocol coordinates the global transaction outcome.

Why isn't a transaction log sufficient to implement distributed atomic commit?

A local log can preserve what one node believed or recorded, but it does not make multiple nodes agree on a single outcome. Distributed atomic commit requires coordination among participants and rules for handling failures and uncertain states. Two-phase commit, for example, uses durable participant state together with coordinator-driven protocol messages. A consensus system addresses a different problem: obtaining agreement among distributed replicas despite certain failures.