高级数据库十三：日志协议

阳光穿透心脏的1/2处 2022-06-02 02:38 217阅读 0赞

# Logging Protocols #

## Logging Schemes ##

### 恢复算法 ###

日志一般与系统恢复有关，恢复算法是确保数据库一致性、原子性和持久性（尽管事务失败）的技术。

恢复算法有两个部分：

*  正常txn处理期间的操作，以确保DBMS可以从故障中恢复。
 *  无法将数据库恢复到确保原子性，一致性和持久性的状态之后的操作。

### 日志方案 ###

有两种日志方案

1.  物理日志记录  
    
    
     *  记录对数据库中的特定记录所做的更改。
     *  示例：存储查询更改的属性的原始值和值之后。
2.  逻辑记录  
    
    
     *  记录txns执行的高级操作。
     *  示例：由txn调用的UPDATE，DELETE和INSERT查询；SQL语句的记录。

逻辑日志记录在每个日志记录中写入较少的数据，物理日志记录则需要写得更多。原因就是大家可以想一下，你随便写一个SQL语句，就会干一大堆事情，逻辑日志记录的是SQL语句，物理日志记录的是干的事情。

但是如果用的是并发的事务，我们就很难用逻辑日志来实现恢复。

*  难以确定数据库的哪些部分可能在崩溃之前被查询修改过。
 *  还需要更长时间才能恢复，因为我们必须重新执行每个事务。

## Crash Course on ARIES ##

### 面向磁盘的日志记录和恢复 ###

面向磁盘的DBMS中的物理日志记录和恢复的“黄金标准”是[ARIES：Algorithms for Recovery and Isolation Exploiting Semantics][ARIES_Algorithms for Recovery and Isolation Exploiting Semantics]（恢复和隔离利用语义的算法）。

依赖STEAL和NO-FORCE缓冲池管理策略。

> STEAL：事务的更新可以在任意时间从缓冲池中刷新到硬盘。  
> NO STEAL：事务的所有更新都保留在缓冲池中，直到事务提交的时候。  
> FORCE：在提交时，所有修改的页面都被强制（刷新）到磁盘。  
> NO FORCE：即使在提交之后，修改的页面仍可能保留在缓冲池中。

### 主要思想 ###

1.  预写日志：  
    
    
     *  在将数据库更改写入磁盘之前，在稳定存储器上记录任何更改。
2.  在Redo期间重复历史记录：  
    
    
     *  在重新启动时，追溯操作并将数据库恢复到崩溃前的确切状态。
3.  在Undo过程中记录更改：  
    
    
     *  记录撤销操作以记录，以确保在重复故障的情况下操作不会重复。

维护事务运行时候的日志，并在任务commit之后，将其持久化保持。

维护checkpoint，包括现在还在运行的事务、现在修改的页等。

维护日志文件的顺序。用全局唯一的log sequence number (LSN) 去标识。之所以ARIES不需要TID而是需要LSN的原因是，两个事物可能更新相同的两个表，但是是不同的顺序，（如，对于page1是T1->T2，对于page2是T2->T1）。那么在redo的时候，就不能按照TID顺序执行，而是要按照每个页面真正被操作的顺序。

每个页面都包含一个pageLSN，表示最近更新该页面的LSN。  
DBMS跟踪写入磁盘的最大日志记录（flushedLSN），通常就是现在的最尾巴的记录。

硬盘中存储的Master Record记录的是上一个checkpoint的位置。

对于我要写的页面，DBMS必须至少更新日志到pageLSNi≤ flushedLSN的点。是因为我们需要等到flushedLSN大于pageLSN的时候，才表面了这个page的更新完全被接受了。

![15146703819666.jpg][]

### 恢复阶段 ###

1.  查看WAL去确认当系统宕机的时候，缓冲区中的脏数据和正在运行的事务。
2.  重复从某个合适的点开始的所有操作。从上到下地一条一条执行。
3.  将在宕机之前没有提交的事务操作全部撤销。从下往上地将abort的事务操作进行撤销。

效率低下。

### GROUP COMMIT ###

将来自多个事务的日志记录一起批处理，并使用一个fsync将它们一起刷新：超时后或缓冲区满时记录将被刷新。

这样可以分摊几个事务的I/O成本。

### EARLY LOCK RELEASE ###

事务最终commit的成功的标志是将数据写入磁盘，那么在commit的过程中可能需要等待，这个时候也需要保留着锁。

事务的锁可以在其提交记录写入磁盘之前释放，只要在成为持久性之前它不返回结果给客户端。

因为如果事务B读取了正在等待的更新的事务A的数据，并将之返回给客户，然后事务A挂了，事务B就无法恢复了，这就不具有recoverability。

所以依赖于在前面提价的事务的事务还是必须等待它依赖的那些事务的日志记录写回磁盘。

## IN-MEMORY DATABASE RECOVERY ##

恢复比较容易一些，因为在恢复期间，DBMS不必担心追踪在缓冲区中的崩溃时候的脏页面。

内存中的DBMS也不需要存储撤消记录，因为当事务commit之后，就直接更新到磁盘，不可能回滚。

但是DBMS仍然受到非易失性存储的慢同步时间的阻碍。

### SILO ###

[SiloR][]使用我们之前讨论的基于epoch的OCC。

它通过并行处理日志，检查点和恢复的各个方面来实现高性能。

DBMS假定每个CPU socket有一个存储设备。

*  为每个设备分配一个日志线程。
 *  工作线程按CPU socket分组。

当工作线程执行一个事务时，它会创建新的日志记录，其中包含写入数据库的值（即REDO）。

每个日志线程帮助其工作线程维护一个日志缓冲区池。

当工作线程的缓冲区已满时，会将其返回到记录器线程以刷新到磁盘并尝试获取新的缓冲区。

日志线程将缓冲区写入磁盘文件

*  100个epoch后，它创建一个新的文件。
 *  旧文件被重命名，并用标记指示它包含的记录的最大epoch。

日志记录格式：

*  修改记录的txn的Id（TID）。
 *  一组价值日志三元组（Table，Key，Value）。
 *  属性+值对的列表。

![15146731885656.jpg][]

具体的步骤过程可以看看课件。我觉得这一段我也迷迷糊糊的，但是大致能够理解过程。

一个特殊的日志线程跟踪当前的持久pepoch

*  特殊的日志文件，保持所有日志线程的最高持久epoch。
 *  在epoch e中执行的事务只能在pepoch对非易失性存储持久时，才能释放其结果。

![15146739509580.jpg][]

pepoch=200表示epoch>200的事务都没有commit。

### RECOVERY PROTOCOL ###

1.  阶段1：加载上一个检查点  
    
    
     *  安装保存在数据库中的最后一个检查点的内容。
     *  所有索引都必须重建。
2.  阶段2：redo日志  
    
    
     *  以相反顺序处理日志以维护每个元组的最新版本。

首先检查pepoch文件以确定最近的持久化epoch。

*  忽略pepoch后的任何日志记录。

日志文件从最新到最旧处理。

*  属性值记录能够以任何顺序重做。
 *  对于每个日志记录，线程检查元组是否已经存在。  
    
    
     *  如果不是，则使用该值创建。
     *  如果是，则只有在日志TID比元组的TID更新时，才会覆盖元组的值。

运行时生成的TID足以确定恢复时的串行顺序。  
这就是为什么SiloR不需要为每个条目保留单独的日志序列号。

## Command Logging ##

OLTP数据库中的节点故障其实很少见。

*  OLTP数据库不是那么大。
 *  他们不需要在数百台机器上运行。

所以对于OLTP，我们更应该对系统优化耗时的操作而不是故障情况。

逻辑日志记录方案，DBMS只记录存储过程调用

*  存储过程名称
 *  输入参数
 *  额外的安全检查

Command Logging = Transaction Logging

### 确定性并发控制 ###

对于给定的数据库状态，串行调度的执行将数据库放入相同的新状态，的条件如下：

*  多个事务（或其查询）的执行顺序在开始执行之前已确定。
 *  事务逻辑是确定性的。

![15146895825915.jpg][]

类似这种的就是事务逻辑不确定，因为它执行起来的时间收影响。

### VOLTDB - 记录协议 ###

DBMS在开始事务执行**之前**记录事务的命令，并且给TID分配序列号。

对于不同的事务，可能是由多个CPU socket共同执行的，但是具有事务的“基本分区”的节点负责写入日志记录。

*  远程分区不记录任何东西。
 *  副本节点必须像他们的主人一样记录。

### VOLTDB - 恢复 ###

DBMS从磁盘加载上一个完整的检查点，然后节点重新执行从该检查点开始后到达的日志中的所有txns。

*  自日志中上次检查点以来经过的时间量决定了恢复的时间。
 *  被中止的Txns仍然必须被执行。

### VOLTDB - 复制 ###

用相同的顺序在多个相同的数据库中多重执行一个确定性的事务。此时的DBMS不需要使用两阶段提交。

![15146910920215.jpg][]

如果日志包含多节点txns，那么如果一个节点停机并且没有更多副本，那么整个DBMS必须重新启动。

## 参考资料 ##

[课件][Link 1]  
[Intro to Recovery: Haerder & Reuter][Intro to Recovery_ Haerder _ Reuter]

[ARIES_Algorithms for Recovery and Isolation Exploiting Semantics]: https://dl.acm.org/citation.cfm?id=128770
[15146703819666.jpg]: https://lh3.googleusercontent.com/-g_taRTAv70g/WkhdmBbnQoI/AAAAAAAAAa0/6uCOQe1Ck6AQQEp2UarMPm281qzNa3NaQCHMYCw/I/15146703819666.jpg
[SiloR]: http://15721.courses.cs.cmu.edu/spring2017/papers/12-logging/zheng-osdi14.pdf
[15146731885656.jpg]: https://lh3.googleusercontent.com/-l26pn7crYZA/WkhdmWNmS5I/AAAAAAAAAa4/kt4TyyAjtn8wVFQy8cksz1B0rPbptXU1gCHMYCw/I/15146731885656.jpg
[15146739509580.jpg]: https://lh3.googleusercontent.com/-rsZe0jEY18Q/WkhdmfX6RrI/AAAAAAAAAa8/ovwgZPEVAUwuhJDKh5bD2sd0IOYw-rnSgCHMYCw/I/15146739509580.jpg
[15146895825915.jpg]: https://lh3.googleusercontent.com/-cyUU4MvQUXk/WkhdmtFrwzI/AAAAAAAAAbA/7Ajec4cKFLAvWTcqzG98o2HrzWgWcmytQCHMYCw/I/15146895825915.jpg
[15146910920215.jpg]: https://lh3.googleusercontent.com/-5CAco1OwGlw/WkhdnPwjI-I/AAAAAAAAAbE/QX18aATbclolNIhUGn-zqWKFj0bdGXHzACHMYCw/I/15146910920215.jpg
[Link 1]: http://15721.courses.cs.cmu.edu/spring2017/slides/12-logging.pdf
[Intro to Recovery_ Haerder _ Reuter]: http://bnrg.cs.berkeley.edu/~adj/cs262/Lec_9_26.html