Databases usually use logs to implement transactions. The common ones are undo log, redo log, and undo/redo log can guarantee transaction characteristics. Here are mainly atomicity and durability, that is, transaction-related operations, either all or not. And the modified data can be persisted.
Assuming that the database is in operation, the logs are recorded according to the following conventions:
1. When the transaction begins, record START T 2. When the transaction is modified, record (T, x, v), indicating that the transaction T operates on the object x, and the value of x is v 3. At the end of the transaction, record COMMIT T
Principle of undo log
The undo log is to roll back all the transactions without COMMIT to the state before the transaction started. When the system crashes, some transactions may not have a COMMIT. When the system recovers, these transactions without a COMMIT need to be rolled back with the help of the undo log.
When using undo log, it is required to:
1. When recording the modification log (redo log), v in (T, x, v) is the value of x before modification, so that this log can be used to roll back; 2. After the transaction is committed, the COMMIT T log must be written after all the modifications of the transaction (including the recorded modification log) are persistent; in this way, it can be ensured that when the crash is recovered, all the modifications of the transaction that have been COMMITed have been persistent. No rollback is required.
Transaction execution order when using undo log
1. Record START T 2. Record the old value of the record that needs to be modified (requires persistence) 3. Update the database according to the needs of the transaction (requires persistence) 4. RECORD COMMIT T
Use undo log for crash rollback
1. Scan the log to find all transactions that have START and have not yet COMMIT. 2. For all uncommited logs, rollback is performed according to the redo log.
If there are many database accesses, the log volume will also be large, and the workload of rollback will be very large when recovering from downtime. In order to speed up the rollback, the checkpoint mechanism can be used to speed up the rollback.
- Record checkpoint_start (T1,T2…Tn) in the log (Tx represents a transaction that has not yet been COMMITed when checkpointing)
- Wait for all ongoing transactions (T1~Tn) to COMMIT
- Log checkpoint_end in the log
Rollback with checkpoint
Scan the undo log from back to front 1. If checkpoint_start is encountered first, all uncommitted transactions after checkpoint_start will be rolled back; 2. If checkpoint_end is encountered first, all uncommitted transactions after the previous checkpoint_start will be rolled back; (in the process of checkpoint, there may be many new transactions START or COMMIT).
Using undo log, when writing COMMIT log, it is required that all modifications of redo log and transaction must be persisted, which usually affects performance.
Principle of redo log
Redo log refers to redoing the transaction that has been committed when replaying the log. For the transaction without commit, it is processed according to abort, and no operation is performed.
When using redo log, it is required:
1. When recording the redo log, v in (T, x, v) must be the modified value of x, otherwise the transaction that has been COMMITed cannot be recovered through the redo log. 2. Before writing the COMMIT T log, the modification of the transaction cannot be persisted. Otherwise, during recovery, the data may have been modified for the operation that has not been COMMITed, but replaying the redo log will not do anything to the transaction, so the transaction cannot be guaranteed. atomicity.
Transaction execution order when using redo log
1. Record START T 2. The record transaction needs to modify the new value of the record (requires persistence) 3. Record COMMIT T (requires persistence) 4. Write transaction-related modifications to the database
Redo transactions using redo log
1. Scan the log to find all transactions that have been COMMITed; 2. For the transaction that has been COMMITed, redo the transaction according to the redo log;
Using checkpoints in logs
1. Record checkpoint_start (T1,T2...Tn) in the log (Tx represents the log that has not yet been COMMITed when doing checkpoint) 2. Persist the changes of all committed transactions; 3. Record checkpoint_end in the log
Speed up recovery based on checkpoints
Scan redo log from back to front 1，如果先遇到checkpoint_start, 则把T1~Tn以及checkpoint_start之后的所有已经COMMIT的事务进行重做； 2. 如果先遇到checkpoint_end, 则T1~Tn以及前一个checkpoint_start之后所有已经COMMIT的事务进行重做；
与undo log类似，在使用时对持久化以及事务操作顺序的要求都比较高，可以将两者结合起来使用，在恢复时，对于已经COMMIT的事务使用redo log进行重做，对于没有COMMIT的事务，使用undo log进行回滚。redo/undo log结合起来使用时，要求同时记录操作修改前和修改后的值，如（T，x，v，w），v为x修改前的值，w为x修改后的值，具体操作顺序为：
1. 记录START T 2. 记录修改日志（T，x，v，w）（要求持久化，其中v用于undo，w用于redo） 3. 更新数据库 4. 记录 COMMIT T
4和3的操作顺序没有严格要求，并且都不要求持久化；因为如果宕机时4已经持久化，则恢复时可通过redo log来重做；如果宕机时4未持久化，则恢复时可通过undo log来回滚；在处理checkpoint时，可采用与redo log相同的处理方式。
http://blog.chinaunix.net/uid-20196318-id-3812190.html