简介
ARIES 是 algorithm for recovery and isolation exploiting semantics 的简称，诞生于92 年。
我打算写的是读的 https://zhuanlan.zhihu.com/p/143173278 的读后感，这篇文章的作者读的是 http://www.redbook.io/ 里提到的论文https://web.stanford.edu/class/cs345d-01/rl/aries.pdf。
好，原始资料我已经放这了，读者大可不必看我这三手资料，可以去直接读原文，不过我还是想稍微写两句，加深自己的理解。
正文
我看这个的原因就是：为什么关系型数据库是 crash safe 的？
昨天尝试写了一下我的理解，后来发现有一些地方很不确定，决定不写了。我只对 mysql 稍微有一点了解，但不知道这个机制在 mysql 中是不是这样的，大家还是自己看原文吧，就是知乎那一篇。
算了，我还是简单描述一下我的理解：
库有 checkpoint，之前的日志全被刷盘了，之后的不一定被刷盘了；
写日志时会同时写 redo、undo，事务提交后会 redo 记录 end，证明事务提交了；如果没有提交则需要先把 redo log 全部执行完，然后再执行 undo log。
然后有一点，就是 undo 是逻辑日志；它在执行时，会生成物理日志，叫 clr，补偿日志记录，这是一种 redo，它会被记录到 redo log。
也就是说你在 rollback 时，如果数据库挂了，有一种机制可以让你从上次 rollback 的位置开始继续 rollback，这个机制就是靠 clr 实现的；做法就是从check pioint 开始执行 redo log，它执行每个 redo log 时，判断 log 的 lsn 是不是比页面的 lsn 大，如果大，说明这个页面没有被 redo 过，则可以执行redo，否则说明已经被 redo 过了，跳过；如果碰到 clr 日志了，这是个 rollback 的 redo log，也执行相同的判断，看是不是已经 undo 过了
然后 undo 时，它是倒着执行：
1->2, 2->3 生成的 undo log 是：2->1; 3->2，然后执行 redo log 时生成的 clr 是这样的：
log1 log2 log2’ log1’
log2’ 的 prevlsn 指向 log1，这样如果故障恢复来到这个 log2’，他不会再执行 undo log2（因为他自己就是 log2），而是指向上一条 undo log1
由于是倒着执行，所以 clr 顺序和 undo log 顺序是相反的
undo 时根据指针不停地往前找，直到找到事务开始时停止；期间不停地执行 undo log，生成 clr（一种redo log）
如果突然间又挂了，还是重复上面的步骤：先执行 redo log，再继续执行 undo log；在这次挂之前 undo 过的日志会被跳过。
尽力了，就讲到这把。
|