扩容Greenplum系统
要扩展性能和存储容量,可通过向系统添加主机来扩展Greenplum数据库系统。通常,将Segment添加到Greenplum集群可实现性能和存储容量的线性扩展。
数据仓库通常会随着时间的增长而增长,因为会收集了更多的数据,并且现有数据的保留期会增加。有时,有必要增加数据库容量以将不同的数据仓库整合为一个数据库。可能还需要额外的计算能力(CPU)来容纳新添加的分析项目。尽管在最初指定系统时提供增长能力是明智的,但是通常不可能在需要资源之前就进行投资。因此,您应该定期执行数据库扩容项目。
由于Greenplum的MPP体系结构,因此,当您向系统添加资源时,其容量和性能与一开始就使用添加的资源实施该系统的情况相同。与需要大量停机才能转储和恢复数据的数据仓库系统不同,扩容Greenplum数据库系统是一个最小化停机时间的分阶段的过程。重新分布数据和维护事务一致性的同时,常规和临时工作负载可以继续。管理员可以安排分布活动以适应正在进行的操作,并可以根据需要暂停和继续。可以对表进行排序,以便按优先顺序重新分布数据集,以确保关键工作负载尽早从扩展的容量中受益,或者释放所需的磁盘空间来重新分布非常大的表。
扩容过程使用标准的Greenplum数据库操作,因此它是透明的,便于管理员进行故障排除。Segment镜像和现有的复制机制就地保持活动状态,因此容错能力不受影响,灾难恢复措施仍然有效。
系统扩容概述
您可以执行Greenplum数据库扩展,以最少的停机时间添加Segment实例和Segment主机。通常,将Segment添加到Greenplum群集可实现性能和存储容量的线性扩展。
数据仓库通常会随着时间的推移而不断增长,通常会以连续的速度增长,因为会收集更多的数据并且现有数据的保留期会增加。有时,有必要增加数据库容量以将不同的数据仓库整合为一个数据库。数据仓库可能还需要额外的计算能力(CPU),以容纳新增加的分析项目。在系统被初始定义时就留出增长的空间是很好的,但是即便您预期到了高增长率,提前太多在资源上投资通常也不明智。 因此,您应该定期地执行数据库扩容项目。
- 可伸缩的容量和性能。当您向一个Greenplum数据库增加资源时,得到的容量和性能就好像该系统一开始就用增加后的资源实现一样。
- 扩展期间不间断的服务。常规负载(计划中的或者临时安排的)不会被中断。
- 事务一致性。
- 容错能力。在扩容期间,标准的容错机制(例如Segment镜像)保持活动、一致并且有效。
- 复制和灾难恢复。在扩容期间,任何现有的复制机制都继续发挥作用。在失败或者灾难事件中需要的恢复机制也保持有效。
- 处理透明。扩容处理利用了标准的Greenplum数据库机制,因此管理员能够诊断和排除任何问题。
- 可配置的处理。扩展可能是一个长期运行的处理,但它可以变成按计划执行的一系列操作。扩容Schema的表允许管理员指定表被重新分布的优先级,而且扩容活动可以被暂停并且继续。
与扩容数据库本身相比,扩容项目的规划和实体方面所占的工作量更大。需要一个多学科团队来计划和执行该项目。对于内部部署安装,必须为新服务器获取和准备空间。必须指定、获取、安装、连接电缆,配置和测试服务器。对于云部署,也应该制定类似的计划。规划新硬件平台描述了部署新硬件的一般注意事项。
在配置新的硬件平台并设置它们的网络之后,请使用Greenplum工具配置操作系统并运行性能测试。Greenplum数据库软件发行版中包含一些工具,这些工具有助于在开始扩容的软件阶段之前对新的服务器进行测试和暖机(burn-in)。有关为Greenplum数据库准备新主机的步骤,请参阅准备和添加主机。
- 扩容过程的软件阶段的第一步是准备Greenplum数据库系统: 添加新的Segment主机并初始化新的Segment实例。 此阶段可以安排在低活动期间进行,以避免中断正在进行的业务运营。在初始化过程中,执行以下任务:
- 安装Greenplum数据库软件。
- 在新Segment主机上的新Segment实例中创建数据库和数据库对象。
- 在postgres数据库里创建gpexpand schema。可以使用schema里的表和视图来监控和管理扩容。
更新系统后,新Segment主机上的新Segment实例将可用。
- 新Segment立即可用,并参与到新的查询和数据加载。但是,现有数据会发生倾斜。它们集中在原Segment上并且需要根据新的Segment总量做重分布。
- 因为有些表的数据已经倾斜了,所以部分查询性能会下降,因为可能需要更多的移动(Motion)操作。
- 软件阶段的最后一步是重新分布表数据。使用gpexpand schema中的扩容控制表作为指导,重新分配表。对于每个表:
- gpexand 工具基于分布策略在所有新老机器上重新分布表数据。
- 扩容控制表中的表状态会被更新。
- 在数据重分布之后,查询优化器会基于不倾斜的数据创建更高效的查询计划。
当所有表都完成了重分布,扩容也就完成了。
重要提示:gprestore工具不能恢复在扩容之前使用gpbackup工具备份的数据。 所以在扩容完成之后立即备份你的数据。
重新分布表数据是一个长时间运行的过程,它会创建大量的网络和磁盘活动。重新分布一些大型数据库可能需要几天的时间。为了最大程度地减少活动增加对业务运营的影响,系统管理员可以临时或根据预定计划暂停和继续扩容活动。可以对数据集进行优先级排序,以便关键应用程序首先从扩容中受益。
在一种典型的操作中,在完整的扩容处理过程中,用户需要用不同的选项运行gpexpand工具四次。
- 创建扩容的输入文件:
gpexpand -f hosts_file
- 初始化Segment并创建扩容schema:
gpexpand -i input_file
gpexpand 创建一个数据目录,从现有的数据库复制表到新的Segment上,并且为扩容schema中的每个表捕捉元数据用于状态跟踪。 在这个处理完成后,扩容操作会被提交并且不可撤回。
- 重新分布表数据:
gpexpand -d duration
在初始化期间, gpexpand添加并初始化新Segment实例。要完成系统扩容,您必须在新添加的Segment实例上运行gpexpand重新分布数据表。根据系统的大小和规模,重新分布可以在低使用时期内一个单一会话中完成,也可以在很长的一段时间内将过程分为多个批。 每个表或分区在扩容期间是无法进行读写操作的。 由于每一个表都会被重新分布在新的Segment上,数据库性能应该会逐步提升直到超过扩容前的性能水平。
您可能需要运行 gpexpand 数次,来完成需要多个重新分布会话的大型系统的扩容。 gpexpand可以从显式的表重新分布排名获益,请参阅规划表的重新分布。用户可以在初始化期间访问Greenplum数据库,但是在严重依赖表哈希分布的系统上,他们可能会遇到性能下降的情况。 尽管用户可能会遇到较慢的响应时间,但ETL作业、用户查询和报告等正常操作仍可继续。
- 要删除扩展架构:
gpexpand -c
有关 gpexpand工具以及其他用于系统扩容的工具的信息,请参阅《Greenplum数据库工具指南》。
规划Greenplum系统扩容
仔细的规划将帮助确保Greenplum扩容项目成功。
本节主题有助于确保您已经准备好执行系统扩容。
- 系统扩容检查清单是一份用户可以用来准备和执行系统扩容处理的检查清单。
- 规划新的硬件平台涵盖了获取和设置新硬件的规划。
- 规划新Segment初始化提供了有关规划使用gpexpand初始化新的Segment主机的信息。
- 规划表的重新分布提供了有关规划在新Segment主机初始化完后,重新分布数据的信息。
Parent topic: 扩容Greenplum系统
系统扩容检查清单
这个检查清单总结了Greenplum数据库系统扩容的任务。
扩容前的在线任务 * 系统已启动并且可用 | |
制定并执行计划,来订购、构建和联网新的硬件平台,或提供云资源的计划。 | |
设计数据库扩容计划。映射每个主机上的Segment数量,安排用于性能测试和创建扩容方案所需的停机时间,并且安排用于表重新分布的时间。 | |
执行一个完整的schema转储。 | |
在新主机上安装Greenplum数据库的二进制文件。 | |
复制SSH密钥到新主机(gpssh-exkeys)。 | |
验证新硬件或者云资源的磁盘I/O和内存带宽(gpcheckperf)。 | |
验证Master的数据目录中,在pg_log目录或者gpperfmon/data目录下没有极大的文件。 | |
扩容前的离线任务 * 在此处理期间系统对所有用户活动不可用。 | |
验证没有目录问题 (gpcheckcat)。 | |
验证现有和新硬件的组合(或云资源)的磁盘I/O和内存带宽(gpcheckperf)。 | |
在线Segment实例初始化 * 系统已启动并且可用 | |
准备扩容输入文件(gpexpand)。 | |
将新Segment初始化进系统,并创建一个扩容的Schema (gpexpand-i input_file)。 | |
在线扩容和表重新分布 * 系统已启动并且可用 | |
在用户开始表重新分布之前,停止任何自动的快照进程或者其他消耗磁盘空间的进程。 | |
在扩容后的系统中重新分布表(gpexpand)。 | |
移除扩容schema(gpexpand -c)。 | |
重要提示:运行analyze来更新分布统计信息。 在扩容期间使用gpexpand -a,在扩容之后使用analyze。 | |
备份数据库 * 系统已启动并且可用 | |
使用gpbackup工具备份数据库。 在开始系统扩容之前创建的备份无法恢复到新扩容的系统,因为gprestore工具只能将备份恢复到具有相同数量节点的Greenplum数据库系统。 |
规划新的硬件平台
一个深思熟虑的、周密的部署兼容硬件的方法会最大程度地降低扩容过程的风险。
新Segment主机的硬件资源和配置应该与现有主机一致。
规划和设置新硬件平台的步骤因每次部署而异。下面是一些相关的考虑:
- 为新硬件准备物理空间,考虑冷却、电力供应和其他物理因素。
- 确定连接新旧硬件所需的物理网络和布线。
- 为扩容后的系统映射现有的IP地址空间,制定网络规划。
- 从现有的硬件捕获系统配置(用户、配置文件、NIC等等),以用作订购新硬件时的清单。
- 创建自定义构建计划,以在特定站点和环境中以所需配置部署硬件。
在选择并且增加新硬件到您的网络环境中后,请确保执行准备和添加主机中描述的任务。
规划新Segment的初始化
当系统启动并可用时,可以执行扩容Greenplum数据库。 运行gpexpand来初始化新Segment到系统中,并创建扩容schema。
所需的时间取决于Greenplum系统中的Schema对象的数量以及其他与硬件性能相关的因素。 在大部分环境中,新Segment的初始化不超过30分钟。
下列工具不能在gpexpand做Segment初始化期间执行。
- gpbackup
- gpcheck
- gpcheckcat
- gpconfig
- gppkg
- gprestore
Important: 开始初始化新Segment之后,您就不再能用扩容系统之前创建的备份文件来恢复系统。 当初始化成功完成后,扩容会被提交且不能被回滚。
规划镜像Segment
如果您的现有系统有镜像Segment,那么新的Segment也必须有配置镜像。 如果现有的Segment没有配置镜像,则不能用gpexpand工具将镜像添加到新主机。 有关镜像Segment的更多信息,请参考关于Segment镜像。
对于具有镜像Segment的Greenplum数据库系统,请确保添加足够的新主机,来容纳新的镜像Segment。 所需的新主机数量取决于镜像策略:
- 组镜像 — 增加至少两台新主机,这样第一台主机的镜像可以被放在第二台主机上,并且第二台主机的镜像可以被放在第一台上。 如果在系统初始化阶段启用了Segment镜像,这是默认的镜像策略。
- 散布镜像 —向系统中增加比每个主机上的Segment数量至少多一台的主机。 要确保均匀分布,独立主机的数量必须大于每台主机上的Segment实例的数量。 您可以在系统初始化期间或为现有系统启用Segment镜像时,指定这种镜像类型。
- 块镜像 — 添加一个或多个主机系统块。 例如,添加一个包含四个或八个主机的块。 块镜像是一种自定义镜像配置。 关于块镜像的更多信息,请参考Greenplum数据库最佳实践指导中的Segment镜像配置。
对每个主机增加新节点
默认情况下,初始化新主机时会使用与现有主机一样多的主Segment。 您可以增加每台主机上的Segment,也可以将新Segment添加到现有主机。
例如,如果现有主机当前在每台主机上有两个Segment,可以使用gpexpand在现有主机上初始化两个额外的Segment,来得到总共四个Segment,并在新主机上初始化四个新Segment。
创建扩容输入文件的交互式过程会提示您该选项,还可以在该输入配置文件中手工指定新Segment的目录。 有关更多信息,请参考为系统扩容创建一个输入文件。
关于扩容Schema
在初始化阶段,gpexpand工具在postgres数据库中创建一个名叫gpexpand的扩容schema 。
扩容Schema存储了系统中每个表的元数据,因此在扩容处理的整个过程中能跟踪其状态。 扩容Schema由两个表和一个跟踪扩容操作进度的视图组成:
- gpexpand.status
- gpexpand.status_detail
- gpexpand.expansion_progress
通过修改gpexpand.status_detail可以控制扩容处理的方方面面。 例如,从这个表中删除一条记录可防止系统在新Segment上扩容该表。 通过更新一条记录的rank值,可以控制表在重新分布过程中被处理的顺序。 更多信息请参考表重新分布的排名。
规划表的重新分布
表重新分布会在系统联机时被执行。 对于很多Greenplum系统,表的重新分布会在低使用时期内单一gpexpand会话中完成。 更大的系统可能会要求多个会话,并且设置表重新分布的顺序来最小化对性能影响。 如果可能的话,尽量在一个会话中完成表重新分布。
Important: 要执行表重新分布,Segment主机必须具有足够多的磁盘空间来临时地保存最大表的一份拷贝。 在重新分布期间,所有的表对于读写操作都不可用。
表重新分布的性能影响取决于一个表的大小、存储类型以及分区设计。 对于任何给定的表,用gpexpand重新分布需要消耗和一次CREATE TABLE AS SELECT操作相同的时间。 在重新分布一个TB级的表时,扩容工具会使用许多可用的系统资源,这可能会影响查询性能或其他数据库工作负载。
在大规模的Greenplum系统中管理重新分布
在规划重新分布阶段时,要考虑重新分布期间在每个表上取得的ACCESS EXCLUSIVE锁的影响。 一个表上的用户活动可能会延迟它的重新分布,而且表在重新分布期间对用户活动不可用。
可以通过调整ranking来控制表重分布的顺序。 参考表重分布排名。 制定重分布顺序有助于调整有限的磁盘空间,并尽快恢复高优先级查询的最佳查询性能。
表重分布方法
Greenplum数据库扩容的时候有两种方法重分布数据。
- rebuild - 建立一个新表,把所有数据从旧表复制到新表,然后替换旧表。 这是默认行为。rebuild方法和使用CREATE TABLE AS SELECT命令创建一个新表类似。 在数据重分布期间,会在表上加ACCESS EXCLUSIVE锁。
- move - 扫描所有数据并做UPDATE操作来移动需要移动的行到不同节点实例上。 在数据重分布过程中,会在表上加ACCESS EXCLUSIVE锁。 一般来说,这个方法需要更少的磁盘空间,但是它在表里留下了很多被淘汰的行,可能在数据重分布后需要VACUUM操作。 另外,此方法一次更新一行索引,这会使它比使用CREATE INDEX命令重建索引更慢。
磁盘空间充裕的系统
如果系统由充裕的空闲磁盘空间(要求用来存储最大表的一份拷贝),可以通过首先重新分布查询使用最多的重点表来尽快恢复最优的查询性能。 为这些表分配高的排名,并且在系统使用量低的时候安排重新分布操作。 一次运行一个重新分布处理,直到大的或者关键的表被重新分布完。
磁盘空间有限的系统
如果现有的主机磁盘空间有限,可以先重新分布较小的表(例如维度表)来腾出空间存储最大表的一份拷贝。 由于每个表会被重新分布到被扩容后的阵列上,在原始节点上的可用磁盘空间会增加。 当在所有节点上存在足够的空闲空间以存储最大表的一份拷贝后,就可以重新分布大的或者关键的表了。 大表的重新分布要求排他锁,请把这种过程安排在非峰值时段。
还要考虑下面的事情:
- 在非峰值时段运行多个并行的重新分布处理以最大化可用的系统资源。
- 在运行多个处理时,处理的数量不能高于Greenplum系统的连接限制。 有关限制并发连接的信息请见限制并发连接。
重新分布追加优化和压缩过的表
gpexpand以与堆表不同的速率重新分布未压缩和压缩的追加优化表。 压缩和解压数据所需的CPU能力会导致增加对系统性能影响。 对于具有类似数据的类似尺寸的表,可以发现如下的总体性能区别:
- 扩展未压缩的追加优化表比堆表快10%。
- 定义为使用数据压缩的追加优化表以比未压缩的追加优化表的扩展速率更慢,可能慢80%。
- 使用了ZFS/LZJB等数据压缩的系统需要更长时间重新分布。
Important: 如果系统节点使用数据压缩,在新结点上使用相同的压缩来避免磁盘空间短缺。
重新分布分区表
因为该扩展工具可以处理一个大型表上的每个分区,一个有效的分区设计能降低表重新分布的性能影响。 只有一个分区表的子表会不被设置为随机分布策略。 一次只对一个子表应用重新分布所需的读/写锁。
重新分布建有索引的表
因为gpexpand工具必须在重新分布之后重新索引每个被索引的表,一次高级的索引会带来很大的性能影响。 在有很多索引要建立的系统中,表的重新分布要慢很多。