Transactions: Recovery

Transcription

1 Transactions: Recovery Lecture 12 1 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Replication Background reading: Book Sections 15.1, 15.2, 25 2

2 Recovery Type of Crash Prevention Wrong data entry Constraints and Data cleaning Disk crashes Redundancy: e.g. RAID, archive Fire, theft, bankruptcy Buy insurance, Change jobs Most frequent System failures: e.g. power DATABASE RECOVERY 3 Reminder: Transactions Assumption: the database is composed of elements Usually 1 element = 1 block Can be smaller (=1 record) or larger (=1 relation) Assumption: each transaction reads/writes some elements Read/write = operation 4

3 Primitive Operations of Transactions X database object t local (program) variable READ(X,t) INPUT(X) t X X WRITE(X,t) OUTPUT(X) program (memory) memory buffer database 5 Read, Write, Input, Output READ(X,t) Read from memory buffer i.e. the value of X is read into t WRITE(X,t) Write into memory buffer i.e. the value of t is written into X INPUT(X) Read value from disk and put it into memory buf. OUTPUT(X) Write value from memory buf. to disk 6

4 Example READ(A,t); t := t*2; WRITE(A,t); READ(B,t); t := t*2; WRITE(B,t) Action t Mem A Mem B Disk A Disk B INPUT(A) READ(A,t) t:=t*2 WRITE(A,t) INPUT(B) READ(B,t) t:=t*2 WRITE(B,t) OUTPUT(A) OUTPUT(B) 7 System Failures Each transaction has internal state When system crashes, internal state is lost Don!t know which parts executed and which didn!t Remedy: use a log Sequence of records that describe database updates made by a transaction Typically, a log is a file

5 The Log An append-only file containing log records Existing log records are never updated/changed Mainly write operations are logged No need to log read operations why? Note: multiple transactions run concurrently, log records are interleaved After a system crash, use log to: Redo some transaction that didn!t commit Undo other transactions that didn!t commit Three kinds of logs: undo, redo, undo/redo 9 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Replication 10

6 Undo log (Write-ahead log) Update record must always be appended to the log before the database is updated: When update is happening in memory: 1. Write change to log to disk 2. Update database on disk Referred to as write-ahead feature 11 Undo-Logging Log records <START T> transaction T has begun <COMMIT T> T has committed <ABORT T> T has aborted <T,X,v> T has updated element X, and its old value was v 12

7 Undo-Logging Rules U1: If T modifies X, then <T,X,v> must be written to disk before X is output to disk Sometimes also called before image U2: If T commits, then <COMMIT T> must be written to disk only after all changes by T are output to disk Hence: OUTPUTs are done early, before the transaction commits 13 Action T Mem A Mem B Disk A Disk B Log <START T> READ(A,t) t:=t*2 WRITE(A,t) <T,A,> READ(B,t) t:=t*2 WRITE(B,t) <T,B,> OUTPUT(A) OUTPUT(B) <COMMIT T> 14

8 Why is it called Undo Log? Once a crash has occurred, write operations can be un-done i.e. the we can roll-back to the latest logged record = Recovery 15 Recovery with Undo Log crash <T6,X6,v6> <START T5> <START T4> <T1,X1,v1> <T5,X5,v5> <T4,X4,v4> <COMMIT T5> <T3,X3,v3> <T2,X2,v2> Question1: Which updates are undone? Question 2: How far back do we need to read in the log?

9 Recovery with Undo Log After system!s crash, run recovery manager Idea 1. Decide for each transaction T whether it is completed or not <START T>.<COMMIT T>. = yes <START T>.<ABORT T>. = yes <START T> = no Idea 2. Undo all modifications by incomplete transactions 17 Recovery with Undo Log Recovery manager: Read log from the end; cases: <COMMIT T>: mark T as completed <ABORT T>: mark T as completed <T,X,v>: if T is not completed then write X=v to disk (i.e. database) else ignore <START T>: ignore 1

10 Recovery with Undo Log Note: all undo commands are idempotent If we perform them a second time, no harm is done E.g. if there is a system crash during recovery, simply restart recovery from scratch 19 Recovery with Undo Log When do we stop reading the log? We cannot stop until we reach the beginning of the log file This is impractical Better idea: use checkpointing 20

11 Checkpointing Checkpoint the database periodically Stop accepting new transactions Wait until all current transactions complete Write a <CKPT> log record Resume transactions 21 Undo Recovery with Checkpointing During recovery, Can stop at first <CKPT> crash <T9,X9,v9> (all completed) <CKPT> <START T2> <START T3 <START T5> <START T4> <T1,X1,v1> <T5,X5,v5> <T4,X4,v4> <COMMIT T5> <T3,X3,v3> <T2,X2,v2> other transactions transactions T2,T3,T4,T5 22

12 Nonquiescent Checkpointing Problem with checkpointing: database freezes during checkpoint Would like to checkpoint while database is operational Idea: nonquiescent checkpointing Quiescent = being quiet, still, or at rest; inactive Non-quiescent = allowing transactions to be active 23 Nonquiescent Checkpointing Write a <START CKPT(T1,,Tk)> where T1,,Tk are all active transactions Continue normal operation When all of T1,,Tk have completed, write <END CKPT> 24

13 Undo Recovery with Nonquiescent Checkpointing During recovery, Can stop at first <CKPT> (provided an <END CKPT> is seen) Q: why do we need <END CKPT>? crash <START CKPT T4, T5, T6> <END CKPT> earlier transactions plus T4, T5, T6 T4, T5, T6, plus later transactions later transactions 25 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Replication 26

14 Redo Logging Log records <START T> = transaction T has begun <COMMIT T> = T has committed <ABORT T>= T has aborted <T,X,v>= T has updated element X, and its new value is v 27 Redo-Logging Rules R1: If T modifies X, then both <T,X,v> and <COMMIT T> must be written to disk before X is written to disk Hence: OUTPUTs are done late 2

15 Action T Mem A Mem B Disk A Disk B Log <START T> REAT(A,t) t:=t*2 WRITE(A,t) <T,A,> READ(B,t) t:=t*2 WRITE(B,t) <T,B,> <COMMIT T> OUTPUT(A) OUTPUT(B) 29 Recovery with Redo Log <START T1> <T1,X1,v1> <START T2> <T2, X2, v2> <START T3> <T1,X3,v3> <COMMIT T2> <T3,X4,v4> <T1,X5,v5> Question1: Which updates are redone? Question 2: How far back do we need to read in the log? crash 30

16 Recovery with Redo Log After system!s crash, run recovery manager Step 1. Decide for each transaction T whether it is completed or not <START T>.<COMMIT T>. = yes <START T>.<ABORT T>. = yes <START T> = no Step 2. Read log from the beginning, redo all updates of committed transactions 31 Nonquiescent Checkpointing Write a <START CKPT(T1,,Tk)> where T1,,Tk are all active transactions Flush to disk all blocks of committed transactions (dirty blocks), while continuing normal operation When all blocks have been written, write <END CKPT> 32

17 Redo Recovery with Nonquiescent Checkpointing Step 1: look for The last <END CKPT> Step 2: find corresponding <START CKPT > All OUTPUTs of T1 are known to be on disk crash <START T1> <COMMIT T1> <START T4> <START CKPT T4, T5, T6> <END CKPT> <START CKPT T9, T10> Step 3: redo from the earliest start of a transaction listed in <START CKPT >, i.e. T4, T5, T6 (transactions committed earlier can be ignored) 33 Comparison Undo/Redo Undo logging: OUTPUT must be done early If <COMMIT T> is seen, T definitely has written all its data to disk (hence, don!t need to redo) inefficient, since changes from different transactions cannot be "accumulated" in the memory buffer Redo logging OUTPUT must be done late If <COMMIT T> is not seen, T definitely has not written any of its data to disk (hence there is not dirty data on disk, no need to undo) inflexible, since changes cannot be written early to the disk and large transactions might require lots of memory buffer Would like more flexibility on when to OUTPUT: undo/redo logging (next) 34

18 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Replication 35 Undo/Redo Logging Log records, only one change <T,X,u,v>= T has updated element X, its old value was u, and its new value is v 36

19 Undo/Redo-Logging Rule UR1: If T modifies X, then <T,X,u,v> must be written to disk before X is written to disk Note: we are free to OUTPUT early or late (i.e. before or after <COMMIT T>) 37 Action T Mem A Mem B Disk A Disk B Log <START T> REAT(A,t) t:=t*2 WRITE(A,t) <T,A,,> READ(B,t) t:=t*2 WRITE(B,t) <T,B,,> OUTPUT(A) <COMMIT T> OUTPUT(B) 3

20 Recovery with Undo/Redo Log After system!s crash, run recovery manager Redo all committed transaction, topdown Undo all uncommitted transactions, bottom-up 39 Recovery with Undo/Redo Log Redo T2 <START T1> <T1,X1,u1,v1> <START T2> <T2, X2,u2,v2> <START T3> <T1,X3,u3,v3> <COMMIT T2> <T3,X4,u4,v4> <T1,X5,u5,v5> Undo T1, T3 crash 40

21 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Replication 41 Replication One way to increase database availability Multiple copies of the same data Log might be replicated Mainly used in distributed databases Several database servers Used to increase read-performance Data locality [explain in class] Trade-off for write performance 42

22 Distributed transactions Two phase commit protocol (2PC) Phase 1: co-ordinator asks for commit Commit request Phase 2: Commit or Abort (requires a roll-back) 43 Synchronous / Asynchronous Replication One transaction is done on multiple database servers How to update data? Eager vs. lazy [Details explained in class] 44

23 Conclusion Logging of database used for recovery Has a certain performance drawback Check-pointing to avoid undo/redo entire log information Data replication is important for availability and increased read performance 45