我们在学习Greenplum的架构时知道，Greenplum中主要有Master管理层和Segment计算层。在高可用方面，Master通过配置一个Standby来实现主备，Segment则通过对实例设置镜像的方式也实现主备高可用（其中主实例称为Primary，备实例称为Mirror)。
Master作为管理层，主要负责元数据的管理及执行计划的分发。为了存储元数据，Master节点上面有一个PG数据库实例，Standby节点上也同样有一个PG数据库实例，Master及Standby上面的PG实例通过流复制的方式来实时同步，关于PG中的主备流复制技术，我们在后面的文章中再作介绍。
那对于Segment节点的主备同步，是否和Master节点同步方式一样，也是基于流复制的方式呢？答案是否定的。其原因如下，

1. Segment节点中有堆表和AO表两种表，AO表不维护MVCC也不写WAL日志，因此无法通过复制WAL的形式来实现对AO表的同步的。
2. 实例对应的pg_control等配置文件也不写WAL日志，因此也不支持WAL流复制。

实现上，对于Segment复制，Primary和Mirror之间的同步包括两部分：数据和文件。之所以要同步文件，是因为Primary和Mirror之间可以自动failover，这就需要保证两者要保持同步，如果只是同步数据，那么由于pg_control、pg_clog、pg_subtrans没有同步会导致主备切换会存在问题。而Master和Standby节点之间则不需要考虑文件复制，一方面Master主备节点中没有AO表只有堆表，另一方面只要是流复制那么pg_control、pg_clog、pg_subtrans这些文件在Standby上面会自动更新。

数据同步

当Master发下执行计划给Segment后，Primary开始执行。如果是DML操作，Primary会产生WAL及更新page。Primary中有一个sender向Mirror发送Message，并由Mirror中的consumer等进程解析消息，执行变更。

文件同步

Primary中有个recovery进程，它循环的把Primary中的g_control、pg_clog、pg_subtrans 等文件覆盖到Mirror。同时检查WAL是否一致，如果不一致以Primary为主对Mirror进行覆盖。除了把Primary部分文件同步到Mirror之外recovery进程还会将Mirror上面的临时文件删掉。

综上，Greenplum中整体的主备同步流程可以用下图展示。