1. 1 Failure Recovery Checkpointing Undo/Redo Logging Source: slides by Hector Garcia-Molina

2. 2 Recovery is very, very SLOW ! Redo log: FirstT1 wrote A,BLast RecordCommitted a year agoRecord (1 year ago)--> STILL, Need to redo after crash!!... Crash

3. 3 Solution: Checkpoint (simple version) Periodically: (1) Do not accept new transactions (2) Wait until all transactions finish (3) Flush all log records to disk (log) (4) Flush all buffers to disk (DB) (do not discard buffers) (5) Write “checkpoint” record on disk (log) (6) Resume transaction processing

4. 4 Example: what to do at recovery? Redo log (disk): Checkpoint Crash... Start from last checkpoint and move forward in the log file redoing updates for committed transactions.

5. 5 Key drawbacks: uUndo logging: data must be written to disk immediately after a transaction finishes, which can increase number of disk I/O's uRedo logging: need to keep all modified blocks in memory until transaction commits and log is flushed, which can increase the number of buffers required

6. 6 Solution: undo/redo logging! Update record in the log has the format

7. 7 Rules uBuffer containing X can be flushed to disk either before or after T commits uLog record must be flushed to disk before corresponding updated buffer is (WAL)

8. 8 Recovery with Undo/Redo Logging 1.Redo all committed transactions in order from earliest to latest  handles committed transactions with some changes not yet on disk 2.Undo all incomplete transactions in order from latest to earliest  handles uncommitted transactions with some chnages already on disk

9. 9 Non-quiescent Checkpoint uSimple checkpointing scheme requires system to "quiesce" (reach a point with no active transactions), ensured by preventing new transactions from starting for a while uAvoid this behavior with non-quiescent checkpointing: wwrite a "start checkpoint" record to the log wlater write an "end checkpoint" record to the log uDetails vary depending on whether undo, redo, or undo/redo logging

10. 10 Non-quiescent Checkpoint for Undo/Redo uwrite "start checkpoint" listing all active transactions to log uflush log to disk uwrite to disk all dirty buffers (contain a changed DB element), whether or not transaction has committed wthis implies some log records may need to be written to disk (WAL) uwrite "end checkpoint" to log uflush log to disk

11. 11 Non-quiescent checkpoint for undo/redo L O G for undodirty buffer pool pages flushed start ckpt active T's: T1,T2,... end ckpt...

12. 12 Recovery process: uBackwards pass (end of log  latest checkpoint start) wconstruct set S of committed transactions wundo actions of transactions not in S uUndo pending transactions wfollow undo chains for transactions in (checkpoint active list) - S uForward pass (latest checkpoint start  end of log) wredo actions of S transactions backward pass forward pass start check- point

13. 13 Examples what to do at recovery time? no T1 commit L O G T 1,- a... Ckpt T 1... Ckpt end... T1-bT1-b  Undo T 1 (undo a,b)

14. 14 Example LOGLOG... T1aT1a T1bT1b T1cT1c T 1 cmt... ckpt- end ckpt-s T 1  Redo T1: (redo b,c)

15. 15 Real world actions E.g., dispense cash at ATM Ti = a 1 a 2 …... a j …... a n $

16. 16 Solution (1) execute real-world actions after commit (2) try to make idempotent

17. 17 Media failure (loss of non-volatile storage) A: 16 Solution: Make copies of data!

18. 18 Example 1 Triple modular redundancy uKeep 3 copies on separate disks uOutput(X) --> three outputs uInput(X) --> three inputs + vote X1X2 X3

19. 19 Example 2 Redundant writes, Single reads uKeep N copies on separate disks uOutput(X) --> N outputs uInput(X) --> Input one copy - if ok, done - else try another one  Assumes bad data can be detected

20. 20 Example 3: DB Dump + Log backup database active database log If active database is lost, – restore active database from backup – bring up-to-date using redo entries in log

21. 21 When can log be discarded? check- point db dump last needed undo not needed for media recovery not needed for undo after system failure not needed for redo after system failure log time

22. 22 Summary uConsistency of data uOne source of problems: failures - Logging - Redundancy uAnother source of problems: Data Sharing..... next