| Advanced Topics in Computer Systems |
|
| Joe Hellerstein & Timothy Roscoe |
|
Intro to Recovery: Haerder & Reuter
Recall that Recovery guarantees Atomicity and Durability.
Paper outlines issues and options for recovery.
Types of Failure: a la Gray/Reuter's model of system behavior and what
can go wrong
-
Transaction failure
-
System failure
-
Media failure
Views of the DB
-
current DB: correct running scenario. disk + buf pool
-
materialized DB: state after a crash. all "propagated" pages (pointed
to by a level of indirection) on disk
-
physical DB: state after a crash, including unpropagated pages (e.g. uninstalled
shadows)
-
direct page allocation (e.g. ARIES): materialized = physical
-
indirect page allocation (e.g. System R's shadow pages, versioning
schemes like POSTGRES): not the case!
Overwriting Options
-
ATOMIC: a transaction' updates become visible in materialized
DB all at once. System R' "shadow paging" scheme did this. Pros/cons?
-
NOT ATOMIC: parts of transactions can be in materialized DB
without other parts. Pros/cons?
Buffer Pool Eviction Options
-
STEAL: a transaction' updates may be flushed from the buffer pool
at arbitrary times, since another transaction is allowed to "steal" a buffer
pool frame. Pros/cons?
-
NO STEAL: all of a transaction' updates remain in the buffer pool
until commit time. Pros/cons?
-
FORCE: at commit time, all modified pages are forced (flushed) to
disk. Pros/cons?
-
NO FORCE: modified pages may remain in the buffer pool even after
commit. Pros/cons?
Log Data
-
Depending on the option chosen above, need some of UNDO and REDO
log
records to support recovery.
-
Log records can be logical (e.g. "inserted tuple ('Gore', 2001) into relation
Presidents"), or physical (e.g. "byte 74 of page 255 used to be `r' and
now is `s'"). Pros/cons of each?
-
Physical log records can be before/after images of pages (subpages), or
various forms of diffs. Beware of idempotency issues! (when
would this arise?)
Checkpoints
-
In order to speed up recovery, it' nice to have "checkpoint" records that
limit the amout of log that needs to be processed during recovery. It can
be tricky to do efficient checkpoints.
State of the Art (as exemplified by ARIES)
-
Focus on speed and generality, rather than simplicity.
-
Direct page allocation, NOT ATOMIC, STEAL, NO FORCE. This allows the buffer
manager to make intelligent (i.e. efficient) decisions about when and what
to flush to disk.
-
Log data is "physiological" -- i.e. some is physical (e.g. B-tree page splits),
and some is logical (heap-tuple insertions.)
-
Many more details in ARIES paper!
Keep this taxonomy in mind as you read papers on transaction systems!
E.g. how does System R, LRVM, POSTGRES fit in here?
- System R: Indirect, ATOMIC, STEAL, NO FORCE
- LRVM: Direct, NOT ATOMIC, NO STEAL, NO FORCE
- POSTGRES: Indirect, ATOMIC, STEAL, FORCE
- Modern DBMSs (ARIES): Direct, NOT ATOMIC, STEAL, NO FORCE
Effects on performance/scalability? On complexity?