ARIES Recovery Algorithm

Why it exists

ARIES was created to provide fast, reliable crash recovery for high-performance databases. Common performance-enhancing memory management policies, like 'steal' and 'no-force', create complex failure scenarios. ARIES provides a formal method to correctly restore a consistent database state in this environment.

The mental model

Think of ARIES as a meticulous accountant for your database. It uses a write-ahead log (a ledger) to record every single change before it happens. After a crash, it first replays the entire ledger to restore the state exactly as it was, then it carefully reverses any transactions that weren't finalized, logging each reversal to prevent errors if it's interrupted again.

How it works

The algorithm is built on three core ideas. First is Write-Ahead Logging (WAL), where every change is written to a log on stable storage before the corresponding database page is modified. Second is repeating history during recovery, where logged operations are reapplied to restore the database to its state at the time of the crash. Third is logging undos, where actions taken to roll back a transaction are themselves logged in special records (CLRs), preventing repeated work if recovery is interrupted.

The recovery process itself has three phases: Analysis, which scans the log to identify dirty pages and active transactions at the time of the crash. Redo, which re-applies all logged changes since the last checkpoint to bring the database up to date. And Undo, which rolls back all incomplete ('loser') transactions from last to first, using the CLRs to ensure idempotency.

When to use it

ARIES is the standard for transactional databases that need high throughput. It is specifically designed for systems using a 'steal/no-force' buffer management policy. 'Steal' allows uncommitted changes to be written to disk to free memory, and 'no-force' avoids flushing committed changes to disk immediately. This combination boosts performance but requires a robust recovery algorithm like ARIES.

When not to use it

The complexity of ARIES is overkill for simpler storage systems or databases that can afford stricter, less performant policies like 'no-steal' (uncommitted data is never written to disk) or 'force' (all committed data is immediately written to disk). In these cases, a simpler recovery mechanism is sufficient.

One canonical example

A user updates their shipping address. The database starts a transaction, modifies the data in a memory buffer, and writes the change to the log file on disk. To free up memory, the buffer manager writes this dirty page to disk before the transaction commits ('steal'). The system then crashes. On restart, ARIES's Redo phase re-applies the logged change. Then, the Undo phase identifies the transaction as a 'loser' (it never committed) and rolls back the address change, restoring the database to a consistent state.