高级数据库十四：检查点协议

约定不等于承诺〃 2022-06-02 03:16 127阅读 0赞

# Checkpoint Protocols #

## 背景 ##

日志允许DBMS在崩溃/重新启动后恢复数据库。 但是这个系统每次都要重做整个日志。

检查点允许系统忽略大部分日志以减少恢复时间，就像存档点一样。

理想的检查点应该具有：

1.  不能减慢常规事务的处理速度。
2.  不能引入不可接受的延迟峰值。
3.  不能要求过多的内存。

### CONSISTENT VS. CHECKPOINTS ###

方法1：一致的检查点（Consistent Checkpoints）

*  大部分的检查点协议使用的方法。
 *  在某个时间点表示数据库的快照。没有未提交的变化。
 *  恢复过程中无需额外处理，因为所有已知的数据全是已经确定修改完成的，需要和日志文件结合来处理当前检查点没有commit的事务操作。

方法2：模糊检查点（Fuzzy Checkpoints）

*  快照可能包含从尚未完成的事务中更新的记录。
 *  必须进行额外的处理才能删除这些更改。

### FREQUENCY ###

保存检查点过于频繁导致运行时性能下降，DBMS将花费太多时间冲洗缓冲区。

但是，在检查站之间等待很长时间也是一样糟糕，这将使恢复时间更长，因为DBMS将不得不重做大量的日志。

## In-Memory Checkpoints ##

和Disk上的数据库不同的是，Disk上的数据库仅仅需要对修改过的页（脏页）进行存档；而In-memory的数据库需要对所有的表（不管是否是脏的）进行存档。

创建检查点的方式有很多，其中一种方式就是与DBMS并发控制方案紧密结合：检查点线程（可能是多个，可能是单个）扫描每个表并将数据异步写入磁盘。

### Naïve Snapshots ###

在内存中的新位置创建整个数据库的一致副本，然后将内容写入磁盘。

使用此方法，DBMS在检查点期间阻塞所有txns。

两种复制数据库的方法：

*  自己做（只有元组块）。
 *  让操作系统为你做（一切，因为操作系统没法分清楚这块内存是数据，这块内存是索引，所以就直接全部拷贝了）。

使用Naïve Snapshots时，事务必须等待检查点线程完成快照存档。

#### [FORK SNAPSHOTS][] ####

通过fork DBMS的进程来创建数据库的快照。

*  如果没有活动的txns，子进程包含一致的检查点。
 *  否则，使用内存中的undo log在子进程中回滚事务。

而父进程继续处理父进程中的事务。

但是这种方法提出不久就被放弃了，原因似乎是因为fork导致子进程的线程问题以及一些其他的多进程并发问题，导致实际运行速度较慢。

### Copy-on-Update Snapshots ###

非常类似多版本控制的方式，但是可以不用维护MVCC，而是用于维护检查点。

在检查点期间，事务创建新的数据副本而不是覆盖它。

*  副本可以在不同的粒度（块，元组）

然后，检查点线程将跳过启动后创建的任何内容。

*  旧数据写入磁盘后被修剪

如果使用的是Copy-on-Update快照，事务可能需要等待检查点线程所占用的锁。

#### VOLTDB ####

一个特殊的事务启动一个检查点，并将DBMS切换到Copy-on-Write模式。

*  数据库的表不再做in-place方式的更新。
 *  DBMS追踪自检查点开始以来元组是否被插入，被删除或被修改了。

经过上面的步骤，我们就有两个版本的数据库数据，一个是在检查点之前的，一个是在检查点之后的。

利用一个单独的线程扫描这些表并将元组写入磁盘上的快照。

*  忽略在检查点之后的任何改变。
 *  清理旧版本。

### Wait-Free ZigZag ###

wairt-free不是lock-free或者latch-free，它的意思是事务不需要等到检查点备份完毕再对数据库进行更新。

通过维护多个数据库副本来实现。每个事务仅仅更新一个副本。

使用两个BitMap来跟踪事务应该从哪个副本的数据进行读写。这样可以避免像Copy-on-Update的方法那样需要动态创建拷贝，减少一定的时间开销。

![15148560058410.jpg][]

BitMap是1的时候表示操作在copy2，0的时候表示操作在copy1。

那么当检查点线程检查的时候，就取write bitmap的反码，然后进行读取。

![15148560851535.jpg][]

当一个事务来需要更新的时候，则按照BitMap来做，就可以和检查点线程错开了。

![15148562245304.jpg][]

如果来了读操作，那么就将读操作和写操作错开，并使用同样的方法构造出检查点需要读取的副本位置。这样就可以和事务的写操作错开。

这样的方式使得检查点无法保存在它开始备份之后的所有修改。

这种方式可能没有在工业界中使用。

### Wait-Free PingPong ###

使用额外的内存和CPU运行以避免在检查点结束时暂停事务。始终保持整个数据库的两个副本，以及额外的shadow copy。

*  指针指示哪个副本是当前的master。
 *  在检查点结束时，交换这些指针。

![15148565027426.jpg][]

用一个指针指示那个是master copy，目前是copy1。它只记录了修改的值，而copy2则是对原数据完整的拷贝，这样检查点线程就会扫描copy2来进行备份。

读的时候就直接读取Base copy的内容，写的时候会在Master和Base copy同时进行。

![15148566533276.jpg][]

现在我们就将master设置为copy2，在这儿我们将之清空了，但是实际上可以不用清空数据（只清空BitMap），而是等到需要修改的时候直接覆盖。

那么对于检查点线程而言，我们只知道上一次的修改是什么，但是还有不少数据还在不知道。

一种方式是，通过Base Copy进行复制。这种方式有很大的弊端，因为你并不知道这个数据是否是修改过的。

另一种方式是，通过硬盘中上一个检查点的内容进行填充。

可能没有在工业界中使用。

### 检查点实现 ###

批量状态复制

*  暂停事务执行，并保存快照。

锁

*  如果工作线程在共享区域上运行，则使用锁存将检查点线程与工作线程隔离。

批量位图重置：

*  如果DBMS使用BitMap来跟踪脏区域，则必须在新检查点开始时执行批量重置。

内存使用情况：

*  为避免同步写入，该方法可能需要为数据副本分配额外的内存。

## Shared Memory Restarts ##

我们可以知道的是，不是所有的DBMS都仅仅因为crash而重启，还有可能是升级操作系统库、硬件升级、DBMS软件升级。

所以我们需要一种能够快速重启DBMS而不用再从数据库中读取信息的方式。

将内存数据库生命周期与进程生命周期分离。  
通过存储数据库共享内存，DBMS进程可以重新启动，并且内存内容将存活。

### FACEBOOK SCUBA ###

将内存数据库生命周期与进程生命周期分离。

通过存储数据库的共享内存，DBMS进程可以重新启动，并且内存内容将存活。

分布式内存DBMS，用于时间序列事件分析和异常检测。

异构体系结构

*  叶节点：在内存数据上执行扫描/过滤器
 *  聚合节点：合并叶节点的结果

![15148583870230.jpg][]

### SCUBA SHARED MEMORY ###

Shared Memory Heaps

*  在正常操作期间，所有数据均在共享内存中分配。
 *  为了线程安全性和可伸缩性，必须使用自定义的分配器来细分内存段。
 *  不能使用共享内存的延迟分配来分配页面。

Copy on Shutdown

*  在正常操作期间，所有的数据都在本地存储器中分配。
 *  关闭时，将数据从堆复制到共享内存。

### SCUBA RESTARTS ###

当管理员启动重新启动命令时，节点停止接收更新。DBMS开始将数据从堆内存复制到共享内存。并且在堆中，删除已经移动到共享内存的块。

一旦快照完成，DBMS重新启动。在启动时，检查共享内存中是否有有效的数据库，

*  若有则，复制到堆中。
 *  否则，DBMS从磁盘重新启动。

[FORK SNAPSHOTS]: https://dl.acm.org/citation.cfm?id=2005619
[15148560058410.jpg]: https://lh3.googleusercontent.com/-K0H81YWJ024/WkrtGWOVWEI/AAAAAAAAAbk/tumEBdGHZuAHWfznC0OpN3jxErRS10VgACHMYCw/I/15148560058410.jpg
[15148560851535.jpg]: https://lh3.googleusercontent.com/-rBsgrZ-RNz8/WkrtHgQgnkI/AAAAAAAAAbo/sWYipOQSo34gFbt0tXca7O0qrEoX5dctQCHMYCw/I/15148560851535.jpg
[15148562245304.jpg]: https://lh3.googleusercontent.com/-Qv6EAyR-9Us/WkrtIEhuudI/AAAAAAAAAbs/gE8wXT7_82AKFSaQrlMEMMWXuEoSwo0lACHMYCw/I/15148562245304.jpg
[15148565027426.jpg]: https://lh3.googleusercontent.com/-rJDbmVgXwZI/WkrtIRiFd3I/AAAAAAAAAbw/hfX6Hl3-63kE2_xohEbvtvMRMPFb47h2wCHMYCw/I/15148565027426.jpg
[15148566533276.jpg]: https://lh3.googleusercontent.com/-4-rdSgaZA7E/WkrtIZgztvI/AAAAAAAAAb0/TYcc3QJsC1EOM7xG6Uo271bjBviTsB4CwCHMYCw/I/15148566533276.jpg
[15148583870230.jpg]: https://lh3.googleusercontent.com/-AJvk1g4RVYg/WkrtI2rFFcI/AAAAAAAAAb4/z73qFrjjvAgIg0x_VPj9Cma8hZ-Kj39ZQCHMYCw/I/15148583870230.jpg