4关于管理和监控工具

4 关于管理和监控工具

Greenplum提供的标准命令行实用程序，用于执行常规监测与管理任务。

Greenplum的命令行实用程序位于$GPHOME/bin目录，这些命令只能在master上执行。

Greenplum提供了实用程序用以执行如下的任务:

•                在阵列上安装Greenplum数据库引擎

•                初始化Greenplum数据库引擎

•                启动和停止Greenplum数据库引擎

•                添加和删除主机

•                扩展阵列和在新的段中重新分布表

•                失败段实例恢复管理

•                管理故障切换和恢复出现故障的主实例

•                备份和恢复数据库(并行)

•                并行装载数据库

•                在Greenplum数据库之间传输数据

•                系统状态报告

Greenplum数据库还提供了一个可选的系统监控和管理工具，管理员可以安装并在Greenplum中启用。

Greenplum Command Center 通过运行在每个段上的数据收集代理来收集并存储Greenplum的系统指标到专用的数据库。段数据收集代理定期（通常每15秒）其数据发送到Greenplum master。用户可以查询该数库，查看查询指标和系统指标。GreenplumCommand Center提供一个Web图形用户界面，用户可以通过其查询系统的相关参数。欲了解更多信息，请参阅Greenplum Command Center文档。

4.1            快照

MVCC模型取决于系统的管理数据行的多个版本的能力。一个查询运行在查询开始时创建的数据库快照上。快照是一组是在语句或事务开始时可见的行。快照确保查询具有数据库对其执行期间的一致和有效的视图。

每个事务被分配一个唯一的事务ID（XID），它是一个递增的32位值。当一个新的事务启动时，它被分配下一个XID。不在一个事务中的SQL语句被视为一个单语句事务，BEGIN 和 COMMIT是隐含添加在这个SQL中。这类似于在某些数据库系统自动提交。

当一个事务插入一行，XID是保存在系统XMIN列的行。当一个事务删除行时，XID保存在XMAX系统列。更新行被处理为删除和插入，所以XID保存到当前行的XMAX，新插入的行保存到XMIN。Xmin和XMAX列，与交易完成状态一起，保证了在指定的范围内，可对其中的行的版本是可见的。事务可以看到所有少于XMIN的事务，这些都是确定提交成功的，但它不能看到大于或等于XMAX任何交易的影响。

多语句事务也必须记录在一个事务中哪些命令插入行（CMIN），或删除的行（Cmax）为使交易可以看到以前的命令在交易中所做的更改。命令序列是相对于事务的，当事务开始时，这个序列被重新初始化为0。XID是数据库的属性。每个段数据库都有其自己的XID序列，这个序列没法通其他段数据库的XID进行对比。Master通过使用称为gp_session_id的集群范围的会话ID来协调所有段的事务。段服务器维护一个分布式事务ID和本地XID的映射关系。

Master使用两阶段提交协议来协调所有段上的分布式事务。如果任何一个段的事务失败，就回滚所有段的事务。你可以用Select语句来查看任何行的xmin, xmax, cmin, cmax

你可以看到XMIN，XMAX，CMIN，和Cmax列与SELECT语句的任何一行：

SELECT xmin,xmax, cmin, cmax, * FROM tablename;

因为你是在master上运行Select命令，所以XID是分布式事务的ID。如果你在一个单独的段数据库上执行命令，xmin 和 xmax就是本地XID。

4.2 Transaction ID Wraparound

该MVCC模型使用事务ID（XIDs），以确定哪些行是在查询或事务的开始时是可见的。该XID是一个32位的值，因此该值溢出之前数据库理论上可以执行40多亿事务后回零。然而，Greenplum使用XID和2³²求模，它允许事务ID环绕，就像一个时钟围绕十二点一样。对于任何给定XID，可能有大约20亿过去的XID和20亿未来的XID。这个机制在通常情况下都没问题，直到一行记录的一个版本一直持续到大约20亿个事务的时候突然似乎是一个新行。为了防止这种情况，Greenplum具有一个特殊的XID，称为为FrozenXID，它始终被认为是比任何常规的XID都旧。一个行的xmin都必须在20亿内的事务时被替换为FrozenXID，这就是VACUUM命令的功能之一。在数据库每执行20亿次事务就必须对数据库进行VACUUM来防止XID重叠。Greenplum会监控事务ID，以便是否需要发出需要VACUUM的警告。

当交易ID不够充足并且在事务重叠之前，数据库就会发出警告：

WARNING: database "database_name" must bevacuumed within number_of_transactions transactions

当发出警告，需要Vacuum操作。如果不进行Vacuum操作，Greenplum数据引擎停止创建事务，以避免可能的数据丢失时，之前发生的时候事务ID重叠和问题这一错误达到限制：

FATAL：database is not accepting commands to avoidwraparound data loss in database "database_name"

请参阅从交易ID限错误的程序从这个错误中恢复恢复。

服务器配置参数xid_warn_limit和xid_stop_limit控制警告显示的时机，xid_warn_limit参数用来指定在xid_stop_limit警告发出之前的事务ID个数，xid_stop_limit参数指定重叠发生并且新事务无法创建时的数量。

4.3 Transaction Isolation Modes

SQL标准描述了数据库事务并发运行时可能出现三种现象：

•                Dirtyread -事务可以从其他并发事务读取未提交的数据。

•      Non-repeatableread -在一个事务读两次行可以改变，因为交易后另一个并发事务提交的修改就开始了。

•      Phantomread -在同一交易执行两次查询可返回行两套不同，因为另一个并发事务添加的行。

SQL标准定义了四种事务隔离模式，数据库系统必须支持：

Table 4: Transaction Isolation Modes

Level

Dirty Read

Non-Repeatable

Phantom Read

Read Uncommitted

Possible

Possible

Possible

Read Committed

Impossible

Possible

Possible

Repeatable Read

Impossible

Impossible

Possible

Serializable

Impossible

Impossible

Impossible

 

该数据库的Greenplum SQL命令，可以请求read uncommitted, readcomitted, or serializable. Greenplum Database 将 readuncommitted 视为read committed. 请求 repeatable read会导致错误，请用serializable 代替. 默认的隔离方式是READ COMMITTED.

READ COMMITTED和SERIALIZABLE之间的区别是，在READ COMMITTED模式，在一个事务中的每个语句只能看到声明开始前已提交的行，而在SERIALIZABLE模式，在一个事务中的所有语句只能看到提交的事务开始前行的行。

 

read committed 的隔离模式允许更大的并发性，比SERIALIZABLE模式更好的性能。它允许non-repeatable reads，其中在一个事务中检索两次行的值会有所不同，因为另一个并发事务一直致力于改变在事务开始。 READ COMMITTED模式还允许phantomreads，凡在同一交易执行两次查询可返回两个不同的行集。

serializable隔离模式可防止non-repeatablereads 和 phantom reads，但并发性和性能为代价。每个并发事务具有执行开始采取了数据库的一致视图。试图修改被另一个事务修改数据的并发事务回滚。在SERIALIZABLE模式下执行事务的应用程序必须准备处理这种失败归因于序列化的错误交易。如果没有应用程序所需的SERIALIZABLE隔离模式，它是更好地使用READ COMMITTED模式。

SQL标准并发串行事务产生，如果依次执行他们会产生相同的数据库状态。该MVCC快照隔离模式防止脏读，不可重复的读取和幻像无需昂贵的锁定读取，但也有可能在Greenplum数据引擎的一些SERIALIZABLE交易是防止被真正的序列化之间发生的其他交互。这些异常通常可以归因于一个事实，即Greenplum数据不执行谓词锁定，这意味着，在一个事务中的写入可能会影响在另一并发事务先前读的结果。

同时运行的交易数据进行检查，以确定未通过禁止同一数据并发更新防止相互作用。发现的问题可以通过使用显式表锁或通过要求冲突的事务更新推出代表冲突虚设行被阻止。

在SQL SET TRANSACTION ISOLATION LEVEL语句设置为当前事务隔离模式。该模式必须在任何SELECT，INSERT，DELETE，UPDATE或COPY语句进行设置：

BEGIN;

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

...

COMMIT;

 

The isolation mode can also be specified as part ofthe BEGIN statement:

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

 

默认的隔离模式可以对单个会话通过设置default_transaction_isolation的属性来改变。

4.4Removing Dead Rows from Tables

更新或删除的行都会在表中留下过去的版本。当过期行不在被任何活动的事务所引用时，它就可以被移除，它所占用的空间就可以被重复利用。VACUUM命令从表中删除过期行。

过期行在表中的不断积累，导致磁盘文件必须扩展以便适应新的行。在执行查询时磁盘I/O的增加使得性能受到影响。这种情况被称为膨胀，需要对表定期进行VACUUM。

VACUUM命令（不带FULL）可以与其他查询同时运行。它会从页面移除过期行，并重新组合剩余行使得自由空间变得密集。如果剩余的空闲空间的量足够大，就会将它增加了页表中的自由空间映射。当Greenplum以后需要空间时，它首先会查询表的自由空间映射，找到可用空间的页面。如果没有找到，新的页面将被添加到该文件。

VACUUM（无FULL）不能整合页面文件或减少磁盘上的表的大小。它恢复的空间仅可通过自由空间映射图获得。为了防止磁盘文件从生长，需要定期的运行VACUUM，每天至少一次，以确保该可用空间能通过自由空间映射中找到。同样在运行在更新或删除大量行的事务后也需要运行VACUUM。

VACUUM FULL命令会重写表，并且过滤掉过期行，以此使得表的到一个最小的容量。执行此操作必须有足够的磁盘空间来创建新表，该表被锁定，直到VACUUM FULL完成。相比于常规VACUUM命令，这是非常昂贵的，并且可以通过定期VACUUM来避免或推迟。最好是在维护期间运行VACUUM FULL。VACUUM FULL另一种是用CREATE TABLE AS语句重新创建一个表，然后删除旧表。

自由空间映射驻留在共享内存并跟踪的所有表和索引的自由空间。每个表或索引使用大约60字节的内存，自由空间的每个页面消耗6个字节。两个系统的配置参数配置的自由空间映射的大小：

max_fsm_pages

设置可被添加到共享自由空间映射磁盘页的最大数目。

每个页面槽都会消耗共享内存的6个字节，默认为200000，该参数必须设置为max_fsm_relations的至少16倍的值。

max_fsm_relations

 

设置将在共享内存中自由空间映射被跟踪关系的最大数量。该参数应该被设置为比tables + indexes + system tables的总数较大的值。默认值是1000。每个段实例的每个关系需要消耗60字节的内存。这个参数设置越大越好。

如果自由空间映射的设置非常低，则某些包含可用空间的磁盘页面不会添加到映射中，在下一次VACUUM运行前这些自由空间都无法被利用。这会导致文件的增长。

你可以执行一个VACUUM VERBOSE tablename命令来获取报告，对每个段，有多少无效行被移除，影响了多少页，含有可用空间的页面数有多少。

查询pg_class系统表，可以找出一个表在所有的段上面使用了多少页面。一定要先对表执行ANALYZE以便获得准确的手。

SELECT relname, relpages, reltuples FROM pg_classWHERE relname='tablename';

另一个有用的工具是在gp_toolkit架构的gp_bloat_diag视图，它通过比较表所用实际页数和预期页数来标识表膨胀。详情参见Greenplum数据参考指南中的“gp_toolkit管理模式”来了解gp_bloat_diag