《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍（3） https://developer.aliyun.com/article/1232755?groupCode=polardbforpg

全局一致性正确性证明

上面HLC的算法，我们可以证明它的正确性。

我们假设在任意一个节点如DN1上，如果有两个并发事务T1、T2,如果T2在扫描T1的修改时，T1还未prepare，那么T1对T2是不可见，因为没有prepare，也没有提交时间戳，所以直接就判断不可见了。

这样的话，T2的start_ts一定会小于T1的commit_ts，这个是因为T1在prepare阶段分布式决策的T1的commit_ts一定会大于等于DN1的prepare_ts，则大于DN1的max_ts。而T2的start_ts 在到达本节点时，一定会更新max_ts，使得 max _ts大于等于 T2的start_ts。因此，当T2扫描T 1的修改时，T 1还未进入prepared状态，则说明T 1的commit_ts一定会大于T2的start_ts。

由于commit_ts和start_ts是全局统一的，因此在任意节点，T1的commit_ts大于T2的start_ts条件都成立，根据时间戳比较判断可见性，T1的修改对T2均不可见。

如果T2在扫描T1修改时，T1处于prepared状态，T2需要等待T1的提交，或者说abort。如果abort，则不可见；如果提交，那就有commit_ts，直接时间戳比较进行可见性判断，即如果T2.start_ts >= T1.commit_ts，则可见。

如果T2在其他节点没有看到T1的prepared状态,根据上面第一点的证明，最终T1的commit_ts会大于T2的start_ts，则在本节点T2等待结束，也看不到T1的修改。因此，T2可能看到T1的修改，仅当T2在所有节点都看到了T1过了prepare阶段。

根据上面的证明总结，如果T2在某个节点扫描时未看到T1的prepared状态，T1的修改对T2不可见，最终T2.start_ts .这样如果T2.start_ts>=T1.commit_ts，则可以看到T1的修改。从而我们可以保证T2要看到T1的修改，当且仅当T2的start_ts大于或等于T1的commit_ts。

外部一致性正确性证明

另外比较关心的就是外部一致性，HLC可以保证跨session之间的快照隔离（内部一致性），以及同一个CN的强外部一致性，跨CN的弱外部一致性。

外部一致性的定义是数据库事务T1提交成功返回，此时开启的事务T2一定能够看到T1的修改，相当于T2在T1提交成功返回以后，立即可以看到T1的修改。如果T1、T2都连接到一个CN的客户端，我们就可以保证外部一致性。T1结束的时候会用T1的commit_ts更新CN的max_ts，T1返回给客户端，发起T2请求，可以是不同的客户端。T2的start_ts会大于等于T1的commit_ts，所以T2一定能看到T1的修改。

不同的CN之间有时钟偏移，此时不定能保障立马能看到，会有一定的时钟倾斜，PTP协议将一个IDC的时钟倾斜同步在1us内。客户端到CN之间的网络来回延迟远大于时钟偏移，此时就可以保证强一致性。

不同CN之间，如果我们依赖传统通用的NTP进行同步，可以保证读到小于时钟倾斜的提交事务修改。比如在CN1上刚提交了，CN2上时钟偏移可能有5毫秒，要等5毫秒才能看到它的修改。当然，从CN1上返回给客户端，让客户端知道它已经提交成功了，也会有一定的时差，所以一般场景下读不到最新提交，相对来说偏差是比较小的。

大部分场景下，跨Session要求读到前面已经提交的需求一般相对较少，大部分情况下都是在同一个Session里面的事务要求看到前面的修改，所以HLC可以保证即便是跨Session，不同的CN可以保证快照隔离，同一个CN是强外部一致性的，跨CN会有弱外部一致性，未来引入先进的 PPT协议就可以保证强外部一致性。

Remote Recovery 设计动机

接下来介绍一下另外一个性能的优化——Remote Recovery机制。

PostgreSQL会通过full page writes来解决故障时部分写入的页面，因为故障的时候页面可能会没有完全写入，在页面写入的中间就crash了。

此时，PG采用的是checkpoint后第一次修改，在WAL中写入full page，回放时，用WAL中的full page来进行回放，此时full page写的开销就会很大。

Remote Recovery 设计想法

我们有一个Remote Recovery的设计想法，就是通常情况下一个数据库节点是有多节点进行容灾，像我们这次开源的三节点，它就有两个节点进行容灾。我们可以采用Remote Recovery机制在多个副本之间进行恢复，就是一个机器节点的页面可能损坏了，但其他副本有最新的有正确页面，就会备机去读然后再进行故障恢复。

这个特性Oracle里面也有，我们的特性和它的不同点在于Oracle的是做checksum的时候发现它不一致了，就去其他节点恢复。我们还是沿用full page write的特性，在checkpoint后发现是第一次修改，就去备机读。因为checksum并不一定保证完全的正确，而我们这样的话可以保证完全的正确性。

Remote Recovery 实现

上图为Remote Recovery的原理框架图。

我们在回放的时候，发现它是checkpoint后第一次修改，我们就会从远程mirrored节点，比如备机从主机，主机从备机，或者备机从备机，可以把另外一个full page先读过来，然后再Apply。

Apply的时候跟WAL回放的原理一样，就是只有LSN大于远程页面的LSN才会回放，否则的话就直接跳过，说明在备机或远程的一个节点已经回放过了。

这里有个很核心的问题，就是何时需要去取remote full page？

在每个checkpoint后第一次修改页面时，我们不写full page，而是在WAL中写入remote fetch page bit，记录一下需要去远程读取页面。

在节点故障恢复重做时，碰到remote fetch page bit，则从mirrored节点远程fetch full page。主机写入checkpoint的时候需要等待备机同步完成，因为我们需要保证主备之间最近的一个checkpoint大家都有，因为回放都是从最近的一个checkpoint开始的，所以必须保证之前的修改在其他节点已经有了，这样我们才能保证回放正确。

这样的话，我们回放的流程跟原来的单机回放是差不多的，也就是当LSN大于page LSN才重做。如果小于，那说明在mirrored的节点已经重做过了，我们就不需要再回放，直接跳过。

还有一些不存在的页，说明它在后面已经删除掉该页了，比如说删除表空间，回收等，我们也可以简单跳过。

我们去连接mirrored节点的时候，需要判断mirrored节点回放是否过了故障恢复节点最近的一个checkpoint点。如果没有，就要等它过了这个点，保证两边最近的checkpoint点是一样的，因为恢复是从最近的checkpoint点来恢复，这样就可以保证两边是一致的。

Remote Recovery的正确性是保证两个节点之间checkpoint点是一样的，这样我们后面回放的时候就有最新的数据，无非是LSN在另外一个节点是否回放过的区别。