简介面向大数据平台运维人员与数据库开发者的 Greenplum 安装部署资料包针对 CentOS 7 环境提供从环境准备、集群配置到服务启动的一整套安装素材适合需要快速搭建 MPP 分析型数据库、验证海量数据查询与数据仓库场景的技术人员使用。压缩包共 32 个文件、约 66.11MB以 yml 和 yaml 编排文件、sh 执行脚本、j2 配置模板为主辅以 ini 主机参数、sql 初始化语句、makefile 编译指令以及 rpm 安装包和许可说明覆盖部署流程中的配置、编排、启动与清理环节。已有 253 人学习下载。读者可据此了解集群编排的目录组织方式掌握主机清单与参数模板的对应关系并借助安装、启动、卸载及失败重试脚本梳理标准化部署与排错思路对定制化开发和环境复现也有参考价值。1. CentOS 7 上装 Greenplum真正难的往往不是那条安装命令三台 CentOS 7 的虚拟机一台 master、两台 segmentGreenplum 装到第三天gpstart每次卡在“Waiting for segment databases to be ready”等到超时退出日志里只有一句“could not create shared memory segment”。最后发现是vm.overcommit_memory和kernel.shmmax没有对齐包是装上了集群就是起不来。CentOS 7 上装 Greenplum 就是这种活按文档走表面一步不差真跑起来处处是坑。系统版本停在 7.9Python 2 和 Python 3 混着用systemd 接管了一部分资源限制任何一处没对上gpinitsystem就会在建库中途退出。greenplum_installer-centos7 这套东西干的事是把分散在十几页文档里的准备动作固定成可重复执行的顺序下面按它的执行阶段拆开写每一步都给等价命令脚本跑挂了也能手工补位。第一次在 CentOS 7 上搭测试集群的开发或者要给预发环境重装一套的运维都可以照着走。2. 版本与环境基线Greenplum 6.x 在 CentOS 7 上要满足什么装 Greenplum 之前先把变量减到最少确定版本、确定拓扑、确定系统基线。这三件事没定下来后面每敲一条命令都要犹豫一次出问题也不知道该怀疑哪一层。我一般把它们放在同一次变更窗口里做完做完再动安装包。2.1 版本选择Greenplum 6.x 与 7.x 在 CentOS 7 上的取舍CentOS 7 上能装 Greenplum 6.x也能装 7.x但两者的运行时依赖完全不是一回事。6.x 的管理工具链跑在 Python 2.7 上而 CentOS 7 自带的/usr/bin/python正好就是 2.7装上就能用7.x 把工具链挪到了 Python 3CentOS 7 默认的 python3 版本又偏老某些辅助脚本会挑解释器版本属于装完能跑、跑久了才知道哪里别扭的类型。维度Greenplum 6.xGreenplum 7.x管理工具运行时Python 2.7Python 3CentOS 7 适配度官方 el7 包长期在 7.x 上验证过有 el7 包但依赖更挑配置模板兼容性老模板基本能直接用部分旧参数被移除照抄会报错适合的场景CentOS 7 上的测试、预发、教学集群新规划集群或已在做版本升级我一般给 CentOS 7 选 6.x 的后期小版本理由很实际系统自带解释器对得上出问题能在文档和社区里找到同版本的答案。选 7.x 也不是不行但要有心理准备——照着 6.x 的gpinitsystem_config抄过去会在初始化阶段收到一堆参数已废弃的告警严重的直接中止。版本一旦定下来就把安装包版本号写进变更单别出现“三台机器装了两个小版本”这种事那是最难查的一类不一致。2.2 主机规划hostname、hosts 和那张 hostfileGreenplum 对主机名的要求比大多数中间件严格每台机器的 hostname 必须能解析到真实网卡地址不能落到127.0.0.1正向反向都要通。计划阶段就把三台机器的角色、IP、主机名定死后面所有配置文件都从这里抄。# 三台机器统一执行设置主机名并确认解析 hostnamectl set-hostname mdw # sdw1 / sdw2 各自替换 cat /etc/hosts EOF 192.168.56.10 mdw 192.168.56.11 sdw1 192.168.56.12 sdw2 EOF # 验证正向、反向、以及 hostname -f 都要能出结果 getent hosts mdw getent hosts 192.168.56.10 hostname -f ping -c 1 sdw1/etc/hosts里最容易写错的是把主机名挂到127.0.0.1那一行后面本地ping mdw通得很好看但gpssh-exkeys分发密钥时会连到自己身上后面初始化就报“hostname is not resolvable”。hostname -f必须返回带域名后缀或至少返回主机名本身返回空说明/etc/hostname和 hosts 没对上。这套检查要在装包之前做完装完再改主机名gp_segment_configuration里存的还是旧名字只能重装。2.3 依赖包与 Python 2.7别急着把 python 指向 python3最小化安装的 CentOS 7 缺的东西比想象中多。Greenplum 的 rpm 会带一部分依赖但apr、apr-util、libevent、rsync、perl这些经常要手工补。缺rsync的表现是gpssh分发文件时报 command not found缺perl则是某些包装脚本直接退出报错信息还不在主日志里。# 最小化安装的 CentOS 7 上这几个包大概率要补 yum install -y apr apr-util bash bzip2 curl krb5-libs libevent \ libxml2 libyaml openssl-libs perl rsync python2 # 确认解释器现状别急着动 /usr/bin/python ls -l /usr/bin/python /usr/bin/python2 /usr/bin/python3 python -V这里有一条踩过很多次的线有人为了跑别的脚本执行ln -sf /usr/bin/python3 /usr/bin/python结果yum当场报 SyntaxError 罢工——因为 CentOS 7 的 yum 本身就是 Python 2 写的。Greenplum 6.x 的gpstate、gpssh这些工具同样依赖 python2把默认解释器换掉装包阶段没事装完一跑管理命令就炸。真需要 python3 就用python3全名调用别动/usr/bin/python这个符号链接这是我在 CentOS 7 上给自己定的规矩。3. 系统层准备installer 在装包之前先做掉的三件事greenplum_installer-centos7 的第一阶段并不碰 Greenplum 的安装包它只做三件事建账号、通免密、把系统参数写死。这三件事手工做也就二十分钟但要在三台机器上做一遍并且保证完全一致脚本化的价值就出来了。理解这三步在干什么脚本中途失败时才知道从哪接上。3.1 账号与目录所有路径都归 gpadminGreenplum 不允许用 root 跑数据库进程必须有一个专用账号而且这个账号的 uid、gid 在全集群必须一致。不一致的后果不是装不上而是装完做扩容、迁移数据目录时文件属主对不上报权限错误那时候再回头改 uid 就麻烦了。# 三台机器执行同一段uid/gid 固定下来别让系统自动分配 groupadd -g 530 gpadmin useradd -g gpadmin -u 530 -m -s /bin/bash gpadmin echo gpadmin | passwd --stdin gpadmin # 数据目录规划master 一份每块盘一组 primary/mirror mkdir -p /data/master /data1/primary /data1/mirror chown -R gpadmin:gpadmin /data /data1 chmod 755 /data /data1-u 530、-g 530这两个数字是习惯用法重点是三台机器写同一个数字。目录规划上/data/master只放 master 的元数据/data1/primary放 segment 数据两块盘分开是底线——master 和 segment 抢同一块盘初始化阶段就可能因为空间不足中止。另外顺手把 SELinux 关掉或者设成 permissivesetenforce 0加改/etc/selinux/config里的SELINUXpermissive不改的话gpinitsystem在写数据目录时会被拦报错信息还很含糊。3.2 免密 SSHgpssh-exkeys 之前先手工验一遍Greenplum 的节点之间是全互联的互信关系不只是 master 到 segment 单向。gpssh-exkeys会尝试把每个节点之间的密钥都打通如果之前没有基础信任它会在交互式密码提示那里停下来放在脚本里就是静默卡死。su - gpadmin # 1) 生成自己的密钥不带口令方便自动化 ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/id_rsa # 2) 先扫一遍主机指纹避免首次连接卡在 yes/no ssh-keyscan -H mdw sdw1 sdw2 ~/.ssh/known_hosts # 3) 把 mdw 的公钥推到所有节点含自己 for h in mdw sdw1 sdw2; do ssh-copy-id -i ~/.ssh/id_rsa.pub gpadmin$h done # 4) 手工验证任意两台之间都要能免密登录 ssh sdw1 hostname; whoami ssh sdw2 hostname; whoamissh-keyscan这一步经常被省略结果自动化脚本卡在“Are you sure you want to continue connecting”等十分钟才发现是人在等一个 yes。手工验证通过之后再跑gpssh-exkeys -f hostfile_exkeys补全剩余方向它就不会再问密码了。hostfile 里每行一个主机名不要写 IP也不要写gpadminmdw这种带用户名的形式。3.3 系统参数sysctl、limits、THP 三处必须落盘这一节是 CentOS 7 上装 Greenplum 最容易漏的地方也是装完起不来时最该先看的地方。共享内存、信号量、文件句柄、透明大页四个东西缺一个症状各不相同。# /etc/sysctl.conf 追加然后 sysctl -p 生效 cat /etc/sysctl.conf EOF kernel.shmmax 500000000 kernel.shmall 4000000000 kernel.shmmni 4096 kernel.sem 250 512000 100 2048 kernel.sysrq 1 kernel.core_uses_pid 1 kernel.msgmnb 65536 kernel.msgmax 65536 kernel.msgmni 2048 vm.overcommit_memory 2 vm.overcommit_ratio 95 vm.swappiness 10 net.ipv4.ip_local_port_range 1025 65535 net.ipv4.tcp_max_syn_backlog 4096 net.core.netdev_max_backlog 10000 EOF sysctl -p # 资源限制gpadmin 的 nofile / nproc 要放开 cat /etc/security/limits.conf EOF gpadmin soft nofile 524288 gpadmin hard nofile 524288 gpadmin soft nproc 131072 gpadmin hard nproc 131072 EOFkernel.shmmax我一般按物理内存的一半给shmall是页数4KB 一页给到 4000000000 这种量级是为了不让它成为瓶颈但前提是别超过物理内存总量。vm.overcommit_memory 2配overcommit_ratio 95是 Greenplum 常用的组合意思是按比例允许内存超额分配设成 0 或者比例给低了segment 启动时申请不到共享内存日志里只有一句“could not create shared memory segment”看不出是谁的问题。limits.conf对 SSH 登录生效依赖 pam_limitsCentOS 7 默认是开的但通过 systemd 拉起的服务不吃这个文件所以 Greenplum 用gpstart在 gpadmin 的 shell 里起进程反而是好事。透明大页单独说因为它不写在 sysctl 里却会影响运行表现# 立即生效 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 重启后依然生效CentOS 7 用 grubby 改内核参数 grubby --update-kernelALL --argstransparent_hugepagenever只写/sys那两行重启就没了grubby这条是给 CentOS 7 的持久化做法改完reboot一次再用cat /sys/kernel/mm/transparent_hugepage/enabled复核输出里[never]带方括号才算生效。这三处参数三台机器必须一模一样装之前对一遍比装完查一天划算。4. 安装与初始化从 RPM 到 gpinitsystem 的完整执行顺序系统层准备完之后真正的安装动作只有三下装 rpm、改配置模板、跑gpinitsystem。顺序不能颠倒尤其别先装包再去调内核参数——gpinitsystem失败一次就得清数据目录重来来两遍人就烦了。4.1 装 RPM 与 greenplum_path.shcd /opt/soft # 包名以实际下载的 6.x 小版本为准这里只示意结构 yum install -y ./greenplum-db-6.x-el7-x86_64.rpm # rpm 默认装到 /usr/local/greenplum-db-version并把属主交给 gpadmin chown -R gpadmin:gpadmin /usr/local/greenplum-db-* # 环境变量固化到 gpadmin 的 .bashrc echo source /usr/local/greenplum-db/greenplum_path.sh /home/gpadmin/.bashrc su - gpadmin source /usr/local/greenplum-db/greenplum_path.sh which gpinitsystem postgres --gp-versiongreenplum_path.sh不是可有可无的便利脚本它设定了PATH、LD_LIBRARY_PATH、PYTHONPATH这几组关键变量Greenplum 自带一批私有.so不 source 它gpinitsystem、gpstate全部报 command not found或者更糟——找到了命令但加载库失败。postgres --gp-version是我装完必敲的一条输出里带 Greenplum 版本号和 build commit能确认装的是哪个包、有没有装错架构。三台机器都要装装完都跑一遍这条输出对比一下版本不一致就趁早重装。4.2 gpinitsystem_config这五六个参数必须改配置模板决定了集群长什么样改错一项初始化未必失败但用起来就是别扭。cat /home/gpadmin/gpinitsystem_config EOF ARRAY_NAMEgp_test SEG_PREFIXgpseg PORT_BASE6000 declare -a DATA_DIRECTORY(/data1/primary /data2/primary) MASTER_HOSTNAMEmdw MASTER_DIRECTORY/data/master MASTER_PORT5432 TRUSTED_SHELLssh ENCODINGUNICODE DATABASE_NAMEgpadmin HEAP_CHECKSUMon HBA_HOSTNAMES0 EOFDATA_DIRECTORY数组里的元素个数决定每台 segment 主机上起几个 primary 实例写两个目录就是每台两个实例机器上的数据盘也要相应准备两块。PORT_BASE6000是起始端口实际实例端口从它往上排选之前用ss -lntp确认这段没被别的服务占着。MASTER_HOSTNAME必须和hostname -f的输出对得上对不上就是前面说的“not resolvable”。HBA_HOSTNAMES0表示pg_hba.conf里用 IP 而不是主机名写访问规则改过主机名的集群就知道这条有多省事。HEAP_CHECKSUMon在建库时定下来建完不能改6.x 默认就是开的别手贱改成 off 去做所谓“性能优化”。ENCODINGUNICODE对应的 locale 必须真的装在系统上缺 locale 是后面排查章节里的一条。配套还要有 hostfilecat /home/gpadmin/hostfile_gpinitsystem EOF sdw1 sdw2 EOF # 只写 segment 主机master 不写进来4.3 跑 gpinitsystem返回码、日志和第一次 gpstartcd /home/gpadmin # -c 指定配置模板-h 指定 segment 主机清单 gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem # 初始化完成后启动集群 gpstart -a gpstate -sgpinitsystem跑到一半会打印一段配置摘要让你输入y确认脚本化执行时用-a参数免交互。它的日志默认落在~/gpAdminLogs/下文件名带时间戳这一点比很多工具贴心——失败之后第一件事不是重跑而是翻这份日志它会明确指出卡在哪台机器、哪个目录、哪个系统调用。返回码 0 也不代表万事大吉只能说明初始化流程走完了集群能不能用还得看gpstart和gpstate。gpstart -a里的-a同样是免确认。4.4 standby 与 mirror初始化之后再补代价明显更高gpinitsystem支持在初始化时用-s指定 standby master用-B带一份 mirror 配置。这两样东西如果在初始化阶段没规划好后面补是能补但要停集群、改配置、重新同步测试环境里多花半小时生产环境里就是一次变更窗口。# 初始化时直接带 standby mastersdw2 兼做 standby gpinitsystem -c gpinitsystem_config -h hostfile_gpinitsystem -s sdw2 # 已经初始化完但没有 mirror 的集群事后补 gpaddmirrors -p 7000 -m mirror_config_file-s sdw2的意思是 standby master 和 sdw2 上的 segment 共用一台机器测试环境资源紧的时候常见但要记得它的内存和 IO 是被分摊的。gpaddmirrors -p 7000里的 7000 是 mirror 实例的起始端口必须和 primary 的 6000 段错开两段撞上了会起不来。mirror 补完之后用gpstate -e看同步进度全部Synchronized才算完成中途别急着做压测。5. 排查清单CentOS 7 上装 Greenplum 的五个高频翻车点出问题的地方翻来覆去就那几个按阶段归类记下来下次遇到能省掉一半时间。下面五条都是我在 CentOS 7 上真实遇到过的现象写清楚是因为报错信息往往出现在预料之外的位置。5.1 初始化阶段解析、残留目录和 locale现象一gpinitsystem刚开始就报Hostname mdw is not resolvable或者gpssh-exkeys长时间无响应。原因/etc/hosts把主机名映射到了127.0.0.1或者sshd没启动、known_hosts里留着旧指纹导致 ssh 直接拒绝连接。还有一种情况是hostname -f返回空Greenplum 拿不到完整主机名。解决getent hosts mdw确认解析结果是不是真实网卡地址hostname -f确认输出非空systemctl status sshd确认服务在跑。旧指纹用ssh-keygen -R mdw清掉再重连。主机名改动之后要重启一次机器别指望hostnamectl改完立刻全局生效。现象二gpinitsystem报Directory /data1/primary is not empty或者报权限不足。原因上一次初始化失败留下的残留目录里已经有gpseg0之类的子目录或者目录属主还是 root因为先建目录后建账号。解决确认里面没有需要的数据之后rm -rf /data1/primary/*再chown -R gpadmin:gpadmin /data1。养成习惯每次重跑gpinitsystem之前先清空数据目录别指望它能覆盖。现象三初始化中途退出日志里出现The locale en_US.UTF-8 is not installed或者编码相关的错误。原因ENCODINGUNICODE要求对应的 locale 真的存在于系统里最小化安装的 CentOS 7 可能只带了C.UTF-8或者什么都没带。解决localedef -i en_US -f UTF-8 en_US.UTF-8生成 locale然后export LANGen_US.UTF-8再跑一次或者把ENCODING改成系统里已有的编码。这一步做完用locale -a | grep -i utf复核。5.2 启动阶段共享内存与内存超额分配现象四gpstart卡在Waiting for segment databases to be ready等到超时退出segment 的pg_log里写着could not create shared memory segment: Invalid argument。原因kernel.shmmax小于 segment 实际要申请的共享内存大小或者vm.overcommit_memory 2配的overcommit_ratio太低导致申请被内核拒绝。还有一种隐蔽情况sysctl参数写在了/etc/sysctl.d/下的某个文件里但被排序更靠后的文件覆盖了sysctl -p之后看着是对的重启又回去了。解决先用sysctl kernel.shmmax kernel.shmall vm.overcommit_memory vm.overcommit_ratio复核当前生效值别只看配置文件。shmmax按物理内存一半给overcommit_ratio给到 95改完sysctl -p再试。如果还是不行去看具体那个 segment 的pg_log里打印的请求大小拿它跟shmmax比一眼就知道差多少。5.3 环境类Python 指向与首次连接现象五装完之后gpstate报SyntaxError: invalid syntax错误指向某一行print语句严重的时候yum也不能用了。原因/usr/bin/python被改成了 python3而 Greenplum 6.x 的管理工具和 CentOS 7 的 yum 都是 Python 2 写的。解决ls -l /usr/bin/python看指向把它改回python2.7需要 python3 的地方显式写python3。改之前先rpm -V python之类的命令确认系统包状态别在已经乱掉的环境上继续叠操作。这类问题属于一改全崩型动这个符号链接之前多问一句“真的需要吗”。6. 验证跑通怎么确认这套 Greenplum 不只是一个看起来像装好的空壳gpstart返回成功、gpstate -s打印出一大段状态很多人到这一步就收工了。实际上这才是最容易出问题的地方进程起来了但 segment 没全部注册、数据分布歪了、mirror 没同步这些都不影响“看起来装好了”。我一般按三层验证从进程层往下走到数据层。先看集群结构这一条能一次性暴露大部分初始化问题-- 每个 segment 的注册状态、角色、端口 SELECT dbid, content, role, preferred_role, status, hostname, port FROM gp_segment_configuration ORDER BY dbid;期望结果是 1 行 mastercontent -1 N 行 primaryrole pstatus全部是u。出现d说明该 segment 没起来出现role m说明主备发生了切换测试环境里刚装完就切换基本可以判定是资源参数没配对。接着用gpstate -e看有没有 segment 处于非同步状态输出为空才是正常的。再往下一层验证分布式写入和查询真的能跑通-- 建表、灌一批数据、看看分布是否均匀 CREATE TABLE t_verify(id int, note text) DISTRIBUTED BY (id); INSERT INTO t_verify SELECT generate_series(1, 100000), ok; SELECT gp_segment_id, count(*) AS rows FROM t_verify GROUP BY gp_segment_id ORDER BY gp_segment_id;每行的rows数量应该大致相当差距过大说明分布键选得不好或者某个 segment 没参与。这一步比gpstate更能说明问题——进程活着但查询走不到某个 segment在gpstate里是完全看不出来的。最后DROP TABLE t_verify收尾别在测试集群里留垃圾表。验证层命令期望结果进程层gpstate -s所有 segment 状态为 UP结构层gp_segment_configurationstatus 全urole 符合规划同步层gpstate -e无输出数据层建表 分组统计各 segment 行数大致均衡从那以后我每次装完 Greenplum都强制自己走一遍这三层尤其是最后那个建表统计哪怕只是测试集群也照做——它花不到两分钟却能挡掉后面几小时的“为什么查询这么慢”。希望帮到你。本文还有配套的精品资源点击获取
