Greenplum Database 管理员指南 (V6.2.1)

Greenplum Database 管理员指南 V6.2.1

Greenplum Database 管理员指南

版本 V6.2.1

2020 年 09 月 27 日

欢迎关注 Greenplum 官方微信公众号和加入官方社区技术讨论群：

编者工作十几年，先后供职于民企，国企，外企，截止目前，已从事 Greenplum

技术工作 10 余年，10 余年来，专注在 Greenplum 和相关技术领域，主要工作职责是

售后支持，帮助我们的 Greenplum 用户解决生产需求和技术问题，我们坚持提供最专

业的建议和解决方案，提供最专业的技术支持服务，提供最专业的落地实施支持。

十多年来，参与过的项目不计其数，有 POC 测试，有开发支持，有故障支持，有

长期驻场支持，有临时的功能支持，甚至可能会作为用户看不见的后端支持，总之，我

们的目标是，努力解决用户的一切不违背自然规律的诉求，我们跟随着 Greenplum 的

成长，见证了 Greenplum 从闭源到开源的成长历程，一路给 Greenplum 做各种补丁

脚本，也看到了 Greenplum 的大幅进步，甚至我们以前的小技巧也不再需要，持续的

进步，带来的是生态的蓬勃发展。

Greenplum Database 管理员指南 V6.2.1

序言

术语约定

： Greenplum 数据库

Master

： GP 的控制节点/实例

Standby

： GP 的备用控制节点/实例

Host(主机)

： GP 的一台独立的机器设备

Instance

： GP 的计算实例，很多时候也叫 Segment

Primary

： GP 的主计算实例

Mirror

： GP 的镜像计算实例

MPP

：大规模并行处理

算子

：执行计划中的运算操作

背景简介

多年前，编者翻译了 GP4.2.2 的 AdminGuide，如今，GP 已经历经了无数个版

本更新和迭代，编者也有了更多的感悟，放眼 GP 的中文资料，为之动容，就想着再为

GP 的发展壮大多做那么一点点贡献，挤出一点时间，重新梳理和打磨这个文档，并完

全根据最新的版本特性进行重新整理，希望能对中文爱好者提供一些帮助，在编写过程

中，仍会参考官方文档，但绝不是简单的翻译，甚至有些内容会与官方文档不一致。

编者提醒，升级版本极其重要，4 版本早该淘汰了，5 版本和 6 版本都带来了极大

的性能和稳定性的提升。

声明

本文档的版权归[陈淼]个人所有，未经许可和授权不得抄袭和引用。

本文档中的绝大部分内容都经过编者重新考量和实测验证，有些观点与官方手册有

出入，仅代表编者本人观点，与官方手册无关。本书中可能会提及一些非官方的命令和

工具等，仅用于讲解相关知识，如有缺失相关细节的情况，请谅解。

致读者

如果您在阅读和参考本书的过程中发现有任何不妥之处，或者有任何的建议和意见，

欢迎联系编者，本书主要针对 GP 数据库的爱好者进行编写，包括产品的安装和使用说

明，以及最佳实践等内容。本书的发布更新情况与编者的时间有关，不做承诺。

编写：陈淼

电邮： miaochen@mail.ustc.edu.cn

Greenplum Database 管理员指南 V6.2.1

Greenplum Database 管理员指南

- 1 -

序言

- 2 -

术语约定

- 2 -

背景简介

- 2 -

声明

- 2 -

第一章：GP 数据库架构

- 11 -

管理节点：Master

- 12 -

计算实例：Instance

- 14 -

内联网络：Interconnect

- 14 -

冗余与故障切换

- 15 -

Instance 镜像

- 15 -

Instance 故障切换与恢复

- 17 -

Master 镜像

- 17 -

网络层冗余

- 18 -

并行数据装载

- 18 -

管理与监控

- 19 -

第二章：分布式数据库概念

- 21 -

数据是如何存储的

- 21 -

解读 GP 分布策略

- 22 -

第三章：角色权限管理

- 24 -

角色与权限安全的最佳实践

- 24 -

创建用户 User Role

- 25 -

修改 ROLE 属性

- 25 -

创建用户组 Group Role

- 27 -

管理对象权限

28 -

模拟 Row 级别的权限控制

- 29 -

密码加密

- 29 -

基于时间的登录认证

- 30 -

需要的权限

- 31 -

如何添加时间约束

- 31 -

第四章：配置客户端认证

- 34 -

允许连接到 Master

- 34 -

编辑 pg_hba.conf 文件

- 35 -

限制并发连接数量

- 36 -

客户端/服务端间的加密连接

- 37 -

第五章：访问数据库

- 39 -

建立数据库会话

- 39 -

支持的客户端应用

- 39 -

GP 的客户端应用程序

- 40 -

针对 GP 的 pgAdminIII

- 41 -

DB 应用程序接口

- 44 -

Greenplum Database 管理员指南 V6.2.1

第三方客户端工具

- 44 -

连接故障排除

- 45 -

第六章：资源管理

- 46 -

使用资源组

- 46 -

资源组基于角色或基于外部组件

- 47 -

资源组的属性

- 48 -

配置与使用资源组

- 57 -

监控资源组状态

- 62 -

转移查询的资源组

- 66 -

使用资源队列

- 68 -

资源队列如何工作

- 68 -

使用资源队列做资源管理的步骤

- 71 -

配置资源队列管理资源

- 71 -

创建资源队列

- 74 -

分配 ROLE(User)到资源队列

- 77 -

修改资源队列

- 78 -

检查资源队列状态

- 79 -

第七章：定义数据库对象

- 83 -

创建与管理数据库

- 83 -

关于数据库模版

- 83 -

创建数据库

- 84 -

查看数据库列表

- 84 -

修改数据库

- 85 -

删除数据库

- 85 -

创建与管理表空间

- 85 -

创建文件空间

- 86 -

转移临时文件或事务文件的位置

- 87 -

创建表空间

- 89 -

使用表空间存储 DB 对象

- 90 -

查看现有的表空间和文件空间

- 91 -

删除表空间和文件空间

- 93 -

创建与管理模式

- 93 -

缺省"Public"模式

- 93 -

创建模式

- 93 -

模式搜索路径

- 94 -

删除模式

- 95 -

系统模式

- 95 -

创建与管理表

- 96 -

创建表

- 96 -

选择表的存储模式

101 -

修改表定义

113 -

删除表

116 -

分区大表

116 -

理解 GP 的表分区

117 -

Greenplum Database 管理员指南 V6.2.1

决定表是否分区的原则

- 118 -

创建分区表

- 119 -

插入数据到分区表

- 125 -

验证分区策略

- 126 -

分区选择性的诊断

- 127 -

查看分区设计

- 128 -

维护分区表

- 128 -

创建与使用序列

- 139 -

创建序列

- 140 -

使用序列

- 140 -

修改序列

- 141 -

删除序列

- 142 -

设置序列为字段缺省值

- 142 -

序列回旋

- 142 -

在 GP 中使用索引

- 143 -

在 GP 中使用聚集索引

- 144 -

索引类型

- 145 -

关于位图索引

- 145 -

创建索引

- 147 -

索引检验

- 148 -

维护索引

- 149 -

删除索引

- 149 -

创建和管理视图

- 150 -

创建视图

- 150 -

删除视图

- 150 -

创建视图的最佳实践

- 151 -

视图的依赖关系

- 152 -

视图是如何被存储的

- 157 -

创建和管理物化视图

- 158 -

创建物化视图

- 159 -

刷新或停用物化视图

- 160 -

删除物化视图

- 160 -

第八章：数据的分布与倾斜

- 162 -

本地关联

- 162 -

数据倾斜

- 162 -

计算倾斜

- 166 -

第九章：数据增删改

- 168 -

关于 GP 的并发控制

- 168 -

插入新记录

- 169 -

更新记录

- 170 -

删除记录

- 170 -

清空表

- 171 -

使用事务

- 171 -

事务隔离级别

- 172 -

Greenplum Database 管理员指南 V6.2.1

全局死锁检测

- 174 -

回收空间

- 176 -

配置自由空间映射

- 177 -

第十章：数据查询

- 179 -

理解 GP 的查询处理

- 179 -

理解执行计划与分发

- 179 -

理解执行计划

- 181 -

理解并行执行

- 182 -

关于 ORCA 优化器

- 183 -

启用或禁用 Orca

- 184 -

收集 ROOT 分区的统计信息

- 186 -

Orca 特性与增强

- 191 -

Orca 带来的改变

- 196 -

Orca 的限制

- 197 -

验证查询是否使用了 Orca

- 198 -

定义查询

- 199 -

SQL 修辞

- 199 -

SQL 值表达式

- 200 -

WITH 语句(CTE)

- 217 -

WITH 子句中使用 SELECT 命令

- 218 -

WITH 子句中使用数据修改命令

- 221 -

使用函数和运算符

- 223 -

在 GP 中使用函数

- 223 -

自定义函数

- 225 -

内置函数和运算符

- 226 -

开窗函数

- 228 -

高级聚合函数

- 229 -

查询性能

- 230 -

控制溢出文件

- 231 -

查询剖析

- 231 -

查看 EXPLAIN 输出

- 232 -

查看 EXPLAIN ANALYZE 输出

- 234 -

检查执行计划排查问题

- 237 -

第十一章：数据导入与导出

- 239 -

创建外部表

- 240 -

数据格式

- 241 -

外部表协议

- 244 -

错误记录处理

- 250 -

gpfdist 服务

- 252 -

使用外部表导入数据

- 257 -

使用外部表导出数据

- 258 -

使用 gpfdist 协议外部表导出数据

- 258 -

使用基于命令的 WEB 型外部表导出数据

- 259 -

使用 COPY 命令导入导出

- 260 -

Greenplum Database 管理员指南 V6.2.1

COPY 导入

- 260 -

COPY 导出

- 263 -

与数据导入相关的优化

- 263 -

第十二章：安装部署与初始化

- 265 -

硬件选型

- 265 -

CPU 主频与 Core 数量

- 265 -

内存容量

- 266 -

内联网络

- 266 -

Raid 卡性能

- 267 -

磁盘配置

- 267 -

容量评估

- 268 -

机房规划

- 269 -

安装操作系统

- 269 -

开启超线程

- 270 -

Raid 划分最佳实践

- 270 -

GP 安装条件

- 271 -

支持的操作系统

- 271 -

软件依赖

- 272 -

硬件与网络最低要求

- 272 -

文件系统要求

- 273 -

安装 RHEL 的介绍

- 273 -

修改操作系统配置

- 274 -

禁用 SELinux 和防火墙

- 274 -

修改 hostname

- 275 -

修改 hosts 文件

- 275 -

修改 sysctl.conf 文件

- 275 -

修改 limits 文件

- 276 -

确认 XFS 挂载参数

- 277 -

确认 IO 参数和 Huge Page 设置

- 277 -

确认 ssh 设置

- 278 -

时钟同步

- 278 -

创建 GP 数据库的管理员用户

- 279 -

安装 GP 软件

- 279 -

建立 ssh 互信

- 279 -

安装确认

- 280 -

GP 软件目录结构

- 281 -

创建数据库工作目录

- 281 -

创建 Master 的工作目录

- 281 -

创建 Instance 的工作目录

- 282 -

系统性能检查

- 283 -

检查网络性能

- 283 -

检查磁盘性能

- 284 -

初始化 GP 数据库集群

- 285 -

创建初始化网络端口文件

- 285 -

Greenplum Database 管理员指南 V6.2.1

创建初始化配置文件

- 286 -

执行初始化操作

- 288 -

为 gpadmin 用户配置环境变量

- 290 -

第十三章：启动与停止 GP 数据库

- 291 -

启动 GP 数据库

- 292 -

停止 GP 数据库

- 293 -

访问 Master Only 模式的 Master

- 294 -

中断客户端进程

- 295 -

第十四章：开启高可用

- 297 -

GP 数据库高可用概述

- 297 -

Instance 镜像概述

- 303 -

Master 镜像概述

- 304 -

为 GPDB 配置镜像

- 304 -

为 Primary 配置 Mirror

- 304 -

为 Master 配置 Standby

- 308 -

检测失败的 Instance

- 309 -

6 版本故障切换的恢复过程

- 311 -

6 之前版本故障切换的恢复过程

- 312 -

FTS 相关参数

- 315 -

检查 Instance 故障

- 316 -

检查故障 Instance 的日志文件

- 317 -

恢复 Instance

- 317 -

主机健康时从 Mirror 恢复

- 319 -

恢复角色初始状态

- 319 -

恢复双宕(double fault)

- 320 -

无 Mirror 集群恢复

- 322 -

主机丢失的恢复

- 322 -

恢复 Master

- 324 -

激活 Standby

- 324 -

恢复 Master 的高可用

- 325 -

恢复 Master 和 Standby 到初始主机

- 325 -

第十五章：备份与恢复

- 327 -

备份与恢复概述

- 327 -

串行备份 pg_dump

- 328 -

并行备份 gpbackup 与 gprestore

- 329 -

条件与限制

- 330 -

gpbackup 和 gprestore 包含的对象类型

- 331 -

执行一个 gpbackup 备份

- 332 -

使用 gprestore 恢复一个备份

- 334 -

第十六章：扩容

- 336 -

扩容概述

- 337 -

GP 数据库扩容规划

- 341 -

扩容准备工作检查清单

- 341 -

新硬件的规划

- 342 -

Greenplum Database 管理员指南 V6.2.1

规划新 Instance 的初始化

- 343 -

规划 Mirror 策略

- 344 -

为现有主机增加 Instance 数量

- 344 -

关于 gpexpand 模式

- 345 -

规划数据重分布

- 346 -

管理大规模集群的数据重分布

- 346 -

可用磁盘空间充足的系统

- 347 -

可用磁盘空间不足的系统

- 347 -

重分布 AO 表和压缩表

- 348 -

重分布分区表

- 348 -

重分布有索引的表

- 349 -

准备并添加新的计算节点主机

- 349 -

将新的主机加入 ssh 互信

- 350 -

检查磁盘 IO 性能和网络性能

- 353 -

新旧主机一起做性能测试

- 354 -

初始化新 Instance

- 354 -

生成扩展配置文件

- 354 -

扩容配置文件的格式

- 357 -

初始化新 Instance

- 358 -

扩容失败回退

- 359 -

数据表的重分布

- 359 -

调整表的重分布顺序

- 360 -

使用 gpexpand 重分布数据

- 361 -

监测数据重分布

- 361 -

清除扩容用的模式

- 362 -

第十七章：数据库的升级

- 364 -

小版本升级

- 364 -

升级条件

- 364 -

小版本升级步骤

- 365 -

排查升级失败

- 367 -

大版本升级

- 368 -

准备一个新版本的 GP 集群

- 368 -

通过备份恢复的方式升级

- 370 -

通过数据同步的方式升级

- 372 -

第十八章：最佳实践

- 373 -

最佳实践概述

- 373 -

数据模型

- 373 -

Heap 表与 AO 表

- 374 -

行存与列存

- 374 -

压缩

- 375 -

分布键

- 375 -

内存管理

- 376 -

分区

- 377 -

索引

- 378 -

Greenplum Database 管理员指南 V6.2.1

资源队列

- 379 -

监控与维护

- 379 -

收集统计信息

- 380 -

回收空间

- 381 -

数据加载

- 381 -

账户安全

- 383 -

高可用

- 383 -

系统配置

- 385 -

文件系统

- 385 -

端口范围配置

- 386 -

IO 参数配置

386 -

操作系统内存参数配置

387 -

共享内存设置

388 -

每个主机上的 Primary 数量

388 -

Instance 的内存配置

389 -

语句的内存配置

390 -

溢出文件的配置

391 -

模式设计

392 -

数据类型

392 -

存储模式

393 -

压缩

395 -

分布键

395 -

分区

402 -

分区和列存的文件数

404 -

索引

405 -

资源组管理内存等资源

- 406 -

GP 数据库的内存配置

- 406 -

在使用资源组时关于内存的考虑

- 408 -

配置资源组

- 409 -

低内存消耗型的查询

- 410 -

命令工具与 admin_group 的 CONCURRENCY 属性

- 410 -

资源队列管理内存等资源

- 410 -

解决内存不足的报错

- 411 -

低内存消耗型的查询

- 413 -

为 GP 数据库进行内存配置

- 413 -

配置资源队列

- 415 -

Greenplum Database 管理员指南 V6.2.1

第一章：GP 数据库架构

目前 GP 数据库已经开源多年，多年来一直由 Pivotal 公司商业运营，在 2020

年，Pivotal 被兄弟公司 VMWare 收购，由 VMWare 继续运营。近年来，Greenplum

在国内建立了一个较大规模的研发团队，越来越多的承担更重要的研发任务，包括

PostgreSQL 的版本合并等，从而，可以为国内商业用户提供更专业和更优质的本地

化服务，用户遇到问题，反馈给专业技术支持人员，或者专业售后服务团队，他们会同

用户一起排查和解决问题，如果有需要，还会保持与研发的持续沟通，虽然以前也是这

种工作模式，但由于时区和语言文化等诸多差异，沟通链路较长，时间较久，研发的本

地化，使得沟通的效率大大提高。

GP 是一个纯软件实现的 MPP 数据库产品，采用 Share-Nothing 架构，可管理和

处理分布在多个不同主机上的大规模数据集。对于 GP 数据库来说，一个数据库集群是

由多个独立的 PostgreSQL 实例构成的，它们分布在不同的主机上，实例之间协同工

作，用户可以像使用一个普通的单机数据库那样，进行访问和执行 SQL 操作。其中

Master 是整个系统的访问入口，负责处理客户端的连接和 SQL 命令、协调系统中的

其他实例协同工作，计算实例负责管理和处理具体的业务数据，并将处理结果反馈给

Master。

这一章节介绍组成 GP 数据库系统的组件及如何协同工作：

 管理节点：Master

 计算实例：Instance

 内联网络：Interconnect

Greenplum Database 管理员指南 V6.2.1

 冗余与故障切换

 并行数据装载

 管理与监控

管理节点：Master

Master 作为 GP 的访问入口，主要负责处理客户端连接的访问以及用户提交的

SQL 语句的解析、生成执行计划、优化执行计划等。Master 不存储业务数据，只存储

用于维持系统运行的全局信息，比如，对象定义信息，统计信息等，Master 非常重要，

如果 Master 丢失，即便是原厂专业技术支持，也不能保证恢复所有信息。

Master 目前采取的是 Active-Standby 的高可用模式，当 Master 处于 Active

状态时，备用 Master(简称为 Standby)是不能接受连接请求和 SQL 访问的。虽然只

有一个 Master，就目前已有用户的使用情况来看，即便是编者有幸参与建设的 192

台计算节点的集群，Master 的资源依然很空闲，并不会成为性能的瓶颈，同时，因为

是单 Master，可以最大限度的规避多 Master 架构的系统表频繁不一致的缺陷。

GP 是基于 PostgreSQL 发展而来，用户端可以如同访问 PostgreSQL 那样与 GP

进行交互。可以通过 PostgreSQL 客户端程序(如 psql、pgAdminIII)和应用程序

接口(APIs(如 JDBC、ODBC))连接 GP。不过，GP 在 5 版本和 6 版本中，因为

PostgreSQL 版本的不断合并，有不少系统表的发生了变化，所以，原有适用的客户

端，可能需要一定的适配开发工作，才能适用新的 GP 版本，编者目前在对 pgAdminIII

进行 5 版本和 6 版本的适配和改造，主要服务商业付费用户。

Master 上存储着全局系统表(Global System Catalog)(包含数据库系统自

身元数据的数据表)，但不存储任何业务数据，业务数据只存储在 Instance 上。

Master 负责客户端的登录认证、SQL 命令接收并生成并行执行计划、对执行计划进行

优化、在 Instance 之间分发执行计划、整合 Instance 处理结果、将 Instance 的

处理结果汇总并反馈给客户端程序。

目前，GP 还不支持 Master 的自动故障切换，不过，已经有很多人适用工具或者

脚本的形式实现了 Master 和 Standby 的自动 FailOver 效果，编者也实现了自动

切换命令，当 Master 出现无法正常工作的故障时，自动激活 Standby 来接管 Master

的任务。下面的流程图，是编者实现的 Master 和 Standby 自动切换的逻辑流程图，

可以供读者参考，不过，编者不方便公开实现的代码。

Greenplum Database 管理员指南 V6.2.1

Master 的连接数是有限的，缺省值为 250 个，如果要大规模提升连接的可用数

量，可以配置使用 GP 自带的 pgbouncer 连接池，这对于一些应用场景会很有帮助，

例如 SAS 等软件连接 GP 时，由于这些软件自身无法严格限制连接数，pgbouncer 会

是一个有效的缓解连接数过大的方案，例如按照如下方式进行配置：

$ cat pgbouncer.ini

[databases]

dwdb = host=127.0.0.1 port=5432 dbname=dwdb auth_user=gpadmin

[pgbouncer]

;;pool_mode = session

pool_mode = transaction

Greenplum Database 管理员指南 V6.2.1

max_client_conn = 2000

default_pool_size = 20

min_pool_size = 5

listen_port = 6432

listen_addr = *

auth_type = hba

auth_file = /home/gpadmin/pgbouncer_users.list

auth_hba_file = /home/gpadmin/pgbouncer_hba.conf

logfile = /data/pgbouncer.log

pidfile = /tmp/.pgbouncer.pid

admin_users = gpadmin

stats_users = gpadmin

ignore_startup_parameters = extra_float_digits,gp_session_role

$ cat restart_pgbouncer.sh

ps ax|grep -w pgbouncer|grep -vw grep|awk '{system("kill -9 "$1)}'

pgbouncer -v -R -d pgbouncer.ini

计算实例：Instance

在 GP 系统中，Instance 才是承担数据存储和查询处理的角色。用户数据表和相

应的索引都分布在 GP 系统中各个 Instance 上，每个 Instance 存储着一部分数据

(对于复制表来说，每个 Instance 存储一份完整的数据，这是 6 版本新引入的分布策

略)，Instance 才是真正进行数据处理的地方。缺省情况下，用户不能跳过 Master

直接访问 Instance，而只能通过 Master 来访问整个数据库系统，不过，对于管理

员来说，有时需要使用 Utility 模式来访问 Instance，访问方法是：

$ PGOPTIONS='-c gp_session_role=utility' psql

在 GP 推荐的硬件配置环境下，每个 Instance 需要对应数个 CPU Core 的资源

资源，具体的比例需要根据数据库的适用场景进行综合评估。例如在生产环境，每个

Instance 所在的主机配置了 2 个 16 Core 的 CPU，可根据不同的场景，配置 4 ~ 12

个不等的 Primary，这个数字的选择需要由富有经验的专业技术支持人员进行评估，

每个 Instance 所在主机配置的 Primary 越多，响应并发的能力越弱，但单个任务的

处理能力越强(这也不是绝对的，当 Primary 数量多到，即便运行单个任务时都会出

现资源争抢，可能运行的效率就会下降)。实际上，每个计算主机的 Primary 个数，

还与其他资源有关，如，磁盘性能，网络性能，内存容量。

内联网络：Interconnect

Greenplum Database 管理员指南 V6.2.1

网络层是 GP 系统的重要组件，在用户执行查询时，每个 Instance 都需要执行相

应的处理，网络层涉及到 Instance 之间的通信和数据传输，网络层可以使用标准的

以太网协议。不要认为网络只是连通作用，请按照 GP 的安装部署要求，必须使用万兆

网络作为内部互联网络，否则，一定会遭受很多网络方面的困扰。

在缺省情况下，网络层使用 UDPIFC 协议。这是经过改善的 UDP 协议，在 UDP 协

议的基础上增强了数据包校验，其可靠性与 TCP 协议相似，但其性能和扩展性远好于

TCP 协议。当集群规模较小，同时，网络的稳定性较差的时候，如果 UDPIFC 协议不

稳定，可以考虑使用 TCP 协议，例如只有几十台主机时。通常，还是强烈建议配备稳

定的网络环境，使用 UDPIFC 协议。

冗余与故障切换

GP 提供了避免单点故障的部署选项。本节讲述 GP 的冗余组件。

 Instance 镜像

 Master 镜像

 网络层冗余

Instance 镜像

在部署 GP 系统时，可以选择配置 Mirror，如果初始化时没有配置 Mirror，后

期也可以再次添加 Mirror，当然，如果要删除已有的 Mirror 也是可以的，不过需要

手动操作，因为 GP 并未提供删除 Mirror 的标准命令，删除 Mirror 的操作，对于 6

版本来说，和 4 版本与 5 版本是不同的，因为 6 版本中，系统表中记录 Mirror 关系

的系统表设计已经发生了重大变化。

Mirror 使得数据库查询在 Primary 不可用时可以自动切换到 Mirror 上。为了

配置 Mirror，GP 系统需要有足够多的主机，从而可以确保作为冗余角色的 Mirror

总是位于与 Primary 不同的 Host 主机上，否则，一旦主机发生宕机故障，位于同一

主机上互为配对关系的 Primary 和 Mirror 将同时不可用，数据库也将处于不可用状

态，这样的话，就失去了 Mirror 的意义。

例如下图所示，这是一种混合循环镜像模式，每 4 台主机组成一个镜像组，每台

计算主机上有 6 个 Primary，6 个 Primary 配对的 Mirror 均匀分布在另外三台机

器上。编者还实现了多种镜像模式，例如，循环镜像，指定的数台主机组成一个环，每

台主机上 Primary 配对的镜像都在下一台机器上，这与自带的 group 模式一致。

Greenplum Database 管理员指南 V6.2.1

如下图所示，这是一种混合配对镜像模式，将一群数量为偶数的机器，分为两组，

每台机器的镜像分散在对面组的机器上。关于如何选择镜像模式，以及如何分散镜像关

系，可以根据用户的实际需求进行评估和实施。

目前，编者的一键式集群配置安装初始化命令已经内置了两种镜像模式，分别为

RING 和 PAIR。RING 是一种带有环状关系的镜像模式，典型的特征是，一组机器形成

对等的环，环上的每台机器，其对应的 Mirror 会散落在后面的一台或者多台机器上，

这种模式包含了 gpinitsystem 命令缺省支持的两种镜像模式：GROUP 和 SPREAD。

PAIR 模式是一种两组配对互为镜像的模式，是一种更能兼顾性能和安全性的方案。

Greenplum Database 管理员指南 V6.2.1

Instance 故障切换与恢复

在 GP 系统启用 Mirror 的情况下，当 Primary 不可访问时，Master 会自动将

任务切换到对应的 Mirror 上，此时，Mirror 取代 Primary 的作用继续提供服务。

只要剩余的可用 Instance 能够保证数据的完整性，在 Instance 或者 Host 主机宕

机时，GP 系统仍可继续保持服务可用的状态。

每当 Master 无法连接到 Primary 时，该 Primary 在 GP 的系统表中将被标记

为失败状态，Master 会激活/唤醒对应的 Mirror 取代原有的 Primary。在采取相应

的措施将失败的 Primary 恢复到健康状态之前，该 Primary 一直保持失败状态。失

败的 Primary 可以在系统处于运行状态下被恢复回来。恢复进程仅仅复制失败期间发

生变化的增量差异，当然，如果失败时间太久或者因失败的 Instance 文件有损毁，

将需要全量恢复或者需要选择全量恢复。在 6 之前的版本，GP 的 Primary 和 Mirror

之间采用的是 filerep 的方式进行 block 级别的变化同步的机制，从 6 版本开始，

使用 WAL 复制，这将可以从根本上解决以往的 block 损毁被复制到 Mirror 上的问题，

也不再需要 persistent 系统表了(这个的确是一个让人很头疼的设计)。

在未启用 Mirror 的情况下，任何的 Primary 失败都会导致 GP 数据库自动停止

服务。必须恢复所有导致 Primary 失败的故障，才能重新启动 GP 数据库集群。

Master 镜像

如同 Primary 需要 Mirror 一样，可以在另一台主机上为 Master 部署一个备份

/镜像，按照惯例将其称为 Standby。在 Master 不可用时，Standby 可以被激活以

接替 Master 的角色。Standby 与 Master 之间保持 WAL 同步，保证与 Master 之

间的实时一致性。

在 Master 失效时，WAL 同步的复制进程会自动停止，同时，Standby 可以被激

活。在 Standby 上，冗余的 WAL 日志会被用来将状态恢复到最后成功提交(commit)

时的状态。激活的 Standby 实际上会成为 GP 的新 Master，通过 Master Port(该

端口需要设置和 Master 的相同)接受客户端的链接访问。一旦 Standby 被激活，旧

的 Master--那个失败了的 Master 将脱离集群，不再属于这个集群，要想将其重新

加入集群中，需要使用 gpinitstandby 命令将其添加为 Standby 的角色。如果因为

误操作，导致一个不应该被激活(例如其已经与 Master 失去同步很久了)的 Standby

被激活了，这个时候，应该尽快停止数据库，将旧的 Master 以 Master 的角色恢复

回来，这是一个复杂的问题，需要在确保风险可控的前提下进行操作，建议联系专业技

术支持，因为激活了 Standy 之后，缺省情况下，旧的 Master 将无法启动。

由于 Master 不存储业务数据，在 Master 和 Standby 之间仅仅是系统表的数据

需要被同步。这些表的数据量与用户的业务表相比，很小，而且较少发生变化，一旦发

Greenplum Database 管理员指南 V6.2.1

生变化，就会自动同步到 Standby 从而保证与 Master 的一致性，所以，Standby

与 Master 可以保持实时同步。在 6 之前的版本，Master 与 Standby 的同步机制就

一直是 WAL 同步，而在 6 版本开始，Primary 和 Mirror 也采用了 WAL 同步，但由

于 Mirror 需要同步的 WAL 日志的量很大，所以，对性能的影响比 Standby 要显著。

会有很多用户问，Master 和 Standby 在绝大多数时间内，资源非常空闲，跟

Instance 主机相比，相当于完全空闲，那么是否可以将 Master 和 Standy 设置到

Instance 主机上呢？从理论的角度来说，答案是肯定的，因为 GP 数据库的集群概念

是虚拟的，并没有严格限制不同角色必须分离，但，对于生产环境来说，除非可以 100%

确保计算节点机器的资源不会被耗尽，否则，都应该尽最大可能避免 Master 和

Standby 设置到 Instance 主机上，因为，这种模式下，一旦系统在处理负载很高的

任务，Master 将很难获得足够的资源，其响应会变慢，稳定性会下降。从两一个角度

来说，如果可以确保集群是非常良性的运转，不会有任务造成 Master 很大的压力，

可以适当配置计算能力稍差的机器。

网络层冗余

网络层关系到 Instance 之间的通信，其依靠基础网络设备，高可用网络层可以

通过部署双重网络实现。虽然，在配置 Mirror 的情况下，通过不同网段间的 Primary

与 Mirror 之间的对应关系也可以达到网络保障的效果，但依然强烈建议采用网卡绑

定的方式实现网络的高可用。建议采用支持 802.3ad 协议的交换机以实现多网口的链

路聚合，这样，在操作系统层面，多个物理网口将聚合并表现为一个 IP 地址，当任何

的网络或者交换机出现故障时，在操作系统级别将不会有任何的连接性异常的感知，只

是网络带宽出现下降，整个数据库集群的 Instance 状态将不会受到任何影响。如果

选择将 Primary 和 Mirror 分布在不同的网段，出现任何的网络故障时，总会有

Instance 的状态发生变化，这对上层应用就不可能做到绝对的无感知。

并行数据装载

Greenplum Database 管理员指南 V6.2.1

海量数据仓库的一个重大挑战是，要在一个受限的时间窗口内完成大量数据的装载。

GP 通过外部表(External Table)支持高速并行数据装载。外部表可以使用[单条记

录出错隔离]模式，以允许在装载数据过程中将出错的数据记录下来。可以设置错误容

忍的阈值，以实现对数据装载质量的控制。也可以对错误信息进行分析，以帮助改善数

据装载的质量。

结合使用外部表和 GP 的并行文件分发服务(gpfdist)，管理员可以实现最大化

的利用网络带宽资源以实现高速并行装载。

上图展示了 GP 外部表和 gpfdist 是如何配合，以实现高速数据装载的，该模式

的性能是完全线性扩展的，数据直接在 gpfdist 和 Primary 之间并行传输，数据的

重分布直接在 Primary 之间完成，整个架构没有瓶颈点。

管理与监控

对 GP 系统的管理，可以通过一系列的命令行来实现，它们都存放在$GPHOME/bin

目录下。GP 提供的命令可以实现如下的管理任务：

 在多个主机上批量执行命令(gpssh)

 初始化 GP 集群(gpinitsystem)

 启动(gpstart)或关闭 GP 集群(gpstop)

Greenplum Database 管理员指南 V6.2.1

 从集群中隔离故障的 Host 主机(gpstop --host)

 扩展 Instance 以及在新节点间重新分布 Table(gpexpand)

 监控和恢复失败的 Instance(gpstate & gprecoverseg)

 监控和恢复失败的 Master(gpstate & gpinitstandby)

 备份和恢复数据库(并行)(gpbackup & gprestore)

 并行装载数据(gpload)

 集群之间并行数据传输(gpcopy)

 系统状态报告(gpstate)

编者在多年的专业技术支持的工作中，也积累了一些不错的命令，例如：

 一键式集群安装部署初始化命令

 Master 和 Standby 自动切换命令

 更灵活的并行数据库备份恢复命令

 高速 DDL 备份命令

 并行 DDL 恢复命令

 更先进的跨集群数据同步命令

 集群间的表结构差异增量比对命令

 良好兼容的 pgAdminIII 客户端

 改善的 gpexpand 命令

Greenplum Database 管理员指南 V6.2.1

第二章：分布式数据库概念

GP 是一个分布式数据库集群系统。这就意味着在物理上，数据是存储在多个数据

库上的(称为 Instance)。这些独立的数据库通过网络进行通信(称为内联网络)。分

布式数据库的一个基本特征是，用户和客户端程序在访问时如同访问一个单机数据库

(GP 访问 Master)一样方便，数据库内部的分布式实现不需要用户过多的关心，对于

客户端应用来说，访问 GP 数据库与单机数据库没有什么区别。不过，对于开发人员和

DBA 来说，要更好的用好 GP 数据库，还是需要了解和掌握分布式数据库的概念，了解

GP 的架构和工作原理，这样才能更好的发挥 GP 的分布式优势，也就是说，学好这些

知识是极其重要的。和很多 IT 技术一样，入门很容易，精通很难，编者认为，GP 入

门更容易，精通也更难，一般不要指望通过几个月的刻苦学习就能达到很深的造诣，甚

至有些人学习了多年，仍无法驾轻就熟的使用和调优，不过，也不要气馁，这就如同打

游戏，不断的学习和积累，终究会在某个点突破禁锢，登堂入室。

数据是如何存储的

要理解 GP 是如何在不同的 Instance 之间存储数据的，可以参考下图所示的简单

逻辑关系，主键(Primary Key)被使用黑体标记，外键(Foreign Key)关系通过连

线标明。

用数据仓库的术语来说，这种数据模型称为星型模型。在这种数据库模型下，Order

表通常被称为事实表(Fact Table)，其他表(Customer、Vendor、Product)被称

为维表(Dimension Table)。不管是哪张表，虽然对于用户来说，看起来就是一张

表，实际上，在每个 Instance 上都有这样 4 张表，分别叫 Order、Customer

Vender

和 Product，针对某一张表来说，每个 Instance 上都存储有一部分数据，所有

Instance 上的这张表的数据的集合组成了这张表的全部数据，这类似分库分表的

Greenplum Database 管理员指南 V6.2.1

Sharding 概念，这样理解起来可能会容易一些。

GP 系统中所有的业务表都是分散的(复制表除外)，这意味着数据被拆分成无重叠

的记录集合。每部分数据存储在一个 Instance 中。数据通过复杂的 HASH 算法分布

到所有 Instance。HASH KEY(一个或者多个)由管理员在定义 Table 时指定。

GP 从底层上来说，通过一系列相关的独立 Database 实现，由一个 Master 和数

个 Instance 组成。Master 不存储用户数据。Instance 存储每张表无重叠的一部

分数据子集(对于复制表，每个 Instance 都存储一份完整的数据)。

解读 GP 分布策略

在 GP 中创建(Create)或者修改(Alter)表时，有一个额外的 DISTRIBUTED 子

句用以定义表的分布策略(Distribution Policy)。分布策略决定了表中的数据记

录如何被分散到不同的 Instance 上。GP 提供了 3 种分布策略：HASH 分布、随机分

布、复制分布。

 HASH 分布

使用 HASH 分布时，一个或数个(强烈建议避免选多个)Table Column 可以被用

作 Distribution Key(简称 DK)。通过 DK 计算出一个 HASH 值用来决定每条记录

分散到哪个 Instance 上。相同 Key 值的记录会 HASH 到相同的 Instance。选择一

个唯一性较高的字段作为 DK，可以确保尽可能平坦的数据分布效果。虽然，主键往往

是唯一性最好的字段，但是，不建议为了选择一个分布键而去增加一个主键，这是一种

逻辑颠倒的做法，通常，应该选择一个常用于大表之间关联的某个唯一性较高的字段作

为分布键，一般这个字段可能在其他某个表中具有主键特征，例如，客户 ID，例如会

员卡号，例如手机号码，例如身份证号码，等等，在选择分布键时，仅需要考虑大表与

大表之间的关联，任何涉及到小表关联的场景均不应作为选择分布键的考虑因素。

如果可以，尽可能只选择一个字段作为分布键，因为，只有当关联字段包含全部的

分布键时，分布键才对关联有帮助，除了空集(没有分布键的分布策略就是 Randomly

随机分布)，只有仅包含一个元素的集合才最容易成为其他集合的子集。如果可以确保

组合分布键常常会被关联查询的字段全部包含，且没有一个合适的字段单独作为分布键，

选择组合分布键也是可以的，但这只应该作为特例来考虑。

 随机(Random)分布

使用随机分布，数据记录被无规律随机分布到所有 Instance 上。相同值的记录

可能会分布在不同的 Instance 上。随机分布可以绝对确保数据分布的平坦性，但是，

为了确保数据分布对查询有帮助，应该尽可能的使用 HASH 分布。

Greenplum Database 管理员指南 V6.2.1

对于一些尺寸很小的表(叫维表或者参考表)来说，无所谓如何分布，所以，这样

的表完全可以按照 HASH 分布或者使用随机分布，甚至复制分布(只要可以接受其尺寸

放大的影响)，对整体的分析查询性能不会有明显的影响。

 复制(Replicated)分布

复制分布，会在每个 Instance 上都存储一份完整的数据拷贝，复制表是在 6 版

本新引入的数据分布策略，这里需要特别指出，复制表，因为需要在每个 Instance

上存储一份完整的数据，数据量大的事实表不适合选择复制分布这种分布策略，如果这

么做，将会极大的浪费存储空间，同时，未必会带来性能的改善，对于复制表的理解，

应该仅限于：复制表的存在，等于提前把广播做好了，减少了执行计划的复杂度，对于

一些非常小的表，涉及的业务场景追求极致的性能时才考虑，对于通常的分析型场景，

无需考虑复制表。对分布策略要理解透彻，不能过度迷信某一种分布策略，时常在社区

听到有人说，复制表的性能更好，这是一种片面的理解，只能说，在某些特定的情况下，

选择复制分布，会表现出更好的性能。在考虑使用复制表时，请谨记一个衡量标准，复

制表的作用仅仅是提前把广播(Broadcast)做好了，仅仅如此，而已。

Greenplum Database 管理员指南 V6.2.1

第三章：角色权限管理

GP 通过角色(Role)的概念来管理数据库的访问权限。Role 的概念包含两个子概

念用户(User)和组(Group)。一个 Role 可以是一个 DB User 或者一个 Group 或者

两者兼备。Role 可以是 DB 对象(例如 Table)的 Owner(只是一种权限的体现，不是

专有对象)并可以分配该对象的权限给其他 Role 从而实现对该对象的权限管理。Role

还可以成为其他 Role 的成员，因此 Role 可以继承其父级 Role 的对象权限。

每个 GP 系统都包含一系列的 Role(User 或 Group)。这些 Role 与运行在 OS

上的 Role 没有直接的关联关系。如果是出于便利考虑，可以选择使用与 OS Role 相

关联的 GP Role，这样对于一些缺省使用 OS User 名称作为 DB User 的应用来说会

有一点点便利性(这点便利微不足道)，不过，往往不太需要这样的设计，因为极少有

需要直接在 Master 主机上来访问 GP 的情况存在。

在 GP 中 User 通过 Master 登录和认证。而对于 Instance 的访问是 Master

通过内部实现完成的，与当前登录的 User 信息无关。

Role 是定义在 GP 系统级别的，这就意味着，在其所在集群的全部 DB 实例中都是

有效的，也就是说，Role 是独立于 DB 存在的，特定的 Role 可以是某个 DB 的 Owner，

但这不等于说这个 DB 是该 Role 专有的，Owner 只是一种权限的体现，没有绝对的隶

属关系，例如 SUPERUSER 可以不受任何限制的访问任何 DB(还受到 pg_database

的 datallowconn 属性限制)和任何对象。

为了能够启动 GP 系统，在初始化系统时会自动包含一个 SUPERUSER，该 Role

与执行该初始化操作的 OS User 相关。该 Role 与该 OS User 具有相同的 Name。按

照惯例，这个 Role 的名称使用 gpadmin。为了能够创建其他 Role，一开始需要使用

该初始化 Role 来访问 GP 数据库集群。

角色与权限安全的最佳实践

 保护系统 User gpadmin。GP 需要使用一个 Linux 的 OS User 来安装和初始

化 GP 系统。按照惯例，该系统 User 的名称使用 gpadmin。gpadmin 用户作为 GP

系统的默认 SUPERUSER，同时是 GP 安装目录及相关数据文件的 Owner。默认的管理

员账户是 GP 系统的基本要素，如果没有该账户，整个数据库系统将无法运行，GP 集

群不可以使用 root 用户进行初始化，另外，没有办法限制 gpadmin 用户的访问权限，

因为这是第一个 SUPERUSER。gpadmin 用户可以绕过 GP 的所有权限限制。任何人通

过 gpadmin 登录到 GP 主机后，都可以 Read、Alter、Delete 任何数据，包括系统

表的访问和任何数据库操作，因此，保护好 gpadmin 用户账号是很重要的。超级用户

(gpadmin)只应该用于执行特定的系统管理任务(例如备份恢复、故障处理、升级、扩

容等)。一般的数据库访问不应该使用 gpadmin 账号，ETL 等生产系统也不应该使用

gpadmin 账号。不要闲的无聊，试图将 gpadmin 修改为 NOSUPERUSER，弄不好如

Greenplum Database 管理员指南 V6.2.1

果系统中一个 SUPERUSER 都没了，可能就悲剧了(编者测试过，很悲剧)。

 为每个登录的 User 分配不同的 Role。出于登录和审计的需要，每个被允许登录

到 GP 的使用者都应该分配一个属于自己的 Role。对于应用程序(APP)或者 Web 应用

来说，应该考虑为每个 APP 或者 Web Server 创建独立的 Role。

 使用 Group 来管理访问权限。当登录的用户数量较多，且经常需要为类似的用户

授予类似的权限时，可以通过 Group 来进行权限的管理，将数据库中对象的权限赋予

Group，当某个 User 需要某类权限时，将该 User 加入到相应的 Group 中，此时该

User 就拥有了该 Group 所拥有的对象权限，Role 属性相关的权限无法被自动继承。

 控制具有 SUPERUSER 属性的 User 数量。具有 SUPERUSER 属性的 Role 将可以

像 gpadmin 那样绕过 GP 的所有权限限制，包括资源队列(Resource Queue/RQ)，

但是不包括资源组(Resource Group/RG)，截止目前的所有版本，任何用户在资源

组中不能超过资源限制，但权限不受限制。所以，应该仅为系统管理员分配 SUPERUSER

权限，拥有 SUPERUSER 权限，几乎可以做任何事情，例如，删除任何的表，删除任何

的 Role，删除任何的 DB，甚至删除操作系统上 gpadmin 用户有操作权限的任何文件

和目录。

创建用户 User Role

User Role 意味着其可以登录数据库并发起 SQL 会话。因此，在使用 CREATE

ROLE 来创建一个 User 时，需要指定 LOGIN 权限。例如：

=# CREATE ROLE jsmith WITH LOGIN;

Role 还需要设置一系列的属性来决定其可以执行哪些数据库操作。可以在

CREATE ROLE 的时候指定这些属性，也可以在 CREATE 之后使用 ALTER ROLE 命令

来完成。

修改 ROLE 属性

属性

描述

SUPERUSER | NOSUPERUSER

SUPERUSER 可以绕过所有权限限制，SUPERUSER 使用有

风险，仅在需要的时候使用。CREATE ROLE 时缺省属性为

NOSUPERUSER。

CREATEDB | NOCREATEDB

是否有 CREATE DATABASE 权限。缺省为 NOCREATEDB。

CREATEROLE | NOCREATEROLE

是否有 CREATE 和管理其他 ROLE 的权限，缺省为

NOCREATEROLE。

CREATEEXTTABLE | NOCREATEEXTTABLE

是否有创建外部表的权限，缺省为 NOCREATEEXTTABLE。

Greenplum Database 管理员指南 V6.2.1

[ ( attribute='value'[, ...] ) ]

在设置外部表权限时还需要指定外部表的权限类型，包括

where attributes and values are:

[可读|可写]以及[gpfdist 协议|http 协议]等。

type='readable'|'writable'

protocol='gpfdist'|'http'

INHERIT | NOINHERIT

决定该 Role 是否继承其所属 Group 的权限。缺省属性为

INHERIT。INHERIT 表明，该 Role 无需单独指定对象的

访问权限，该 Role 所属的 Group 具有的权限将会自动被

该 Role 继承。

决定 ROLE 是否可以登录数据库。具有 LOGIN 属性的 ROLE

就是 USER。不具有 LOGIN 属性的 ROLE 往往被用来做权限

管理(GROUP)。缺省为 NOLOGIN。

CONNECTION LIMIT connlimit

对于可以 LOGIN 的 Role 来说，决定其同时最多可以有多

少个连接。缺省值为-1(无限制)。

PASSWORD 'password'

设置 Role 的 PASSWORD。如果暂时不打算让该 Role 登陆

数据库，可忽略该属性，如果不指定密码，PASSWORD 会被

设置为 NULL 并且始终无法登录。空密码也可以明确定义为

PASSWORD NULL。

ENCRYPTED | UNENCRYPTED

指定密码是否加密，缺省行为受 password_encryption

参数决定(缺省为 ON)。如果目前的密码已经使用了加密存

储，可忽略该属性。

VALID UNTIL 'timestamp'

设置在指定的日期后该 Role 的密码失效。不设置的情况下

为永远有效。

RESOURCE QUEUE queue_name

将 Role 分配到指定的资源队列(RQ)。所有的语句都受到

该 RQ 的约束。需要注意的是该属性不会被继承，必须为每

个 USER 指定该属性。缺省的是 pg_default。

RESOURCE GROUP group_name

将 Role 分配到指定的资源组(RG)。所有的语句都受到该

RG 的约束。需要注意的是该属性不会被继承，必须为每个

USER 指定该属性。缺省的是 default_group。

DENY {deny_interval | deny_point}

定义限制 Role 登录的时间段，在指定的时间段内不允许登

录。可以指定日期或者日期加时间的格式。这些信息存储在

pg_catalog.pg_auth_time_constraint 系统表中。

该功能鲜有使用，该系统表的维护一直存在明显的问题，该

表没有约束限制，完全相同的限制信息可以被重复的存储在

该系统表中。

例如下面的例子：

=# ALTER ROLE reuser WITH PASSWORD 'passwd123';

=# ALTER ROLE reuser VALID UNTIL 'infinity';

=# ALTER ROLE reuser LOGIN;

=# ALTER ROLE reuser RESOURCE QUEUE adhoc;

=# ALTER ROLE reuser DENY DAY 'Sunday';

除了上述的一些自有的属性外，ROLE 还可以配置一些 GUC 参数的属性值，例如设

Greenplum Database 管理员指南 V6.2.1

置缺省的搜索路径：

=# ALTER ROLE admin SET search_path TO myschema, public;

需要注意的是，在 Role 上设置 GUC 参数要进行适当的验证检查，例如，要在 Role

上设置内存参数 max_statement_mem 和 statement_mem 时需要注意，在系统级别，

max_statement_mem 这个参数的值是多少，缺省为 2GB，如果在 Role 级别要设置

的 statement_mem 超过系统级别的 max_statement_mem 值，虽然 Role 上的

max_statement_mem 参数值足够大，但仍可能会报错，因为这取决于哪个参数设置

先生效。

创建用户组 Group Role

在管理一组类似的 User 的权限时，将它们绑定到一个 Group 是很方便的，通过

这种方式，一组 User 可以通过一个 Group 来统一授予权限和回收权限。在 GP 中，

通过 CREATE ROLE 的方式来创建 GROUP，并通过以角色作为权限实体的方式通过

GRANT 命令来为 USER 分组并实现权限继承。

通过 CREATE ROLE 命令创建新的 GROUP ROLE：

=# CREATE ROLE admin CREATEROLE CREATEDB;

一旦 GROUP 创建好之后，就可以通过 GRANT 和 REVOKE 添加或者删除

Member(USER ROLE)了：

=# GRANT admin TO john, sally;

=# REVOKE admin FROM bob;

为了合理的管理对象权限，需要将合适的权限赋予 GROUP ROLE。因为其所有的

USER ROLE 成员都会继承该 GROUP ROLE 的对象权限。例如：

=# GRANT ALL ON TABLE mytable TO admin;

=# GRANT ALL ON SCHEMA myschema TO admin;

=# GRANT ALL ON DATABASE mydb TO admin;

不过，对于 ROLE 的 LOGIN、SUPERUSER、CREATEDB 和 CREATEROLE 等属性，

是不会像普通的权限一样被继承的，GROUP 的 USER 成员需要明确的使用 SET ROLE

命令进行获取。例如，admin ROLE 具备 CREATEDB 和 CREATEROLE 属性，sally

是 admin 的成员，其可以通过下面的语句来获取 admin ROLE 的属性权限：

=# SET ROLE admin;

=# SELECT current_role;

Greenplum Database 管理员指南 V6.2.1

admin

这也提醒了我们，在使用 Group 做权限管理时要小心控制这种属性权限，同时，

需要提醒的是，对于普通 Role 来说，不要因为 SET ROLE 可以获得更高的权限而动

歪心思，因为数据库日志中记录的操作信息仍然是你的大名。

管理对象权限

当一个对象(Table、View、Sequence、Database、Function、Language、

Schema、Tablespace)被创建时，其会被分配一个所有者(Owner)。通常 Owner 是

执行了创建语句的 User。对于大多数的对象(Object)来说，缺省只有其 Owner(或

者 SUPERUSER)可以对其做不受限制的操作。要允许其他 User 使用该对象，需要使

用 Grant 进行授权，有趣的是，Owner 还可以把自己的权限 Revoke，Revoke 之后

自己就没有了相关的权限(还可以再 Grant 回来)，这真是一个神奇的设计。GP 对于

每种对象支持的权限为：

对象类型

权限

Tables、Views、Sequences

SELECT

INSERT

UPDATE

DELETE

RULE

ALL

External Tables

SELECT

RULE

ALL

Databases

CONNECT

CREATE

TEMPORARY | TEMP

ALL

Functions

EXECUTE

Procedural Languages

USAGE

Schemas

CREATE

USAGE

ALL

注意：每个对象的权限必须被独立的授权。例如：被授予了一个数据库的 ALL 权限不

等于把该数据库的所有对象都授权了。这仅仅是授权了数据库本身的全部权限

(CONNECT、CREATE、TEMPORARY)。

使用 GRANT 命令给指定的 Role 授予一个对象权限。例如：

Greenplum Database 管理员指南 V6.2.1

=# GRANT INSERT ON mytable TO jsmith;

在 6 版本开始支持 Column 级别的权限管理，如果要控制 Column 级别的权限，

可以在 Grant 的时候列出 Column 的名称，缺省在不列出 Column 名称的情况下，包

含全部字段的权限。例如：

=# GRANT SELECT(col1) on TABLE mytable TO jsmith;

还可以通过 DROP OWNED 和 REASSIGN OWNED 命令来取消 Role 的 Owner 权限

(只有该对象的 Owner 或者 SUPERUSER 可以执行这样的操作)。例如：

=# REASSIGN OWNED BY sally TO bob;

=# DROP OWNED BY visitor;

这里需要注意，DROP OWNED 是删除所有 Owner 为指定 Role 的对象，这可能是

一个风险很高的操作，而 REASSIGN OWNED 是找到所有 Owner 为指定 Role 的对象，

将其 Owner 改为新的 Role。当我们需要删除某个 Role 并且不希望删除任何依赖的对

象时，应该使用 REASSIGN OWNED 而不是 DROP OWNED。

在 6 版本开始，可以通过 GRANT ALL IN SCHEMA 命令来完成指定 Schema 内

全部某类对象的授权。例如：

=# GRANT ALL ON ALL TABLES IN SCHEMA public TO bob;

=# REVOKE ALL ON ALL TABLES IN SCHEMA public FROM bob;

=# REVOKE ALL ON ALL FUNCTIONS IN SCHEMA public FROM bob;

=# REVOKE ALL ON ALL SEQUENCES IN SCHEMA public FROM bob;

需要注意的是，GRANT ALL IN SCHEMA 语法只是将当前状态下 Schema 内现有

的对象进行授权，之后创建的对象不包含在本次授权中，从原理上来说，GRANT ALL IN

SCHEMA 语法是一种内置的循环授权的方式，并不是在 Schema 上保存权限信息。

模拟 Row 级别的权限控制

GP 到目前的 6 版本为止，还不支持 Row 级别的权限控制。Row 级别的权限控制可

以通过 View 的方式来模拟。可以通过添加一个 Column 的形式来存储权限信息，使用

基于该 Column 的 View 来控制访问的 Row，再将该 View 授权给相应的 User。

密码加密

缺省情况下， GP 使用 MD5 算法对库内存储的 ROLE 的密码进行加密存储，所有

Greenplum Database 管理员指南 V6.2.1

具有权限查看 pg_authid 系统表的用户都可以看到加密后的密码，不过这些密码都是

经过 MD5 加密后的字符串，由于 MD5 加密算法的不可逆性，查看者无法看到真实的原

始明文密码。当进行 DDL 的备份和恢复时，操作的是加密后的字符串，无法获取真实

的明文密码串。在设置密码的时候，密码就被加密了：

=# CREATE USER name WITH ENCRYPTED PASSWORD 'password';

=# CREATE ROLE name WITH LOGIN ENCRYPTED PASSWORD 'password';

=# ALTER USER name WITH ENCRYPTED PASSWORD 'password';

=# ALTER ROLE name WITH ENCRYPTED PASSWORD 'password';

当 password_encryption 参数设置为 on 时，ENCRYPTED 关键字是可以省略

的

password_encryption 的缺省值为 on，password_encryption 的值决定了，

当不指定 ENCRYPTED 或者 UNENCRYPTED 关键字时的缺省动作，当设置为 on 时，缺

省等效于指定了 ENCRYPTED，即，对密码进行加密存储，如果指定了 UNENCRYPTED，

在 pg_authid 系统表中的密码将会以明文的方式进行存储。例如：

=# CREATE ROLE name WITH UNENCRYPTED PASSWORD 'password';

=# SELECT rolpassword FROM pg_authid WHERE rolname='name';

rolpassword

密码除了使用 MD5 进行加密，还可以使用 SHA-256 算法进行加密，该算法生成一

个 64 字节的十六进制字符串，前缀为 sha256 字符。MD5 算法生成的加密密码前缀为

md5 字符。pg_authid 系统表中存储的加密密码，是通过对密码拼接用户名之后的字

符串执行相应的加密算法得到的，同时以加密时的加密算法名作为前缀。例如：

=# CREATE ROLE name1 WITH PASSWORD 'password';

=# SET password_hash_algorithm TO 'sha-256';

=# CREATE ROLE name2 WITH PASSWORD 'password';

=# SELECT rolpassword FROM pg_authid WHERE rolname = 'name1';

md5c3ac1a95fe4ba7cac352448ff1e5d6ec

=# SELECT rolpassword FROM pg_authid WHERE rolname = 'name2';

sha2569fca82e96e5092248ec38609bfc503dc3e138b4a83e719c69e325128e289ac40

$ echo -n passwordname1|md5sum

c3ac1a95fe4ba7cac352448ff1e5d6ec

$ echo -n passwordname2|sha256sum

9fca82e96e5092248ec38609bfc503dc3e138b4a83e719c69e325128e289ac40

基于时间的登录认证

GP 允许管理员限制 Role 的登录时间。可以使用 CREATE ROLE 或者 ALTER ROLE

命令来管理基于时间的限制，使用 ALTER ROLE 可以随时修改时间限制。

Greenplum Database 管理员指南 V6.2.1

访问限制可以控制到具体时间点，且约束的改变不需要删除或者重建 ROLE。为权

限的管理提高了灵活性。

时间约束仅仅对于指定的 Role 有效。如果一个 Role 被另一个受时间约束的 Role

包含，该时间约束不会被继承。

时间约束仅仅是在 LOGIN 的时候会被检查。SET ROLE 和 SET SESSION

AUTHORIZATION 命令对于时间约束不受任何影响，也就是说，即便执行了这些语句也

无法继承时间约束的设置，时间约束只针对指定的 ROLE 有作用。

需要的权限

要设置时间约束，SUPERUSER 或者 CREATEROLE 权限是必须的。另外没有任何

User 可以给 SUPERUSER 设置时间约束，否则会得到如下报错：

ERROR: cannot alter superuser with DENY rules

如何添加时间约束

有两种办法添加时间约束。在 CREATE ROLE 或者 ALTER ROLE 的时候使用 DENY

关键字并跟随如下的选项来实现：

 某天或者某个时间的访问限制(不需要 BETWEEN 关键字)，例如：周二不允许登录。

 一个有开始时间和结束时间的访问限制(需要 BETWEEN AND)，例如：周二下午

10 点到周三上午 8 点不允许登录。

还可以指定多个限制，例如：周二的任何时间不允许登录并且周五的下午 3 点到 5

点不允许登录。

指明日期和时间

有两种方法指明哪一天。使用 DAY 关键字并紧跟英文的星期几，或者 0~6 的数字，

如下表所示：

英文表述

数字表述

DAY 'Sunday'

DAY 0

DAY 'Monday'

DAY 1

Greenplum Database 管理员指南 V6.2.1

DAY 'Tuesday'

DAY 2

DAY 'Wednesday'

DAY 3

DAY 'Thursday'

DAY 4

DAY 'Friday'

DAY 5

DAY 'Saturday'

DAY 6

每日中的时间可以使用 12 小时或者 24 小时格式。在 TIME 关键字之后跟随单引

号引起来的时间格式。仅仅含有小时和分钟的时间即可(也可以使用秒单位)，且使用

冒号(:)作为分隔符。如果使用 12 小时格式，需要指定 AM 或者 PM 结尾以确定上下午。

下面的例子表明了几种时间格式：

TIME '14:00' (24 小时格式的时间)

TIME '02:00 PM' (12 小时格式的时间)

TIME '02:00' (24 小时格式的时间) 其等价于 TIME '02:00 AM'

注意：时间约束是强制以服务器时间为准的。时区信息会被忽略。

指定时间段

要指定限制访问的时间段，需要两个[日期/时间]来确定，且通过 BETWEEN 和 AND

关键字连接。DAY 是必须的。

BETWEEN DAY 'Monday' AND DAY 'Tuesday'

BETWEEN DAY 'Monday' TIME '00:00' AND DAY 'Monday' TIME '01:00'

BETWEEN DAY 'Monday' TIME '12:00 AM' AND DAY 'Tuesday' TIME '02:00 AM'

BETWEEN DAY 'Monday' TIME '00:00' AND DAY 'Tuesday' TIME '02:00'

BETWEEN DAY 1 TIME '00:00' AND DAY 2 TIME '02:00'

最后 3 句是等价的。

注意：日期间隔不能跨越 Saturday(周六)。

Incorrect：DENY BETWEEN DAY 'Saturday' AND DAY 'Sunday'

正确语法为：

DENY DAY 'Saturday'

DENY DAY 'Sunday'

例子：

下面的例子说明在 CREATE ROLE 和 ALTER ROLE 的时候使用时间约束。这里只

是展示了时间约束部分的命令。关于 CREATE ROLE 和 ALTER ROLE 的细节可参考相

关章节。

Greenplum Database 管理员指南 V6.2.1

例 1-创建包含时间约束的 ROLE，限制周末访问。

=# CREATE ROLE generaluser DENY DAY 'Saturday' DENY DAY 'Sunday';

例 2-修改 ROLE 添加时间约束，每天晚上 2:00 到 4:00 限制访问。

=# ALTER ROLE generaluser

DENY BETWEEN DAY 'Monday' TIME '02:00' AND DAY 'Monday' TIME '04:00'

DENY BETWEEN DAY 'Tuesday' TIME '02:00' AND DAY 'Tuesday' TIME '04:00'

DENY BETWEEN DAY 'Wednesday' TIME '02:00' AND DAY 'Wednesday' TIME '04:00'

DENY BETWEEN DAY 'Thursday' TIME '02:00' AND DAY 'Thursday' TIME '04:00'

DENY BETWEEN DAY 'Friday' TIME '02:00' AND DAY 'Friday' TIME '04:00'

DENY BETWEEN DAY 'Saturday' TIME '02:00' AND DAY 'Saturday' TIME '04:00'

DENY BETWEEN DAY 'Sunday' TIME '02:00' AND DAY 'Sunday' TIME '04:00';

例 3-修改 ROLE 添加时间约束，周三或者周五下午 3:00 到 5:00 限制访问。

=# ALTER ROLE generaluser

DENY BETWEEN DAY 'Wednesday'

DENY BETWEEN DAY 'Friday' TIME '15:00' AND DAY 'Friday' TIME '17:00';

删除时间约束

要删除时间约束，可使用 ALTER ROLE 命令。跟着 DROP DENY FOR，并跟着日

期/时间。例如：

DROP DENY FOR DAY 'Sunday'

任何与该条件有交集(互相有重叠关系)的约束都会被移除。例如存在的约束为

BETWEEN DAY 'Monday' AND DAY 'Tuesday'。那么删除'Monday'限制时会移

除整个限制。原则是有交集即移除。例如：

=# ALTER ROLE generaluser DROP DENY FOR DAY 'Monday';

这些限制登录的信息存储在 pg_catalog.pg_auth_time_constraint 系统

表中。

Greenplum Database 管理员指南 V6.2.1

第四章：配置客户端认证

在 GP 系统初始化成功之后，系统包含一个预定义的 SUPERUSER ROLE。该 USER

的 USER NAME 与初始化 GP 系统的 OS USER 同名。该 ROLE 按照惯例使用 gpadmin。

缺省情况下，系统会被设置为只允许 gpadmin 从本地连接。为了让其他 ROLE 可以连

接数据库，或者允许从远程主机连接数据库，必须配置相应的许可以允许这些连接。本

章介绍如何配置客户端连接和认证。

允许连接到 Master

客户端的访问许可是通过一个叫做 pg_hba.conf(也是标准的 PostgreSQL 的

认证文件)的配置文件来控制的。关于该文件的细节可以参考 PostgreSQL 的文档。

在 GP 中，Master 的 pg_hba.conf 文件控制着客户端连接到 GP 系统的认证。

在 Instance 上也存在 pg_hba.conf 文件，通常此文件已经被正确配置为允许从

Master 访问。不过根据以往的经验来看，也出现过配置错误的情况，该情况会导致

gpexpand 之类的操作报错失败。通常来说，Instance 是不需要接受外部客户端连

接的(如果需要，必须通过 Utility 模式连接)，不太有必要去修改 Instance 的

pg_hba.conf 文件。编者编写的一些增值服务的命令中有些会涉及需要修改

Instance 的 pg_hba.conf 文件，不过，缺省情况下这些命令会自动完成这些必要

的修改操作。

pg_hba.conf 是一个平面文件，按照行来区分每条记录。空行会被忽略，任何在

(#)后的字符串都会被忽略。每行记录由一系列 Space 和 Tab 混合分割的属性组成。

如果需要在属性中出现空白字符，需要将该属性用引号引起来。记录不可跨行。每条远

程客户端的访问许可，都像这种格式：

host database role CIDR-address authentication-method

而每个 UNIX 本地连接的访问许可，都像这种格式：

local database role authentication-method

这些属性的含义如下：

字段

描述

local

匹配 UNIX 嵌套连接。如果没有这种记录，UNIX 嵌套连接是不被允许的。

host

匹配 TCP/IP 方式的连接。除非该 Server 属于一个合适的 IP 段，否则

其访问是不被允许的。

hostssl

匹配 TCP/IP 方式的 SSL 加密连接。这个配置需要配合 SSL 参数的设置，

并且在 GP 数据库启动时生效。

Greenplum Database 管理员指南 V6.2.1

hostnossl

匹配 TCP/IP 方式的非 SSL 加密连接。

database

设置该记录匹配的 DB Name。all 可以匹配全部 DB。多个 DB Name 可以

使用逗号(,)分割。或者使用@符号跟随文件名的方式指定，该文件包含需

要匹配的 DB Name。

role

匹配哪个 ROLE。all 可以匹配全部的 ROLE。如果想把一个 GROUP 的所

有成员匹配上，可以在 ROLE Name 前使用加号(+)表示。多个 ROLE Name

可以使用逗号(,)分割。或者使用@符号跟随文件名的方式指定，该文件包

含需要匹配的 ROLE Name。

address

指定该记录匹配的客户端 IP 地址或者范围，也可以是一个 hostname。

如果是 IP，其包含一个标准的小数点分割的 IP 地址和一个掩码长度值。

IP 地址只能使用数字形式。掩码长度表示 IP 地址高位与客户端 IP 匹配

的长度。指定的掩码长度右边的二进制 IP 地址必须是 0。IP 地址与分隔

符(/)和掩码长度之间不可以有任何的空字符。例如

172.20.143.89/32。其只能匹配 172.20.143.89 IP 地址。

172.20.143.0/24 可以匹配 172.20.143 网段的任何 IP 地址。要匹配

单个 IP 地址 IPv4 使用 32 作为掩码长度

IPv6 使用 128 作为掩码长度。

如果使用 hostname 来配置，hostname 的解析依赖/etc/hosts 文件的

配置或者 DNS 的解析，如果 hostname 解析出的 IP 地址与访问时的 IP

地址不能匹配，则访问会被拒绝。通常可能没有必要使用 hostname 来进

行配置，这个特性主要是为了 gp4k 而新增的功能。

IP-address

通过标准子网掩码的格式作为掩码长度的可选方案。其被作为一个单独的

IP-mask

字段。255.0.0.0 等效于 IPv4 的 8 位掩码长度。255.255.255.255

等效于 IPv4 的 32 位掩码长度。例如：

192.168.0.0

255.255.0.0 与 192.168.0.0/16 等价

authentication-m

指定连接时使用的认证方法。例如 trust 为不需要密码，md5 为使用 md5

ethod

加密认证。更多细节可以查看 PostgreSQL 文档的认证方法部分。

编辑 pg_hba.conf 文件

下面的例子展示如何编辑 Master 上的 pg_hba.conf 文件从而允许远程的客户

端通过加密认证的方式访问数据库。

编辑 pg_hba.conf 文件

1. 使用文本编辑器(例如 VI)打开$MASTER_DATA_DIRECTORY/pg_hba.conf 文

件，并进入编辑状态。

2. 为每类需要允许的连接添加一行记录。记录是被顺序读取的，所有记录应该被有序

的安排。通常前面的记录匹配更少的连接但要求较弱的认证，后面的记录匹配更多

的连接但要求更严格的认证。例如：

Greenplum Database 管理员指南 V6.2.1

# allow the gpadmin user local access to all databases

# using ident authentication

local all gpadmin ident sameuser

host all gpadmin 127.0.0.1/32 ident

host all gpadmin ::1/128 ident

# allow the 'dba' role access to any database from any

# host with IP address 192.168.x.x and use md5 encrypted

# passwords to authenticate the user

# Note that to use SHA-256 encryption, replace md5 with

# password in the line below

host all dba 192.168.0.0/32 md5

# allow all roles access to any database from any

# host and use ldap to authenticate the user. Greenplum role

# names must match the LDAP common name.

host all all 192.168.0.0/32 ldap ldapserver=usldap1 ldapport=1389

ldapprefix="cn=" ldapsuffix=",ou=People,dc=company,dc=com"

3. 保存并关闭文件。

4. 重新加载 pg_hba.conf 文件从而使得刚刚的修改生效。例如：

$ gpstop -u

注意：pg_hba.conf 文件中的记录是顺序匹配的，当某个登录被前面的记录匹配了，

将不会继续匹配后面的记录。所以，一定要避免记录之间有互相包含的关系出现，否则

不容易发现登录失败的原因。编辑这个文件时一定要注意保证输入的正确性，避免

Windows 隐藏符号等特殊不可见字符的出现，也不能随意修改初始化时自动生成的记

录，错误的修改可能会导致数据库无法访问，甚至出现无法执行 gpstop 等尴尬情况，

那时只能使用 pg_ctl 或者 kill -9 才能停止数据库，这是不应该发生的。

限制并发连接数量

为了限制对 GP 数据库系统的并发访问数量，可以通过配置 Server 参数

max_connections 来实现。这是一个本地化参数，就是说，需要把 Master，Standby

以及所有的 Instance 都修改。通常建议 Instance 的值是 Master 的 5-10 倍，不

过这个规律并非总是如此，在 max_connections 比较大的时候通常没有这么高的倍

数，2-3 倍也是允许的，但无论如何 Instance 的值不能小于 Master。在设置

max_connections 时，其依赖的参数 max_prepared_transactions 参数也需要

修改，该参数的值至少要和 Master 上的 max_connections 值一样大，另外

Instance 上的值要与 Master 相同。

例如：

Greenplum Database 管理员指南 V6.2.1

在$MASTER_DATA_DIRECTORY/postgresql.conf(包括 Standby)文件中：

max_connections=100

max_prepared_transactions=100

在所有的 Instance 上 SEGMENT_DATA_DIRECTORY/postgresql.conf 文件中：

max_connections=500

max_prepared_transactions=100

修改最大连接数的步骤

1. 通过 gpstate 命令确认数据库状态无异常，如：

$ gpstate -e

$ gpstate

$ gpstate -f

2. 使用 gpconfig 命令修改参数值：

$ gpconfig -c max_connections -v 1500 -m 500

$ gpconfig -c max_prepared_transactions -v 500

3. 执行 CHECKPOINT 操作：

$ psql postgres -c "CHECKPOINT"

4. 停止数据库：

$ gpstop -f

5. 重新启动数据库：

$ gpstart -a

注意：增加该参数的值可能需要更多的共享内存，需要注意操作系统参数方面内存相关

的参数配置。

客户端/服务端间的加密连接

GP 原生支持客户端与 Master 服务端之间的 SSL 连接。SSL 连接可以有效的防止

Greenplum Database 管理员指南 V6.2.1

第三方对包的窥探，防止中间层的攻击。在非安全网络环境中有必要使用 SSL，且在使

用权限认证时更为必要。使用 SSL 需要在客户端和 Master 端都安装有 OpenSSL。在

设置参数 ssl=on(在 Master 的 postgresql.conf 文件)后重新启动集群就开启了

SSL。在使用 SSL 模式启动时，数据库会查找 Master 目录下的 server.key(服务器

密钥)文件和 server.crt(服务器证书)文件。这些文件必须被正确的安装，否则数据

库系统将无法启动。

重要提示：不要为 server.key 设置访问口令。数据库不会为密钥提示输入口令，这

样会导致出错并无法启动数据库系统。

关于如何安装 OpenSSL，可参考 PostgreSQL 的相关文档，至少到目前为止，编者没

有进行过这方面的测试。

Greenplum Database 管理员指南 V6.2.1

第五章：访问数据库

本章介绍可以使用哪些客户端工具连接 GP，以及如何建立数据库会话：

 建立数据库会话

 支持的客户端应用

 连接故障排除

建立数据库会话

用户可以使用任何 PostgreSQL 兼容的客户端程序连接到 GP，例如 psql。用户

或者管理员总是通过访问 Master 来连接到 GP 数据库，通常，Instance 不能直接使

用客户端连接，如确有必要，需要使用 Utility 模式来连接。

要连接到 GP 的 Master，需要知道下面这些连接参数并在客户端程序进行正确的配置。

连接参数

描述

环境变量

Application name

连接到数据库的应用名称，该参数为可选项。

$PGAPPNAME

Database name

需要连接的数据库名称。对于新初始化的系统来

$PGDATABASE

说，首次访问可以使用 postgres。

Host name

要连接的 GP Master 的主机名称。缺省为

$PGHOST

localhost。远程连接可能需要 IP 地址。

Port

GP Master 上 Master Instance 的端口号。缺

$PGPORT

省为 5432。

User name

要连接的用户名。其没必要与 OS 的 User Name

$PGUSER

相匹配。在不知道 User Name 的情况下最好联系

询问数据库管理员。每个 GP 系统都有一个初始化

时的 SUPERUSER。该 User Name 与初始化的 OS

User Name 相同(通常为 gpadmin)。

支持的客户端应用

可以使用这些客户端应用连接 GP 数据库：

 在 GP 安装时提供的客户端应用。psql 提供了交互式的命令行方式访问 GP。

Greenplum Database 管理员指南 V6.2.1

 针对GP的pgAdminIII作为一种强化版本支持GP数据库。从1.10.0版本开始，

PostgreSQL 客户端工具 pgAdminIII 开始支持 GP 特性。安装包可以从

pgAdmin 网站下载。因 pgAdminIII 很久没有更新了，对于 5 版本和 6 版本中

的很多特性没有支持，编者为此做了定制开发，针对 5 版本和 6 版本的新功能和

系统表的修改进行了必要的适配，可以很好的兼容 5 版本和 6 版本。

 使用标准数据库应用接口，例如 ODBC 和 JDBC，用户可以开发出自己的客户端程

序。由于 GP 基于 PostgreSQL 而来，可以直接使用 PostgreSQL 驱动访问 GP。

 使用标准数据库应用接口的客户端程序，例如使用 ODBC 和 JDBC 的客户端程序，

可以通过配置的方式连接到 GP。

GP 的客户端应用程序

在 GP 安装时在 Master 主机的$GPHOME/bin 下有一系列的客户端应用程序。下

面是一些常用的客户端应用程序：

名称

用途

createdb

创建新的数据库

createlang

创建新的程序语言

createuser

创建新的数据库 ROLE

dropdb

删除数据库

droplang

删除程序语言

psql

PostgreSQL 交互式命令

reindexdb

将数据库重建索引

vacuumdb

回收数据库的磁盘空间并分析数据库

在使用这些客户端应用程序时，必须通过 GP Master 来访问数据库，必须知道需

要访问的目标 DB Name、Host Name、Port 以及连接使用的 User Name。这些参

数在命令行可以分别使用-d、-h、-p 和-U 提供。没有指定任何选项的参数会优先被

解读为 DB Name。

那些有缺省值的参数可以不指定。缺省的 Host Name 是 localhost。缺省的 Port

是 5432。缺省的 User Name 是当前的 OS User Name，在不指定数据库名称参数时，

当前用户的 User Name 会被当作 DB Name 来使用。GP 的 User Name 与 OS User Name

未必相同。

如果缺省参数值是错误的，可以选择将正确的值保存在环境变量 PGDATABASE、

PGHOST、PGPORT、PGUSER 中。设置 PGPASSWORD 环境变量，或者在~/.pgpass

文件中设置合适的值可以避免反复输入密码的麻烦。.pgpass 文件的格式为：

hostname:port:database:username:password

Greenplum Database 管理员指南 V6.2.1

使用 psql 连接

根据缺省值或者环境变量，下面的例子说明如何通过 psql 连接：

$ psql -d gpdatabase -h master_host -p 5432 -U gpadmin

$ psql gpdatabase

$ psql

如果还没有用户数据库存在，可以连接系统数据库 postgres。例如：

$ psql postgres

在成功连接到数据库之后，psql 会出现一个提示符，包含连接的 DB Name 和一

串字符(=>)(或者=#，仅当该用户是 SUPERUSER 时)。例如：

postgres=>

在提示符处，就可以直接输入 SQL 命令并执行。SQL 命令必须以分号(;)结尾才

能将命令发给 Master 并被数据库执行。例如：

=> SELECT * FROM mytable;

要得到关于 psql 客户端应用程序的更多信息，可以查看 PostgreSQL 的相关文档。

针对 GP 的 pgAdminIII

如果更喜欢图形化界面(有谁不喜欢呢)，可以使用针对 GP 的 pgAdminIII。该

GUI 客户端除了支持标准 PostgreSQL 外，还支持一些 GP 的专有特性。

针对 GP 的 pgAdminIII 支持下列的 GP 专有特性：

 外部表(External tables)

 追加优化表(Append-Optimize table)，压缩表(Compressed

Append-Optimize table)

 图形化的解释器(EPLAIN ANALYZE)

 Server 的参数配置

 资源组

Greenplum Database 管理员指南 V6.2.1

 资源队列

这里提到的 pgAdminIII 是编者自己修改编译的版本，不再是网上直接找到的版

本，目前已经针对 6 版本完成了必要的适配和优化，同时支持 4 版本和 5 版本，能够

正确的显示资源组和资源队列的信息，修复了资源队列刷新的 BUG，外部表的 DDL 信

息正确显示，物化视图，数据表的 UNLOGGED 属性等正确显示，表空间定义的正确显

示，数据库中的对象都按照登录角色的权限只显示应该看得到的对象，包括字段权限。

不过，编者在 github 公开发布的版本，可能会有使用时间的限制，过期之后，

建议联系编者获取新的执行文件，编者并不保证能够及时更新。

安装针对 GP 的 pgAdminIII

支持 5 版本和 6 版本的安装包可以从编者处获取(目前仅提供给编者服务的客户使

用，本文档中提到的其他编者自己的工具命令也是仅提供给编者服务的客户使用，至少

到目前为止，没有公开传播)，获取的将是一个 zip 压缩文件，直接解压成目录后即可

运行使用，目前在编者的 github 上有可以试用的压缩包提供下载，编者服务的用户，

可以联系编者获取无时间限制的可执行文件。

使用 pgAdminIII 执行管理操作

该节介绍诸多 GP 管理操作中的两个重要部分：编辑服务器配置，图形化查看执行计划。

编辑服务器配置

Greenplum Database 管理员指南 V6.2.1

pgAdminIII提供了修改Server配置文件postgresql.conf的方式：通过[工

具]>[服务器配置]> postgresql.conf。不过，编者强烈建议不要使用这种方式修

改服务器参数配置，请使用gpconfig命令完成参数的修改配置。

远程编辑服务器配置

1. 连接到需要修改的数据库。如果连接了多个数据库，要确保已经选中需要修改的数

据库。

2. 选择[工具]>[服务器配置]>postgresql.conf菜单。配置信息将会以列表的形

式打开。

3. 双击需要修改的参数打开一个参数设置对话框。

4. 输入参数的新值。修改好之后点击[确定]按钮保存修改，或者点击[取消]按钮放

弃修改。

5. 如果修改的参数可以通过重新加载配置的方式生效，点击左上角的绿色箭头来完成。

有些参数的修改是需要重启数据库(不是gpstop -u)才能生效的。

查看执行计划

使用pgAdminIII工具，可以通过执行EXPLAIN命令查看执行计划。输出内容包

括GP的分布式查询处理算子，如Hash，Sort，Merge，Join，Filter等，以及

Instance之间数据移动Motion。还可以查看图形化的执行计划，这将非常有助于对

执行计划进行直观的分析。

查看图形化的执行计划

1. 在正确的数据库连接下，选择[工具]>[查询工具]。

2. 使用SQL编辑器输入查询语句，还可以通过图形化对象编辑器或者打开一个SQL文

件的方式来编写SQL语句。

3. 选择[查询]>[解释选项]确认下面的选项：[详细模式]--如果想查看图形化的执

行计划，需要取消该选项。

4. 点击查询面板上端的执行计划按钮，或者使用快捷键[F7]，或者选择[查询]>[解

释]。

执行计划在屏幕的底部展现。例如：

Greenplum Database 管理员指南 V6.2.1

DB 应用程序接口

若需要开发针对GP的应用程序，PostgreSQL提供的一些通用的API同样可以应用

在GP上。这些驱动包并没有与GP一起发布，而是一些独立的项目，需要单独下载和安

装配置从而连接GP。有下面这些驱动可以获取：

PostgreSQL

API

下载连接

Driver

ODBC

pgodbc

可以从 GP 或者 PG 的官网获得。

JDBC

pgjdbc

可以从 GP 或者 PG 的官网获得。

Perl DBI

pgperl

http://gborg.postgresql.org/project/pgperl

Python DBI

pygresql

http://www.pygresql.org

使用通用API来访问GP的说明：

1. 下载相应的语言和对应平台的API文件。例如下载JDK和JDBC。

2. 编写相应的程序连接GP。需要注意SQL的语法支持问题。

下载合适的PostgreSQL驱动并配置到Master Instance的连接。

第三方客户端工具

很多第三方的ETL和BI工具使用标准的API如ODBC、JDBC，都可以通过配置连接

到GP。下面这些工具经过用户证实可以很好的协同GP一同工作：

Greenplum Database 管理员指南 V6.2.1

 Business Objects

 Microstrategy

 Informatica Power Center

 Microsoft SQL Server Integration Services (SSIS) and Reporting

Services (SSRS)

 Ascential Datastage

 SAS

 Cognos

GP专业技术支持可以协助用户配置他们选定的第三方工具协同GP工作。

连接故障排除

有很多导致客户端程序无法成功连接GP的原因。本节介绍一些常见的问题并说明

如何解决这些问题。

问题

解决办法

No pg_hba.conf

要允许远程客户端连接到 GP，必须正确的配置 Master 的

entry for host or

pg_hba.conf 文件。

user

Greenplum

在 Master 失败的情况下，用户是无法连接的。可以通过在 Master 上

Database is not

使用 gpstate 工具检查 GP 系统是否已经启动。

running

Network problems

从远程连接 Master 时，网络问题可能会妨碍连接，例如 DNS 解析错

Interconnect

误。要排除这种问题可先 ping Master 主机，先确保客户端主机可以

timeouts

ping 通 Master。另外需要分清 localhost 与实际的 Host Name。

当然有时候还存在网络防火墙的问题，这种情况下，可以 ping 通

Master，在 Master 主机通过 psql 可以连接数据库，但从客户端连

接 Master 无法连接，此时应该寻求相关的网络管理人员的帮助。

Too many clients

缺省情况下，Master 最大连接数是 250，Instance 为 750。超过这

already

个限制的请求会被拒绝。该限制是由 postgresql.conf 文件中的

max_connections 参数配置的。若修改 Master 上的该参数，还必须

修改 Instance 上该参数为合适的值。

Greenplum Database 管理员指南 V6.2.1

第六章：资源管理

本章介绍GP的资源管理的概念，GP提供了一些功能来帮助用户管理资源，根据业

务的情况来控制资源的使用，防止出现资源的恶性竞争。可以通过资源管理来限制并发

执行的查询数量，内存的消耗量，以及CPU的使用量。GP提供了两种资源管理的方案，

资源组和资源队列。

注意：在RedHat6或者CentOS6中使用资源组是有问题的，这是因为早期的

cgroup有缺陷，最好将Kernel升级到2.6.32-696或者更高的版本以修复已知问题，

从而可以更好的使用资源组功能。这些问题在Redhat7或者CentOS7中已经修复。

资源队列或者资源组这两种资源管理方案同时只能选择使用一种，无法在一个集群

中同时使用两种管理方案。

在初始化数据库时，缺省启用的是资源队列方案。在使用资源队列的时候，可以创

建和管理分配资源组(不是完全没有限制的，例如不能设置CPUSET)，但要真正启用资

源组方案，必须明确的启用资源组，且需要重启数据库以使其生效。

下表列举了资源队列和资源组之间的差异：

功能点

资源队列

资源组

并发

查询语句级别的控制

事务级别的控制

CPU

指定查询的优先级

指定 CPU 资源的百分比或 CPU Core 限制

内存

在资源队列中控制，允许超过限制

在事务级别控制，更精准，不允许超过限制

内存隔离

无

在资源组之间隔离，在同一资源组内的不同

事务之间隔离

用户

资源配额仅对非管理员用户有效

资源配额对管理员用户和非管理员用户同样

有效

排队

仅当没有槽位可用时开始排队

当没有槽位可用时或者没有足够的可用内存

时开始排队

查询失败

当没有足够的可用内存时可能会立即

当事务达到资源组限制的内存，且没有更多

失败

的共享资源组内存时，此时事务如果还需要

需要更多的内存，会导致该查询失败

跳过限制

对超级用户和某些操作和函数不限制

对 SET、RESET 和 SHOW 命令不限制

外部组件

无

可以管理PL/Container的CPU和内存资源

使用资源组

Greenplum Database 管理员指南 V6.2.1

在 GP 数据库中，可以使用资源组(RESOURCE GROUP)来压制 CPU、限制内存和

控制最大并发事务数量。在创建了资源组之后，可以将该资源组分配给多个 ROLE，还

可以分配给 PL/Container 外部组件，以控制这些 ROLE 和外部组件的资源。

当把一个资源组分配给一个 ROLE(基于角色的资源组)时，资源的限制将影响到该

资源组上的所有 ROLE。例如，一个资源组上的内存配额，将限制该资源组上所有 ROLE

正在执行的事务的总的内存使用量上限。

同样，当把一个资源组分配给一个外部组件时，资源配额将影响到该外部组件上的

所有正在执行的实例。例如，为 PL/Containe 创建了一个资源组，该资源组的内存

配额，将限制该外部组件上所有正在运行的实例的总内存使用上限。

 资源组基于角色或基于外部组件

 资源组的属性

 内存管理模式

 并发事务数限制

 CPU配额

 内存配额

 配置与使用资源组

 启用资源组

 创建资源组

 配置基于内存限制的查询终止

 分配资源组给ROLE

 监控资源组状态

 转移查询的资源组

资源组基于角色或基于外部组件

GP 有两类资源组，分别是为 ROLE 管理资源的资源组和为外部组件(如

PL/Container)管理资源的资源组。资源组最普遍的用途是用于限制 GP 数据库中活

Greenplum Database 管理员指南 V6.2.1

跃事务的数量，当然，也可以用于压制 CPU 和内存资源的使用量。

基于角色的资源组通过 Linux Kernel 的 cgroup 来管理 CPU 资源，GP 数据库

使用名为 vmtracker 的内存管理模式为基于角色的资源组进行内存的管理。

当执行一个事务时，数据库会根据 ROLE 所属的资源组的资源配额进行评估，当所

属资源组的资源没有达到配额限制，且资源组的并发事务数也没有达到限制，事务将会

立即被执行。假如，资源组中的并发事务数已经达到限制，后续的事务将要进行排队等

待，直到前面有事务结束。当增加资源组的并发事务数量限制和内存配额，正在排队的

查询也可能会马上得到执行，也就是说这种限制会随着资源组属性的修改而重新评估。

在基于角色的资源组中，查询的排队是先进先出的，先排队的先得到执行，后排队的只

有等到前面排队的事务都得到执行并且空出资源时才会被执行，数据库会定期评估负载

情况以决定资源的分配和是否应该让新的事务开始排队。

使用基于外部组件的资源组来管理外部组件的 CPU 和内存资源。这种资源组，使

用 cgroup 来管理外部组件的 CPU 和内存的使用总量。

注意：GP 的容器化部署，例如 Greenplum for Kubernetes(GP4K)，可能会创建

一组嵌套的 cgroup 配置来管理系统资源，这可能会影响 GP 的资源组管理 CPU 的使

用率、Core 数量和内存使用量，资源组的资源限制将受到上层资源配额的限制。

例如，GP 数据库运行在 cgroup 的限制中，那么 GP 的 cgroup 则会嵌套在上层

的 cgroup 中，上层的系统为 GP 配置了 60%的系统 CPU 配额，GP 的资源组配置了 90%

的 CPU 配额，那么 GP 可以利用的系统 CPU 为 60% x 90% = 54%。

嵌套的 cgroup 不影响基于外部组件(如 PL/Container)的资源组对内存的配额，

只有 GP 的资源组的 cgroup 被配置为顶级 cgroup 时才能管理外部组件的内存配额。

资源组的属性

在创建资源组时，需要确定内存管理模式以确定资源组的类型。另外，还需要确定

该资源组的 CPU 配额和内存的配额，以及可共享内存的比例等，这些资源配额的设置，

都是通过资源组的不同属性来设置的。

资源组的属性有：

属性(限制类型)

描述

MEMORY_AUDITOR

资源组的内存管理模式。基于角色的资源组需要配置为

vmtracker(缺省值)，基于外部组件的资源需要配置为 cgroup。

CONCURRENCY

最大活跃并发事务数量，idle 的事务也包含在内。

Greenplum Database 管理员指南 V6.2.1

CPU_RATE_LIMIT

资源组的 CPU 资源的百分比配额。

CPUSET

资源组保留的 CPU core 的序号标识字符串。

MEMORY_LIMIT

资源组的内存资源的百分比配额。

MEMORY_SHARED_QUOTA

资源组中，事务之间可共享的内存百分比。

MEMORY_SPILL_RATIO

资源组中，内存密集型事务使用的内存百分比上限，超过该限制后

需要溢出到文件。

注意：资源组对 SET、RESET 和 SHOW 命令不做资源限制，因为这种操作本来就不需

要消耗很多资源。不过，编者认为，仅仅是对这几种 SQL 命令不做限制还是不够的，

还需要有更多可选项，比如资源队列的 MIN_COST，或者可以匹配特定的 SQL，因为，

短查询参与长时间的排队总是让人难以接受。

内存管理模式

通过 MEMORY_AUDITOR 属性来确定资源组的类型，vmtracker 表明这是一个基

于 ROLE 的资源组，cgroup 表明这是一个基于外部组件的资源组。MEMORY_AUDITOR

属性的缺省值是 vmtracker，即，基于 ROLE 的资源组。为资源组指定内存管理模式

会影响到，GP 如管理分配给资源组特定配额的内存资源，以及如何管理 CPU 资源：

属性(限制类型)

基于 ROLE

基于外部组件

CONCURRENCY

Yes

No；必须是 0，就是不管

CPU_RATE_LIMIT

Yes

CPUSET

Yes

MEMORY_LIMIT

Yes

MEMORY_SHARED_QUOTA

Yes

组件相关

MEMORY_SPILL_RATIO

Yes

组件相关

注意：对于内存管理模式配置为 vmtracker 的资源组，GP 支持基于内存使用量来自

动终止查询。与参数 runaway_detector_activation_percent 有关。

并发事务数限制

CONCURRENCY 属性配置基于 ROLE 的资源组中最大并发事务的数量。

注意：CONCURRENCY 限制不适用于基于外部组件的资源组，这种资源组必须设置该属

性为 0。对于 SUPERUSER 来说，其并发事务数量也会受到资源组的 CONCURRENCY 属

Greenplum Database (V6.2.1) - 1