第 15 章日常系统维护

第 15 章日常系统维护

为了保持高效运行的Greenplum数据系统中，数据库必须定期清除过期数据和表统计信息必须进行更新，以便查询优化器的准确信息。

和其他的数据库软件一样，GPDB需要一些定期的维护任务以达到最佳性能。这里讨论的任务是必要的，他们是可重复的，所以可以使用标准的UNIX工具如cron脚本来调度。不过，设置合适的脚本以及确保它们成功的执行是数据库管理员的责任。

日常 Vacuum 和 Analyze

由于GPDB使用的是MVCC事务并发模型，被删除或更新的数据行依然占据着物理磁盘空间，即便它们对于新的事务已经不可见。如果数据库有大量的更新和删除，会产生大量过期记录。VACUMM命令还会收集表级别的统计信息，如行数和页面数，因此对于AO表VACUUM也是有必要的。VACUUM对于AO表的操作很快，因为其没有空间需要被回收。

VACUUM追加优化表和堆表的过程不同。在每个段上，当前段的可见数据被复制到一个新创建的段文件里，当这个段文件被复制后，系统将其标记为待删除，新复制的文件被置为可用。这就要求每个段有足够的空间来复制可见行数据，直到原来的段文件都被删除为止。

 

如果段文件中隐藏的行和总行的比率小于阈值（10，默认情况下），段文件未压实。阈值可以与gp_appendonly_compaction_threshold服务器配置参数进行配置。 VACUUM FULL会忽略gp_appendonly_compaction_threshold的值并重写段文件。

 

你可以使用gp_toolkit模式中的 __gp_aovisimap_compaction_info() 来探查追加优化表的VACUUM操作的有效性。

关于__gp_aovisimap_compaction_info()函数的信息，参看"CheckingAppend- Optimized Tables" in the GreenplumDatabase Reference Guide.

可以通过设置gp_appendonly_compaction参数来在AO表上禁用vacuum。

关于在数据库上进行的vacuum，参看Vacuuming the Database.

有关gp_appendonly_compaction_threshold服务器配置参数和vacuum命令的信息，请参阅Greenplum数据参考指南。

事务ID管理

Greenplum的MVCC事务语意依赖于比较事务ID（XID）的数值来确定可视性其他交易。交易ID号使用模232运算，从而使运行超过20亿交易后出现事物ID循环的问题，XID计数器回到0,所有过去的事务突然变成将来的事务一这意味着不可见的记录变得可见。为了避免这个问题，在每个数据库每20亿个事务的时候，对每张表执行VACUUM是很有必要的。

重要提示：Greenplum数据监控事务ID。如果你不经常VACUUM数据库，Greenplum数据会产生警告和错误。

GreenplumDatabase issues the following warning when a significant portion of thetransaction IDs are no longer available and before transaction ID wraparoundoccurs:

WARNING:database "database_name" must be vacuumed within number_of_transactions  transactions

当发出警告，需要VACUUM操作。如果不进行VACUUM操作，如果当它到达时事务ID重叠发生的限制之前，Greenplum数据停止创建事务。数据库会识别出这个错误并停止创建事务，这样就能避免可能的数据丢失。

FATAL:database is not accepting commands to avoid wraparound data loss in database"database_name"

 

Greenplum配置的parameterxid_warn_limit会控制警告在什么时间显示，xid_stop_limit controls会控制数据库在什么时间停止创建事务。

Recoveringfrom a Transaction ID Limit Error

当因缺乏vacuum维护是的Greenplum达到xid_stop_limittransaction ID限制，数据库就会变得无响应。为了从这种局面恢复，需要以数据库管理员的身份来执行如下步骤。

1.              关闭 Greenplum Database.

2.              临时将xid_stop_limit 降低 10,000,000.

3.              启动 Greenplum Database.

4.              在所有受影响的数据库上执行vacuum freeze

5.              将xid_stop_limit 设置为初始值.

6.              重启 Greenplum Database.

Forinformation about the configuration parameters, see the GreenplumDatabase Reference Guide.

Forinformation about transaction ID wraparound see the PostgreSQL documentation.

系统目录维护

大量的CREATE和DROP命令会导致系统表的迅速膨胀，以至于影响系统性能。 例如，在大量的DROP TABLE语句之后，扫描系统元数据的操作性能会大大降 低。根据不同的系统，在数千个DROP TABLE语句之后就可能会发生性能下降 的情况。

GP建议定期的执行系统目录维护操作，以回收因删除对象而导致的空间占用。 如果很长时间没有执行，可能需要执行一个更密集的操作来清理系统目录。本节讲述这两种操作。

常规的系统目录维护

GP建议定期的在系统目录上执行VACUUM清理删除对象占用的空间。如果 DROP语句是常规的数据库操作，每天在空闲时间段运行系统目录维护操作将是很有必要且安全的。也可以在系统处于常规运行状态时做这些操作。

下面的示例脚本是执行在系统目录下执行vacuum,reindex, and analyze

 

#!/bin/bash

DBNAME="<database-name>"

SYSTABLES="'pg_catalog.' || relname || ';' from pg_class a, pg_namespace b

where a.relnamespace=b.oidand b.nspname='pg_catalog' and a.relkind='r'"

psql -tc"SELECT 'VACUUM' || $SYSTABLES" $DBNAME | psql -a $DBNAME

reindexdb--system -d $DBNAME

analyzedb -s pg_catalog -d $DBNAME

 

 

密集系统目录维护

如果很长时间都没有执行系统目录维护，系统表可能会被过期空间严重膨胀，导致即便简单的元数据操作也需要很长的等待时间。比如列出用户表的操作需要等待1到2秒，例如使用\d 的metacommand，这可以表明系统目录的膨胀。

如果发现了系统目录膨胀的迹象，一个密集的系统目录维护操作必须在预定的停机期间使用VACUUM FULL来完成执行。在这段时间必须停止系统上的所有操作，因为在系统目录维护过程中会对这些系统目录采用独占式的排它锁。

定期的运行系统目录维护可以避免较高成本的密级操作。

为优化查询进行回收和分析

GPDB根据数据库的统计信息使用基于成本的查询规划器。精确的统计信息使 得查询规划器更好的评估选择性和检索的行数从而选择最有效的查询计划。 ANALYZE命令收集查询规划器需要用到的列统计信息。VACUUM和 ANALYZE操作可以在同一个命令中一起运行。例如：

=# VACUUM ANALYZE mytable;

 

运行VACUUMANALYZE命令时，命令在一个显著膨胀的表上运行可能会产生不正确的统计（表磁盘空间显著量由删除或过时的行占据的）。对于大表，ANALYZE命令计算从行的随机抽样统计。它通过在表中实际的页数每页的平均行数乘以样品中估计表中的行数。如果样本含有许多空页，估计的行计数可以是不准确的。

对于表，你可以查看有关gp_toolkit观点gp_bloat_diag（由删除或过时的行占据的空间）的未使用的磁盘空间量的信息。如果表的bdidiag列包含膨胀怀疑的值显著量的表磁盘空间显著量由未使用的空间。条目添加到gp_bloat_diag视图中的表已经VACUUM了。

对于表，你可以查看有关gp_toolkit观点gp_bloat_diag（由删除或过时的行占据的空间）的未使用的磁盘空间量的信息。如果表的bdidiag列包含膨胀怀疑的值显著量的表磁盘空间显著量由未使用的空间。条目添加到gp_bloat_diag视图中的表已经真空了。

从表中删除未使用的磁盘空间，则可以运行命令VACUUM FULL。由于表锁的要求，VACUUM FULL操作应该在维护期执行。

作为临时解决办法，运行ANALYZE计算列统计信息，然后在表上运行VACUUM产生一个精确的行数。本示例运行分析并进行真空上cust_info表。

ANALYZE cust_info;

VACUUM cust_info;

重要提示：如果您打算启用了PivotalQuery Optimizer对分区表执行查询时，必须收集有关分区表根分区采用用analyze命令ROOTPARTITION获得的统计。有关Pivotal QueryOptimize的信息，请参阅PivotalQuery Optimize的概述。

注意：您可以使用Greenplum的数据库实用程序analyzedb更新表统计信息。表可以同时进行分析。对于附加优化表，analyzedb更新的统计数据仅统计数据不是最新的。有关analyzedb实用程序的信息，请参阅Greenplum的数据库实用程序指南。

日常重建索引

对于B-tree索引，新重建的索引通常比存在较多更新的表访问更快，因为逻辑上相邻的页面在新重建的索引中也是逻辑上相邻的。定期的重建索引对于改善访问速度是值得的。同样，如果全部索引键的一部分被删除了，索引页面也会存在过期空间。 重建索引可以收回这些过期的空间。在GPDB中，删掉索引(DROP INDEX)然后重新创建(CREATE INDEX)通常比REINDEX命令更快。

当更新索引列时，Bitmap索引不会被更新。如果更新了一张有Bitmap索引的表，为了保持最新的信息，应该删除并重新创建该索引。

管理GPDB日志文件

•                数据库服务日志文件

•                管理程序的日志文件

数据库服务日志文件

GPDB的日志输出量很大(尤其在较高的调试级别)而且不需要无限期的保存这些日志。管理员需要定期的滚动日志文件，从而可以保证新的日志文件被使用而旧的日志文件可以被定期的删除。

GPDB在Master和所有的Segment实例上开启了日志文件滚动。每天的日志文件 放在每个Instance数据目录的pg_log目录下并使用约定命名方式：

 gpdb-YYYY-MM-DD-hhmmss.csv.

尽管日志是按天滚动的，但它们不会被自动清空或删除。管理员需要通过一些脚本或程序来定期的清理各实例pg_log目录下的旧日志文件。

管理程序的日志文件

GP管理程序的日志文件缺省位于~/gpAdmmLogs目录下。管理程序日志文件的约定命名方式为：

script_name_date.log

日志记录的格式为：

<timestamp>:<utility>:<host>:<user>:[INFO|WARN|FATAL] :<message>

在程序运行时，其日志文件会追加到特定的日期文件。