数据库recovery的一些基本概念

1. REDO, UNDO, checkpoint

Write Ahead Logging (WAL) is a standard approach to transaction logging. Briefly, WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged - that is, when log records have been flushed to permanent storage. When we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages will first be redone from the log records (this is roll-forward recovery, also known as REDO) and then changes made by uncommitted transactions will be removed from the data pages (roll-backward recovery - UNDO). [1]
已commit但未apply的, 执行REDO, 而由 未commit的事务 的修改 需要执行UNDO.

------------------

Its transaction recovery log contains log records of the following form:
<txnId, objectId, beforeValue, afterValue>

有如下log:

1 <T1 BEGIN>
2 <T1, X, 1, 2>
3 <T2 BEGIN>
4 <T3 BEGIN>
5 <T2, Y, 1, 2>
6 <T2 COMMIT>
7 <T1, Y, 2, 3>
8 <T3, Z, 1, 2>
9 <CHECKPOINT>
10 <T1, X, 2, 3>
11 <T1, Y, 3, 4>
12 <T3, Z, 2, 3>
13 <T3 COMMIT>
14 <T1, Z, 3, 4>

Assume that the DBMS flushes all dirty pages when the recovery process finishes. What are the values of X, Y, and Z after the DBMS recovers the state of the database ?
答: X=1, Y=2, Z=3
checkpoint 并不暗示着commit, 本例中没有对T1进行commit,
所以, x维持旧值, 为1.
Y的话, 看 6 之前, 为2.
Z的话, 看 13 之前, 为3.

---

While doing deferred updates with WAL, if we prevent the DBMS from writing dirty records to disk until the transaction commits, then we do not need to store their original values. fong:由于不是steal, 不commit就不会回写, 这样, 就不需要undo, 也就不需要记录旧值.

The undo operation not only restores the data items to their old value, but also writes log records to record the updates performed as part of the undo process. These log records are special redo-only log records, since they do not need to contain the old-value of the updated data item. [2] 之所以称为 redo-only log, 在recovery时, 无需进行undo操作. 比如说,
T1, X, 1, 2 (格式为 事务id, key, 旧值1, 新值2)
没有commit, 然后掉电(第1回)
重启后, 执行recovery, 对于T1, 生成
CLR undo T1 ....
然后还有其他log要recovery, 结果突然掉电(第2回)了,
重启后, 执行recovery, 看到有CLR undo T1 ....
对于这条记录是不会 undo such an undo operation, 所以,是 redo-only log.

2. no-steal, force policy

One might expect that transactions would force-output all modified blocks to disk when they commit. Such a policy is called the force policy. The alternative, the no-force policy, allows a transaction to commit even if it has modified some blocks that have not yet been written back to disk. [2]
如果是the force policy, 那么, 当commit时, 强制要求所有修改过的块都已经写入磁盘. 而no-force策略, 则不要求已写入磁盘, 就可以commit.

one might expect that blocks modified by a transaction that is still active should not be written to disk. This policy is called the no-steal policy. The alternative, the steal policy, allows the system to write modified blocks to disk even if the transactions that made those modifications have not all committed. [2]

3. 参考资料

1. https://www.postgresql.org/docs/7.3/static/wal.html
2. Database System Concepts 6th edition

本文地址: https://awakening-fong.github.io/posts/database/db_recovery_concept

转载请注明出处: https://awakening-fong.github.io