mysql数据库undo日志恢复_数据库日志与故障恢复

现在的机子开数据库也很慢，仿佛跟90年代的机子没什么区别，其中一个原因就是刚启动时数据库要用日志进行一致性检查与恢复。一致性(Consistence)：事务ACID四特性之一，如A转100元给B，这个事务完成后必须是A-100，B+100。ACID分别指Atomicity, Consistency, Isolation和Durability。

一致性检查与恢复时，存在大量的磁盘IO，近些年机械硬盘读写速度并没有很大提升。这时，如果将日志和data存在SSD上，会比存在机械硬盘上速度快，因为一致性检查时恢复毕竟占少数，更多是从外存读数据到内存，SSD读快的优势立马就显现出来了~

经常有朋友i7的处理器仍卡的要死，加了一块SSD后就变得飞起，也是因为对磁盘IO速度的需求大于对CPU性能的要求。制图、渲染视频的同学应该感触颇深，因为图像文件通常很大，内存不足以放下，会产生大量磁盘IO，这种需求下不仅要看GPU性能，还要增大内存，并考虑在SSD上存在work file。

1. 为什么要进行一致性检查？

首先，我们不能接受不一致的出现，比如你往卡里打了1亿元，隔天一查发现没有；其次，系统可能是从某个未完成的事务开始的(如断电、系统崩了导致)，这时就需要日志。事务中断在中间某个操作(crush)，要作recovery，这即是一致性要求，也是原子性要求，事务的操作，要么不做，要么全做(atomicity)。

2. 什么时候产生日志

导致不一致的原因是内存更新的data还没来及写到磁盘，设计日志，我们需要先分析可能破坏一致性的事务操作：

定义1 事务的原语操作

input(x)：读x的磁盘块进内存

output(x)：写x内存块到磁盘

read(x,t)：内存中，读x给t。t是次要数据，不重要

write(x,t)：内存中，写t给x

可以看出，只有write(x)才可能导致不一致，需要产生日志。

3. 三种日志恢复机制

三种日志恢复机制：Undo日志、Redo日志、Undo/Redo日志。先给出一个三种日志都必须满足的一个定理：

定理1 先写日志(Write Ahead Logging，WAL)：ouput(x)将x写回磁盘前，必须先将对应日志写回磁盘。

3.1 Undo日志

(1)write(x)产生，其中T表哪个事务

(2)output(x)前先将 flush到磁盘(WAL先写日志)

(3)output()完后再将日志写到磁盘

表事务开始，表事务完成。

恢复算法：

e.g.1

T1在磁盘中无，撤销到前的一致状态。

e.g.2 一个很可惜的例子

磁盘中仍无，全要撤回。

3.2 Redo日志

(1)write(x)产生

(2)同样，output(x)前先将 flush到磁盘(WAL先写日志)

(3)不同于Undo日志：output前先产生并写到磁盘，即和前面的 一起写到磁盘

恢复算法：

3.3 Undo日志 vs. Redo日志

所以，Undo可以write()一个output一个，内存代价小

Redo必须全write()后，再output，内存代价高

但Undo是恢复old values，恢复代价更高，如e.g.2

综合Undo、Redo日志，便产生了Undo/Redo日志。

3.4 Undo/Redo日志

(1)write(x)产生日志，其中v是old value，w是new value

(2)同样，WAL先写日志，output前，先flush所有的日志

(3)output前(同Undo)，或所有write后(同Redo)二选一

恢复算法：先Redo的话，后面的Undo会破坏Redo恢复的new value。

e.g.3

References