系统扩展概述

当用户扩展用户的数据库时，用户应该期待下列特质：

可伸缩的容量和性能。当用户向一个Greenplum数据库增加资源时，得到的容量和性能就好像该系统一开始就用增加后的资源实现一样。
扩展期间不中断服务。常规负载（计划中的或者ad hoc）不会被中断。为了初始化新的服务器，会要求一个短暂的、计划中的停机时段，这类似于重启系统所要求的停机。停机时间的长度与系统在扩展前后的尺寸无关。
事务一致性。
容错。在扩展期间，标准的容错机制（例如Segment镜像）保持活动、一致并且有效。
复制和灾难恢复。在扩展期间，任何现有的复制机制都继续发挥作用。在失败或者灾难事件中需要的恢复机制也保持有效。
处理透明。扩展处理利用了标准的Greenplum数据库机制，因此管理员能够诊断并且排查任何问题。
可配置的处理。扩展可能会是一个长时间运行的处理，但它可以变成按计划执行的一系列操作。扩展模式的表允许管理员指定表被重新分布的优先级，而且扩展活动可以被暂停并且继续。

一个扩展项目的计划和物理形态是一项比扩展数据库本身更加重大的工作。将需要一个多学科团队来规划和执行该项目。对于本地安装，必须为新的服务器获得并且准备好空间。必须先确定好这些服务器的规格，然后获得并且安装它们，还要用线缆把它们连接起来，最后还要进行配置和测试。对于云部署，也应该做类似的计划。规划新的硬件平台描述了部署新硬件的一般考虑。

在准备好新的硬件平台并且设置好它们的网络之后，配置它们的操作系统并且使用Greenplum的工具运行性能测试。Greenplum数据库软件发布包括一些工具，这些工具有助于在开始扩展的软件阶段之前对新的服务器进行测试和拷机。为Greenplum数据库准备新主机的步骤请见。

一旦新服务器被安装并且测试，Greenplum数据库扩展处理的软件阶段就开始了。软件阶段被设计为尽量少被打断、事务一致、可靠并且灵活。

系统被重启并且应用继续进行。
- 新的Segment立即可用并且立即参与到新的查询和数据装载中。不过，现有的数据是倾斜的。因为现有数据集中在原有的Segment上，并且必须被重新分布在当前的所有主要Segment上。
- 因为表现在有一种随机分布策略，优化器会创建不依赖于分布键的查询计划。一些查询的效率会不那么好，因为需要更多的数据移动操作符。
当所有的表都被重新分布完后，扩展也就完成了。

重新分布数据是一个长时间运行的处理，它会创建大量的网络和磁盘活动。可能需要数天时间来重新分布某些非常大型的数据库。为了最小化这些活动对业务操作的影响，系统管理员可以随意或者根据一个预定好的计划暂停并且继续扩展活动。数据集也可以被定义优先级，这样关键的应用可以从扩展中首先获益。

要创建一个扩展输入文件：
要：

gpexpand会创建一个数据目录、从现有的数据库复制表到新的Segment上并且为扩展方案中的每个表捕捉元数据用于状态跟踪。在这个处理完成后，扩展操作会被提交并且不可撤回。
要重新分布表：

在初始化时， gpexpand在所有现有数据库中的表上取消哈希分布策略（分区表的父表除外）并且将所有的表的分布策略设置为随机分布。

在需要多个重新分布会话的大型系统中，可能需要多次运行gpexpand来完成扩展。gpexpand可以从显式的表重新分布排名获益，详见。

在初始化完成并且系统重新上线后，用户可以访问Greenplum数据库，但是他们可能在严重依赖于表哈希分布的系统上体验到性能下降。ETL工作、用户查询以及报表等普通操作可以继续，但用户可能会体验到较慢的响应时间。

当一个表使用的是一种随机分布策略时，Greenplum数据库无法强制唯一约束（例如PRIMARY KEY）。这可能影响用户的ETL和装载处理直到表重新分布完成，因为重复行不会导致发出约束违背错误。

有关gpexpand工具和其他用于系统扩展的工具的信息可见Greenplum数据库工具指南。