合 扩容Greenplum系统（增加segment节点）相关理论

简介

为了放大性能和存储能力，通过向集群增加主机来扩容用户的Greenplum系统。

随着额外的数据被收集以及现有数据的保留时间增加，数据仓库会随着时间而长大。 有时，有必要增加数据库能力来联合不同的数据仓库到一个数据库中。 也可能需要额外的计算能力（CPU）来适应新增加的分析项目。 尽管在系统被初始定义时就留出增长的空间是最为明智的，但是通常不太可能在提前太多在资源上投资。 因此，用户应该寄望于定期地执行一次数据库扩容项目。

由于Greenplum的MPP架构，在用户增加资源到系统时，得到的容量和性能就好像该系统一开始就用增加后的资源实现一样。 和要求大量停机时间来转储和恢复数据的数据仓库系统不同，扩容一个Greenplum数据库系统是一种最小化停机时间的分阶段处理。 在数据被重新分布时，常规和特别负载可以继续并且事务一致性也能被维护。 管理员可以安排分布活动以适合正在进行的操作并且可以按需暂停和继续。 表可以被排名，这样数据集可以以一种优先序列的方式被重新分布，从而确保关键性的负载能很快从扩容后的能力受益，或者释放所需的磁盘空间来重新分布非常大的表。

扩容处理使用标准的Greenplum数据库操作，因此它是透明的并且管理员易于排查错误。 Segment镜像和任何复制机制就地保持活动，因此容错性没有打折扣并且灾难恢复措施也保持有效。

• 系统扩容概述
  用户可以最小化停机时间，通过增加节点实例和节点主机来扩容Greenplum数据库。
• 规划Greenplum系统扩容
  细心的规划将帮助确保一个成功的Greenplum扩容项目。
• 准备并增加节点
  验证用户的新节点已经准备好整合到现有的Greenplum系统中。
• 初始化新节点
  使用gpexpand工具创建并初始化新节点实例，并创建扩容schema。
• 重分布表
  重新分布表让现有数据在新扩容后的集群上得以平衡。
• 移除扩容Schema
  要在扩容Greenplum集群后进行清理，需要移除扩容Schema。

系统扩容概述

用户可以最小化停机时间，通过增加节点实例和节点主机来扩容Greenplum数据库。

随着收集额外数据并且现有数据的定期增长，数据仓库通常会随着时间的推移而不断增长。 有时，有必要增加数据库能力来联合不同的数据仓库到一个数据库中。 数据仓库也可能需要额外的计算能力（CPU）来适应新增加的分析项目。 在系统被初始定义时就留出增长的空间是很好的，但是即便用户预期到了高增长率，提前太多在资源上投资通常也不明智。 因此，用户应该寄望于定期地执行一次数据库扩容项目。

当用户扩容数据库时，会期待如下特性：

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

扩容项目的规划和实体层面比扩容数据库本身更重要。 需要一个多学科团队来规划和执行项目。 对于内部部署安装，必须为新服务器获取和准备空间。 必须指定，获取，安装，连接，配置和测试服务器。 对于云部署，也应该做类似的计划。 规划新的硬件平台描述了部署新硬件的常规考虑。

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

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

• 扩容过程的软件阶段的第一步是准备Greenplum数据库系统： 添加新节点的主机并初始化新的节点实例。 此阶段可以安排在低活动期间进行，以避免中断正在进行的业务运营。 在初始化过程中，执行以下任务：

  • Greenplum数据库软件已被安装。
  • 在新的Segment主机的新节点实例上创建了数据库和数据库对象。
  • gpexpand schema在postgres数据库里被创建。 可以使用schema里的表和视图来监控和管理扩容。

  在系统被更新后，新节点主机上的新节点实例已经可以使用了。

  • 新节点立即生效并参与到新查询和数据加载里。 但是现有数据会发生倾斜。 它们集中在原节点上并且需要根据新节点总量做重分布。
  • 因为有些表的数据已经倾斜了，所以部分查询性能会下降，因为可能需要更多的Motion操作了。

• 软件阶段的最后一步就是重新分布表数据。 使用gpexpand schema中的扩容控制表作为指导，重新分配表。 对每一个表：

  • gpexand工具基于分布策略在所有新老机器上重新分布表数据。
  • 扩容控制表中的表状态会被更新。
  • 在数据重分布之后，查询优化器会基于不倾斜的数据创建更高效的查询计划。

  当所有表都完成了重分布，扩容也就完成了。

Important: gprestore工具不能恢复在扩容之前使用gpbackup工具备份的数据。 所以在扩容完成之后立即备份你的数据。

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

在一种典型的操作中，在完整的扩容处理过程中，用户需要用不同的选项运行gpexpand工具四次。

1. 创建扩容输入文件：

   gpexpand -f hosts_file

   1	gpexpand -f hosts_file

2. 初始化Segment并且创建扩容schema：

   gpexpand -i input_file

   1	gpexpand -i input_file

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

3. 重新分布表数据：

   gpexpand -d duration

   1	gpexpand -d duration

   在初始化时，gpexpand增加并初始化新节点实例。 必须运行gpexpand在新增节点实例上重分布数据来完成系统扩容。 取决于系统的大小和规模，重新分布可能在一个单一会话中经过数个利用率较低的小时才会完成，或者用户可以把该处理划分成一个长时段上的批处理。 每个表或分区在扩容期间是无法进行读写操作的。 由于每一个表都会被重新分布在新的Segment上，数据库性能应该会逐步提升直到超过扩容前的性能水平。

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

   用户可以在初始化期间访问Greenplum数据库，但是在严重依赖表的哈希分布的系统上，它们可能会出现性能下降。 尽管用户可能会遇到较慢的响应时间，但ETL作业，用户查询和报告等正常操作仍可继续。

4. 移除扩容schema：

   gpexpand -c

   1	gpexpand -c

规划Greenplum系统扩容

细心的规划将帮助确保一个成功的Greenplum扩容项目。

这一节中的主题将帮助确保用户已经准备好执行一次系统扩容。

• 系统扩容检查列表是一份用户可以用来准备和执行系统扩容处理的检查列表。
• 规划新的硬件平台包括为获得和设置新硬件做规划的内容。
• 规划新Segment初始化提供了有关规划使用gpexpand初始化新的Segment主机的信息。
• 规划表的重新分布提供了有关规划在新Segment主机初始化完以后重新分布数据的信息。

系统扩容检查列表

这个检查列表摘要了一次Greenplum数据库系统扩容包括的任务。

扩容前的在线任务 系统已启动并且可用
	制定并执行订购，构建和联网新硬件平台或配置云资源的计划。
	设计一个数据库扩容计划。映射每个主机上的Segment数量、安排用于性能测试和创建扩容方案所需的停机时段并且安排用于表重新分布的时段。
	执行一个完整的方案转储。
	在新主机上安装Greenplum数据库的二进制文件。
	复制SSH密钥到新主机（gpssh-exkeys）。
	验证新旧硬件或者云资源的操作系统环境（gpcheck）。
	验证新硬件或者云资源的磁盘I/O和内存带宽（gpcheckperf）。
	验证Master的数据目录中在pg_log或者gpperfmon/data目录下面没有极大的文件。
扩容前的离线任务 在此处理期间系统对所有用户活动不可用。
	验证没有catalog问题 (gpcheckcat)。
	验证组合的现有和新硬件或云资源的操作系统环境(gpcheck)。
	验证组合的现有和新硬件或云资源的磁盘I/O和内存带宽(gpcheckperf)。
在线节点实例初始化 系统已启动并且可用
	准备扩容输入文件(gpexpand)。
	将新节点初始化为数组并创建扩容Schema (gpexpand-i input_file)。
在线扩容和表重新分布 系统已启动并且可用
	在用户开始表重新分布之前，停止任何自动的快照处理或者其他消耗磁盘空间的进程。
	在扩容后的系统中重新分布表（gpexpand）。
	移除扩容方案(gpexpand -c)。
	运行analyze来更新分布统计信息。在扩容期间使用gpexpand -a，在扩容之后使用analyze。
备份数据库 系统已启动并且可用
	使用gpbackup工具备份数据库。 在开始系统扩容之前创建的备份无法还原到新扩容的系统，因为gprestore实用程序只能将备份还原到具有相同数量节点的Greenplum数据库系统。

规划新的硬件平台

一个深思熟虑的、周密的部署兼容硬件的方法会大大地最小化扩容处理的风险。

新节点主机的硬件资源和配置应该与现有主机一致。

规划和设置新硬件平台的步骤在每一次部署中都有不同。下面是一些相关的考虑：

• 为新硬件准备物理空间，考虑冷却、电力供应和其他物理因素。
• 确定连接新旧硬件所需的物理网络和布线。
• 为扩容后的系统映射现有的IP地址空间和开发中的网络规划。
• 从现有的硬件捕捉系统配置（用户、配置文件、NIC等等），这将被用作订购新硬件时的清单。
• 为在特定站点和环境中用期望的配置部署硬件创建一个自定义的建设计划。

在选择并且增加新硬件到网络环境中后，确保执行验证OS设置中描述的任务。

规划新Segment初始化

当系统启动并可用时，可以执行扩容Greenplum数据库。 运行gpexpand来初始化新节点到阵列中并创建扩容schema。

所需要的时间取决于Greenplum系统中的方案对象的数量以及其他与硬件性能相关的因素。 在大部分环境中，新Segment的初始化不超过30分钟。

下列工具不能在gpexpand在做节点初始化期间执行。

• gpbackup
• gpcheck
• gpcheckcat
• gpconfig
• gppkg
• gprestore

Important: 在用户开始初始化新Segment之后，用户就不再能用扩容系统之前创建的备份文件来恢复系统。 当初始化成功完成后，扩容会被提交且不能被回滚。

规划Mirror节点

如果现有的阵列有Mirror节点，新的节点也必须有Mirror配置。 如果现有的节点没有配置Mirror，则不能用gpexpand工具给新主机增加Mirror。 有关节点Mirror的更多信息，请参考关于Segment镜像。

对于带有Mirror节点的Greenplum数据库阵列，确保增加了足够的新主机来容纳新的Mirror节点。 所需的新主机数量取决于Mirror策略：

• 散布镜像 — 向阵列中增加比每个主机上的节点数量至少多一台的主机。 要确保平均散布，阵列中独立主机的数量必须大于每台主机上的节点实例数量。 散布镜像会把每台主机的镜像散布到集群中剩余的主机上并且要求集群中的主机数量比每个主机上的Primary节点数量更多。
• 组镜像 — 增加至少两台新主机，这样第一台主机的镜像可以被放在第二台主机上，并且第二台主机的镜像可以被放在第一台上。 如果在系统初始化阶段启用了节点镜像，这是默认的Mirroring策略。
• 块镜像 — 添加一个或多个主机系统块。 例如，添加一个包含四个或八个主机的块。 块镜像是一种自定义镜像配置。 关于块镜像的更多信息请参考Greenplum数据库最佳实践指导中的Segment镜像。

对每个主机增加新节点

默认情况下，新主机上初始化后会有和现有主机上数量相同的主节点。 可以增加每台主机上的节点或者向现有主机上增加新的节点。

例如，如果现有主机当前在每台主机上有两个节点，可以使用gpexpand在现有主机上初始化两个额外的节点来得到总共四个节点，这样将在新主机上有四个新的节点。

创建扩容输入文件的交互式处理会提示这个选项，还可以在该输入配置文件中手工指定新节点的目录。 更多信息请参考为系统扩容创建一个输入文件。

关于扩容Schema

在初始化阶段，gpexpand工具在postgres数据库中创建扩容schema gpexpand。

扩容Schema存储了系统中每个表的元数据，因此在扩容处理的全过程中能跟踪其状态。 扩容Schema由两个表和一个跟踪扩容操作进度的视图组成：

• gpexpand.status
• gpexpand.status_detail
• gpexpand.expansion_progress

通过修改gpexpand.status_detail可以控制扩容处理的方方面面。 例如，从这个表中移除一个记录会阻止系统在新节点上扩容该表。 通过更新一个记录的rank值，可以控制表在重新分布过程中被处理的顺序。 更多信息请参考表重分布排名。

规划表的重新分布

表重新分布会在系统在线时被执行。 对于很多Greenplum系统，表重新分布会在一个安排在低利用率时期执行的单一gpexpand会话中完成。 更大的系统可能会要求多个会话并且设置表重新分布的顺序来最小化对性能影响。 如果可能的话，尽量在一个会话中完成表重新分布。

Important: 要执行表重新分布，节点主机必须具有足够多的磁盘空间来临时地保存最大表的一份拷贝。 在重新分布期间，所有的表对于读写操作都不可用。

表重新分布的性能影响取决于一个表的尺寸、存储类型以及分区设计。 对于任何给定的表，用gpexpand重新分布需要消耗和一次CREATE TABLE AS SELECT操作相同的时间。 在重新分布一个T级别的表时，扩容工具会使用许多可用的系统资源，这可能会影响其他数据库负载的查询性能。

在大规模Greenplum系统中管理重新分布

在规划重新分布阶段时，要考虑重新分布期间在每个表上取得的ACCESS EXCLUSIVE锁的影响。 一个表上的用户活动可能会延迟它的重新分布，而且表在重新分布期间对用户活动不可用。

可以通过调整ranking来控制表重分布的顺序。 参考表重分布排名。 操作重分布顺序有助于调整有限的磁盘空间，并尽快恢复高优先级查询的最佳查询性能。

表重分布方法

Greenplum数据库扩容的时候有两种方法重分布数据。

• rebuild - 建立一个新表，把所有数据从旧表复制到新表，然后替换旧表。 这是默认行为。rebuild方法和使用CREATE TABLE AS SELECT命令创建一个新表类似。 在数据重分布期间，会在表上加ACCESS EXCLUSIVE锁。
• move - 扫描所有数据并做UPDATE操作来移动需要移动的行到不同节点实例上。 在数据重分布过程中，会在表上加ACCESS EXCLUSIVE锁。 一般来说，这个方法需要更少的磁盘空间，但是它在表里留下了很多被淘汰的行，可能在数据重分布后需要VACUUM操作。 另外，此方法一次更新一行索引，这会使它比使用CREATE INDEX命令重建索引更慢。

磁盘空间充裕的系统

如果系统由充裕的空闲磁盘空间（要求用来存储最大表的一份拷贝），可以通过首先重新分布查询使用最多的重点表来尽快恢复最优的查询性能。 为这些表分配高的排名，并且在系统使用量低的时候安排重新分布操作。 一次运行一个重新分布处理，直到大的或者关键的表被重新分布完。

磁盘空间有限的系统

如果现有的主机磁盘空间有限，可以先重新分布较小的表（例如维度表）来腾出空间存储最大表的一份拷贝。 由于每个表会被重新分布到被扩容后的阵列上，在原始节点上的可用磁盘空间会增加。 当在所有节点上存在足够的空闲空间以存储最大表的一份拷贝后，就可以重新分布大的或者关键的表了。 大表的重新分布要求排他锁，请把这种过程安排在非峰值时段。

还要考虑下面的事情：

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。