Greenplum介绍
组织架构
Greenplum数据库是一种大规模并行处理（MPP）数据库服务器，其架构特别针对管理大规模分析型数据仓库以及商业智能工作负载而设计。
MPP（也被称为shared nothing架构）指有两个或者更多个处理器协同执行一个操作的系统，每一个处理器都有其自己的内存、操作系统和磁盘。
Greenplum数据库通过将数据和处理负载分布在多个服务器或者主机上来存储和处理大量的数据。Greenplum主要由Master节点、Segment节点、interconnect三大部分组成。
Figure 1. 高层的Greenplum数据库架构
Master Host：1.它是Greenplum数据库系统的入口，可接受客户端连接并处理系统用户发出的SQL命令。2.Master节点将工作负载分发给其它数据库系统节点（segment节点），由它们存储和处理数据。3.Master节点不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据。
Master是全局系统目录的所在地。全局系统目录是一组包含了有关Greenplum数据库系统本身的元数据的系统表。 Master上不包含任何用户数据，数据只存在于Segment之上。 Master会认证客户端连接、处理到来的SQL命令、在Segment之间分布工作负载、协调每一个Segment返回的结果以及把最终结果呈现给客户端程序。
Segments Host：1.它是数据存储和数据查询处理的节点。2.用户定义的表及其索引分布在Greenplum数据库系统中的可用Segments中，每个Segments包含数据的不同部分。3.用户不会直接与Greenplum数据库系统中的Segment操作，而是通过Master Host进行操作。
Greenplum数据库的Segment实例是独立的PostgreSQL数据库，每一个都存储了数据的一部分并且执行查询处理的主要部分。当一个用户通过Greenplum的Master连接到数据库并且发出一个查询时，在每一个Segment数据库上都会创建一些进程来处理该查询的工作。服务于Segment数据的数据库服务器进程运行在相应的Segment实例之下。 用户通过Master与一个Greenplum数据库系统中的Segment交互。Segment运行在被称作Segment主机的服务器上。 一台Segment主机通常运行2至8个Greenplum的Segment，这取决于CPU核数、RAM、存储、网络接口和工作负载。 从Greenplum数据库获得最佳性能的关键在于在大量能力相同的Segment之间平均地分布数据和工作负载，这样所有的Segment可以同时开始为一个任务工作并且同时完成它们的工作。
Interconect是Greenplum数据库架构中的网络层,负责不同PostgreSQL实例之间的通信。Interconnect指的是Segment之间的进程间通信以及这种通信所依赖的网络设施。 通过在用户的网络上部署双千兆以太网交换机以及到Greenplum数据库主机（Master和Segment）服务器的冗余千兆连接，用户可以得到非常可靠的Interconnect。
扩展
用户可以最小化停机时间，通过增加节点实例和节点主机来扩容Greenplum数据库。
随着收集额外数据并且现有数据的定期增长，数据仓库通常会随着时间的推移而不断增长。 有时，有必要增加数据库能力来联合不同的数据仓库到一个数据库中。 数据仓库也可能需要额外的计算能力（CPU）来适应新增加的分析项目。
当用户扩容数据库时，会期待如下特性：
- 可伸缩的容量和性能。当用户向一个Greenplum数据库增加资源时，得到的容量和性能就好像该系统一开始就用增加后的资源实现一样。
- 扩容期间不中断服务。常规负载（计划中的或者临时安排的）不会被中断。
- 事务一致性。
- 容错。在扩容期间，标准的容错机制（例如Segment镜像）保持活动、一致并且有效。
- 复制和灾难恢复。在扩容期间，任何现有的复制机制都继续发挥作用。在失败或者灾难事件中需要的恢复机制也保持有效。
- 处理透明。扩容处理利用了标准的Greenplum数据库机制，因此管理员能够诊断并且排查任何问题。
- 可配置的处理。扩容可能会是一个长时间运行的处理，但它可以变成按计划执行的一系列操作。扩容Schema的表允许管理员指定表被重新分布的优先级，而且扩容活动可以被暂停并且继续。
segment的故障切换和恢复
当Greenplum数据库系统中启用了镜像时，系统会在主要Segment变成不可用后自动切换到镜像Segment。 在一个Segment实例或者主机出问题的情况下，只要在剩余的活动Segment上的所有数据可用，Greenplum数据库系统就能保持可操作。
如果Master无法连接到一个Segment实例，它会在Greenplum数据库系统目录中标记该Segment实例为宕机并且把镜像Segment提升起来作为替代。 失效的Segment实例将保持无法操作的状态直到管理员采取措施将它重新恢复上线。 管理员可以在系统运行时恢复失效的Segment。 恢复进程只会复制该Segment无法操作期间错过的更改。
如果用户没有启用镜像，当一个Segment实例变得无效时整个系统将会自动关闭。在继续操作之前，用户必须恢复所有失效的Segment。
HA
Greenplum的HA体系架构
Greenplum数据库中的Master镜像
StandbyMaster 节点
选择部署主实例的备份或镜像。如果主Master主机无法运行，则备用Master主机将用作热备份。备用主服务器通过事务日志复制过程保持最新状态，该过程在备用主服务器主机上运行，并在主主机和备用主服务器主机之间同步数据。如果主主服务器发生故障，则日志复制过程将关闭，管理员可以在其位置**备用主服务器。当备用主服务器处于活动状态时，复制的日志用于在最后一次成功提交的事务时重建master主机的状态。由于主数据库不包含任何用户数据，因此仅系统目录表需要在主副本和备份副本之间进行同步。更新这些表后，更改将自动复制到备用主数据库，因此它始终与主数据库同步。
如果主Master失效，日志复制进程会停止，并且后备Master会被**以替代它的位置。 这种切换不会自动发生，而是必须由外部触发。 在**后备Master时，将用已复制的日志来重构Master主机最后一次成功提交时的状态。 被**的后备Master实际会变成Greenplum数据库的Master，它会在主端口（在Master主机和备份Master主机上必须被设置为相同）上接受客户端连接。
Segment镜像
部署Greenplum数据库系统时，可以配置Mirror实例。 Mirror节点可以使当Primary节点宕机的时候，将数据库查询转移到备份节点上。 Mirror节点通过将数据从主节点同步到从节点的事务日志复制进程保持同步。 Mirror机制在生产环境中强烈建议开启，并且是Pivotal支持所必须的。
Greenplum数据库中的散布镜像