高可用集群架构

（一）高可用架构

首先我们先了解一下PolarDB for PG的高可用架构。

总的来说，PolarDB for PG的高可用架构是把物理复制跟一致性协议相结合，来保证各个节点上的默认值的强一致性。我们看一下原生PG的物理复制方案，也就是流复制方案。

PG原生的流复制支持异步、同步、Quorum Base的机制来同步WAL日志，我们简单分析一下这三种复制方式。首先是同步复制，同步复制的首要目标是保证不丢数据，但其实它会有一些问题，第一个问题是它无法满足可用性的要求，当备库出现故障的时候，或者网络链路上有抖动的时候，这个时候可能会影响主库的可用性，或者主库的RT。其次，它本身并不具备故障自动切换的能力，意味着它并不会去探测主库的可用性，更不用说触发自动的故障切换。另外，旧的主库在故障恢复之后，可能无法重新加入到集群里面来。比如当事务在主库上WAL日志已经持久化成功了，但是在备库上还没有收到日志的时候，如果主库出现故障了，这个时候可能需要通过手动或者通过管控系统来把备库promote成新的主库。

过了一段时间之后，如果旧的主库恢复了，正常的逻辑应该是旧的主库以Standby的方式重新从新的主库上同步WAL日志，但这个时候由于旧的主库在挂掉之前，本身自己会有一些多余的WAL日志，所以这个时候是无法直接从主库上拉取日志，因为拉取日志的时候，会发现自己本身已有的日志在主库上不存在，在流复制里面它是会失败的，所以说这个时候我需要先执行一下pg_rewind。另外，对于不丢数据这一点，其实它也不完全是丢数据，比如说到Master上面，其实是在事务提交的时候，它会等待Standby同步日志，从而保证当Master可见的数据在Standby上肯定是已经同步到了。但是当Master写入了本地日志，然后Standby上还没有写入日志的时候，Master重启了，这时候Master重启之后，它会回放自己所有WAL日志，导致没有被同步到Standby的日志也会被回放。回放之后会出现一个现象，就是Master上已经看到的这些数据，但是对应的WAL日志还没有同步到Standby上，所以严格意义上来说，同步复制也并不能保证不丢数据。

其次我们看一下异步复制，异步复制跟同步复制相比，不需要等待StandbyWAL日志持久化成功。它发送过去行了，根本不关心备库到底有没有持久化成功，然后本地的事务就可以提交了。跟同步复制相比，它可用性比较好，或者说性能比较好，但它的问题是可能会丢数据。

最后一个是Quorum复制，Quorum复制看起来是说如果我们使用了一个多数派的方案之后，是否可以保证不丢数据。但其实在一致性协议里，它除了多数派同步的方案之外，它本身还会有一些选主、日志一致性、集群在线变更等方面的逻辑，但是PG本身Quorum复制里面，它并没有涉及到这些逻辑，所以从本质上来说，它其实并不是一个完整的RPO=0的高可用方案。

那么分析完PG的三种复制方式之后，我们再看一下我们PolarDB for PG的一个高可用方案。

首先我们通过把一致性协议引入到物理复制里，使用的一致性协议是阿里的X-Paxos协议，X-Paxos协议在阿里内部的业务中，包括阿里云的多个产品中，已经稳定使用了很长一段时间，包括企业版的AliSQL、PolarDB for MySQL以及PolarDB-X等产品，都使用了X-Paxos，具体的协议这里就不详细展开阐述，跟其他的一致性协议基本类似。这块主要讲一下，我们在物理复制里面引入了一致性协议之后的主要能力。

首先整个高可用集群是一个单点写入、多点可读的集群系统，其中Leader节点可以作为单点的写入节点来对外提供读写服务，产生了WAL日志之后，它会向其他节点进行同步，Follower节点是不可写入的，它主要是接受来自于Leader的WAL日志，然后进行回放，最终它可以对外提供一个只读服务。

那么我们高可用系统的特点是什么？

首先，它能保证集群数据的强一致性，也就是RPO=0。当多数派节点的WAL日志写入成功后，我们才认为日志是提交成功了。

另外一点是本身我们支持自动failover的，当发生failover之后，WAL日志会首先跟Leader对齐，然后再次从Leader拉取日志，对齐主要是通过一致性协议来实现，后面会详细讲一下。

第三个特点是刚才提到自动failover，大家知道在我们的高可用集群里面，只要半数以上节点存活的时候，就能保证集群正常对外提供服务。但是当Leader节点出现故障的时候，我们就会自动触发集群的重新选主流程，然后由新主对外提供读写服务，然后Follower节点也会自动从新的Leader节点上同步WAL日志，同时自动跟新的Leader对齐WAL日志。

第四点是在线集群变更，就是可以在线增删节点，包括手动切换，这些操作不影响业务的正常运行，具体也是由一致性协议来保证的，最终集群内的配置肯定会达成一致。即使在集群配置变更过程中发生一些异常，比如主库挂了或其中一个备库挂了这样的情况，最终集群成员状态还是能保证一致性。

除了Leader、Follower节点之外，我们在集群中还有其他两个节点，其中一个是Logger节点。Logger节点不存储数据，它从Leader中拉取到日志之后，它不进行回放，只保留实时日志，日志的目的是三个节点成本与主备基本相当。

另外一个是Learner节点，它本身没有多数派的决策权，但是它能提供只读服务。比如Leader节点在判断多数派节点的时候，其实并不考虑Learner节点，这个节点主要作用是它作为加节点的一个中间状态，比如新加的节点相对于Leader节点延迟比较大的时候，此时如果直接把它当做一个多数派决策的节点加进来，可能会影响Leader的可用性，或者影响Leader的提交延迟，所以我们先把它以Learner的角色加入到集群中，让它先同步数据，当数据基本追上的时候，我们再把它升级成Follower节点。

其次，Learner节点另外一个作用就是我们可以把它作为一个异地的灾备节点，主要特点是当时发生地点切换之后，自动从新的地方同步日志，对于原生的standby，当发生了主库切换之后，它并不会自动地从新主库上同步日志。

在集中部署方面，我们支持跨机房和跨域的部署，包括同机房三副本，同城三机房三副本，以及两地三机房五副本，还有三地三机房五副本的部署。

另外是跨域，刚才提到可以用Learner节点进行灾备，此时并不会影响Leader节点的可用性。另外，我们这个架构里最重要的一点也是比较关键一点，就是我们兼容PG原生的流复制和逻辑复制，能保证下游的消费者不受影响。

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