以下执行SQL基于Greenplum Database 6.18.2版本（和Greenplum Database 4版本略有不同）
1.1.集群状态查询
查询命令：gpstate
集群实例正常状态示例图
集群实例异常状态示例图
查看集群主实例与镜像实例同步状态
查询命令：gpstate -m
Status均为Passive，Data Status均为为Synchronized则正常，否则异常
1.2.负载查询
使用vmstat命令可以监控 CPU 使用、进程状态、内存使用、虚拟内存使用、硬盘输入/输出状态等信息，常使用方法为：vmstat [刷新延时 刷新次数]
1.3.会话查询
select datid, --数据库OID
datname, --数据库名
pid, --后台服务器进程号(即对应该会话在master节点操作系统进程ID号)
sess_id, --会话线程号
usesysid, --role ID号
usename, --role名称
client_addr, --客户端地址
client_port, --客户端端口
application_name, --客户端应用名称
substr(query,1,80) --请求SQL，较长SQL截取部分
query_start, --请求开始时间
backend_start, --backend进程开始时间，即用户连接数据库时建立会话的时间
xact_start, --事务开始时间
waiting, --是否等待True if waiting on a lock, false if not waiting
waiting_reason --等待原因. The value can be:lock, replication, or resgroup
from pg_stat_activity where state<>’idle’;复制
1.4. 磁盘空间查询
数据库查看使用量
select * from gp_toolkit.gp_disk_free;复制
系统命令行查看（在此例中“host_list”为所有服务器节点清单，“data”为数据存放目录，根据实际目录文件名查询即可）
gpssh -f host_list -e “df -h |grep data”复制
2.1.修复前负载判定(是否是实例宕机，是否需要kill会话,是否需要重启等)
在查看集群状态为异常后，进一步查看是否存在超过一个小时以上的会话，是否存在锁等情况
select * from gp_segment_configuration;
--以上语句查询结果中status存在'd'结果，则是存在实例宕机，可以往下继续判断
--如果均为'u'，可以参考后面的2.6小节
select pid,usename,query_start,client_addr,xact_start,waiting ,waiting_reason,query from pg_stat_activity where state <>'idle' and query_start < now()-interval '1 hour' order by query_start;复制
查看节点负载，可以使用1.2中的vmstat命令，也可以使用nmon监控工具（需安装）
c 查看CPU相关信息
m 查看内存相关信息
d 查看磁盘相关信息
n 查看网络相关信息
t 查看相关进程信息
h 查看帮助相关信息
2.2.日志备份([可选]判定实例>判定路径>备份日志)
Select con.time,
con.dbid,
seg.content,
seg.status,
seg.port,
seg.hostname,
seg.datadir ,
con."desc"
from gp_segment_configuration seg ,gp_configuration_history con
where con.dbid=seg.dbid and seg.status='d' order by con.time desc limit 10;复制
集群实例宕机后首要是先恢复集群状态，但这恢复的时候数据节点日志往往会被清理掉，所以可以先备份当天节点日志后，先恢复集群，后面再查看日志寻找宕机的具体原因，根据seg.hostname和seg.datadir，以及 con.time备份对应实例pg_log目录下对应日期的日志
2.3.常规修复(以防突然断电或远程断开等情况，一般建议后台运行)
nohup gprecoverseg -a &复制
若存在主备切换，则需要在修复完成后进行实例切回
nohup gprecoverseg -ra &复制
2.4.查看修复进度
gpstate -e复制
2.5.全量修复方式
nohup gprecoverseg -Fa &复制
若存在主备切换，则需要在修复完成后进行实例切回
nohup gprecoverseg -ra &复制
2.6.非实例宕机的情况
如果集群状态显示异常，但在2.1中查询结果并不存在实例宕机的情况，可以先查看是否是集群用户存在密码过期导致无法互信的情况
查看互信情况，发现其中一台服务器无法连接，ssh时并提示密码过期
这样就需要重新设置改服务器gpadmin用户的密码或者过期时间即可
3.1.创建role/schema
创建用户可以使用CREATE USER 或者CREATE ROLE命令，唯一区别是CREATE USER默认情况下假定LOGIN， 而CREATE ROLE默认情况下假定NOLOGIN.
如创建test用户可以登陆资源队列为 pg_default，密码为passwd：
create role test with login resource queue pg_default password 'passwd';复制
创建模式
Create schema test;复制
如果是为角色创建一个同名模式：如
Create schema authorization test;复制
创建资源队列
create resource queue rq_df with(active_statements=1,priority=medium);复制
修改用户资源队列
alter role test with resource queue rq_df;复制
查看用户资源队列对应情况
select rolname,rsqname from pg_roles,gp_toolkit.gp_resqueue_status where pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.queueid;复制
3.2.授权与回收权限
根据需要授权用户使用相应权限
GRANT { {SELECT | INSERT | UPDATE | DELETE | REFERENCES |
TRIGGER | TRUNCATE } [, ...] | ALL [PRIVILEGES] }
ON { [TABLE] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC} [, ...] [ WITH GRANT OPTION ]
GRANT { {USAGE | SELECT | UPDATE} [, ...] | ALL [PRIVILEGES] }
ON { SEQUENCE sequence_name [, ...]
| ALL SEQUENCES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]复制
例如：
授权用户使用模式权限(用户需要先有schema的使用权限，才能使用其他权限)
GRANT USAGE ON SCHEMA schema to user;复制
授权用户查询表权限
grant select on tablename to user;复制
postgresql 9.0 版本以后，如果是一个用户对另一个用户新建的表需要有查询等权限，可以使用一些语句，不用再对新建表去重新授权
alter default privileges for user test in schema test grant select on tables to test1;
--举例中，test用户在test模式下再建新表时，test1用户自动对test模式下新建的表有select权限复制
回收权限则是revoke命令，后面to 改为from即可，如回收用户使用模式权限
REVOKE USAGE ON SCHEMA schema from user;复制
在上例中，回收上面的权限的语句为：
alter default privileges for user test in schema test revoke select on tables from test1;复制
3.3.权限查看
查看哪些用户对具体表有哪些权限
lect * from information_schema.table_privileges where table_name ='test';复制
查看具体用户有哪些表的哪些权限
elect * from information_schema.table_privileges where grantee='test' or grantor='test';复制
3.4.锁定role
—锁定用户
alter role test with nologin;复制
3.5.删除schema（生产环境慎用！！！）
—删除schema
DROP SCHEMA [IF EXISTS] name [, ...] [CASCADE | RESTRICT];复制
3.6.删除role（生产环境慎用！！！）
—删除用户
DROP ROLE [IF EXISTS] test;复制
4.1.会话查询
select datid, --数据库OID
datname, --数据库名
pid, --后台服务器进程号(即对应该会话在master节点操作系统进程ID号)
sess_id, --会话线程号
usesysid, --role ID号
usename, --role名称
client_addr, --客户端地址
client_port, --客户端端口
application_name, --客户端应用名称
substr(query,1,80) --请求SQL，较长SQL截取部分
query_start, --请求开始时间
backend_start, --backend进程开始时间，即用户连接数据库时建立会话的时间
xact_start, --事务开始时间
waiting, --是否等待True if waiting on a lock, false if not waiting
waiting_reason --等待原因. The value can be:lock, replication, or resgroup
from pg_stat_activity where state<>’idle’;复制
4.2.锁查询
—锁查询跟踪
SELECT pg_locks.pid as pid, --进程ID
transactionid as transaction_id, --事务ID
nspname as schemaname, --schema名
relname as object_name, --对象名
locktype as lock_type, --锁类型
mode lock_mode, --锁模式
CASE
WHEN granted = 'f' THEN
'get_lock'
WHEN granted = 't' THEN
'wait_lock'
END lock_satus, --锁状态：持有锁|等待锁
CASE
WHEN waiting = 'false' THEN
'already get lock,sql executing'
WHEN waiting = 'true' THEN
'waiting get lock,sql waiting execute'
END waitting_satus, --当前会话状态：执行中|等待中
least(query_start, xact_start) AS query_start, --query请求开始时间
substr(query, 1, 25) AS query_text --当前SQL语句
FROM pg_locks
LEFT OUTER JOIN pg_class
ON (pg_locks.relation = pg_class.oid)
LEFT OUTER JOIN pg_namespace
ON (pg_namespace.oid = pg_class.relnamespace), pg_stat_activity
WHERE NOT pg_locks.pid = pg_backend_pid()
AND pg_locks.pid = pg_stat_activity.pid
ORDER BY query_start;复制
4.3.会话kill
— 停止会话
当报Too many sessions会话数满或数据库无响应或事务被锁需要中断锁源头时，可以使用杀会话方式临时解决。优先建议使pg_cancel_backend()函数(长事务会话需要等待较长时间中断)，在无法等待较长时间等待时，可pg_terminate_backend()函数(该方式杀会话有极小概率导致系统元数据不一致)。在数据库响应等极端情况可，方可考虑使用 kill -9 pid进行强制会话进程中断，一般先使用 kill -15 pid终端会话进程。
正常取消会话
select pg_cancel_backend(pid);复制
强制中断会话
select pg_terminate_backend(pid);复制
其中：pid为pg_stat_activity视图中的pid查询结果，如：
gpdw=# select pg_cancel_backend(2243);
pg_cancel_backend
-------------------
t
(1 row)
gpdw=# select pg_terminate_backend(2243);
pg_terminate_backend
----------------------
t
(1 row)复制
查询空闲会话ID并使用杀会话方式进行会话资源释放。
select pid from pg_stat_activity where state='idle';复制
查询某时间段之后的会话
select pid from pg_stat_activity where query_start>CAST('2022-06-26 11:12:10' AS TIMESTAMP);复制
查询30分钟内会话
select * from pg_stat_activity where backend_start>(now() - interval '30 min'复制
操作系统层面查看idle会话进程 kill后台进程
ps -ef |grep -i postgres |grep -i idle|grep -v grep | awk '{print $2}' |xargs kill -15复制
5.1.策略文件说明
Greenplum数据库连接访问及验证机制由pg_hba.conf配置文件控制，在Greenplum数据库系统中，master主机上的pg_hba.conf文件控制客户端的访问及验证，而segment节点上的pg_hba.conf文件已经默认只与master主机连接，不接受其他外部客户端的连接。pg_hba.conf目录为$MASTER_DATA_DIRECTORY。更新该策略文件后，使用gpstop -u生效。
—pg_hba.conf格式说明
该文件有如下5列，列间为空格，不区分大小写。
登陆客户端类型 允许访问数据库 数据库角色名 允许连接客户端IP(段) 验证方式
登陆客户端类型：host|local --远程登录|本地登录
允许访问数据库：dbname|all --具体数据库名|所有数据库
数据库角色名：rolename|all --具体用户名|所有用户
允许连接客户端IP(段) --设置IP地址或IP地址段,格式如下：
192.168.32.100/32 --指定IP地址192.168.32.100
192.168.32.0/24 --指定192.168.32.0网段
192.168.0.0/16 --指定192.168.0.0网段
192.0.0.0/8 --指定192.0.0.0网段
验证方式：ident|md5|password|trust|reject --说明如下：
ident：本地验证，即使用操作系统gpadmin用户验证。
md5：密码验证
password：发送明文密码至数据库验证(建议不用)
trust:免密登录
reject:拒绝登录，即黑名单。建议黑名单放在pg_hba.conf文件最末复制
5.2.策略配置及生效
gpstop -u复制
5.3.策略登录验证
psql -d gp -h ip -U test复制
正常连接到数据库则策略添加成功
点击此处阅读原文
↓↓↓
