Greenplum属于一种看似“重量级”的数据库MPP架构，没有基于MySQL的基于中间件的架构那么轻量，但是要说说一些具体的场景，比如Greenplum支持存储过程，它支持列式存储，加上分区表和内置数据分片等多种模式，这是典型的OLAP场景，专攻技术行业是有意义的。最近由于业务需要和改造，需要部署多套GP集群。总的来说，过去的一些顽固问题需要解决和改进。跑几个几百节点的集群还是有一定压力的。不过飞象同学这几年根据劳动成果，整个集群比较稳定，在运行过程中也发现了一些额外的问题和痛点。1）之前设计的GP段数过多。由于资源限制，过多考虑了功能和性能，没有考虑集群的稳定性和资源均衡。每个物理机节点部署10个Primary和10个主节点。一个Mirror，一旦某个Segment节点不可用，将会对整个集群的稳定性造成很大的隐患。最尴尬的是一个segment节点不可用，另一个segment节点负载过高，最后导致集群不可用。幸运的是，这2)GP集群的存储资源和性能之间的平衡还不够。GP存储基准基本都是几百TB，跟我们说的大数据系统的PB还是比较不一样的。GP里面计算出来的数据一般都是比较重要的，整体存储容量不会特别大，现在盘的规格是8T。如果放置12块磁盘，RAID-5的存储空间将近70T，而RAID-10的存储空间约为48T。如果RAID-5的两块硬盘同时失效，就尴尬了，不过RAID-10还是有转机的。这种情况以前遇到过一次。在更换一个坏盘时，工程师发现另一个盘也快坏了。RAID-5需要一个一个更换。当时，我为此彻夜未眠，想了很多打算。说了这么多是想表达GP的存储容量不需要那么大。在损失一定存储容量的基础上将隐患降到最低是非常划算的，所以基于存储容量和性能的结合，我们选择了RAID-103）集群进行验收和安全工作补充。如果一个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和Standby3）内核参数的配置和调整除了基本的kernel.shmmax和kernel.shmall配置外，还有一些配置需要调整如下：虚拟机。swappiness=10vm.zone_reclaim_mode=0vm.dirty_expire_centisecs=500vm.dirty_writeback_centisecs=100vm.dirty_background_ratio=0#SeeSystemMemoryvm.dirty_ratio=0vm.dirty_background_bytes=1610612736vm.dirty_bytes=4294967296vm.min_free_kbytes=3943084vm.overcommit_memory=2kernel.sem=50020480002004096集群部署的大体流程:1)首先是配置/etc/hosts，需要整理好所有节点的IP和主机名。2）配置用户，很常规的步骤groupaddgpadminuseraddgpadmin-ggpadminpasswdgpadmin3）配置sysctl.conf和资源配置4）使用rpm方式安装yuminstall-yaprapr-utilbzip2krb5-develzip#rpm-ivhopen-source-greenplum-db-6.16.2-rhel7-x86_64.rpmPreparing...##################################[100%]更新/安装...1：开源-greenplum-db-6-6.16.2###################################[100%]5)配置两个host文件也是为了方便以后统一部署。这里建议先开启gpadmin的sudo权限，一些比较复杂的批量操作可以通过gpssh处理。6）通过gpssh-exkeys打通ssh信任关系，这里需要吐槽一下这个ssh互信，端口必须是22，不然处理gpssh-exkeys-fhostlist会很麻烦7）比较复杂的步骤是打包master的Greenplum-db-6.16。涉及到文件打包，批量传输和配置，可以使用gpscp和gpssh，比如gpscp传输文件，下面命令将传输到/tmp目录下gpscp-f/usr/local/greenplum-db/conf/hostlist/tmp/greenplum-db-6.16.2.tar.gz=:/tmp8)master节点需要单独配置相关目录，而segment节点的目录可以提前规划好，比如我们把primary和镜像在不同的分区。mkdir-p/data1/gpdata/gpdatap1mkdir-p/data1/gpdata/gpdatap2mkdir-p/data2/gpdata/gpdatam1mkdir-p/data2/gpdata/gpdatam29）整个过程中最关键的是gpinitsystem_config配置，因为id的Segment节点的配置、命名、端口间隔都是按照一定的规则动态生成的，所以要格外注意目录的配置。10）部署GP集群最关键的命令是gpinitsystem-cgpinitsystem_config-s[standby_hostname]整个过程大概5分钟到10分钟左右完成。这里也走了不少弯路，比如一些配置不完整，防火墙权限不够，导致部署时界面卡在那里。例如，其中一个问题是/etc/hosts配置不完整导致Primary可以启动，但是Mirror无法启动。问题看起来很奇怪，GP日志中的信息也很简短。如果难以定位，可以直接在对应的segment节点上查看对应的日志。检查日志是一项技术任务。如果冻结，请不要等待，你得看看后端卡在什么地方，需要同步查看日志的刷新，定位并修正问题。在这方面，GP的一些安装体验还是比较粗糙的。安装部署就像一道无形的门槛。只要你做一次，我相信这些步骤是非常简单的。相反，它就像一座无法绕过的大山。对于安装和部署，最全面的文档是官方文档。
