第 16 章推荐的监控和维护任务
本节给出了监控和维护建议,用于确保Greenplum集群的高可用和一致性的性能。
下面章节给出的表格给出了Greenplum数据库系统管理员可周期性执行的,以确保系统的所有部件都运行在最佳的活动。通过监控系统,你可以尽早的检测和诊断问题。维护活动,可用使得系统保持最新的状态并避免日益恶化的性能。例如,臃肿的系统表或者磁盘空间日益减少。
在所有的集群上都执行所有的建议是没有必要的。以使用频率和严重程度为指导,根据服务需求来落实各项措施。
活动 | 步骤 | 相关活动 |
列出当前宕机的segment,如果返回任何行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp segment configuration WHERE status <> 'u'; | 如果查询返回任何行,请按照下列步骤来解决问题: 1.验证包含停机的段的主机仍能响应。 2.如果主机正常,检查停机段的primary和mirror的pg_log文件来发现段停机的根本原因。 3.如果没有发现意外错误,运行gprecoverseg工具使得停机的段重新联机。 |
检查当前处在change tracking mode的段。如果返回任何行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp_segment_configuration WHERE mode = 'c'; | 如果查询返回任何行,请按照下列步骤来解决问题: 1.验证包含停机的段的主机仍能响应。 2.如果主机正常,检查停机段的primary和mirror的pg_log文件来发现段停机的根本原因。 3.如果没有发现意外错误,运行gprecoverseg工具使得停机的段重新联机。 |
Activity | Procedure | Corrective Actions |
检查处于 re-syncing的段。如果返回的行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp segment configuration WHERE mode = 'r'; | 如果这个查询返回行,就意味着段处于re-synched状态,如果状态不是从 'r' 到 's'(state does not change from 'r' to 's'),需要检查受影响段的primary和mirror的pg_log来检查错误。 |
检查段不是以其设定好的角色在运行。如果发现任何段,说明集群处于不平衡状态。如果返回任何行,则必须发出一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | Execute the following query in the postgres database: SELECT * FROM gp_segment_configuration WHERE preferred_role <> role; | 如果段不是以其设定的角色在运行,则每个段主机上的primary的个数就参差不齐,这就意味着数据倾斜。需要等待一个维护窗口,重新启动数据库并将该段恢复其预设定的角色。 |
运行一个可以在所有的段上执行的分布式查询,每个primary段必须返回一行。 推荐频率:每运行5至10分钟 严重性:严重 | Execute the following query in the postgres database: SELECT gp_segment_id,count(*) FROM gp_dist_random('pg_class') GROUP BY 1; | 如果这个查询失败,则意味着调度集群的某些段出现问题。这是一个罕见的事件。检查不能被调度的主机,以确保没有硬件或网络问题。 |
测试Greenplum Database 4.2或更早版本的集群的 master mirror状态。如果状态值是"Not Synchronized",则引发警报或警告。 推荐频率:每运行5至10分钟 严重性:重要 | Execute the following query in the postgres database: SELECT summary_state FROM gp_master_mirroring; | 在master和 standby master的pg_log中检查错误。如果没有意外的错误,并且主机都在运行,则执行gpinitstandby使得standby master重新在线。对于GPDB 4.2和更早的版本,需要数据库重启。 |
检查Greenplum Database 4.3 及更高版本的 master mirror状态,如果不是"STREAMING",则引发警报会警告。 推荐频率:每运行5至10分钟 严重性:重要 | Run the following psql command:
psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;' | 在master和 standby master的pg_log中检查错误。如果没有意外的错误,并且主机都在运行,则执行gpinitstandby使得standby master重新在线。 |
Activity | Procedure | Corrective Actions |
执行基本检查,确认master是否开机并且功能可用。 推荐频率:每运行5至10分钟 严重性:严重 | Run the following query in the postgres database: SELECT count(*) FROM gp_segment_configuration; | 如果查询失败,则master可能已经停机。再尝试数次,并手工检查master的活动状态。如果active master已经停机,则重新开机或关机后再开机使得没有活动在active master上执行。然后激活 standby master。 |
Table 17:Database State Monitoring Activities
活动 | 步骤 | 相关活动 |
列出当前宕机的segment,如果返回任何行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp segment configuration WHERE status <> 'u'; | 如果查询返回任何行,请按照下列步骤来解决问题: 1.验证包含停机的段的主机仍能响应。 2.如果主机正常,检查停机段的primary和mirror的pg_log文件来发现段停机的根本原因。 3.如果没有发现意外错误,运行gprecoverseg工具使得停机的段重新联机。 |
检查当前处在change tracking mode的段。如果返回任何行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp_segment_configuration WHERE mode = 'c'; | 如果查询返回任何行,请按照下列步骤来解决问题: 1.验证包含停机的段的主机仍能响应。 2.如果主机正常,检查停机段的primary和mirror的pg_log文件来发现段停机的根本原因。 3.如果没有发现意外错误,运行gprecoverseg工具使得停机的段重新联机。 |
Activity | Procedure | Corrective Actions |
检查处于 re-syncing的段。如果返回的行,这应该产生一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | 在postgres 数据库执行如下SQL: SELECT * FROM gp segment configuration WHERE mode = 'r'; | 如果这个查询返回行,就意味着段处于re-synched状态,如果状态不是从 'r' 到 's'(state does not change from 'r' to 's'),需要检查受影响段的primary和mirror的pg_log来检查错误。 |
检查段不是以其设定好的角色在运行。如果发现任何段,说明集群处于不平衡状态。如果返回任何行,则必须发出一个警告或警报。 推荐频率:每运行5至10分钟 严重性:重要 | Execute the following query in the postgres database: SELECT * FROM gp_segment_configuration WHERE preferred_role <> role; | 如果段不是以其设定的角色在运行,则每个段主机上的primary的个数就参差不齐,这就意味着数据倾斜。需要等待一个维护窗口,重新启动数据库并将该段恢复其预设定的角色。 |
运行一个可以在所有的段上执行的分布式查询,每个primary段必须返回一行。 推荐频率:每运行5至10分钟 严重性:严重 | Execute the following query in the postgres database: SELECT gp_segment_id,count(*) FROM gp_dist_random('pg_class') GROUP BY 1; | 如果这个查询失败,则意味着调度集群的某些段出现问题。这是一个罕见的事件。检查不能被调度的主机,以确保没有硬件或网络问题。 |
测试Greenplum Database 4.2或更早版本的集群的 master mirror状态。如果状态值是"Not Synchronized",则引发警报或警告。 推荐频率:每运行5至10分钟 严重性:重要 | Execute the following query in the postgres database: SELECT summary_state FROM gp_master_mirroring; | 在master和 standby master的pg_log中检查错误。如果没有意外的错误,并且主机都在运行,则执行gpinitstandby使得standby master重新在线。对于GPDB 4.2和更早的版本,需要数据库重启。 |
检查Greenplum Database 4.3 及更高版本的 master mirror状态,如果不是"STREAMING",则引发警报会警告。 推荐频率:每运行5至10分钟 严重性:重要 | Run the following psql command:
psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;' | 在master和 standby master的pg_log中检查错误。如果没有意外的错误,并且主机都在运行,则执行gpinitstandby使得standby master重新在线。 |
Activity | Procedure | Corrective Actions |
执行基本检查,确认master是否开机并且功能可用。 推荐频率:每运行5至10分钟 严重性:严重 | Run the following query in the postgres database: SELECT count(*) FROM gp_segment_configuration; | 如果查询失败,则master可能已经停机。再尝试数次,并手工检查master的活动状态。如果active master已经停机,则重新开机或关机后再开机使得没有活动在active master上执行。然后激活 standby master。 |
Database Alert Log
Table 18:Database Alert Log Monitoring Activities
Activity | Procedure | Corrective Actions |
检查系统的 FATAL and ERROR日志消息 推荐频率:每15分钟运行 严重性:警告 此活动和下一个是在log_alert_history表监视消息的两种方法。仅需要设置一个或另一个。 | Run the following query in the gpperfmon database: SELECT * FROM log_alert_history WHERE logseverity in ('FATAL', 'ERROR') AND logtime > (now() - interval '15 minutes');
| 发送警报给DBA以对此警报进行分析。你可以添加额外的过滤器添加到查询中以忽略不重要的信息。 |
设置服务器配置参数发送SNMP或电子邮件警报。 推荐频率:N/A。系统生成警报。 严重性:警告 此活动和以前是在log_alert_history表监视消息的两种方法。仅需要设置一个或另一个。 | Enable server configuration parameters to send alerts via SNMP or email: • gp_email_smtp_server • gp_email_smtp_userid • gp_email_smtp_password or gp_snmp_monitor_address • gp_snmp_community • gp_snmp_use_inform_or_trap | DBA takes action based on the nature of the alert. |
Hardware and Operating System Monitoring
Table 19:Hardware and Operating System Monitoring Activities
Activity | Procedure | Corrective Actions |
底层平台检查需要维护或者硬件系统瘫痪 推荐的频率:实时,如果可能的话,或每15分钟 严重性:严重 | 设置SNMP或硬件和操作系统错误等系统检查。 | 如果需要,从Greenplum的集群中删除一台机器解决硬件和操作系统的问题,那么,之后将其重新添加到集群并运行gprecoverseg。 |
检查用于Greenplum的数据库的数据存储和操作系统卷上的磁盘空间使用情况。 推荐的频率:每5至30分钟 严重性:严重 | 设置一个磁盘空间检查。 •设置阈值,当达到磁盘容量的百分比来发出警报。推荐的阈值为75%。 •不推荐运行具有接近100%容量的系统。 | 通过移除数据或文件来释放空间。 |
检查上的网络接口错误或丢弃的数据包。 推荐频率:每小时 严重性:重要 | Set up a network interface checks. 设置一个网络接口检查 | 通过和网络及操作系统团队的合作解决问题。 |
检查RAID错误或降级的RAID性能。 推荐频率:每5分钟 严重性:严重 | Set up a RAID check. | •尽快更换出现故障的磁盘。 •与系统管理团队合作,尽快解决其他RAID或控制器错误。 |
配合Pivotal的建议标准,运行Greenplum的gpcheck实用程序来测试该群集的配置。 推荐频率:创建群集或添加新机群集时 严重性:重要 | Run gpcheck. | 与系统管理团队合作,根据由GP检查实用程序的建议更新配置。 |
Activity | Procedure | Corrective Actions |
检查是否有足够的I/O带宽和I/O歪斜。 推荐频率:当创建群集或当硬件问题被怀疑。 | Run the Greenplum gpcheckperf utility. | 群集可以是根据规定的,如果数据传输速率是不类似于以下: •每秒的磁盘读取2GB •每秒磁盘写入1GB •每秒网络万兆读写 如果传输率低于预期,以及关于业绩预期数据架构师咨询。 如果群集机器上显示不均衡的性能配置,与系统管理团队合作,解决故障的机器。 |
Table 20:Catalog Monitoring Activities
Activity | Procedure | Corrective Actions |
运行目录的一致性检查,确保集群中的每个主机上的目录是一致的,并且处在良好的状态。 推荐频率:每周 严重性:重要 | Run the Greenplum gpcheckcat utility in each database: gpcheckcat -O | Run repair scripts for any issues detected. |
运行持久表目录检查。 推荐频率:每月 严重性:严重 | 在一次停机时间,系统没任何用户,请在每个数据库Greenplum运行gpcheckcat实用程序: gpcheckcat -R persistent | 如果有任何发现问题,请联系Pivotal support的支持。 |
检查pg_class条目里有没有相应的条目pg_attribute里条目 推荐频率:每月 严重性:重要 | 一次停机时间,系统没任何用户,请在每个数据库Greenplum运行gpcheckcat实用程序: gpcheckcat -R pgclass | Run the repair scripts for any issues identified. |
Activity | Procedure | Corrective Actions |
检查泄露的临时架构和失踪模式定义。 推荐频率:每月 严重性:重要 检查泄露的临时架构和失踪模式定义。 推荐频率:每月 | 一次停机时间,系统没任何用户,请在每个数据库Greenplum运行gpcheckcat实用程序: gpcheckcat -R namespace | Run the repair scripts for any issues identified. |
检查随机分布表的约束。 推荐频率:每月 严重性:重要 | 一次停机时间,系统没任何用户,请在每个数据库Greenplum运行gpcheckcat实用程序: gpcheckcat -R distribution policy | Run the repair scripts for any issues identified. |
检查上不存在的对象依赖关系。 推荐频率:每月 严重性:重要 | 一次停机时间,系统没任何用户,请在每个数据库Greenplum运行gpcheckcat实用程序:gpcheckcat -R dependency | Run the repair scripts for any issues identified. |
Table 21: DataMaintenance Activities
Activity | Procedure | Corrective Actions |
检查表上缺少的统计。 | Check the gp_stats_missing view in each database: SELECT * FROM gp_toolkit.gp_stats_missing; | Run analyze on tables that are missing statistics. |
检查因文件膨胀而不能使用普通的VACUUM命令回收空间的表 推荐频率:每周或每月 严重性:警告 | Checkthe gp bloatdiag view in each database: SELECT * FROM gp_toolkit.gp_bloat_diag; | 在没有用户访问时执行VACUUM FULL用来消除膨胀的数据空间 |
Table 22:Database Maintenance Activities
Activity | Procedure | Corrective Actions |
在堆表中标记出已删除的行,让他们占据的空间可以重复使用。 推荐频率:每天 严重性:严重 | Vacuum user tables: VACUUM <table>; | Vacuum updated tables regularly to prevent bloating. |
更新表统计信息。 推荐频率:在加载数据和执行查询之前 严重性:严重 | Analyze user tables. You can use the analyzedb management utility: analyzedb -d <database> - a | Analyze updated tables regularly so that the optimizer can produce efficient query execution plans. |
备份数据库中的数据。 推荐频率:每天,或满足您的备份计划 严重性:严重 | Run the gpcrondump utility to create a backup of the master and segment databases in parallel. | Best practice is to have a current backup ready in case the database must be restored. |
对系统目录执行Vacuum, reindex,analyze以维护一个高效的系统目录 推荐频率:每周或更频繁,如果数据库对象的创建和删除 | 1.在每个数据库VACUUM系统表。 2.在每个数据运行 REINDEX SYSTEM,或者使用带-s选项的reindexdb命令行实用程序: reindexdb -s <database> 3.分析每个系统表: analyzedb -s pg_catalog -d <database> | 优化器从系统表中检索信息来创建查询计划。如果系统表和索引被允许随着时间的推移臃肿,扫描系统表增加了查询执行时间。在重建索引后执行ANALYZE非常重要的,因为REINDEX叶没有统计指标。 |
Table 23:Patch and Upgrade Activities
Activity | Procedure | Corrective Actions |
确保任何错误修复和增强功能应用到内核。 推荐频率:至少每6个月 严重性:重要 | Follow the vendor's instructions to update the Linux kernel. | 保持内核的最新状态,bug修复和安全修补程序,并避免未来难以升级。 |
安装Greenplum数据引擎小版本,比如4.3.x.y. 推荐频率:季报 严重性:重要 | 按照Greenplum Database Release Notes的说明。随时升级到该系列中的最新产品。 | 保持Greenplum的数据库软件目前纳入bug修复,性能改进和增强功能到您的Greenplum集群。 |