再读greenplum的admin guide文档

master

The master is where the global system catalog resides. The global system catalog is the set of system tables that contain metadata about the Greenplum Database system itself.
master负责的内容包括：
* authenticates client connections
* processes incoming SQL commands
* distributes workloads among segments
* coordinates the results returned byeach segment
* presents the final results to the client program.

The key to obtaining the best performance from Greenplum Database is to distribute data and workloads evenly across a large number of equally capable segments so that all segments begin working on a task simultaneously and complete their work at the same time.

工具包

$GPHOME/bin

vacuum

每20亿事务执行后，需要执行一次数据库级别的vaccum动作，不然会导致XID wraparound
xid_warn_limit和xid_stop_limit是两个可设定的值，越界后，会导致如下两种情况：

WARNING: database database_name must be vacuumed within number_of_transactions transactions

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

vaccum，建议每天执行一次，可以避免表空间增长过快，尤其是在进行过大量的update和delete后操作，效果更好。它的实现是根据table's free space map来进行的。
vaccum full，会重写表数据，会做的更彻底。这个操作执行的时候，一定要保证磁盘空间充足。执行的时候会锁住表，所以此命令最好在运维修复环境的时候执行。

analyze

主要用来收集元数据信息，statistics。
statistics主要是optimizer在做查询计划的时候用，保存在system catalog里。
有三个办法可以触发收集信息：
1. 数据库内执行analyze
2. linux系统命令行，执行analyzedb
3. 配置gp，在收到DML操作的时候，自动进行收集

analyze的目的是收集元数据信息，进而使得optimizer做查询计划时候更合理，进而导致更快的查询速度。但是如果查询规划不符合预期效果，可以查实修改gp_analyze_relative_error，默认是0.25，可以调整的更低一些，这样收集的元数据信息会更准确，但是会带来更多的磁盘消耗和analyze执行所需的时间。

analyze还有另一个可以调整的参数，default_statistics_target，但是作用还没看明白。

analyze可以基于一个表内的几列来做。

system statistics

在执行vaccum和analyze的时候会进行收集信息的update

pg_class

收集了表信息：rows和pages
表pg_class
列：

• reltuples
• relpages

当reltuples和select count(*)的结果差异较大的时候，就应该执行analyze或者vaccum了
当reindex命令执行后，reltuples和relpages会被置零。

pg_statistic & pg_stats

pg_statistic保存了上一次analyze执行后各表的statistics信息。

查看无statistics信息的表

select * from gp_toolkit.gp_stats_missing;

创建了一个表，插入了一条数据，做过analyze后，missing表里还有这个表的信息，不知道为什么。

segment mirror

segment有两个角色primay和mirror，mirror就是备份的计算单元。
mirror的分布有两种，一个是group mirroring，一个是spread mirroring。第一种保证mirror不和primary分布在同一台计算节点上，其他的就没有了。第二种相当于自定义的，开源社区讨论有说用4个计算节点做一个小圈，其实就是数学上的概念，尽量均衡分布segment，可以容错更多的物理服务器宕机场景。

segment的分布有两种方案：

• group mirroring
• spread mirroring

group mirroring，是默认方案，spread mirroring，是自定义方案。
spread mirroring可以让用户自行配置mirror segment放置的位置。基于数学计算，可以用4个物理服务器组成一个小圈，能够达到这样一个效果：如果1个物理机宕机，这个物理机上的segment会被均衡地在其他三台机器上激活。而group mirroring方案，很有可能会导致segment负责不均衡。

legacy optimizer

legacy optimizer有如下控制参数，决定一些开关：

enable_bitmapscan
enable_groupagg
enable_hashagg
enable_hashjoin
enable_indexscan
enable_mergejoin
enable_nestloop
enable_seqscan
enable_sort
enable_tidscan
gp_enable_adaptive_nestloop
gp_enable_agg_distinct
gp_enable_agg_distinct_pruning
gp_enable_direct_dispatch
gp_enable_fallback_plan
gp_enable_fast_sri
gp_enable_groupext_distinct_ gather
gp_enable_groupext_distinct_ pruning
gp_enable_multiphase_agg
gp_enable_predicate_ propagation
gp_enable_preunique
gp_enable_sequential_window_ plans
gp_enable_sort_distinct
gp_enable_sort_limit

下面这些参数，是legacy optimizer的调优参数，但是参数相互之间有关联，所以官方不建议随意调整：

cpu_index_tuple_cost
cpu_operator_cost
cpu_tuple_cost
cursor_tuple_fraction
effective_cache_size
gp_motion_cost_per_row
gp_segments_for_planner
random_page_cost
seq_page_cost

调优可以从如下几个方面进行：
1. statistics收集（analyze相关参数调整）
2. sort
3. aggregate
4. join

增量备份

greenplum支持增量备份，备份原理是：第一次进行一次完整备份，后续仅仅对表内，有数据修改的分区数据，进行备份。
这种备份方式要求：第一次完整备份，以及后续所有的增量备份都存在，才能进行数据恢复。
所以，对分区规划合理，且数据修改量不大的场景下，增量备份很合适。

检查系统

查看状态

gpstate
gpstate -s
gpstate -m
gpstate -c
gpstate -f

磁盘使用

磁盘水位设定为70%比较合适&