ARIES Recovery 2020-06-02

https://blog.csdn.net/weixin_34123613/article/details/92562478

在看到上面的文章后总结一下自己的看法
该算法在1992的时候被提出，几乎所有db都用ARIES来做recovery，或着是它的变种，可见其地位。ARIES的核心思想如下。

• Write-Ahead Logging

  在内存中的所有修改，都要以log的形式在data之前刷到磁盘
  1.所有的日志记录必须在它对应的行数据页被写入磁盘之前写入稳定存储（保证Atomicity）。
  2.所有的日志记录必须在其所属的事务提交（commit）之前写入稳定存储（保证Durability）。
  commit之前将log写入持久化存储（落盘），保证只要commit的事务都在持久化log中存在，没有commit的会做undo操作，清除对于可能落盘的影响

• Redo

  重启的时候，对所有已提交的事务做redo

• undo

  重启的时候，对所有未提交的事务做undo

ARIES的前提是该 数据库 是STEAL + NO-FORSE。否则事情就简单了，不需要用ARIES这么复杂。

• STEAl

  允许未提交的事务将dirty data刷到磁盘
  使用了STEAL 就需要 UNDO，可能在系统崩溃前有的数据就已经落盘，但系统崩溃时该事务还未提交，需要UNDO将这个事务的影响去除，需注意恢复只恢复已经COMIIT的事务。

• NO-FORSE

  在事务提交之前，不强制将所有dirty data刷到磁盘
  使用NO_Force就需要REDO，提交之后也可能有的数据还在内存之中，未落盘系统就崩溃了。
  可见最简单的实现当然是NO-STEAL + FORSE，也就不需要redo和undo了，但是性能低。而且当机器的内存不足以支撑事务所需要的大小时，也不可行。

在系统恢复阶段 Aries分为三个步骤：
Analysis阶段：
首先，根据存储在磁盘上的master record找到最近的checkpoint位置，同时获取到该点时间Transaction表和dirty Page Table，Transaction表记录未提交的数据，dirty Page Table存之前的操作，PageId表示操作的页面编号，LSN可以看作一个唯一性标识符，记录每一个操作。
分析阶段所做的事情就是从检查点开始图中从4开始全部跑一边，从4到10，重现一下崩溃前数据库当中事务的操作。

image.png

Analysis最后阶段，transaction表中只剩下崩溃前没有COMMIT的事务，留作UNDO时候操作。
Dirty Page Table中保存的都是已经完成了的操作，但不知道是否落盘的数据，REDO阶段就是对未落盘的数据重新操作一遍。

image.png

可以看到Dirty Page Table中第一条P1找到了RecLSN为1 然后磁盘上（Disk）也是1所以表示该条数据落盘了.就无需操作。

image.png

然后从一到十像原先一样操作 期间会修改Dirty Page Table的内容，确认已经落盘的会消除掉Dirty Page Table中的内容 ，新来的会添加进Dirty Page Table中。

image.png

这样整个REDO就算完成了，会对右边绿色的全部REDO。

Undo阶段：undo阶段就是将Transaction表中的残存的事务做一遍undo操作 保证这些事务即使落盘了，也要被清除掉，保证不影响后面的。方向从后到前 和之前两个阶段不同。

分析阶段：
1.决定从哪里开始REDO
2.决定哪些页可能是存在脏数据
3.决定哪些事务并没有在CRASH前COMMIT（需要被UNDO）

Logical Undo

Page-oriented REDO
REDO操作包含一整个单页 这个页也被记录在log 记录中

Fuzzy checkpoint
inexpensive checkpoint
相对普通的checkpoint
CLR compensation log record（UNDO的时候用）
second crash 问题