Framing
- Recovery is called "the third hardest lecture of the semester"; losing data is unacceptable, which is why application programmers should not write their own recovery components and should rely on a battle-hardened DBMS instead (
0:27). - Last lecture covered the write-ahead log (WAL) built during normal processing: transaction ID, modified object, before value, after value (
1:51). - This lecture covers the other half: after a crash or unclean shutdown, how to use that WAL to put the database back into the correct state and preserve atomicity, consistency and durability (
1:51). - Deliberate methodology: present the basic, conservative, correct version first; optimizations come afterwards (
2:40,3:02).
Buffer pool policy assumed: STEAL + NO-FORCE
- STEAL — dirty pages of uncommitted transactions may be flushed out of the buffer pool, but only if the corresponding WAL records were written first (
3:23). - NO-FORCE — a committing transaction is not required to flush its dirty pages; only its log records must be written (
3:23).
The target scenario
Three transactions, then a crash (3:23):
| Transaction | Activity | Required post-recovery state |
|---|---|---|
| T1 | write, then commit | changes must be durable — the outside world was told it committed (4:02) |
| T2 | write, then abort | no changes visible (4:20) |
| T3 | read, write, crash | no partial updates visible (4:02) |
Why ARIES
- ARIES is the canonical definition of how to make a database safely recoverable; the paper dates from ~1992 and runs about 70 pages of methodical case analysis (
5:08). - Recovery protocols existed before ARIES, but they optimized for specific situations and missed corner cases (
5:08). - The defining capability ARIES adds: recovering correctly even if the system crashes during recovery (
5:38,5:53). - Real systems (PostgreSQL included) do not implement ARIES literally — e.g. most do not flush all pages when recovery finishes — but they are "close enough" (
4:46,5:08).