openGauss源码解析（65）
openGauss源码解析：存储引擎源码解析（33）
4.3.8 检查点
与openGauss磁盘存储引擎不同，MOT存储引擎不基于页面存储数据，因此MOT的检查点机制与磁盘引擎的检查点机制完全不同。MOT检查点机制基于CALC（checkpointing asynchronously using logical consistency，使用逻辑一致性异步检查点）算法，该算法出自耶鲁大学Kun Ren等人在数据库顶级会议SIGMOD 2016发表的《Low-Overhead Asynchronous Checkpointing in Main-Memory Database Systems》。
1. CALC算法
CALC算法的优点如下。
（1） 内存占用少：任意时刻每行最多2个副本。只有当检查点为活动状态时，更具体地说，仅在检查点的一个特定阶段，才会创建第二个副本，从而减少了内存占用。
（2） 开销小：CALC比其他异步检查点算法开销小。
（3） 使用虚拟一致性点：CALC不需要停止数据库就能实现物理一致性。虚拟一致性点是数据库的视图，它反映了在指定时间之前提交的所有修改，而不包含指定时间之后提交的修改，而且在不停止数据库系统的情况下就可以获得。实际上，可以通过部分多版本创建虚拟一致性点。
如图4-70所示，精确部分多版本算法（precise partial multi-versioning）的总体思想如下。
（1） 每行都与两个版本相关联，一个是活动版本，一个是稳定版本。通常，稳定版本为空，表明稳定版本与活动版本一致，检查点线程可以安全地记录实时版本。稳定版本仅在检查点的一个特定阶段创建，此时检查点线程将记录该稳定版本。
（2） 每行维护一个稳定状态位，指示稳定行的状态。
图4-70 检查点概述
MOT检查点算法在五个状态之间循环，如图4 71所示。
通常，在进入下一阶段之前，系统要等待所有上一阶段开始提交的事务完成。
1） REST阶段：初始阶段，不进行checkpoint。
（1） 在REST阶段，每行只存储一个活动版本。所有稳定版本都为空，稳定状态位始终为不可用（not available）。
（2） 在此阶段开始提交的任何事务将直接对行的活动版本进行操作，并且不会创建稳定版本。
2） PREPARE阶段：这是虚拟一致性点之前的阶段。当openGauss要求MOT创建快照时，系统从REST阶段移动到PREPARE阶段。
（1） 与REST阶段类似，每行只存储一个活动版本。所有稳定版本都为空，稳定状态位始终为不可用。
（2） 在此阶段开始提交的任何事务将直接对行的活动版本进行操作，不会创建稳定版本。
3） RESOLVE阶段：该阶段标识出虚拟一致性点。在此时间点之前提交的所有事务都将包含在此检查点中，而随后提交的事务将不包含在检查点中。一旦在REST阶段开始提交的事务完成，系统将自动从REST阶段变为RESOLVE阶段。
（1） 在此阶段不允许任何事务启动提交，以避免这些事务在openGauss占用检查点的重做点前写入重做日志。
（2） 一旦在REST阶段开始提交的事务完成，MOT将在此阶段获取要包含在此检查点中的任务列表。
4）CAPTURE阶段：在此阶段中，后台工作进程将数据刷入磁盘。RESOLVE阶段一直持续，直到在准备阶段已开始的所有事务完成并释放其所有锁为止。系统准备任务列表，然后进入CAPTURE阶段。
（1） 在CAPTURE阶段开始的事务已经在一致性点之后开始，因此他们肯定会在一致性点之后完成。因此，除非记录已经具有显式稳定版本，否则总是在更新前将活动版本复制为对应的稳定版本。
（2） 收到BEGIN_CHECKPOINT事件后，系统生成检查点工作进程，扫描所有记录，并将没有显式稳定版本的行，或活动版本的对应的稳定版本刷盘。在此过程中，显式稳定版本一旦刷盘就会被释放。
5） COMPLETE阶段：这是紧跟捕获阶段完成的阶段。检查点捕获完成后，系统进入COMPLETE阶段。事务写入行为恢复为与REST阶段相同的状态。
与REST阶段类似，每行只存储一个活动版本。所有稳定版本都为空，稳定状态位始终为不可用（not available）。
一旦在捕获阶段开始的所有事务都完成，系统将转换回REST阶段，并等待下一个触发检查点的信号。但是，在返回到REST阶段之前，调用函数SwapAvailableAndNotAvailable翻转稳定状态位。这允许MOT避免只能通过完全扫描来重置稳定状态位，因为在CAPTURE阶段之后，所有稳定状态位都可用，但在Rest阶段开始时，希望所有稳定状态位都不可用。
