select+update引发的一些思考（3）再探日志

提要

cmu440(12) Fault Tolerance, Logging and recovery 3
之前cmu440课程上讲的有关数据库里WAL技术，没有仔细探讨细节，比较懵懂。好像就记住了几个数据流向，有个什么redo、undo之类的。

通过本篇文章想稍微了解下恢复过程，commit及rollback
解决下前面的问题
q：commit与数据更新的联系，是不是commit了数据库才更新数据，还是说事务中的每个操作执行完后，数据库就会更新

WAL（保证原子性）

英文全称是Write Ahead Logging，预先写入日志，在数据真正持久化之前先把变更写入 log 的方式。

假设一个程序在执行某些操作的过程中机器掉电了。在重新启动时，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了WAL，程序就可以检查log文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。

数据会在哪些地方出现

1. 内存：某次操作，我们取了数据库某表格中的数据，这个数据会在内存中缓存一些时间。
2. 磁盘：真正存储数据库文件

我们操作数据库里的数据首先改的是内存里的数据，当数据在内存里的缓冲区已满或者其他条件，这些数据才会写入到磁盘。真正修改磁盘数据库文件跟COMMIT的时机无关
那COMMIT/ABORT是怎么来控制事务的提交和回滚

日志恢复

日志出现位置

日志在内存里也是有缓存的（log buffer），磁盘上的日志文件（log file）
log file一般是追加内容，可以认为是顺序写，顺序写的磁盘IO开销要小于随机写。

undo、redo

undo用于回滚的日志（old value）、redo用于提交的日志（new value）

例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为，Redo日志为。

整个数据操作的过程

例如：数据库中A=1,B=2,需要update A=3,B=4
1.事务开始
2.记录A=1到undo log
3.修改A=3
4.记录A=3到redo log
5.记录B=2到undo log
6.修改B=4
7.记录B=4到redo log
8.将redo log顺序写入磁盘
9.事务提交
redo日志进行持久化写入磁盘，之后再才是持久化数据的修改。这就是WAL的本义

崩溃恢复

如果整个事务的执行中发生系统崩溃或者断电了。
如果发生在事务提交之后，已经持久化redo日志，则完成数据的更新；
如果发生在写入磁盘之前，则undo回滚；
如果发生在8 redo持久化的过程，则看redo log file 是否有结束标志（COMMIT或者END），如果没有结束标志，则回滚

q：undo去哪了？不应该也持久化吗？

Undo和Redo Log需要关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，而不用在redo log之前写入磁盘了。

性能相关

除了带来事务一致性的保证，由于只需要把操作写到 WAL 里就可以认为操作完成而无需等待持久化真正的数据库变更完成就可以返回，数据库操作的效率也得到了一些提升。你可能要问了写 log 也要持久化呀那里性能提升了？窍门在于 WAL 是顺序写入的一直在文件末尾 append，而持久化数据库的数据是一个随机写入操作，顺序写会节省大量的磁盘悬臂来回寻址的过程，效率要高好几个量级。

检查点checkpoint

checkpoint是为了定期将db buffer的内容刷新到data file。当遇到内存不足、db buffer已满等情况时，需要将db buffer中的内容/部分内容（特别是脏数据）转储到data file中。在转储时，会记录checkpoint发生的”时刻“。在故障回复时候，只需要redo/undo最近的一次checkpoint之后的操作。
还没有commit，数据库就有可能已经做了持久化，在发生故障时通过undo回滚

参考

预写式日志-维基百科
数据库如何用 WAL 保证事务一致性？ [转]MySQL日志——Undo | Redo
理解数据库中的undo日志、redo日志、检查点
数据库正在操作时突然断电，为什么可以用日志恢复？既然断电了，还怎么能写入日志？