1. 前言

MPPDB集群服务组件主要分为内核端和集群管理端，内核端主要包括GTM组件，CN组件和DN组件；集群管理端主要包括CMServer组件和CMagent组件。

2. 内核端高可用设计

2.1 GTM高可用

在MPPDB中，GTM在集群中只有一个实例，如果故障后，集群将无法使用，因此需要给GTM配置一个备机，主机故障后，备机可以接管服务。

GTM主要负责分发xid和snapshot，由于xid要全局唯一，因此需要持久化到磁盘上，凡是需要持久化磁盘的都需要有备份，那么GTM主机在每将一次xid值写入到gtm.control文件中，就会和备机同步一次，备机写完后，主机再写。

在同步过程中，主机业务线程只需给GTM备机发送一个消息包，GTM备机接收到消息后创建一个服务线程，并将事务xid写入本地文件，回复消息，主机的一次同步便完成。GTM在内存中xid每加2000时会向备机同步一次。

如果GTM主机永久故障，GTM备机升主后，只需要重新初始化一个GTM实例出来然后和主机同步xid即可

2.2 CN高可用

通常一个集群中会部署多个CN，多个CN互为主备。如果一个CN故障，那么客户端可以使用其他CN。

由于CN只存储元信息数据（即每张用户表数据分布在哪几个DN），因此只有DDL操作时才设计到CN存储数据，DML时CN并不需要写数据。在DDL操作时，接受业务的CN会把该SQL发送到所有其他CN与所有DN，通过两阶段提交来保证各个CN的数据一致性。这里也有一个设计缺陷，即当一个CN故障时，那么集群便无法操作DDL，此时只能手动从集群中删除该CN才能使用。

如果集群中一个CN永久故障，那么需要重新初始化一个CN，然后使用gs_dump从另一个CN到处元数据再导入到该新CN上。

2.3 DN高可用

由于所有用户表数据通过sharding的方式存储在各个DN主上，各个DN数据完全没有分叉，如果主机故障后，那么数据将丢失，并无法提供服务，因此DN的高可用尤为重要，必须给DN主备配置一个或多个备机。

MPPDB中的DN的高可用主要包含两大块设计，第一：主、备、从高可用设计；第二：数据复制。

2.3.1 主、备、从高可用设计

主备从中，其中主和备各有一份完整的数据，从备上不存储数据。由于分布式环境，一份数据分片在多个DN上，那么必须要求各个DN主与备必须强同步，如果不是强同步的话，主机故障，备机升主后，备机可能没有主机的部分数据，这样在分布式环境下就会产生有的DN上有数据，有的没有，会造成集群的数据不一致，因此DN的主备必须是强同步，事务提交时，数据必须已经写到备机上才可以提交。

此时就会暴露另外一个问题，即如果集群中有任意一个DN主或DN备故障后，那么集群将无法进行写事务，当集群中DN数据较多时，单节点故障场景在生产环境往往是不可避免的。因此为了解决单节点故障后集群写事务可用时，我们引入了从备这个实例，简单来讲就是备机故障后，数据将发送给从备，仍然保证了数据写两份的原则，事务照样可以提交。如果备机和从备均故障后，那么写事务仍然无法进行。

当主备从正常时，数据只发送给备机，从备空闲：

当备机故障时，数据会发送给从备，保证写事务正常进行；备机故障修复后，继续连接主机追赶故障过程中丢失的数据，并且此时主机数据不再发送给从备，直至备机追赶完主机达到同步状态，那么主机将发送命令，删除从备上所有数据。

当备机在追赶主机的时候，主机故障，那么会触发备机Failover，备机连接从备，接收数据，接收完成后，备机升主，数据同步给从备。

设计反思：

主备从当时设计的时候主要考虑的事避免数据的3份冗余，因为硬件层面已经做了RAID，软件层面再3份冗余，存储空间利用率很低，当时跟N9000配合，N9000就是卖存储的，所以提了这样一个方案。

实际上，从备，再进一步演化，可以变成oracle的far sync，oracle的far sync只接受日志不redo

Oracle far sync材料：

http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf

http://www.oracle.com/technetwork/database/availability/8395-data-guard-far-sync-1967244.pdf

另外，在TP里面，数据量没那么大，对可用性要求更高，从备就显得有点鸡肋了。所以在TP V1R5的设计里面，彻底去掉了从备。至少是1主2备。

2.3.2 数据复制

在PG单机时，主备数据同步通过XLOG事务日志同步。在大量写事务场景下，会产生大量的XLOG日志，主机需要先将XLOG下盘，然后日志同步进程读取XLOG发送给备机，备机收到XLOG日志后下盘，然后恢复进程读取日志进行REDO。这个过程主备一共有两次写IO和两次读IO请求。

在OLAP场景中，普遍数据量都很大，并且很多场景往往只需要查询某张表中的某一列数据，这样通常采用列式存储格式。不仅有利于性能提升，并且按列存储，数据格式一样，非常利于压缩，节省存储空间。由于按列存储时，如果再按行存储方式去导入一行记录一条日志，那么性能将非常慢，如果没有日志，将无法实现主备同步目的，因此需要探求一种新的数据同步方式。

基于上面两方面考虑，我们设计了数据复制通道，即数据导入到DN后，组成一个个最小存储单元（行存按页面大小8K为单位，列存按CU大小8K为单位），然后发送给备机，备机接收到后，将数据写盘，并回复主机写盘数据逻辑位置（主机发送时，给每个数据单元设置一个uint64位单调递增的偏移位置，类似于XLOG中的LSN），主机在事务提交前，如果该事务要求写盘数据已经传输给备机，那么即可提交。

主要设计框架：

主备复制过程中，XLOG复制和数据复制并行传输，备机接收后，并行写盘，对于日志恢复drop table 或truncate table文件类操作时，两者通过表级锁来控制并发。

日志复制：主机记录XLOG后，会定期写到磁盘上，WalSend线程会读取磁盘上的日志，通过TCP网络发送给备机WalReceiver线程，该线程接收后会写到一个内存队列中，WalRecWriter线程定时从队列中取出来写盘，并更新备机写盘LSN，WalReceiver线程回复主机消息时把该值发送给主机。恢复日志线程定期读取磁盘上XLOG对日志进行REDO。

数据复制：数据复制只有在行存批量导入数据和列存导入数据时触发，数据导入后，存储层将多个数据tuple组成一个个数据最小存储单元，并将其发到发送队列中，DataSend线程将从发送队列中取数据通过TCP网络发送给备机DataReceiver线程，该线程接收数据后会写到一个内存队列中，由DataRecWriter回复主机消息时将该值发送给主机。数据复制过程中数据直接由DataRecWriter写盘，不需要恢复日志线程去恢复数据