- MPPDB历史
MPPDB最早起源于12-13年开始的POC预研，最初把开源PG-XC社区版本作为基线，在此版本上研发。主要预研分布式执行框架（注明的stream算子应该就源于此）、向量化引擎、列存储等OLAP领域中较重要的特征。
PG-XC介绍：PG-XC社区源于日本人铃木发起，并主导开发，主要致力于研发一个分布式OLTP式系统（目前的多CN架构遍源于此），由于社区平淡，后来美国人在此基础上发展PG-XL，致力于在XC的架构下发展OLAP能力，再后来铃木看XL发展还好，于15年又将XC更名为X2，致力于将XC和XL的代码合并，间距两个分支的优良特性。但好景不长，15年9月GP开源后，对X2社区起了巨大的冲击。至今，X2shequ发展仍然平平。
14年我们开始以PG-XC1.1 release版本作为基线，开始正式商业产品化，14年6月份发布第一个商业产品，江湖名称530版本，寓意5月30日发布，何如的主要特性有分布式执行框架，DN中HA功能、GTM批量导入、CM（集群管理）、OM（集群自动化安装），主要是满足产品化功能，此时MPPDB在产品上有了一个基本的模型。14年下半年主要何如向量化引擎、列式存储、HA中数据复制、主备从复制、扩容充分布及各个模块增强。15年主要以稳定上一个版本为主，合入SCTP新一代通信方式、MPP on Hadoop二期、LLVM动态编译、ADIO，ETCD等。17年主要合入了SMP、MPP on Cloud、动态资源管理，nodegroup，事务性能优化，就地升级，列存支持btree等。
- MPPDB的各个组件
MPPDB是一个较复杂的系统，目前核心代码量大概在百万行左右，从特性角度来看需要比较详细的介绍，但基本遵循传统关系型数据库的架构。这里从MPPDB整体架构来看，简单描述各个组件基本功能，这样更有利于初学者快速入门，了解整体架构，方便以后继续深入研究各个细节。
2.1 GTM组件
GTM名为全局事务管理器，系统中只有一个，采用主备方式，系统中常驻的服务进程，多线程架构。主要用来分发xid与snapshot，保证系统中全局事务的一致性。GTM是被动接受连接的，通常只有CN会主动连接GTM，DN在autovaccumwork时连接GTM。
2.2 CN组件
CN名为协调者，是所有客户端（gsql，jdbc，odbc等）的入口，客户端连接CN，发送SQL，CN接收解析后发送给所有的DN执行，执行完后返回结果给CN，由CN统一返回给客户端，这样完成一次SQL的交互。系统中常驻的服务进程，多线程架构。
CN在系统中可以有1个或多个，每个相互独立，通常每个物理机部署一个，由于其主要记录表中元信息，每次的DDL所有的CN都需要参与，因此它不需要做备份，所有CN互为备份，坏了一个可采用另一个CN恢复。
2.3 DN组件
DN名为数据节点，真正意义上的执行者，存储于计算均参与。主要受CN控制，系统中DN可以有多个，数据采用hash或者rr方式分布在各个DN中，因此每个DN数据完全不同，相互独立。通常一个物理机器上会部署4-8个DN，系统中常驻的服务进程，多线程架构。
由于DN是系统中参与计算和存储的节点，因此它的高可用需要完整的设计。目前每个DN均是主、备、从结构，可以简单理解为1主2备，采用的事强同步机制，就是必须完成写两份才提交。
2.4 CM组件
CM名为集群管理。一个系统中各个组件需要智能的自动化协同工作，离不开集群管理系统。CM组件主要分为4个子模块：
cm_ctl：一个集群操作的客户端工具，可以用来启动、停止和管理整个MPPDB集群。主要是通过将用户命令发送给cm_server，由cm_server分析控制整个系统的行为。非常驻进程，执行完命令后即退出。
cm_server：集群管理的大脑，整个管理系统的仲裁者，系统中只有一个，主备架构，系统中常驻的服务进程，多线程架构。主要收集cm_agent返回的各个实例（GTM主备、CN、DN主备从）状态信息，从而通过分析给出谁是主谁是备，什么时候需要failover切换，什么时候需要重建DN。cm_server的另一个作用就是接收客户端cm_ctl发送的命令使得cm_ctl可以管理整个集群。
cm_agent：集群管理的实际执行者，接收cm_server的命令后，操作本地的各个实例，顾名思义，cm_agent的分布与集群物理机树梁相关，每台物理机一个cm_agent，常驻进程，多线程架构。负责各个实例的启动、停止、主备switchover、备机failover、仲裁主备等命令的下发。任何一个实例（包括cm_server进程）因异常停止后，cm_agent检测到即会重新拉起。
om_monitor：这是一个神奇的进程，所用非常简单，就是启动集群后如果cm_agent异常停止后，它会拉起cm_agent。由于任何一个实例终止后，由cm_agent拉起，cm_agent终止后，由于om_monitor拉起，那么问题来了，om_monitor挂掉后，谁来拉起呢？然而操作系统有一个功能叫crontab，只要把任务按照要求写入这个服务中，它可以定时检测某个任务，如果不存在便拉起。这样便完成了一个完全自动化的管理。om_monitor是系统中常驻进程。
2.5 扩容、缩容及重分布
分布式数据库有一个非常重要的特点就是弹性，可以扩容、缩容。既然是可以扩容、缩容，那么可以涉及到的组件必定不是单点的，因此GTM是没有必要扩容的，可以弹性的只有CN和DN了。
CN只有系统的元信息，没有用户数据，每个CN均存储，因此扩容CN时只需要重新初始化一个数据库，将一个老的CN元数据dump出来再导入到新的CN就可以了，过程中很快。缩容即删除某个CN，再从系统中将其信息删除即可。
DN拥有用户数据，因此扩容、缩容比较复杂，前面与CN类似，最后需要执行重分布。也就是扩容时先将数据初始化出来，导入dump出来的元数据。最后执行重分布。重分布顾名思义，就是将以前所有的DN实例的数据重新分布一下，把部分数据挪到新的DN实例上，使得扩容后所有的DN数据均匀分布，可以充分利用资源。
重分布的执行工具名为gs_redis，是一个外部工具，主要通过SQL交互的方式完成重分布过程，思想类似于一致性hash，过程中迁移部分数据，做法非常巧妙。执行完后即退出，非常驻进程。
DN的缩容与扩容类似，先执行重分布，将数据重新分布后，删除缩容的DN，再将其从集群系统中删除其信息即可。
2.6 OM组件
OM组件的简称貌似是operation manager。主要用于设置系统环境，安装部署整个集群，里面含有各种神奇的工具，比如扩容、缩容、实例替换、节点替换、升级、备份恢复等等。
所有工具均非常驻进程，执行完后即退出。
2.7 升级
升级总所周知，就是新版本发布后，客户想使用更高级的特性及更好的性能便可以将老的版本替换，使用新版本。如果新旧版本改动不大，那么很简单，直接替换掉二进制即可。如果新版本改动很大，诸如修改了很多系统表之类的信息，这样需要大版本升级，过程比较复杂，其大概流程为：先将老的系统元信息全都dump出来，物理数据不变，重新初始化新的集群后将dump出来的数据导入，把物理数据挪过来，便完成了升级。大版本升级有时很慢，瓶颈主要是在表数据量特别多时，元信息的导出导入比较耗时。
升级组件名称为gs_upgrade，非常驻进程，执行完后即退出。整个过程是一个离线升级的过程，业务在升级过程中无法执行。
2.8 备份恢复
备份恢复是数据库中一个重要的工具，用于先备份数据，待使用时再恢复，因此备份恢复通常是一对整体的工具。
单机系统中，备份实际上是将一个数据库做一份basebackup，即我们通常所说的build，这个过程可以在线进行。
分布式中和这个过程类似，由于是在线运行，因此需要解决备份过程中事务并发运行问题，对此，XC中的解决方案是备份结束时创建一个barrier，目的是锁住写事务，记录一条事务日志，释放barrier锁，使得系统写事务继续运行，这样在恢复时遇到barrier日志便恢复结束，保证了集群所有节点的一致性。
恢复过程相对简单，就是把备份的数据还原，对于单机而言，basebackup做完后启动recovery即可。对于MPPDB而言，将各个组件数据解开，启动recovery，DN的备机还需要通过主机的build出来。
备份恢复组件名称为gs_roach，非常驻进程，执行完后即退出。整个过程是一个在线过程，业务不中断。
2.9 负载均衡
由于我们采用的是多CN架构，每个CN均可以接受任务，对于客户端而言，连接任何CN均可以，没有一个统一分配的入口，当连接到一个CN上的SQL过多时，该CN将成为系统的瓶颈。
负载均衡就是为了解决这个问题，对外提供一个统一的IP与端口，连接进来后均匀分发到各个CN上分别执行，结果返回由CN直接返回给客户端，这样便使得各个CN任务均匀。
负载均衡通过开源软件LVS实现，工作于操作系统的内核态，为一个内核模块，使用keepalived软件实现LVS的高可用，防止LVS的单点故障。