GP高可用原理

下面重点讲GP的同步原理。这个图是用了阿里云之前的blog里面的一个图案。在GP里面它是有master这种架构，在master节点上，用户连到GP之后，后台会起相应的back进程的处理用户的请求。当比如有建表或者删表或者更新数据字典的操作的时候，是通过Postgres的WAL日志流复制的方式，比如说新建一个表，就会先把这个日志写到buffer里面，然后再刷盘。这边会有新的进程然后同步到standby节点，standby节点也会把日志刷到磁盘上。

 

Greenplum数据同步原理

元数据和底下数据节点的安全性

对于GP元数据的同步，是采用了Postgres原生的流复制的方式，是强同步的方式，就是元数据这种变更的时候，一定是它这边真正刷盘成功之后，才会认为写入的动作成功。所以在元数据这块，是能保证绝对的可靠性，假如master挂掉之后，那这个standby进程会读Postgres进程，做回访，应用到standby数据。当异常情况的时候，集群会重新拉起来的时候，也会用xlog做恢复，这样就保证了元数据的安全和可靠。

对于底下节点来说，GP是采用自己的一套块数据的复制方式，怎么来理解呢？当有数据插入或者变更的时候，当这个数据要真正刷盘之前，在写入磁盘之前，它会截获到数据的变化，然后会把这个变化同样是通过这个进程发到对应的mirror节点，mirror节点后台会有相应的consumer的进程，包括heap表，来做相应的写盘动作。对于整个来说，只有mirror节点，把这个数据写成功之后，才会返回给primary节点，告诉它数据已经写成功了，就是真正后台会有一个刷盘的动作。

在GP整个的数据库里面，不管是从master节点还是底下的数据计算节点，是能保证数据的强一致性的。在任何情况下，比如机器突然掉电的情况下，不会出现切到mirror之后发现已经提交的事物丢失的情况。后面具体讲一下它后台的进程。

 

Greenplum主节点同步原理

这个就是说对于master和standby节点，当一个事物在提、把WAL刷盘的时候，它就会先把数据同步到standby节点，standby节点会写到本地盘上，然后再返回，告诉它表示已经写成功了，最后会传达到客户端请求已经成功，整个在元数据这块是通过WAL的流复制保证数据的安全可靠。

对于底下的计算节点，同样是当有大的数据插入或者更新来说，有一个WAL replication的进程，当这个数据要写盘的过程当中，会根据AO表还是heap表，会从不同的buffer里面会纳入到块的变化。比如说要刷盘的时候，这个replication的进程会通过新的进程把数据通过TCP/IP这个协议发到mirror节点，mirror节点拿到这个数据之后，也会先把它放到它的内存里面，然后有相应的consumer进程把它写到对应的底下的文件系统上，之后会有一个act进程，告诉primary节点，说数据已经写入成功了，通过这样的一个完整的链路，告诉primary节点，说这个时候也可以把事物提交，完成整个的动作。

 

Greenplum数据节点同步原理

它就是通过这种方式，类似管道的方式，在数据真正写盘之前，在primary节点写盘之前，就是通过这种强一致的刷盘的动作，不管是AO表还是heap表，都会通过强制的刷盘动作，保证数据的绝对安全、可靠，就是任何情况下机器断电等等情况下都不会造成数据的丢失。这也是为什么GP在金融客户有非常非常多的应用案例的原因，就是它不管是从原数据还是底下的数据节点，都能保证数据的绝对的安全可靠。

底层的同步进程

在一个节点上看一下它对应的mirror节点。mirror节点是它只负责底下计算的数据的冗余，正常情况下是不承担任何的计算负载，只有当primary节点挂掉之后，它会自动切到这边做相应的激活，就是切换成primary的角色。

它其实有三个最重要的进程：

1.一个是consumer进程

mirror consumer process主要负责xlog的写入和控制文件，因为在写入之后，比如做检查点之后，会更新相应的控制文件。它主要是负责xlog的写入。

2.一个是write process

负责heap表的写入，对于heap表的写入是通过xlog日志，就是通过xlogdump提供的工具，当数据写入之后，比如在heap表里插入之后，会解析它后台到底是做了什么样的动作。解析后可以看到当有heap表插入时，会马上在对应的mirror把WAL日志写到相应的磁盘上。对于底下来说，去跟踪刚刚提到的heap表的consumer进程，真正的数据文件的写入，在write的时候，底下并没有看到有think的动作。因为write的时候，它只是把数据从buffer里写到文件系统cache里面，并没有确定数据一定是刷到磁盘上的。

对于heap表的写入，只是保证了xlog在mirror节点的写入，但是对于真正的数据文件并不是一个强同步的过程。但是在做checkpoint时会发现heap表也会刷到这个磁盘上，但是通过这种方式已经能保证对于heap表的写的操作一定是一致的，因为对于heap表的xlog已经写到磁盘上，那就是挂掉之后，大不了再用xlog做一下恢复就可以了。这样的话，对于heap表写入操作完成之后，数据在mirror上绝对是不会丢掉的。

3.还有一个是appendonly process

负责AO表的写入动作。AO表的插入跟heap表有不一样的地方。因为在GP里面，AO是用了自己另外一套机制去实现的，所以它可以做压缩等等。但是它里面对于appendonly表另外还有一些heap表作为辅助的数据字典，比如pg-fastsequence和aoseg，就是它上面的一些索引和原数据的记录信息。对于AO表的这些辅助的一些数据结构，在GP里面也是采用heap的存储方式。

当在AO表里面去插入的时候，去跟踪一下刚刚提到的xlog的写入进程会发现它也会写xlog日志，但是它写入的是AO表，就是appendonly表对应的heap的数据字典的一些信息，真正的数据是通过mirror consumer appendonly process去写到磁盘上的。就是对于AO表的写入，比heap表要稍微复杂一点，就是它在写入的过程当中，同步是要包括一些xlog的一些写入，同时也包括一些本身的数据写入。

对于AO表来写入的话，把AO表插入的时候不用做commit去跟一下进程，它在写入的时候，把数据文件写到文件系统cache之上，会马上调一个fsync，这样的话对于AO表的数据是会马上写到底下的磁盘上的。所以对于AO表来说，它也是通过自己内部的机制，保证了数据在写入的过程当中是强同步的刷盘动作，保证了数据的可靠。

另外，对于刚刚提到的写xlog的consumer进程，不管是对heap表还是AO表写入，都会有相应的写入，写入之后紧接着会有一个fsync的动作。对于AO表的话，也是写入之后马上就会有一个fsync的动作。所以说对于GP来说，对于底层的数据存储，不管是heap表还是AO表，通过xlog日志和本身的appendonly表的写入机制，保证了两边数据的绝对安全可靠。