作者介绍
杨建荣，dbaplus社联合发起⼈，竞技世界资深DBA，前搜狐畅游数据库专家，Oracle ACE，腾讯云TVP。具有⼗余年数据库开发和运维经验，⽬前专注于开源技术、运维⾃动化和性能调优。《Oracle/MySQL DBA⼯作笔记》作者，坚持通过、博客进⾏技术分享，已坚持2200多天。
最近对离线数仓体系进⾏了扩容和架构改造，也算是⼀波三折，出了很多⼩插曲，有⼀些改进点对我们来说也是真空地带，通过对⽐和模拟压测总算是得到了预期的结果，这⽅⾯尤其值得⼀提的是郭运凯同学的敬业，很多前置的⼯作，优化和应⽤压测的⼯作都是他完成的。
防伪胶带整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集架构的优化和改造。
⼀、集架构改造的⽬标
在之前也总结过⽬前存在的⼀些潜在问题，也是本次部署架构改进的⽬标：
1、之前的GP segment数量设计过度，因为资源限制，过多考虑了功能和性能，对于集的稳定性和资
源平衡性考虑有所⽋缺，在每个物理机节点上部署了10个Primary，10个Mirror，⼀旦1个服务器节点不可⽤，整个集⼏乎⽆法⽀撑业务。 2、GP集的存储资源和性能的平衡不够，GP存储基于RAID-5，如果出现坏盘，磁盘重构的代价⽐较⾼，⽽且重构期间如果再出现坏盘，就会⾮常被动，⽽且对于离线数仓的数据质量要求较⾼，存储容量相对不是很⼤，所以在存储容量和性能的综合之上，我们选择了RAID-10。
3、集的异常场景的恢复需要完善，集在异常情况下（如服务器异常宕机，数据节点不可⽤，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在⼀些迁移和改造中，相对底⽓不⾜，存在⼀些知识盲区。 4、集版本过低，功能和性能上存在改进空间。毕竟这个集是4年前的版本，底层的PG节点的版本也⽐较旧了，在功能上和性能上都有⼀定的期望，⾄少能够与时俱进。
5、操作系统版本升级，之前的操作系统是基于CentOS6，⾄少需要适配CentOS 7 。
6、集TPCH压测验收，集在完成部署之后，需要做⼀次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能⽬标。 此外在应⽤层⾯也有⼀些考虑，总⽽⾔之，是希望能够解决绝⼤多数的痛点问题，⽆论是在系统层⾯，
还是应⽤层⾯，都能上⼀个台阶。
⼆、集规划设计的选型和思考
明确了⽬标，就是拆分任务来规划设计了，在规划设计⽅⾯主要有如下的⼏个问题：
1、Greenplum的版本选择，⽬前有两个主要的版本类别，⼀个是开源版（Open Source distribution）和Pivotal官⽅版，它们的其中⼀个差异就是官⽅版需要注册，签署协议，在此基础上还有GPCC等⼯具可以⽤，⽽开源版本可以实现源码编译或者rpm安装，⽆法配置GPCC。综合来看，我们选择了开源版本的6.16.2，这其中也询问了⼀些⾏业朋友，特意选择了⼏个涉及稳定性bug修复的版本。
2、数据集市的技术选型，在数据集市的技术选型⽅⾯起初我是⽐较坚持基于PostgreSQL的模式，⽽业务侧是希望对于⼀些较为复杂的逻辑能够通过GP去⽀撑，⼀来⼆去之后，加上我咨询了⼀些⾏业朋友的意见，是可以选择基于GP的⽅案，于是我们就抱着试⼀试的⽅式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集来⽀撑。
3、GP的容量规划，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，⽐如⼀共12台服务器，其中有10台服务器是Segment节点，每台上⾯部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）*10+2，整体的配置情况类似下⾯的模式。
4、部署架构⽅案选型，部署架构想起来⽐较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby 节点如果混⽤还是能够节省⼀些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从⾛⼊部署阶段之后，很快就发现这种交叉部署的模式是不可⾏的，或者说有⼀些复杂度。
除此之外，在单个GP集的部署架构层⾯，还有4类⽅案考虑。
•⽅案1：Master,Standby和segment混合部署
•⽅案2：Master,Standby和segment独⽴部署，整个集的节点数会少⼀些
•⽅案3：Segment独⽴部署，Master,Standby虚拟机部署
•⽅案4：最⼩化单节点集部署（这是数据集市最保底的⽅案）
这⽅⾯存在较⼤的发挥空间，⽽且总体来说这种验证磨合的成本也相对⽐较⾼，实践给我上了⼀课，越是想⾛捷径，越是会让你⾛⼀些弯路，⽽且有些时候的优化其实我也不知道改怎么往下⾛，感觉已经⽆路可⾛，所以上⾯这4种⽅案其实我们都做了相关的测试和验证。
三、集架构的详细设计和实践
1、设计详细的部署架构图
在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror，服务器两两映射。
卡因是什么制成的>钢筋剥肋滚丝机2、内核参数优化
按照官⽅⽂档的建议和具体的配置情况，我们对内核参数做了如下的配置：vm.swappiness=10
<_reclaim_mode = 0
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.dirty_background_ratio = 0 # See System Memory电极箔
vm.dirty_ratio = 0
vm.dirty_background_bytes = 1610612736
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 3943084
vm.overcommit_memory=2
kernel.sem = 500 2048000 200 4096
四、集部署步骤
1、⾸先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。
2、配置⽤户，很常规的步骤
groupadd gpadmin
groupadd gpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3、配置f和资源配置
4、使⽤rpm模式安装
# yum install -y apr apr-util bzip2 krb5-devel zip
# rpm -ivh open-source-greenplum-db-6.16.2-rhel7-x86_64.rpm
natr-241
5、配置两个host⽂件，也是为了后⾯进⾏统⼀部署⽅便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理⼀些较为复杂的批量操作
6、通过gpssh-exkeys来打通ssh信任关系，这⾥需要吐槽这个ssh互信，端⼝还得是22，否则处理起来很⿇烦，需要修改/etc/ssh/sshd_config⽂件橡塑发泡保温材料
gpssh-exkeys -f hostlist
7、较为复杂的⼀步是打包master的Greenplum-db-6.16.2软件，然后分发到各个segment机器中，整个过程涉及⽂件打包，批量传输和配置，可以借助gpscp和gpssh，⽐如gpscp传输⽂件，如下的命令会传输到/tmp⽬录下
gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6.16. =:/tmp
或者说在每台服务器上⾯直接rpm -ivh安装也可以。
8、Master节点需要单独配置相关的⽬录，⽽Segment节点的⽬录可以提前规划好，⽐如我们把Primary和Mirror放在不同的分区。
mkdir -p /data1/gpdata/gpdatap1
mkdir -p /data1/gpdata/gpdatap2
mkdir -p /data2/gpdata/gpdatam1
mkdir -p /data2/gpdata/gpdatam2
9、整个过程⾥最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端⼝区间都是根据⼀定的规则来动态⽣成的，所以对于⽬录的配置需要额外注意。
10、部署GP集最关键的命令是
gpinitsystem -c gpinitsystem_config -s 【standby_hostname】
其中⽂件gpinitsystem_config的主要内容如下：
MASTER_HOSTNAME=xxxx
declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1 /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3
/data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)
TRUSTED_SHELL=ssh
TRUSTED_SHELL=ssh
declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1 /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)
MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts
整个过程⼤约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的⽇志查看是否有异常，异常情况下的体验不是很好，可能会⽩等。
五、集部署问题梳理
集部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，⽬录权限等问题，我提另外⼏个：
1、资源配置问题，如果/etc/f的资源配置不⾜会在安装时有如下的警告：
gpinitsystem:xxxx:gpadmin-[WARN]:-Standby Master open file limit is 51200 should be >= 65535
2、⽹络问题，集部署完成后可以正常操作，但是在查询数据的时候会抛出错误，⽐如SQL是这样的，看起来很简单：select count(*) from customer，但是会抛出如下的错误：
WARNING: interconnect may encountered a network error, please check your network (seg9 slice1 xxxx:6003
pid=268865)
DETAIL: Failed to send packet (seq 1) to 127.0.0.1:3106 (pid 65933 cid 4) after 100 retries.
WARNING: interconnect may encountered a network error, please check your network (seg6 slice1 xxxx:6000
pid=268862)
这个问题的主要原因还是和防⽕墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。
对于数据节点可以开放略⼤的权限，如：
⼊⼝的配置：
-A INPUT -p all -s xxxxx -j ACCEPT
出⼝的配置：
-A OUTPUT -p all -s xxxxx -j ACCEPT
3、⽹络配置问题，这个问题⽐较诡异的是，报错和上⾯是⼀样的，但是在排除了防⽕墙配置后，select count(*) from customer；这样的语句是可以执⾏的，但是执⾏的等待时间较长，⽐如表lineitem这表⽐较⼤，过亿的数据量，，在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。
为了排查⽹络问题，使⽤gpcheckperf等⼯具也做过测试，4节点和10节点的基础配置也是相同的。
gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp
$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
#127.0.0.1 test-dbs-gp-128-230
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议