GreenPlum数据库日常维护运维(持续更新)

0    230    5

Tags:

👉 本文共约14402个字,系统预计阅读时间或需55分钟。

本页目录 隐藏

简介

现在企业客户中搭建的Greenplum集群服务器数量是越来越大,在电信行业和银行业,搭建50台服务器以上的Greenplum集群越来越多。而集群服务器数量越多也就代表故障发生率越高。作为Greenplum的DBA和运维人员,不单只关注Greenplum本身,还要关注集群中各硬件的状况,及时发现及时处理。硬盘状态、阵列卡状态、硬件告警、操作系统告警、空间使用率等都是应关注的重点。这些都可通过厂商提供的工具,编写监控程序,SNMP协议对接企业监控平台等手段提升日常巡检和监控的效率。

要保持一个Greenplum数据库系统高效运行,必须对数据库定期清理过期数据并且更新表统计信息, 这样查询优化器才能有准确的信息。

Greenplum数据库要求定期执行特定的任务来达到最优性能。这里讨论的任务都是必须的,但数据库管理员可以使用 标准的UNIX工具(如cron脚本)来自动化这些任务。管理员建立适当的脚本并且检查它们是否 成功执行。

日常维护关注点

针对Greenplum,DBA需要关注的重点:

(1)Greenplum的状态:Standby master的同步状态往往容易被忽略。通过监控平台或者脚本程序,能够及时告警则最好。

(2)系统表:日常系统表维护(vacuum analyze),在系统投产时就应该配置好每天执行维护。

(3)统计信息收集:统计信息的准确性影响到运行效率,用户表应该及时收集统计信息。在应用程序中增加收集统计信息的处理逻辑,通过脚本定时批量收集统计信息,或者两者相结合。针对分区表日常可按需收集子分区的统计信息,可节省时间提升效率。

(4)表倾斜:表倾斜情况应该DBA的关注点之一,但无需每天处理。

(5)表膨胀:基于postgresql的MVCC机制,表膨胀情况不能忽视。重点应该关注日常更新和删除操作的表。

(6)报错信息:在日志中错误信息多种多样,大部分不是DBA需要关注的。应该重点关注PANIC、OOM、Internal error等关键信息。

官方文档

一切尽在官方文档中......

http://docs-cn.greenplum.org/

http://docs-cn.greenplum.org/v6/homenav.html

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/9ccd913ea8be24b9.md

日常运维查询命令

启动和关闭

数据库启动:gpstart

常用可选参数: -a : 直接启动,不提示终端用户输入确认

-m:只启动master 实例,主要在故障处理时使用

数据库停止:gpstop

常用可选参数:-a:直接停止,不提示终端用户输入确认

-m:只停止master 实例,与gpstart –m 对应使用

-M fast:停止数据库,中断所有数据库连接,回滚正在运行的事务

-u:不停止数据库,只加载pg_hba.conf 和postgresql.conf中运行时参数,当改动参数配置时候使用。

总结

查看实例配置和状态

主要字段说明:

Content:该字段相等的两个实例,是一对P(primary instance)和M(mirror Instance)

Isprimary:实例是否作为primary instance 运行

Valid:实例是否有效,如处于false 状态,则说明该实例已经down 掉。

Port:实例运行的端口

Datadir:实例对应的数据目录

集群状态查询

查询命令:gpstate

显示Greenplum数据库运行状态,详细配置等信息

常用可选参数:-c:primary instance 和 mirror instance 的对应关系

-m:只列出mirror 实例的状态和配置信息

-f:显示standby master 的详细信息

-Q:显示状态综合信息

该命令默认列出数据库运行状态汇总信息,常用于日常巡检。

评:最开始由于网卡驱动的问题,做了mirror后,segment经常down掉,用-Q参数查询综合信息还是比较有用的。

查看集群主实例与镜像实例同步状态

查询命令:gpstate -m

Status均为Passive,Data Status均为为Synchronized则正常,否则异常

负载查询

使用vmstat命令可以监控 CPU 使用、进程状态、内存使用、虚拟内存使用、硬盘输入/输出状态等信息,常使用方法为:vmstat [刷新延时 刷新次数]

也可以使用gpcc历史视图查询,参考:https://www.xmmup.com/greenplumguanfangjiankonggongjugpccjianjiejishiyong.html

磁盘空间查询

数据库查看使用量

系统命令行查看(在此例中“host_list”为所有服务器节点清单,“data”为数据存放目录,根据实际目录文件名查询即可)

查询数据库、表占用空间大小

必须在数据库所对应的存储系统里,至少保留30%的自由空间,日常巡检,要检查存储空间的剩余容量。

评:可以查看任何数据库对象的占用空间,pg_size_pretty可以显示如mb之类的易读数据,另外,可以与pg_tables,pg_indexes之类的系统表链接,统计出各类关于数据库对象的空间信息。

查询数据库大小

参考:https://www.xmmup.com/greenplumchaxunshujukudaxiao.html

表占用空间大小

索引占用空间大小

分区表大小

查看GreenPlum表的分布键和压缩类型

查询对象类型和个数

查看表数据分布情况(数据倾斜)

参考:https://www.xmmup.com/greenplumxingnengdiaoyouzhishujuqingxie.html

如数据分布不均匀,将发挥不了并行计算的优势,严重影响性能。

评:非常有用,gp要保障数据分布均匀。

分步键的选择参数gp_create_table_random_default_distribution参考:https://www.xmmup.com/greenplumchuangjianheguanlibiao.html#can_shugp_create_table_random_default_distribution

查看数据库数据分布情况(数据倾斜)

会话、锁信息管理

会话查询、慢查询SQL

pg_stat_activity 该表能查看到当前数据库连接的IP 地址,用户名,提交的查询等。

另外也可以在master 主机上查看进程,对每个客户端连接,master 都会创建一个进程。ps -ef |grep -i postgres |grep -i con

锁查询

会话kill、停止会话、杀会话

当报Too many sessions会话数满或数据库无响应或事务被锁需要中断锁源头时,可以使用杀会话方式临时解决。优先建议使pg_cancel_backend()函数(长事务会话需要等待较长时间中断),在无法等待较长时间等待时,可pg_terminate_backend()函数(该方式杀会话有极小概率导致系统元数据不一致)。在数据库响应等极端情况可,方可考虑使用 kill -9 pid进行强制会话进程中断,一般先使用 kill -15 pid终端会话进程。

区别pg_cancel_backend 只是取消当前某一个进程的查询操作,但不能释放数据库连接。但pg_terminate_backend可以在pg的后台杀死这个进程,从而释放出宝贵的连接资源,类似于kill -9 pid操作。

正常取消会话

强制中断会话

其中:pid为pg_stat_activity视图中的pid查询结果,如:

查询空闲会话ID并使用杀会话方式进行会话资源释放。

查询某时间段之后的会话

查询30分钟内会话

操作系统层面查看idle会话进程 kill后台进程

登陆与退出Greenplum

参数查询

这个有用,可以管道给grep。

查询分步键

在Greenplum中,建表时指定分布键的语法如下:

其中,DISTRIBUTED BY子句用于指定分布键,可以指定一个或多个列。一般来说,指定的分布键字段组合的大小应该控制在2-4个左右,这样可以保证分布键的效果,即让数据尽可能均匀地分布到各个节点上,提高查询性能。如果组合的字段过多,可能会导致某些节点上的数据倾斜,进而影响查询性能。

需要注意的是,指定的分布键字段不一定需要是表的主键,但应该是常用于查询和筛选的字段。另外,为了进一步提高查询性能,还可以考虑在表上创建合适的索引。

请参考:https://www.xmmup.com/greenplumchuangjianheguanlibiao.html#can_shugp_create_table_random_default_distribution

创建数据库

创建GP文件系统

创建GP表空间

删除GP数据库

查看GP日志

OBJECT的DDL操作统计

队列查询

gpfdist外部表

参考:https://www.xmmup.com/greenplumzhongdeshujujiazaigongjuzhigpfdisthegpload.html

注意:

1、数据库服务端必须能访问客户端,且telnet 客户端IP 8081是通的。

gpload导入数据

copy导出导入数据

执行sql文件

或者psql登陆后执行

查询gp最后vacuum时间

磁盘空间不足

将查询结果导出到文件

添加和删除standby master

添加和删除standby master的命令:

添加segment镜像mirror

需要注意一点的是:greenplum目前只提供添加mirror命令,而没有提供删除mirror命令,不过可以通过其它方式删除,在生产库不建议操作(我做了一次把库搞挂了)

Master节点故障恢复

1、若master故障,则直接在standby master上执行如下命令将standby master激活为主master:

若有VIP也需要切换VIP。

然后原来的master节点可以删除数据后,然后作为新的standby加入:

2、若standby master故障,则分情况:若是宕机,其实可以正常启动,使用如下命令正常启动:

若数据库文件损坏不能正常启动,则需要将standby节点数据删除,然后重新初始化一下standby服务器即可,需要先删除再添加:

3、master和standby master就是PG中的主从复制,要想实现自动故障转移,则需要借助keepalived或repmgr或patroni或pgpool实现高可用自动切换。

Segment节点故障恢复

  1. 当一个primary segment节点故障,那么它所对应的mirror segment节点会自动接替primary的状态,继续保证整个集群的数据完整性

  2. 当一个mirror segment节点出现故障,它不会影响整个集群的可用性,但是需要尽快修复,保证所有的primary segment都有备份

  3. 如果primary segment 和它所对应的mirror segment 节点都出现故障,那么greenplum认为集群数据不完整,整个集群将不再提供服务,直到primary segment 或 mirror segment恢复

  4. primary segment节点和mirror segment节点的故障修复方式是一样的,都执行如下命令即可:gprecoverseg -a

    恢复方式都一样,若没有业务连接,则可以直接进行恢复:

    若有业务连接,则需要关闭和重启集群:

  5. 在执行gprecoverseg恢复segment后,原有的primary和mirror会发生变动,可能导致所有的primary都在同一台几点,会导致性能问题,所以应该执行命令进行重平衡gprecoverseg -r就可以让集群回到最初的配置角色了。

扩容GreenPlum系统

1、主要是4步扩容:

2、监控视图,在postgres数据库中:

例行清理和分析

Greenplum数据库中使用的MVCC事务并发模型的设计意味着被删除或者被更新的数据行仍在磁盘上占据物理空间, 即便它们已经对新事务不可见。如果数据库进行了很多更新和删除,会有很多过期行存在并且它们所使用的空间必须使用 VACUUM命令来回收。VACUUM命令还会收集表级的统计信息,例如行数和 页面数,因此即便无需从被更新或者被删除行回收空间,也还是有必要去清理追加优化表。

清理一个追加优化表遵循一种和清理堆表不同的处理逻辑。在每一个Segment上,会创建一个新的Segment文件并且 把可见行从当前Segment复制到该文件中。当Segment文件被拷贝完时,将会安排删除原始的Segment文件并且让新 的Segment文件变得可用。这要求足够的可用磁盘空间用于拷贝可见行,直到原始的Segment文件被删除为止。

如果一个Segment文件中隐藏行和所有行的比率低于一个阈值(默认是10),该Segment文件不会被紧缩。 该阈值可以通过gp_appendonly_compaction_threshold服务器配置参数配置。VACUUM FULL 忽略gp_appendonly_compaction_threshold的值并且不管该比率为多少都会重写Segment文件。

可以使用gp_toolkit模式中的__gp_aovisimap_compaction_info()函数来查看 追加优化表上的VACUUM操作的效果。

有关__gp_aovisimap_compaction_info()函数的信息请见Greenplum Database Reference Guide “检查追加优化表”部分

可以使用gp_appendonly_compaction服务器配置参数为追加优化表禁用 VACUUM操作。

有关清理数据库的细节请见清理数据库

有关gp_appendonly_compaction_threshold服务器配置参数和VACUUM 命令的信息请见Greenplum Database Reference Guide。

事务ID管理

Greenplum的MVCC事务机制依赖于比较事务ID(XID)号来判断当前数据对于其他事务的可见性。 事务ID号使用一种模232的算法来比较,因此一个运行了超过二十亿事务的 Greenplum系统可能会遇到事务ID回卷,即过去的事务变成了未来的事务。这意味着过去的事务的 输出变得不可见。因此,每过二十亿个事务就有必要VACUUM每个数据库中的 每个表至少一次。

Greenplum数据库只对涉及DDL或者DML操作的事务分配XID值,通常也只有这些事务需要XID。

Important: Greenplum数据库会监控事务ID。如果没有定期清理数据库,Greenplum 数据库将产生警告和错误。

当事务ID中相当多的一部分变得不再可用并且事务ID回卷还没有发生时,Greenplum数据库会发出 下面的警告:

WARNING: database “database_name” must be vacuumed within number_of_transactions transactions

当这个警告被发出时,需要一次VACUUM操作。如果没有执行VACUUM 操作,当Greenplum数据库在事务ID回卷发生前达到一个限制,它会停止创建新的事务。在停止创建 事务以避免可能的数据丢失时,Greenplum数据库会发出这个错误:

Greenplum数据库配置参数xid_warn_limit控制何时显示该警告。参数 xid_stop_limit控制何时Greenplum数据库停止创建事务。

从一次事务ID限制错误中恢复

当Greenplum数据库由于不频繁的VACUUM维护而达到 xid_stop_limit事务ID限制时,它会变得没有响应。为了从这种情况中 恢复过来,作为数据库管理员执行下面的步骤:

  1. 关闭Greenplum数据库。
  2. 临时将xid_stop_limit降低10,000,000。
  3. 启动Greenplum数据库。
  4. 在所有受影响的数据库上运行VACUUM FREEZE。
  5. 将xid_stop_limit重置为原来的值。
  6. 重启Greenplum数据库。

有关这些配置参数的信息请见Greenplum Database Reference Guide

有关事务ID回卷的信息请见PostgreSQL documentation.

系统目录维护

多次使用CREATE和DROP命令的数据库更新会增长系统目录尺寸并且 影响系统性能。例如,运行很多次DROP TABLE语句会降低总体系统性能,因为在目录表上 的元数据查询期间会需要更多扫描时间。性能损失会在数千次或者数万次DROP TABLE语句 之间发生,具体时间取决于系统。

应该定期维护系统目录来回收已删除对象所占据的空间。如果长时间没有运行这种定期回收操作,那可能需要运行 一个更彻底的回收操作来清理系统目录。这个主题会描述这两种方式。

常规系统目录维护

推荐周期性地在系统目录上运行REINDEX和VACUUM来清理系统索引和 表中已删除对象所占用的空间。如果常规的数据库操作包括很多DROP语句,那么每天在非峰值 时间用VACUUM命令运行一次系统目录维护是安全且适当的。用户可以在系统可用时执行这种操作。

下面是Greenplum数据库系统目录维护步骤。

  1. 在系统表上执行REINDEX命令以重建系统表索引。该操作移除索引膨胀并提高VACUUM 性能。

    Note: 当在系统表上执行REINDEX操作时,表上会产生锁,此时可能会对当前正在运行的 查询产生比较大的影响。建议在系统负载较低时执行REINDEX操作,以避免对正在运行的 业务操作产生较大的干扰。

  2. 在系统表上执行VACUUM操作。

  3. 在系统表上执行ANALYZE操作,用以更新统计信息。

下面的示例脚本在一个Greenplum数据库系统目录上执行一次REINDEX、VACUUM 以及ANALYZE操作: 将脚本中的替换为真实数据库名。

Note: 如果在系统维护时间内已经开始了正常的系统目录维护操作,但是由于时间原因想要停止某一维护进程, 此时可以运行Greenplum数据库函数pg_cancel_backend() 以安全停止该Greenplum数据库进程。

深度系统目录维护

如果很长时间都没有执行一次系统目录维护操作,该目录可能因为废弃空间而膨胀。这会导致简单的元数据 操作都会等待很长时间。在psql中用\d命令列出用户表需要超过 两秒的等待,就是目录膨胀的一种征兆。

如果发现系统目录膨胀的征兆,就必须在计划好的停机时段用VACUUM FULL执行一次 深度系统目录维护操作。在这一时段中,停止系统上的所有目录活动,这种VACUUM FULL 系统目录维护过程会对系统目录加排他锁。

运行定期系统目录维护操作可以防止对这种更高开销操作的需求。

以下是深度系统目录维护操作的步骤。

  1. 停止Greenplum数据库系统上的所有活动元数据操作。
  2. 在系统表上执行REINDEX操作以重建系统表索引。该操作移除索引上的膨胀并提高 VACUUM操作性能。
  3. 在系统表上执行VACUUM FULL命令,具体查看下面的注释。
  4. 在系统表上执行ANALYZE命令以更新系统表的统计信息。

Note: 通常来说,表pg_attribute是最大的系统表。如果pg_attribute 表膨胀的特别厉害,该表上的VACUUM FULL操作可能需要更长的时间并且可能需要分开执行。 以下两种情况的出现预示着pg_attribute表膨胀很厉害并且需要长时间的VACUUM FULL 操作:

  • pg_attribute表包含大量记录。
  • gp_toolkit.gp_bloat_diag视图中的信息显示pg_attribute的状态为significant amount of bloat

为查询优化进行清理和分析

Greenplum数据库使用一种基于代价的查询优化器,它依赖于数据库的统计信息。准确的统计信息帮助查询优化器 更好的评估选择度以及一个查询操作检索的行数。这些评估会帮助它选择最有效的查询计划。ANALYZE 命令会为查询优化器收集列级的统计信息。

可以在同一个命令中同时执行VACUUM和ANALYZE操作。例如:

当在一个显著膨胀的表(显著膨胀的表磁盘空间被已删除或者已废弃行占据)上运行VACUUM ANALYZE 命令时,该命令可能会产生不正确的统计信息。对于大型的表,ANALYZE命令会从行的一个随机 采样中计算统计信息。它会通过计算采样中每页的平均行数与表中实际页数的成绩来估算表中的总行数。如果采样包含 很多空页,估计出的行计数可能会不准确。

对于一个表,可以在gp_toolkit视图gp_bloat_diag中查看有关未使用磁盘空间(被已删除或者 已废弃行占据的空间)量的信息。如果一个表的bdidiag列包含值 significant amount of bloat suspected,那么相当多的表磁盘空间由未使用空间组成。 在一个表被清理后,相关项会被加入到gp_bloat_diag视图中。

要从表中移除未使用的磁盘空间,可以在该表上运行命令VACUUM FULL。由于对表锁的需求, VACUUM FULL可能无法在非维护时段运行。

作为一种临时的变通方案,可以运行ANALYZE来计算列统计信息,然后在该表上运行 VACUUM来生成准确的行计数。这个例子在cust_info表上先运行ANALYZE, 然后运行VACUUM。

Important: 如果想要在启用了GPORCA(默认启用)的情况下对分区表执行查询, 必须用ANALYZE命令在分区表根分区上收集统计信息。有关GPORCA的信息,请见GPORCA概述

Note: 可以使用Greenplum数据库工具analyzedb来更新表统计信息。表可以被并行地分析。 对于追加优化表,只有统计信息不是当前值时,analyzedb才会更新统计信息。有关analyzedb 工具的信息,请见analyzedb

常规的索引重建

对于B-树索引,一个刚刚构建的索引访问起来比一个已经更新过很多次的索引要快一点,因为在新构建的索引中逻辑 上相邻的页面在物理上也相邻。定期地重建旧的索引可以提升访问速度。如果一个页面上除了索引以外的数据都被删除, 那么索引页上对应的也会产生浪费的空间。重建索引操作会回收这些被浪费的空间。在Greenplum数据库中,删除索引 (DROP INDEX)再重建 (CREATE INDEX)通常比直接使用REINDEX 命令要快。

对于有索引的表列,批量更新或者插入之类的一些操作可能会执行得更慢,因为需要更新索引。为了提高带有索引 的表上的批量操作性能,可以先删除掉索引,然后执行批量操作,最后再重建索引。

管理Greenplum数据库日志文件

数据库服务器日志文件

Greenplum数据库的日志输出常常会体量很大,尤其是在调试级别时,用户不需要无限期保存它。管理员可以应该 定期清理日志文件。

Greenplum数据库在Master和所有的Segment实例上都启用了日志文件轮转。 日志文件被创建在Master以及每个Segment的数据目录中的pg_log子目录下,这些文件使用 命名规则:gpdb-YYYY-MM-DD_hhmmss.csv。数据库管理员需要 编写脚本或程序定期清理Master以及每个Segment日志目录pg_log下的旧文件。

日志轮转可以被当前日志文件的大小或当前日志文件的年龄触发。log_rotation_size 配置参数设置触发日志轮转的单个日志文件大小。当日志文件大小等于或大于特定的大小时,该文件会停止写入, 系统重新创建一个新的日志文件。log_rotation_size的值的单位为KB。默认为1048576, 即1GB。如果log_rotation_size设置为0,表示基于文件大小的日志轮转被禁用。

log_rotation_age配置参数定义了出发日志轮转的日志文件年龄。当文件自创建时开始到达 特定长度的时间时,该文件停止写入,系统重新创建一个新的日志文件。默认的log_rotation_age 时间为1d,即当前日志文件创建24小时之后。如果log_rotation_age设置为0,表示基于时间 的轮转被禁用。

更多查看数据库日志文件的信息,请见查看数据库服务器日志文件.

管理工具日志文件

reenplum数据库管理工具的日志文件默认被写入到~/gpAdminLogs。管理日志文件的命名规则是:

日志详情的格式是:

每次一个工具运行时,就会向其每日的日志文件中增加与其执行相关的日志信息。

收集统计信息,回收空间

定期使用Vacuum analyze tablename 回收垃圾和收集统计信息,尤其在大数据量删除,导入以后,非常重要

vacuum分两种,一种是analyze,优化查询计划的,还有一种是清理垃圾数据。

postgres删除工作,并不是真正删除数据,而是在被删除的数据上,做一个标记,只有执行vacuum时,才会真正的物理删除,这个非常重用,有些经常更新的表,各种查询、更新效率会越来越慢,这个多是因为没有做vacuum的原因。

以下脚本用于生成收集统计信息的shell脚本:

缺失统计信息的表可以通过如下SQL查询

对表做DDL操作会导致统计信息失效,而gp_toolkit将统计信息失效的表也归纳为统计信息缺失。

ANALYZE会给目标表加SHARE UPDATE EXCLUSIVE锁,也就是与UPDATE,DELETE,还有DDL语句冲突。

定时收集统计信息

vacuumdb

缺点:不能并行,执行较慢

优点:占用资源少

analyzedb

优点:可以并行,执行较快

缺点:占用资源多

分析执行计划

explain:在提交大的查询之前,使用explain分析执行计划、发现潜在优化机会,避免将系统资源熬尽。

少写了个analyze,如果只是explain,统计出来的执行时间,是非常坑爹的,如果希望获得准确的执行时间,必须加上analyze。

集群修复

查看节点状态

修复前负载判定(是否是实例宕机,是否需要kill会话,是否需要重启等)

在查看集群状态为异常后,进一步查看是否存在超过一个小时以上的会话,是否存在锁等情况

查看节点负载,可以使用1.2中的vmstat命令,也可以使用nmon监控工具(需安装)

c 查看CPU相关信息
m 查看内存相关信息

d 查看磁盘相关信息

n 查看网络相关信息

t 查看相关进程信息

h 查看帮助相关信息
GreenPlum数据库日常维护运维(持续更新)
GreenPlum数据库日常维护运维(持续更新)

日志备份([可选]判定实例>判定路径>备份日志)

集群实例宕机后首要是先恢复集群状态,但这恢复的时候数据节点日志往往会被清理掉,所以可以先备份当天节点日志后,先恢复集群,后面再查看日志寻找宕机的具体原因,根据seg.hostname和seg.datadir,以及 con.time备份对应实例pg_log目录下对应日期的日志

常规修复(以防突然断电或远程断开等情况,一般建议后台运行)

通过gpstate 或gp_configuration 发现有实例down 掉以后,使用该命令进行恢复。

若存在主备切换,则需要在修复完成后进行实例切回

查看修复进度

全量修复方式

若存在主备切换,则需要在修复完成后进行实例切回

非实例宕机的

如果集群状态显示异常,但在2.1中查询结果并不存在实例宕机的情况,可以先查看是否是集群用户存在密码过期导致无法互信的情况

GreenPlum数据库日常维护运维(持续更新)

GreenPlum数据库日常维护运维(持续更新)

查看互信情况,发现其中一台服务器无法连接,ssh时并提示密码过期

GreenPlum数据库日常维护运维(持续更新)

这样就需要重新设置改服务器gpadmin用户的密码或者过期时间即可

GreenPlum数据库日常维护运维(持续更新)

用户管理

创建role/schema

创建用户可以使用CREATE USER 或者CREATE ROLE命令,唯一区别是CREATE USER默认情况下假定LOGIN, 而CREATE ROLE默认情况下假定NOLOGIN.
如创建test用户可以登陆资源队列为 pg_default,密码为passwd:

创建模式

如果是为角色创建一个同名模式:如

创建资源队列

修改用户资源队列

查看用户资源队列对应情况

授权与回收权限

根据需要授权用户使用相应权限

例如:
授权用户使用模式权限(用户需要先有schema的使用权限,才能使用其他权限)

授权用户查询表权限

postgresql 9.0 版本以后,如果是一个用户对另一个用户新建的表需要有查询等权限,可以使用一些语句,不用再对新建表去重新授权

回收权限则是revoke命令,后面to 改为from即可,如回收用户使用模式权限

在上例中,回收上面的权限的语句为:

权限查看

查看哪些用户对具体表有哪些权限

查看具体用户有哪些表的哪些权限

锁定role

—锁定用户

删除schema

—删除schema

删除role

—删除用户

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

访问策略管理

策略文件说明

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列,列间为空格,不区分大小写。

策略配置及生效

策略登录验证

正常连接到数据库则策略添加成功

系统表的维护

Greenplum与其他所有关系型数据库一样,拥有一套管理数据库内部对象及关联关系的元数据表,我们称之为Greenplum系统表。Greenplum的产品内核是基于postgresql数据库基础上开发完成的,因此,Greenplum系统表很多继承于postgresql数据库。

Greenplum的系统表大致可分为这几类:

(1)数据库部对象的元数据,如:pg_database、pg_namespace、pg_class、pg_attribute、pg_type、pg_exttable等。

这类系统表既涵盖了全局的对象定义,也涵盖了每个数据库内的各种对象定义。这类系统表的元数据不是分布式的存储,而是每一个数据库实例(不论是master实例还是segment实例)中都各有一份完整的元数据。但也有例外,如:gp_distribution_policy(分布键定义)表则只在master上才有元数据。

对于这类系统表,各个实例之间元数据保持一致十分重要。

(2)维护Greenplum集群状态的元数据,如:gp_segment_configuration、gp_configuration_history、pg_stat_replication等。

这类系统表主要由master实例负责维护,就如segment实例状态管理的两张表gp_segment_configuration和gp_configuration_history的数据是由master的专用进程fts负责维护的。

(3)Persistent table,如:gp_persistent_database_node、gp_persistent_filespace_node、gp_persistent_relation_node、gp_persistent_tablespace_node。

这类系统表同样是存在于每一个数据库实例中。在每个实例内,persistenttable与pg_class/pg_relation_node/pg_database等系统表有着严格的主外键关系。这类系统表也是primary实例与mirror实例之间实现同步的重要参考数据。

在Greenplum集群出现故障时,会有可能导致系统表数据有问题。系统表出现问题会导致很多种故障产生,如:某些数据库对象不可用,实例恢复不成功,实例启动不成功等。针对系统表相关的问题,我们应该结合各个实例的日志信息,系统表的检查结果一起定位问题,本文将介绍一些定位、分析及解决问题的方法和技巧。

使用gpcc视图查询系统性能

更多请参考:https://www.xmmup.com/greenplumguanfangjiankonggongjugpccjianjiejishiyong.html

以下查询都需要切换到gpperfmon数据库。

系统资源

系统负载SQL(历史SQL语句)

查询pg_log日志

视图gpmetrics.gpcc_pg_log_history只记录日志级别为FATAL、ERROR和WARNING的日志。

视图gpmetrics.gp_log_master_ext有记录LOG级别的日志,但是时间比较短。

告警日志

数据库查询数历史

磁盘空间使用历史

索引膨胀率

跟踪SQL

控制写入日志文件的有关查询工作进程创建和查询管理的信息量。 默认值为OFF,不记录信息。

参考

https://mp.weixin.qq.com/s/G5cPCt7remAuDJHGadOI2w
http://t.zoukankan.com/butterflies-p-12056514.html

https://blog.csdn.net/weixin_45428187/article/details/125600114

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/74e3477d2a3f3548.md

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部