第 16 章推荐的监控和维护任务

第 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

•每秒网络万兆读写

如果传输率低于预期，以及关于业绩预期数据架构师咨询。

如果群集机器上显示不均衡的性能配置，与系统管理团队合作，解决故障的机器。

Catalog Monitoring

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.

Data Maintenance

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用来消除膨胀的数据空间

Database Maintenance

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叶没有统计指标。

Patching and Upgrading

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集群。