合 扩容Greenplum系统(增加segment节点)相关理论
Tags: GreenPlumscale out(横向扩展)scale up(纵向扩展)扩容增加节点理论
- 简介
- 系统扩容概述
- 规划Greenplum系统扩容
- 系统扩容检查列表
- 规划新的硬件平台
- 规划新Segment初始化
- 规划Mirror节点
- 对每个主机增加新节点
- 关于扩容Schema
- 规划表的重新分布
- 在大规模Greenplum系统中管理重新分布
- 表重分布方法
- 磁盘空间充裕的系统
- 磁盘空间有限的系统
- 重新分布追加优化和压缩过的表
- 重新分布分区表
- 重新分布建有索引的表
- 准备并增加节点
- 增加新结点到受信主机环境
- 用root交换SSH密钥
- 创建gpadmin用户
- 使用gpadmin用户交换SSH密钥
- 验证OS设置
- 运行gpcheck
- 确认磁盘I/O和内存带宽
- 运行gpcheckperf
- 整合新硬件到系统中
- 初始化新节点
- 为系统扩容创建一个输入文件
- 在交互模式中创建一个输入文件
- 在交互模式中创建一个输入文件
- 扩容输入文件格式
- 运行gpexpand初始化新节点
- 用一个输入文件运行gpexpand
- 回滚一个失败的扩容设置
- 监控集群扩容状态
- 重分布表
- 表重分布排名
- 使用gpexpand重分布表
- 使用gpexpand重分布表
- 监控表的重分布
- 查看扩容状态
- 查看表状态
- 移除扩容Schema
- 移除扩容Schema
- gpexpand命令详解
- 概要
- 先决条件
- 描述
- 选项
- 示例
- 另见
- 监控视图
- gpexpand.status
- gpexpand.status_detail
- gpexpand.expansion_progress
- 参考
简介
为了放大性能和存储能力,通过向集群增加主机来扩容用户的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工具四次。
创建扩容输入文件:
1gpexpand -f hosts_file初始化Segment并且创建扩容schema:
1gpexpand -i input_filegpexpand会创建一个数据目录、从现有的数据库复制表到新的Segment上并且为扩容方案中的每个表捕捉元数据用于状态跟踪。 在这个处理完成后,扩容操作会被提交并且不可撤回。
重新分布表数据:
1gpexpand -d duration在初始化时,gpexpand增加并初始化新节点实例。 必须运行gpexpand在新增节点实例上重分布数据来完成系统扩容。 取决于系统的大小和规模,重新分布可能在一个单一会话中经过数个利用率较低的小时才会完成,或者用户可以把该处理划分成一个长时段上的批处理。 每个表或分区在扩容期间是无法进行读写操作的。 由于每一个表都会被重新分布在新的Segment上,数据库性能应该会逐步提升直到超过扩容前的性能水平。
在需要多个重新分布会话的大型系统中,可能需要多次运行gpexpand来完成扩容。 gpexpand可以从显式的表重新分布排名获益,参考规划表的重新分布。
用户可以在初始化期间访问Greenplum数据库,但是在严重依赖表的哈希分布的系统上,它们可能会出现性能下降。 尽管用户可能会遇到较慢的响应时间,但ETL作业,用户查询和报告等正常操作仍可继续。
移除扩容schema:
1gpexpand -c
规划Greenplum系统扩容
细心的规划将帮助确保一个成功的Greenplum扩容项目。
这一节中的主题将帮助确保用户已经准备好执行一次系统扩容。
- 系统扩容检查列表是一份用户可以用来准备和执行系统扩容处理的检查列表。
- 规划新的硬件平台包括为获得和设置新硬件做规划的内容。
- 规划新Segment初始化提供了有关规划使用gpexpand初始化新的Segment主机的信息。
- 规划表的重新分布提供了有关规划在新Segment主机初始化完以后重新分布数据的信息。
系统扩容检查列表
这个检查列表摘要了一次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
1 2 3 | select * from gpexpand.status; select * from gpexpand.status_detail; select * from 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命令重建索引更慢。
磁盘空间充裕的系统
如果系统由充裕的空闲磁盘空间(要求用来存储最大表的一份拷贝),可以通过首先重新分布查询使用最多的重点表来尽快恢复最优的查询性能。 为这些表分配高的排名,并且在系统使用量低的时候安排重新分布操作。 一次运行一个重新分布处理,直到大的或者关键的表被重新分布完。
磁盘空间有限的系统
如果现有的主机磁盘空间有限,可以先重新分布较小的表(例如维度表)来腾出空间存储最大表的一份拷贝。 由于每个表会被重新分布到被扩容后的阵列上,在原始节点上的可用磁盘空间会增加。 当在所有节点上存在足够的空闲空间以存储最大表的一份拷贝后,就可以重新分布大的或者关键的表了。 大表的重新分布要求排他锁,请把这种过程安排在非峰值时段。
还要考虑下面的事情:
- 在非峰值时段运行多个并行的重新分布处理以最大化可用的系统资源。
- 在运行多个处理时,处理的数量不能高于Greenplum系统的连接限制。 有关限制并发连接的信息请见限制并发连接。
重新分布追加优化和压缩过的表
gpexpand以与堆表不同的速率重新分布未压缩和压缩的追加优化表。 压缩和解压数据所需的CPU能力会导致增加对系统性能影响。 对于具有类似数据的类似尺寸的表,可以发现如下的总体性能区别:
- 扩展未压缩的追加优化表比堆表快10%。
- 定义为使用数据压缩的追加优化表以比未压缩的追加优化表的扩展速率更慢,可能慢80%。
- 使用了ZFS/LZJB等数据压缩的系统需要更长时间重新分布。
Important: 如果系统节点使用数据压缩,在新结点上使用相同的压缩来避免磁盘空间短缺。
重新分布分区表
因为该扩展工具可以处理一个大型表上的每个分区,一个有效的分区设计能降低表重新分布的性能影响。 只有一个分区表的子表会不被设置为随机分布策略。 一次只对一个子表应用重新分布所需的读/写锁。
重新分布建有索引的表
因为gpexpand工具必须在重新分布之后重新索引每个被索引的表,一次高级的索引会带来很大的性能影响。 在有很多索引要建立的系统中,表的重新分布要慢很多。
准备并增加节点
验证用户的新节点已经准备好整合到现有的Greenplum系统中。
要为扩展准备新的系统节点,需要安装Greenplum数据库软件的二进制文件、交换必要的SSH密钥并且运行性能测试。
先在新节点上运行性能测试然后再在所有结点上测试。在所有节点上运行测试时应该让系统离线,这样用户活动就不会使结果失真。
通常来说,当管理员修改了节点网络或者系统中出现其他特殊情况时,用户应该运行性能测试。 例如,如果用户将在两个网络集群上运行扩展后的系统,应在每一个集群上都运行测试。
增加新结点到受信主机环境
新主机必须与现有主机交换SSH密钥,以使Greenplum管理实用程序能够在没有密码提示的情况下连接到所有节点。 使用gpssh-exkeys工具执行两次密钥交换过程。
为了管理便利,第一次作为root执行该过程,然后为管理工具作为用户gpadmin再执行一次。 按顺序执行下列任务:
Note: Greenplum数据库的Segment主机命名习惯是sdwN,其中sdw是一个前缀而N是一个整数(sdw1、sdw2 等等)。 对于具有多个接口的主机,命名习惯是对该主机名追加一个破折号(-)以及数字。 例如,sdw1-1和sdw1-2是主机sdw1的两个接口名。
用root交换SSH密钥
使用用户的阵列中的现有主机名创建一个主机文件以及一个含有新扩展主机名的单独的主机文件。 对于现有的主机,用户可以使用在系统中设置SSH密钥的同一个主机文件。 在这些文件中,列出所有的主机(Master、备份Master和Segment主机),每一行一个主机名但是不要有额外的行或者空白。 如果用户使用的是一个多NIC配置,请使用为一个给定的主机用配置好的主机名交换SSH密钥。 在这个例子中,mdw被配置为有一个NIC,并且sdw1、sdw2和sdw3被配置为有4个NIC:
12345678910111213mdwsdw1-1sdw1-2sdw1-3sdw1-4sdw2-1sdw2-2sdw2-3sdw2-4sdw3-1sdw3-2sdw3-3sdw3-4用root登录Master主机,并且从用户的Greenplum安装中source greenplum_path.sh文件。
12$ su -# source /usr/local/greenplum-db/greenplum_path.sh运行gpssh-exkeys工具引用主机列表文件。例如:
12# gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x/home/gpadmin/new_hosts_filegpssh-exkeys会检查远程主机并且在所有的主机之间执行密钥交换。 在提示时输入root用户的密码。例如:
1***Enter password for root@hostname: <root_password>
创建gpadmin用户
使用gpssh在所有的新Segment主机(如果该用户还不存在)上创建gpadmin用户。 使用用户创建的新主机列表来做密钥交换。例如:
12# gpssh -f new_hosts_file '/usr/sbin/useradd gpadmin -d/home/gpadmin -s /bin/bash'为新的gpadmin用户设置一个密码。 在Linux上,用户可以使用gpssh同时在所有的Segment在主机上做这件事情。例如:
12# gpssh -f new_hosts_file 'echo gpadmin_password | passwdgpadmin --stdin'通过查找gpadmin用户的home目录来验证该用户已经被创建:
1# gpssh -f new_hosts_file ls -l /home
使用gpadmin用户交换SSH密钥
使用gpadmin登入,运行gpssh-exkeys工具并引用主机列表文件。例如:
12# gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x/home/gpadmin/new_hosts_filegpssh-exkeys将会检查远程主机并且在所有的主机之间执行密钥交换。 在提示时输入gpadmin用户的密码。例如:
1***Enter password for gpadmin@hostname: <gpadmin_password>
验证OS设置
使用gpcheck工具来验证用户的阵列中所有的新主机都有正确的OS设置以运行Greenplum数据库软件。
运行gpcheck
使用将要运行Greenplum数据库系统的用户登录master主机(例如:gpadmin)。
1$ su - gpadmin使用用户的新主机的主机文件运行gpcheck工具。例如:
1$ gpcheck -f new_hosts_file
确认磁盘I/O和内存带宽
使用gpcheckperf工具来测试磁盘I/O和内存带宽。
运行gpcheckperf
使用新主机的主机文件运行gpcheckperf工具。 在每一台主机上使用-d选项指定用户想要测试的文件系统。 用户必须对这些目录具有写访问权限。例如:
1$ gpcheckperf -f new_hosts_file -d /data1 -d /data2 -v该工具可能会花长时间来执行测试,因为它需要在主机之间拷贝非常大的文件。 当它完成时,用户将会看到磁盘写、磁盘读以及流测试的摘要结果。
对于划分成子网的网络,用每个子网单独的主机文件重复这个过程。
整合新硬件到系统中
在用新Segment初始化系统之前,先用gpstop关闭系统以防止用户活动使性能测试结果倾斜。 然后,使用包括所有节点(现有的和新加的)的主机文件重复性能测试:
初始化新节点
使用gpexpand工具创建并初始化新节点实例,并创建扩容schema。
第一次用一个合法文件运行gpexpand工具,它会创建并初始化节点实例并创建扩容schema。 这些过程完成后,运行gpexpand检测扩容schema是否被创建,如果成功则做表重分布。
为系统扩容创建一个输入文件
要开始扩容,gpexpand要求一个包含有关新节点和主机信息的输入文件。 如果用户运行gpexpand但不指定输入文件,该工具会显示一个交互式的问讯来收集所需的信息并且自动创建一个输入文件。
如果用户使用交互式问讯创建输入文件,用户可以在问讯提示符中指定一个含有扩容主机列表的文件。 如果用户的平台或者命令shell限制主机列表的长度,使用-f指定主机就是唯一的办法。
在交互模式中创建一个输入文件
在用户运行gpexpand在交互模式中创建一个输入文件之前,确保用户了解:
- 新主机的数量(或者一个主机文件)
- 新主机名(或者一个主机文件)
- 现有主机中使用的镜像策略(如果有)
- 每个主机要增加的Segment数量(如果有)
该工具会基于这些信息、dbid、content ID以及gp_segment_configuration中存储的数据目录值自动生成一个输入文件,并将该文件保存在当前目录中。
在交互模式中创建一个输入文件
使用将要运行Greenplum数据库的用户登录master主机;例如,gpadmin。
运行gpexpand。该工具显示关于如何准备一次扩容操作的消息,并且它会提示用户退出或者继续。
可以选择用-f指定一个主机文件。例如:
1$ gpexpand -f /home/gpadmin/new_hosts_file在交互中,输入Y以继续。
除非用户用-f指定了一个主机文件,用户会被提示输入主机名。 可以输入新扩容主机的主机名组成的由逗号分隔的列表。 不要包括接口主机名。例如:
1> sdw4, sdw5, sdw6, sdw7如果只对现有主机增加节点,在这个提示符处留一个空行。 不要指定localhost或者任何现有的主机名。
输入在用户的系统中使用的镜像策略(如果有)。 选项是spread|grouped|none。默认设置是grouped。
确保用户有足够的主机用于选中的组策略。 更多有关镜像的信息请见规划Mirror节点。
输入要增加的主节点的数量(如果有)。 默认情况下,新主机会被用与现有主机相同数量的主节点初始化。 输入一个大于零的数字可以为每个主机增加节点数量。 用户输入的数字将是在所有主机上初始化的额外节点的数量。 例如,如果现有每个主机当前有两个节点,输入一个值2会在现有主机上多初始化两个节点,而在新主机上会初始化四个节点。
如果用户在增加新的主节点,为这些新的节点输入新的主数据目录的根目录。 不要指定真实的数据目录名称,目录会由gpexpand基于现有数据目录名称自动创建。
例如,如果用户的现有数据目录像下面这样:
12/gpdata/primary/gp0/gpdata/primary/gp1那么输入下面的内容(每一个提示输入一个)来指定两个新的主节点的数据目录:
12/gpdata/primary/gpdata/primary当初始化运行时,该工具会在/gpdata/primary下面创建新目录gp2以及gp3。
如果用户在增加新的镜像节点,为这些新的节点输入新的镜像数据目录的根目录。 不要指定数据目录名称,目录会由gpexpand基于现有数据目录名称自动创建。
例如,如果用户的现有数据目录像下面这样:
12/gpdata/mirror/gp0/gpdata/mirror/gp1输入下面的内容(每一个提示输入一个)来指定两个新的镜像节点的数据目录:
12/gpdata/mirror/gpdata/mirror当初始化运行时,该工具会在/gpdata/mirror下面创建新目录gp2以及gp3。
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信dbaup66,谢谢!