《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理（中） https://developer.aliyun.com/article/1232683?groupCode=polardbforpg

（三）一致性协议复制流程

下面我们看一下一致性协议复制的流程。

当PG进程需要提交WAL日志的时候，首先本地会写入WAL日志，然后开始等待提交LSN超过当前要提交的位点。提交了请求之后，我们会在两个链路上并行进行同步，在流复制链路上，它跟原生的逻辑其实是差不多的，它首先是通过WAL Sender来发送WAL日志，然后在Follower节点上由WAL Receiver接收，并持久化WAL日志。

在Consensus提交链路上，它主要流程是在Leader上，刚才也提到了由Append Thread根据当前的WAL日志回刷点来生成Consensus Log etnry，然后它需要把Consensus Log etnry写入本地，之后会传递给X-Paxos，开始发送到Follower节点。

在Follower节点上接收到Consensus Log之后，首先要确保所对应位点的WAL日志已经持久化成功了，确保之后就可以在本地写入Consensus Log，完成之后就可以回复Leader，表示本地已经持续化成功了。Leader节点会根据当前所有节点Consensus Log的持续化位点来确定当前最新的提交位点，之Advance线程会把提交位点转化成LSN，然后推进Commit LSN，再唤醒所有等待的PG进程。

正常的流程可能会比较简单一些，复杂的是当集群的状态、节点的状态发生变化的时候，应该如何进行协同处理，这个问题下文会阐述。

（四）Consensus日志存储

下面看一下Consensus日志的存储问题。

X-Paxos协议本身只负责日志的强一致同步，日志的持久化是通过API的方式由外部实现。

我们看一下在一致性协议中，X-Paxos内部有两类日志，首先是刚才提到由Append thread产生的，就是与日志同步本身相关的一些正常Log etnry。

从上文可以看到，这类日志本身除了一致性协议相关的一些信息，比如Term、 Log Index 、Type，还会自带一个CRC。

除了这些信息之外，它其实只是包含了当前所对应那段WAL日志的结束LSN，所以它的长度是固定的，这类日志在Consensus Log里面是占据了大多数。

第二类是X-Paxos协议，它本身会产生一些成员变更或者集群配置变更的日志，这些日志肯定是变长的，因为它里面要包含各个节点的配置信息，但是这个日志只占了非常小的一部分。所以在日志存储这方面，我们结合大部分日志都是固定长度的特点，采用了定长日志和变长日志混合存储。这个方案就是

在定长日志流中，对于定长日志它存储了完整的日志；变长日志只存储了它的偏移和长度，然后把变长日志的Payload，我们会在另外一个日志流里面存储。

在日志读取的时候，首先根据日志类型来确定是定长日志还是变长日志，如果是定长日志的话，就直接获取LSN信息，就可以获取到完整的信息。如果是变长日志，我们就根据日志中记录的偏移和长度去变长日志流里读取相应的内容。这样的好处是大部分情况下，当我们要获取定长日志的时候，可以直接通过Log Index定位日志所在的页面，以及这个页面上到底在哪个etnry，它的偏移是什么。

我们可以加速这个页面的定位，另外我们也引入了页面缓存，同时也引入了相关的一个LRU替换策略。

（五）Consensus状态机与DB状态机协同

介绍完日志复制的主要逻辑之后，接下来介绍如何根据X-Paxos内部Consensus的状态变化来推动DB状态的变化。

主动探测Consensus状态变化，触发Postmaster状态变更信号

Postmaster进程处理变更信号：

Slave：通知Startup进程Recovery状态变更，包括截断WAL日志、重建流复制或者升级等。

Master：降级则重启进入Recovery状态

首先，我们采用的方案是由Consensus进程主动探测X-Paxos层的状态变化，然后根据状态的变化产生一些变更的事件信号，然后通知Postmaster进行状态变更。如上图所示，左半部分是根据Consensus状态的状态变化产生事件，右边是DB侧收到这些信号之后，推进DB层的状态变化。

这会涉及到WAL日志对齐的问题，举个例子，比如发生了一个切主状态变化之后，如果Follower节点上从旧主库上拉取的WAL日志在新主库上不存在，那么当我们从新主库上重新去拉取WAL日志的时候，需要先充填掉多余的WAL日志。对于这一类状态变更，只有当日志对齐了之后，Consensus才能继续向前推进。

为了解决这个问题，我们给WAL日志也赋予了一个Term状态，也就是说只有当WAL日志的Term推进到最新之后，有相应的Term的Consensus log才能持久化，这样就能保证把上一个Term的WAL日志，多余的日志截断完成之后，下一个Term的Consensus Log才能持久化，否则根本不知道LSN对应的是一个上轮Term还是当前Term。除了刚才提到的WAL日志截断情况，在一致性协议里面，Consensus Log本身可能也会出现截断的情况。在这种情况下，本地的WAL日志也是需要被截断的。在以上两种情况下，WAL日志被截断之后，DB侧的一些数据状态，比如数据页面clog页面，这些应该如何处理？

首先，我们处理的策略主要包含三点。第一点是数据页面或者Clog页面在回刷磁盘持久化之前，必须要确保对应的WAL日志都已经在多数派上提交成功了，因为一旦持久化之后的状态肯定不会退，在一致性协议里面不会发生提交的状态、日志被截断。

另外一个点是在Follower节点上，只有当WAL日志在多数派上提交成功之后才开始回访。这个时候Follower节点上不管是缓存还是持久化的状态，其实都不可能出现回退的情况。

说到缓存，本身PG的机制是先修改比如说数据的Buffer，之后它会持久化WAL日志，所以可能当出现Leader降级之后，需要回退cache的情况，这里的处理逻辑是直接重启。因为此时需要从一个正常的读写状态进入到Recovery状态，目前PG里没有从读写状态进入到Recovery状态的逻辑，所以就直接重启再重新进入到Recover状态。

（六）双状态机协同-示例1

接下来会通过一个例子来具体介绍一下整个状态变更的过程。

比如当前是Follower状态，原来的状态如上图所示，每种状态是上半部分，下半部分是新的状态。

首先，比如Consensus进程探测到Term和Leader ID发生了变化，原来的Term是5，Leader ID是2，新的Term变成了6，新的Leader ID也变成了3。

当Consensus进程发现了这个状态变化之后，首先需要额外再获取当前Leader的信息，比如把ID转化成IP和Port，然后再获取一下当前Consensus Log的日志位点。获取到这些信息之后，就会直接去修改Postmaster的状态。修改完Postmaster状态之后，就给Postmaster发一个信号，然后Postmaster收到的信号事件，就是Leader发生了变化。Postmaster进程在收到这个信号之后，因为这个时候是Stream复制状态，所以需要去触发startup进程进行Recovery状态的变更。其中就会修改startup进程的recovery状态，比如还是保持Stream复制状态，becameLeader仍然是false，把Term变成6，再设置一下最新的Leader的IP和Port，其中也包含当前Consensus Log的位点。

修改完这个状态之后，就通知startup进程状态变更，然后startup进程本身会不断检测自己的Recovery状态，当发现Leader状态发生变化，会重启流复制，然后从新的Leader上拉取。比如刚才提到的可能会截断日志，这里不详细展开，有兴趣的话可以对照代码仔细看一下。

代码结构

（一）主要代码修改

上文介绍了一致性协议复制的原理和大体实现，接下来看一下相关的代码修改

主要包含以下几个方面，首先是一致性协议复制，第一部分是Consensus进程管理和提交主流程，第二部分是Consensus日志管理，比如日志的Append，日志根据Log Index的读取，都在Consensus日志管理文件里，第三部分是Consensus日志页面，就是具体缓存和持久化的相关管理。

第二块是流复制，主要包含两部分，第一部分是要收到包括从Consensus状态如何触发Postmaster的状态变化，然后Postmaste去触发startup进程的状态变化，主要是在xlog.c里。另外，流复制walsender和walreceiver这块也做了一些简单的修改，主要是在walsender.c和walreceiver.c文件里，大家可以去看一下。

另外，我们知道PG是C语言，X-Paxos是C++语言，所以这里需要相互的Wrapper。第一个是需要基于X-Paxos的相关接口提供一个c的Wrapper，另外日志管理这块是用C实现的，那么为了给X-Paxos使用，所以这块会提供日志管理接口的C++的Wrapper。

X-Paxos主要包含两部分，一个是算法的实现，就是在Libconsensus下面Consensus文件夹里，另外一块是X-Paxos本身依赖的高性能的网络编程框架，就是Libeasy。

最后一块是日志节点的实现，也就是Logger Syncer的功能，主要在polar_datamax.c这个文件里面，主要是如何驱动流复制的逻辑，其次是从Consensus状态变化，如何驱动Logger Syncer的状态变化。