Greenplum属于一种看起来“较重”的数据库MPP架构，不像基于MySQL基于中间件的架构那么轻量，但是要说一些具体的场景，比如Greenplum支持存储过程，支持列式存储，加上分区表和内置的数据分片等多种模式，都是典型的OLAP场景，术业有专攻还是有一定道理的。
最近因为业务需求和改造需要部署几套GP集群，总体来说也是需要解决以前的一些顽疾并加以改进，运行几个上百节点的集群还是有一定的压力的，不过前几年在飞祥同学的劳动成果之上，整个集群还是比较稳定的，在运行中也发现了一些额外的问题和痛点。
1）之前的GPsegment数量设计过度，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror,导致一旦出现Segment节点不可用，对于整个集群的稳定性会是一个大的隐患，最尴尬的莫过于一个Segment节点不可用，另外一个Segment节点负载过高，最后集群不可用，所幸这种情况暂未出现
2）GP集群的存储资源和性能的平衡不够。GP存储对标基本都是百TB,相对来说和我们所说的大数据体系的PB还是有很大差异的，GP里面计算的数据总体都是比较重要，而且总体的存储容量不会特别大，磁盘现在有8T的规格，如果放12块盘，则RAID-5会有近70多T的存储空间，而RAID-10则有48T左右的空间，如果RAID-5同时坏了2块盘就尴尬了，但是对于RAID-10来说还是有转机的，这个情况之前碰到过一次，在替换一块坏盘的时候，工程师发现另外一块盘也快坏了，RAID-5要一块一块的换，当时还因为这个熬了个通宵，想了很多预案，说了这么多是想表达，GP存储的容量不用那么大，如果在损失一定存储容量的基础上能够最大程度降低隐患是很划算的，所以在存储容量和性能的综合之上，我们是选择了RAID-10
3)集群的验收和保障工作补充。如果一个GP集群用过很长一段时间就会发现启停都是一个大工程，之前启停要耗时半个小时，让小心脏压力很大。这个过程中也发现了以前遗漏了一些环节，比如性能压测，导致不太确定整个集群的支撑能力到底如何。
在此基础上，还需要额外考虑如下的一些因素：
1）集群的跨机房迁移如何做到平滑，或者影响最低，之前一次机房搬迁，导致IP变化后的集群无法启动，当时真是吓坏了，因为在这种问题面前，就是0和1的博弈，如果是0就意味着数据都丢弃了，所以在这方面还是需要做一些扎实的铺垫。
2）服务器后续过保要做硬件替换，如何能够实现滚动替换，这是在已有的基础之上需要前瞻考虑的重要点，几年后的服务器过保如何应对，如果有了可靠的方案，以后也会从容一些。
3）GP的版本和基础环境需要同步升级，比如我们目前的主流操作系统为CentOS7,如果继续使用CentOS6就不应该了，同时对于GP的版本也需要重新评估，在较新版本和稳定版本之间进行平衡。
整个GP集群的部署架构如下：
Greenplum是我知道的数据库中的角色最完整的。Master,Standby,Primary,Mirror,各种数据库中的不同角色在这里有一套完整的体系命名。
新的这一套环境注定在我手中构建，所以我希望完善以下的一些细节。
1）Greenplum的版本选择，目前有两个主要的版本类别，一个是开源版（OpenSourcedistribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了开源版本的6.16.2，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。
2）GP的容量规划，这一次经过讨论是选择了折中的配置，即（6+6）*10+2，具体解释就是一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby
3)内核参数的配置和调整
除了基础的kernel.shmmax和kernel.shmall配置之外，还有如下的一些配置需要调整：
vm.swappiness=10
vm.zone_reclaim_mode=0
vm.dirty_expire_centisecs=
vm.dirty_writeback_centisecs=
vm.dirty_background_ratio=0#SeeSystemMemory
vm.dirty_ratio=0
vm.dirty_background_bytes=
vm.dirty_bytes=
vm.min_free_kbytes=
vm.over