13扩展一个Greenplum System

1        扩展一个Greenplum System

为了扩展性能和存储容量，通过将主机添加到阵列扩展Greenplum的系统。

数据仓库的数据因为额外的数据收集和保留期现有数据的增加而导致其容量随时间增长而增长。有时，有必要替身单一的数据仓库容量以便将不同的数据仓库合并到一个单一的数据仓库。可能也需要额外的计算能力（CPU），以适应新添加的分析项目。虽然在一个系统刚初始化时就提供了足够的能力以应对需求的增长，但这样为资源在使用前就预留很长时间在实际上不太可行。因此，你应该会定期执行数据库扩建项目。

因为Greenplum的MPP的体系结构，当将资源添加到系统中，容量和性能都一样，系统就和一开始就将后面添加的资源都纳入到系统一样。和传统的数据仓库需要大量的停机时间，以转储和恢复数据不同，拓展一个Greenplum的数据库系统是用最少的停机时间分阶段的过程。常规的和特别的工作负荷能够继续在数据重新分配和事务一致性得以保持。管理员可以安排分发活动，以适应日常运营，并可以暂停，并根据需要恢复。表可以被安排优先级，使数据集的优先顺序重新分配，既可以确保关键工作负载从容量的扩展越早受益，或重新分配非常大的表需要的可用磁盘空间。

扩张过程中使用标准的Greenplum数据库操作所以它是透明的，便于管理员进行故障排除。段镜像和到位的复制机制仍然有效，所以容错是不打折扣的和灾难恢复措施仍然有效。

1.1       系统扩展概述

数据仓库的数据因为额外的数据收集和保留期现有数据的增加而导致其容量随时间增长而增长。有时，有必要替身单一的数据仓库容量以便将不同的数据仓库合并到一个单一的数据仓库。可能也需要额外的计算能力（CPU），以适应新添加的分析项目。虽然在一个系统刚初始化时就提供了足够的能力以应对需求的增长，但这样为资源在使用前就预留很长时间在实际上不太可行。因此，你应该会定期执行数据库扩建项目。

当你扩大你的数据库，你应该期望以下素质：

•      可扩展的容量和性能。当添加资源后，其容量和性能应该和起初就具备添加资源后的集群的容量和性能一样。

•      扩展期间不间断的服务。常规工作，定期的和特定的，都不能被中断。一个很短的，计划的停机时间还是必需的，以便初始化新的服务器，类似于重启系统所需要的停机时间。停机时间的时长和系统容量无关。

•                事务一致性

•      容错。期间膨胀，标准容错机制，如段镜像-保持活跃的，一致的和有效的。

•      复制和灾难恢复。任何现有的复制机制，继续在扩展过程中发挥作用。恢复机制在遇到故障或灾难的情况下仍然有效。

•      过程的透明度。扩张过程中采用标准的Greenplum数据引擎的机制，因此管理员可以诊断并排除故障。

•      可配置的过程。扩展可以是一个长时间运行的进程，但它可以配合到正在进行的行动计划。扩展控制表允许管理员就在其中表被重新分配和扩展活动可以暂停和恢复的优先顺序。

 

Consulting Greenplum Database platform engineers inthe planning stages will help to ensure a successful expansion project.Planning New Hardware Platforms describes general considerations for deploying newhardware.

扩建项目的规划和和物理范畴是比扩展数据库容量更大的一个工作。这将需要多学科的团队来计划和执行该项目。新的空间必须获取并准备给新的服务器。这些服务器必须明确，获取，安装，加电，配置和测试过。在规划阶段咨询Greenplum数据库平台的工程师将有助于确保一个成功的扩建项目。规划新的硬件平台描述部署新的硬件一般考虑。

您准备后的新的硬件平台，并建立了自己的网络，使用Greenplum的utilities.The Greenplum数据引擎软件分发包含有帮助测试和开始的软件阶段之前老化的新服务器配置实用程序的操作系统和运行性能测试的扩展。请参阅准备和措施准备Greenplum数据引擎的新主机添加节点。

一旦新的服务器安装和测试，在Greenplum数据引擎扩张过程中的软件阶段开始。软件相被设计成最低限度地破坏性的，事务一致的，可靠的和灵活的。

•      有短暂的停机时间，此时新实例被初始化，系统准备开始扩展。这个停机时间可以在业务低峰执行以避免中断正在进行的事务。在这个初始化进程中，执行如下的任务：

 

•                      安装Greenplum Database软件.

•                      数据库和数据库对象在新的主机的段实例上创建。

•                      一个扩展的schema在master的数据库创建出来用于控制扩展进程。

•                      每个表的散列策略被更改为随机分布。

•                      系统重新启动，并开始应用的恢复。

•                      新的段可以立即参与新的查询和数据负载。但当前的数据是倾斜的，它集中在原始的段中，需要在新的所有的主段中进行重新分配。

•                      由于表现在有一个随机的分配政策，优化程序查询计划不依赖于分布键。因为需要更多的数据运动使得一些查询效率会降低。

 

•                      使用扩展控制表作为指南，表格和分区重新分配。为每个表：

 

•                      altertable命令会执行，将分布策略改为原来的策略。这就导致自动的数据重分布操作，在所有的节点上进行。

 

•             该表的状态在扩展控制表中近更新。

•             查询优化程序通过包括在计划的distribution key以生成更高效的执行计划。

•             当所有的表都被重新分配，扩展完成

重新分配数据是一个长期运行的进程，创建一个大容量的网络和磁盘活动。它可能需要数天来重新分配一些非常大的数据库。为了尽量减少对业务运营活动增加的影响，系统管理员可以暂停和一个特设的基础上继续扩张活动，或者根据预定时间表。数据集可以进行优先排序，使关键的应用程序从扩展第一时间受益。

在一个典型的操作，您在完整的膨胀过程中运行gpexpand实用程序不同的选项四次

1.             创建一个扩展输入文件：

gpexpand -f hosts_file

2.             要初始化段和创建扩展架构：

gpexpand-i input_file -D database_name

gpexpand创建一个数据目录，从现有的数据库拷贝所有的数据表到新的段实例，并捕获元数据在状态跟踪扩展模式中的每个表。这个过程完成后，扩展操作被提交，不可撤销。

3.             要重新分配表：

gpexpand -d duration

在初始化时，gpexpand抵消对表散列分布政策，所有现有数据库，除了分区表的父表，并为所有表随机分布的分配政策。

要完成系统扩展，您必须运行gpexpand跨越新添加的部分重新分配数据表。根据您的系统的数量和规模，重新分配可以在一个业务低峰中一次完成，也可以在较长时间内分批次完成。每个表或分区是再分配期间读或写操作不可用。由于每个表跨越新的段实例重新分配，数据库性能应逐步提高，直到超过扩展前的水平。

您可能需要运行gpexpand几次来完成需要多个会话再分配大型系统的扩展。 gpexpand可从明确的表再分配排名中获益。请参阅规划表再分配。

初始化完成后，系统重新上线后，用户可以访问Greenplum数据，但他们可能对严重依赖表散列分布系统出现性能下降。如ETL作业，用户查询和报告正常操作可以继续，尽管用户可能会遇到较慢的响应时间。

当一个表有一个随机的分配政策，Greenplum的数据库不能强制唯一约束（如主键）。直到表再分配完成，因为重复的行不发出违反约束的错误这可能会影响您的ETL和加载过程。

4.             要卸下扩展架构：

gpexpand -c

有关gpexpand实用工具以及用于系统扩展的其他实用程序的信息，请参阅Greenplum的数据库实用程序指南。 see the Greenplum Database Utility Guide.

 

1.2            规划Greenplum 系统扩展

仔细的规划将有助于确保一个成功的Greenplum的扩建项目。

在本节中的主题帮助，以确保您准备执行系统扩展。

•系统扩展清单就是你可以用它来准备和执行系统扩展过程的清单。

•规划新的硬件平台包括规划获取和设置新硬件。

•规划新建客户群提供的初始化有关规划信息，以初始化新段上的主机与gpexpand。

•计划表再分配提供了有关规划中的数据重新分配新的段上的主机已被初始化后的信息。

 

1.2.1    系统扩展清单

这个清单概述性的介绍系统扩展的必须步骤。

Table 11: Greenplum Database System ExpansionChecklist

扩展前的在线状态准备

*系统处于正常运行状态

□

Devise and execute a plan for ordering, building, and networking new hardware platforms.

规划并执行新硬件的采购、配置与网络调整

□

Devise a database expansion plan. Map the number of segments per host, schedule the offline period fortesting performance and creating the expansion schema, and schedule the intervals for table redistribution.

设计一个数据库的扩张计划。映射每个主机的段数，安排用于测试性能和创建扩充模式脱机期间，并安排为表再分配的区间。

□

Perform a complete schema dump.

执行一个完整的模式备份

□

Install Greenplum Database binaries on new hosts.

在新的主机上安装GPDB的二进制安装文件

□

Copy SSH keys to the new hosts (gpssh-exkeys).

复制交换 SSH 密钥(gpssh-exkeys)到新的主机

□

Validate the operating system environment of the new hardware (gpcheck).

检查新硬件的OS环境(gpcheck)

□

Validate disk I/O and memory bandwidth of the new hardware (gpcheckperf).

检查新硬件的磁盘I/O和内存带宽(gpcheckperf)

□

Validate that the master data directory has no extremely large files in the pg_log or gpperfmon/data directories.

检查在Master数据目录pg_log和gpperfmon/data下没有超大尺寸文件

□

Validate that there are no catalog issues (gpcheckcat).

验证有没有目录的问题（gpcheckcat）。

□

Prepare an expansion input file (gpexpand).

准备扩展配置文件(gpexpand)

停机扩展任务

*系统在这一过程中会被活动用户锁住

Offline Expansion Tasks

* The system is locked and unavailable to all user activity during this process.

□

Validate the operating system environment of the combined existing and new hardware

(gpcheck).

检查已有系统和新硬件的环境(gpcheck)

□

Validate disk I/O and memory bandwidth of the combined existing and new hardware

(gpcheckperf).

检查已有系统和新硬件的磁盘I/O和内存带宽(gpcheckperf)

□

Initialize new segments into the array and create an expansion schema (gpexpand-i input_ file).

初始化新 Instance 并创建扩展 Schema(gpexpand -i input_file)

在线重分布表

*系统处于正常运行状态

Online Expansion and Table Redistribution

* System is up and available

□

Before you start table redistribution, stop any automated snapshot processes or other processes that consume disk space.

在开始重分布前，停止所有快照操作和消耗磁盘的操作。

□

Redistribute tables through the expanded system (gpexpand).

在系统上重分布表(gpexpand)。

□

Remove expansion schema (gpexpand -c).

清除扩展 Schema(gpexpand -c)

□

Run analyze to update distribution statistics.

During the expansion, use gpexpand -a, and post-expansion, use analyze.

运行ANALYZE更新分布统计信息

运行gpexpand -a或者后续使用ANALYZE命令来分析

 

1.2.2    规划新硬件

一个精心的，彻底的方法来部署兼容硬件大大减少扩展过程的风险。

需要做扩展的GPDB集群，新节点应该与现有资源相匹配。GP建议在为GP集群 购买新的扩展硬件之前，最好获得GP平台工程师的支持。

步骤规划，并成立了新的硬件平台为每个部署的不同而不同。一些注意事项包括：

•准备新的硬件的物理空间;考虑散热，供电，以及其他物理因素。

•确定已有硬件连接新硬件的物理网络和布线。

•为扩展的系统规划IP地址和网络结构。

•获取已有硬件的系统配置(用户、配置文件、网络等)以帮助配置新硬件。

•制定一个构建计划以便于在特定的环境中按照理想配置部署硬件。。

在将新硬件加入网络环境后，确保执行“检查系统设置”中描述的接入任务。

 

1.2.3     规划新实例的初始化

GPDB扩展需要在有限的系统停机时间段内完成。在此期间，必须执行gpexpand 完成新Instance的初始化和生成扩展Schema。

所需的时间取决于GP系统中Schema对象的数量，还有就是硬件性能的因素。 多数情况下，新Instance的初始化可以在小于30分钟的停机时间内完成。

注意：在完成初始化新的Instance之后，将无法再使用扩展前的gp_dump文件来 恢复系统。在初始化成功之后，扩展配置即被提交，且无法回滚。

.

1.2.3.1   Planning Mirror Segments

如果已有集群有Mirror，新的Instance也必须有Mirror配置。相反的，如果已有系统没有Mirror，使用gpexpand命令时新的Instance无法添加Mirror。

对于有Mirror的GPDB集群来说，必须确保新增主机的数量足够适应添加新的 Mirror。需要新主机的数量取决于已有Mirror的策略。

•      Spread Mirroring —新主机的数量至少比每个主机Instance的数量大1。主机的数量必须大于每个主机Instance的数量，以确保Mirror分布的平坦性。

•      Grouped Mirroring —-新主机数不小于2。在最少2台主机的情况下，确保第一个主机上Instance的Mirror可以在第二个主机上，反之亦然。更多信息参考“Segment镜像”相关章节。seeAbout Segment Mirroring.

1.2.3.2   增加每个主机Instance数量

缺省时，新初始化的主机与已有主机配置相同数量的Instance。作为可选，在扩展时，可以调整增加每个主机的Instance数量，还可以在不增加主机数量的情况 下只增加现有主机的Instance数量。

例如，现有系统每个主机有2个Instance，可以使用gpexpand初始化，在现有主机上增加2个Instance(总数变为4)，同时新主机的Instance数量也为4。

在生成扩展配置文件时，交互式处理命令会提示该选项，扩展配置文件的格式允许手动修改。参考“生成扩展配置文件”相关章节。seeCreating an /nput File for System Expansion.

1.2.3.3   关于扩展Schema

在初始化新Instance时，gpexpand会生成一个扩展Schema。如果在初始化时 (gpexpand -D)不指定数据库，扩展Schema会创建到环境变量PGDATABASE定义的数据库中。系统中每张表的源数据被存到扩展Schema中，以帮助跟踪扩展过程中的状态。 该Schema中包含两张Table和一个View用以跟踪扩展操作的状态：

•               gpexpand.status

•               gpexpand.status_detail

•               gpexpand.expansion_progress

可以通过修改gpexpand.status_detail表来控制扩展细节。例如，从该表中删除记 录以阻止相应Table扩展到新Instance上。通过修改记录的rank字段的值，可以控

制Table在重分布过程中的先后顺序。更多信息参考”排名重分布表”相关章节。see Ranking Tables for Redistribution.

1.3       规划重分布表

重分布表是系统运行时进行的。对于多数GP系统来说，重分布表的操作可以在一个短期的gpexpand会话中完成。对于大型系统来说，可能需要安排多个gpexpand会话来完成，还需要安排重分布表之间的顺序，目的是尽可能的减小性能的影响。如果数据库的尺寸和设计允许的话，GP建议尽可能使用一个会话来完成重分布。

注意：为了完成重分布表，Segment主机必须有足够的空间来存放大表的临时 数据。每个正在被重分布的表，操作期间对于读和写都是不可用的。 重分布对性能的影响取决于表的尺寸、存储类型和分区结构。一张表重分布的时间与CREATE TABLE AS SELECT操作相当。在重分布一张TB级别的事实表时可能会占用大部分的可用系统资源，这对于其他的查询和工作负载会有很大的影响。

1.3.1    管理大规模GP系统的重分布

可以如在“排名重分布表”章节中描述的那样调整重分布的等级来管理重分布的顺序。对重分布顺序的管理可以应对磁盘空间的限制，以及快速恢复查询的性能。

在规划重分布时，应该考虑每个表在被重分布时独占锁的影响。用户活动对表 的影响可能会延迟重分布计划的开始时间。同样的，当gpexpand正在重分布某张表时，其他操作也无法访问这张表。

 

1.3.1.1    系统有丰富的磁盘空间

在磁盘空间(存储大表临时数据需要)丰富的系统中，可以首先重分布最常用的表以尽快的恢复查询性能。因此，将这些表的排名调高，并在系统资源利用较 低的时候安排重分布操作。只运行一次重分布程序，直到大表或关键表已经成功的完成了重分布。

1.3.1.2    系统空余磁盘空间有限

如果已有的节点上的磁盘空间有限，应该尽量先重分布较小的表，这样可以为后续被重分布的大表清理出足够的磁盘空间。已有节点的空余空间会随着每完成一张表的重分布而增加。一旦所有节点的磁盘空间都足够存储一张最大的表， 此时可以开始大表和关键表的重分布了。重申一次，因为排它锁的要求，应该在系统空闲时间安排大表的重分布。

还应该考虑以下因素：

•      在空闲时间运行并发的重分布操作，最大化利用系统资源来完成重分布。

•      在使用并发重分布操作时，需确认GP系统的最大连接数限制。更多信息参考“限制并发连接”相关章节。seeLimiting Concurrent Connections.

1.3.2    分布AO表和压缩表

AO表与压缩AO表在使用gpexpand重分布时的效率与堆表是不同的。对于压缩表来说，需要CPU资源来压缩和解压数据，这会增加对系统性能的影响。对于类似数据类似尺寸的表来说，总体的性能差异大致如下：

•               非压缩AO表比堆表的重分布快10%。

•      ZLIB压缩AO表比非压缩AO表的重分布慢的很明显，可能会慢80%。

•      使用如ZFS/LZJB之类数据压缩的文件系统，通常重分布也会慢的很明显。

非常重要：如果数据在已有节点上使用了压缩，那么在新的节点上应该使用同样的压缩以避免磁盘空间不足的情况出现。

1.3.3    重分布有主键约束的表

在初始化新Instance完成之后和重分布表完成之前，这段时间内的主键约束是不生效的。在此期间插入到表中的重复数据会妨碍重分布表。一旦表被成功重分布，主键约束会再次生效。

如果在扩展中数据违反了约束，在所有表重分布完之后，会在屏幕打印出警告信息。可以使用如下的方法补救约束例外情况：

•               清除违反主键约束的重复数据，重新运行gpexpand命令。

•               删除主键约束，重新运行gpexpand命令。

1.3.4    重分布有自定义类型的表

对于那些有被删除自定义类型列的表，无法通过扩展命令来执行重分布。要重 分布这些有被删除自定义类型列的表，先使用CREATE TABLE AS SELECT重建该表，这样，那些被删除的列在该过程中会被清除，然后再使用扩展命令重分布该表。

1.3.5    重分布分区表

因为扩展命令可以一个分区一个分区的重分布一张大表，因此，有效的分区设计可以显著的降低重分布对性能的影响。仅仅是分区表的子表会被置为 RANDOMLY策略，而且也只有子表在重分布时会获取读写锁定的排它锁。

1.3.6    重分布有索引的表

由于在重分布表之后gpexpand命令必须重建索引，高度索引的表重分布会有很大的性能影响。重分布有密集索引表的系统将会慢的非常明显。

 

1.4       节点的准备与添加

为扩展准备新节点的系统，安装GPDB二进制文件，交换SSH互信，执行性能测试。 GP推荐至少执行两次性能测试：第一次只测试新节点，第二次新节点和已有节点一 起测试。为了避免用户活动扭曲测试结果，第二次必须在系统停机状态下进行。

除了这些通用的指导外，GP建议在网络环境发生变化或者任何系统环境发生变化时都应该执行性能测试。比如：要准备在两套网络环境下扩展系统，应该在每套环境 下分别执行性能测试。

本节的剩余部分解释如何运行GP管理命令来检查准备整合到已有GP系统的新节点。

1.4.1    将新节点添加到互信环境

为了确保GP管理工具可以在不提示密码输入的情况下连接到所有节点，新节点 必须与已有节点之间交换SSH密钥。

GP建议执行两次密钥交换：一次使用root用户(为了方便管理)，一次使用 gpadmin用户(GP管理命令需要)。按照顺序执行如下任务：

1.              交换root的SSH密钥

2.               创建gpadmin用户

3.              交换gpadmin的SSH密钥

注意：Greenplum数据段主机命名约定是sdwN,SDW是一个前缀和N是整数。例如，一个Greenplum数据DCA系统上，段的主机名是sdw1，sdw2等。对于具有多个接口的主机，惯例是添加一个破折号（ - ）和数量的主机名。例如，sdw1-1和sdw1-2是用于主机sdw1两个接口名称。

1.4.1.1    To exchange SSH keys as root

1.              创建两个独立的Host列表文件：一个包含现有GPDB集群的所有Host名称， 另一个包含所有新扩展节点的Host名称。对于已有主机，可使用首次建立SSH密钥的Host文件。

Host文件应该包含所有主机(Master、Standby和Instance主机)，每个Host名称一行。如果使用了多网口配置，需确保交换了每个主机所有HostName 的SSH密钥。文件中不能有空行和多余的空字符。例如：

mdw

sdw1-1

sdw1-2

sdw1-3

sdw1-4

sdw2-1

sdw2-2

sdw2-3

sdw2-4

sdw3-1

sdw3-2

sdw3-3

sdw3-4

2.    在Master主机上以root登录，从GP安装目录加载greenplum_path.sh文件

$ su -

#                        source /usr/local/greenplum-db/greenplum_path.sh

3.               使用Host列表文件执行gpssh-exkeys命令。例如：

#         gpssh-exkeys -f/home/gpadmin/existing_hosts_file -x /home/gpadmin/new_hosts_file

4.    gpssh-exkeys会检查远程主机并在所有主机之间执行密钥交换。在提示的时候输入root用户密码。例如：

***Enterpassword for root@hostname: <root_password>

1.4.1.2    创建gpadmin用户

1.              使用gpssh命令在所有新Segment主机上创建gpadmin用户(如果还没有的话)

使用之前创建用于交换密钥的Host文件。例如：

#                        gpssh -f new_hosts_file '/usr/sbin/useradd                                              -d

/home/gpadmin -s /bin/bash'

2.    设置新建gpadmin用户的密码。在Linux上，可以通过gpssh—次完成所有节点的操作。例如：

#         gpssh -f new_hosts_file 'echogpadmin_password | passwd gpadmin --stdin'

3.               通过查看根目录确认gpadmin用户已经创建：

#                 gpssh-f new_hosts_file ls -l /home

 

1.4.1.3    交换gpadmin的SSH密钥

1.              以gpadmin用户登录Master主机，使用相关的Host列表文件执行 gpssh-exkeys 命令。例如：

#                        gpssh-exkeys -e /home/gpadmin/exiseing_hosts_file-x /home/gpadmin/new_hosts_file

2.               gpssh-exkeys会检查远程主机并在所有主机之间执行密钥交换。在提示的时候输入gpadmin用户密码。例如：

***Enter password for gpadmin@hostname:

1.4.2     检查OS设置

使用gpcheck命令来检查所有新Segment主机，确保其OS设置符合GPDB软件运行的要求。

1.4.2.1    运行 gpcheck

1.                       使用运行GPDB系统的用户（比如gpadmin)登录Master主机。

$ su - gpadmin

2.               使用Host列表文件执行gpcheck测试新Segment主机。例如：

$ gpcheck -f                                                              new_hosts_file

1.4.3     检查磁盘I/O和内存带宽

使用gpcheckperf命令来测试磁盘I/O和内存带宽。

1.4.3.1    运行 gpcheckperf

1.    使用Host列表文件执行gpcheckperf测试新Segment主机。使用-d参数指定在每个主机(必须具有这些目录的写权限)上需要测试的文件系统目录。例如：

$ gpcheckperf -f new_hosts_file -d /data1 -d /data2-v

2.    由于完成该测试需要在Host上拷贝很大的文件，该命令需要花费较长的时间。在测试完成时，将会列出磁盘写、磁盘读、流测试结果的概要。

. 注意：这个例子中没有指定-r参数，真实的测试可参考“测试硬件性能”相关章 节，而不是直接使用本例中的命令。

1.4.4    集成新硬件到系统中

在初始化新Instance之前，应在包含新Segment主机的所有节点上重复一遍性能 测试。在停机之后使用包含所有主机名称的Host文件执行同样的测试：

•       检查OS设置

•       检查磁盘I/O和内存带宽

 

由于用户活动会扭曲测试结果，必须在GPDB停机(gpstop)后执行测试。

 

 

1.5       初始化新Instance

使用gpexpand命令来初始化新Instance，生成扩展Schema，在系统范围内设置DB的分布策略为RANDOMLY。缺省情况下，在第一次使用有效的扩展配置文件从Master 运行gpexpand命令时就完成了这些任务。随后再执行gpexpand命令，其将发现扩展 Schema已经创建，并开始执行重分布表。.

•                生成系统扩展配置文件

•                交互模式生成扩展配置文件

•                Rolling Back a Failed Expansion Setup

1.5.1     生成系统扩展配置文件

要开始扩展，gpexpand命令需要一个包含关于新Instance和Host信息的配置文件。 如果不指定配置文件运行gpexpand命令，命令将显示一个交互式的方式，采集 需要的信息以自动生成配置文件。

如果使用交互方式生成配置文件，可以选择性的指定文件包含哪些扩展主机。 如果在交互式输入主机名时所使用的平台或命令对长度有限制，可以通过-f参 数来指定主机名列表。

 

交互模式生成扩展配置文件

在执行gpexpand以交互模式生成配置文件之前，需要确认下列所需信息：

•        新节点数量(或者Host文件）

•        新节点的Host名称(或者Host文件）

•        已有节点的Mirror策略，假如有

•        每个主机添加的Instance数量，假如有

gpexpand程序会根据这些信息生成一个配置文件，包含dbid、content ID、数据目录(和gp_segment_configuration表中的一样)，该配置文件会被保存在命令运行的当前目录。

1.5.1.1   为了交互模式生成扩展配置文件

 

1.    以GPDB系统运行用户(比如gpadmin)登录Master主机。

2.    运行gpexpand命令。命令会提示关于准备扩展操作的信息，提示退出或继续。

作为可选，使用-f指定一个Host文件。例如：

$gpexpand -f /home/gpadmin/new_hosts_file

3.    在提示时，选择[Y]继续。

4.    除非使用-f指定Host文件，命令会提示输入HostName。将新扩展主机的主机名按照逗号分割的方式输入。不要包含多网口相关的主机名。例如：

>     sdw4-1, sdw4-2, sdw4-3, sdw4-4

正确的使用是列出每个节点独立的主机名。例如：

>     sdw4, sdw5, sdw6, sdw7

如果只是在已有节点上增加Instance,在提示处输入空行即可。不要输入localhost或者任何系统中已经存在的Host Name。

5.    假如有Mirror，输入Mirror策略。选项为spread|grouped|none，缺省为grouped。

需确保有足够的节点数量来支撑选择的Mirror策略。更多信息参见”规划MirrorInstance”相关章节。

6.    如果有必要，输入要在每个节点上增加的Instance数量。缺省情况下，新节点初始化与已有节点相同数量的Instance。但作为可选项，可以增加每个节点的Instance数量。

如果想要增加每个节点Instance的数量，输入一个非0的数字。该数量的额 外Instance会在所有节点上被初始化。例如，现有系统每个节点有2个Instance，输入一个数值2，在现有节点上会新初始化2个Instance,同时新节 点的Instance数量也为4个。

7.    如果增加新的Instance，需要为新Instance输入数据目录的跟路径。不要指 定真实的数据目录，其会由gpexpand命令在已有的数据目录下自动创建。 例如，已有的数据目录像这样：

/gpdata/primary/gp0

/gpdata/primary/gp1

应该像下面这样输入(每个提示输入一个)来指定两个新的Instance的数据目录：

/gpdata/primary

/gpdata/primary

在执行初始化时，gpexpand命令会在/gpdata/primary目录下自动创建gp2和gp3两个新的目录。

8.    如果增加新的Mirror，需要为新Mirror输入数据目录的跟路径。不要指定真 实的数据目录，其会由gpexpand命令在已有的数据目录下自动创建。

例如，已有的数据目录像这样：

/gpdata/mirror/gp0

/gpdata/mirror/gp1

应该像下面这样输入(每个提示输入一个)来指定两个新的Mirror的数据目录：

/gpdata/mirror

/gpdata/mirror

在执行初始化时，gpexpand命令会在/gpdata/mirror目录下自动创建gp2和gp3两个新的目录。

重要提示：那些为Instance和Mirror指定的目录必须在新的节点存在，而且运行gpexpand命令的用户需具备这些目录的写权限。

在输入全部需要的信息之后，命令会在当前路径生成一个扩展配置文件。 例如：

gpexpand_inputfile_yyyymmdd_145134

1.5.1.2   扩展配置文件的格式

完全可以按照要求的格式自行创建扩展配置文件。除非对于扩展来说有特殊的需求，GP都建议使用交互的模式来生成扩展配置文件。 扩展配置文件的格式为:

hostname:address:port:fselocation:dbid:content:preferred_role:replication_port

例如:

sdw5:sdw5-1:50011:/gpdata/primary/gp9:11:9:p:53011

sdw5:sdw5-2:50012:/gpdata/primary/gp10:12:10:p:53011

sdw5:sdw5-2:60011:/gpdata/mirror/gp9:13:9:m:63011

sdw5:sdw5-1:60012:/gpdata/mirror/gp10:14:10:m:63011

一个扩展配置文件在格式上需要每个新Instance的如下信息：

参数

有效值

描述

hostname

主机名

Segment节点的主机名

port

可用的端口号

数据库的监听端口。应该从已有的端口为基数增加端口号的数值。

fselocation

目录名称

Instance的数据目录(文件空间)位置。如同 pg_filespace_entry 系统表中一样。

dbid

整数。不可与已有的冲突

Instance的数据库ID。该值应该从已有的值(参见 系统日志表gp_segment_configuration)增加而来。 例如，已有的10个Instance的集群dbid为1-10， 那么新的Instance的dbid应该为11-14

content

整数。不可与已有的冲突

nstance的目录ID。Primary的应该与对应的Mirror相同。该值应该从已有的值增加而来。更多信息 参考系统日志表 gp_segment_configuration

preferred_role

plm

指定该Instance为Primary或者Mirror。p代表 Primary，而 m 代表 Mirror

replication_port

可用的端口号

Instance的文件同步端口。该值应该从已有的 replication_port 值增加而来

1.5.2     运行gpexpand初始化新Instance

1.5.2.1   运行gpexpand初始化新Instance

在生成扩展配置文件之后，运行gpexpand来初始化新Instance。由于初始化 Instance的需要，该命令会自动停止GPDB，在完成初始化之后会自动重启系统。

1.      以GPDB系统运行用户(比如gpadmin)登录Master主机。

2.      使用-i参数指定扩展配置文件，运行gpexpand命令。作为可选，使用-D指 定扩展Schema所在的数据库。例如：

$ gpexpand -i input_file -D database1

该命令会查出GP系统中是否已经存在一个扩展Schema。如果已经存在一个扩展Schema，在开始新的扩展操作之前应该使用gpexpand -c命令清除该 Schema。参照“清除扩展Schema”相关章节。

在新Instance被成功初始化且扩展Schema被成功创建后，gpexpand命令会打印成功信息并退出。

在初始化过程完成之后，即可连接到GPDB查看扩展Schema。该Schema位于-D参数指定的数据库，或者通过PGDATABASE环境变量指定的数据库。更多信 息查看“关于扩展Schema”相关章节。

1.5.3    回滚失败的扩展

可以使用gpexpand --rollback 命令来回滚失败的扩展安装。不过，这个命令仅适用于失败的情况。一旦操作成功完成，扩展即被提交，且不能回滚。

要回滚失败的扩展安装，使用下面的命令，指定包含扩展Schema的数据库名称：

gpexpand --rollback -D database_name

1.6       重分布表

在成功生成一个扩展Schema之后，就可以将GPDB恢复到在线状态并在全部集群中 重新分布表。可以按照特定的时间间隔使用gpexpand来重分布表，在空闲时间段使 用gpexpand命令重分布表可以降低CPU使用和表锁对数据库操作的影响。另外，可以调整Table的排名来确保大表和关键表按照优先顺序被重分布。

在重分布表的过程中：

•        任何新表或分区的创建都是在所有Instance节点上的，这也刚好是正常的情况。

•        查询会使用所有Instance，即便相关的数据可能还未分布到新的Instance上。

•        正在重分布的表会被锁住，其他任何读写操作都无法访问该表。在重分布完成 之后，即恢复正常操作。

1.6.1    排名重分布表

对于大型系统，建议通过在扩展Schema中调整重分布表的排名来空值重分布的 顺序。这样就允许首先重分布重要的表从而最小化对系统性能的影响。另外， 可用磁盘空间的两也会影响到重分布表的排名，更多信息参考“管理大规模GP 系统的重分布”相关章节。

通过更新gpexpand.status_detail表的rank值来调整重分布表的排名，使用psql或 者其他支持的客户端连接到GPDB来修改。更新gpexpand.status_detail表的命令 例如这样：

=> UPDATE gpexpand.status_detail SET rank= 10;

UPDATE gpexpand.status_detail SET rank=1 WHERE fq_name = 'public.lineitem';

UPDATE gpexpand.status_detail SET rank=2 WHERE fq_name = 'public.orders';

第一条命令是将所有表的排名降到10,然后将lineitem的排名设置为1，而orders 的排名设置为2。在开始重分布时，lineitem会首先被重分布，接下来的是orders， 然后才是gpexpand.status_detail中的其他表。

注意：任何不希望被重分布的表，必须从gpexpand.status_detail表中删除对应的记录。

1.6.2    使用gpexpand重分布表

1.6.2.1   使用gpexpand重分布表

1.      以GPDB系统运行用户(比如gpadmin)登录Master主机。

2.      执行gpexpand命令。作为可选，可以选择使用-d或者-e来定义重分布会话 的周期。例如，运行该命令并限制最长60个小时的周期：

$ gpexpand -d 60:00:00

该命令会一直运行到分布Schema中的最后一张Table被标记为成功的完成分布为止，或者直到指定的持续时间或者结束时间到达为止。每个会话的开始和结束时间，gpexpand命令都会更新到gpexpand.status表中。

1.6.2.2   监测重分布表

在重分布表过程中的任何时间，都可以查询该扩展Schema。视图 gpexpand.expansion_progress提供了当前进度的摘要，包括预估的已经重分布的比率和估计的完成时间。gpexpand.status_detail表可用于查看每张表的重分布状态信息。

查看扩展状态

由于gpexpand.expansion_progress中估算的比率是基于每张表的比率获取的，因此该视图无法准确的计算出比率，直到第一张表的扩展完成为止。每次开始一个新的重分布表的会话时都会重新开始计算。

使用psql或者其他支持的客户端连接到GPDB，通过查询 gpexpand.expansion_progress来监测扩展的进度。像下面这样使用SQL命令查询 gpexpand.expansion_progress ：

=# SELECT * FROM gpexpand.expansion_progress;

name | value

------------------------------+-----------------------

Bytes Left | 5534842880

Bytes Done | 142475264

Estimated Expansion Rate | 680.75667095996092 MB/s

Estimated Time to Completion | 00:01:01.008047

Tables Expanded | 4

Tables Left | 4

(6 rows)

1.6.2.3   查看表的状态

表gpexpand.status_detail中存储了每张表的状态、最后更新时间以及其他的有用信息。使用psql或者其他支持的客户端连接到GPDB，通过查询gpexpand.status_detail来监测特定Table的状态。像下面这样使用SQL命令查询 gpexpand.status_detail：

=> SELECT status, expansion_started, source_bytes FROM

gpexpand.status_detail WHERE fq_name = 'public.sales';

status | expansion_started | source_bytes

-----------+----------------------------+--------------

COMPLETED | 2009-02-20 10:54:10.043869 | 4929748992

(1 row)

1.7       清除扩展Schema

在确保扩展操作已经完成之后，扩展Schema可以被安全的删除。要想在GP系统上 运行其他的扩展操作，首先必须清除已有的扩展Schema。

1.      以GPDB系统运行用户(比如gpadmin)登录Master主机。

2.      使用-c参数执行gpexpand命令。例如：

$ gpexpand –c