gpexpand分析

程序员文章站 2022-03-07 11:32:48

...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文由maxluo发表于云+社区专栏

一、 gp扩容步骤

1.1 初始化机器

目标：新增加的机器需要初始化和已有机器环境一样。

具体包括不限于以下内容：创建用户名，设置环境变量，创建数据目录，安装greenplum软件包，解压目录路径。

1.2 修改host

集群所有机器（包括已有机器和新扩容机器）的/etc/hosts文件中，增加新扩容机器的host配置。

1.3 修改GP配置文件

具体修改三个文件。

其中allhostlist，seghostlist文件中添加新增机器的host。

新增文件host_expand，并把新增机器的host写入该文件中。

1.4 打通ssh互信登录

执行命令：

/home/gpadmincloud/install/bin/gpssh-exkeys  -f  /home/gpadmincloud/deploy/host_expand

**备注：**host_expand只需是新增加机器的host，而非全部机器HOST。这样也可以实现已有其他机器到新增机器的无密登录。

1.5 生成扩容配置

a) 创建数据库myexpand：执行命令create database myexpand;

作用：用于存储扩容进度等信息。

b) 执行命令，生成配置。gpexpand -f host_expand -D myexpand。

在命令执行过程中，会交互式的让用户确认相关信息。其中一步是确定扩容节点的分布方式。

提示如下：

What type of mirroring strategy would you like?

 spread|grouped (default=grouped):

需要注意的是，这里的分布方式和集群初始化时选择的方式不一定要求一致。也就是说以前机器如果是spread分布，新增加节点既可以是grouped，也可以是spread分布。

对于不同模式，新增机器数量限制如下：

Grouped Mirror： 则新增机器数量必须大于等于2，确保新增加的primary segment节点和mirror segment节点不在同一台机器上。

Spread Mirror: 新增的主机数至少要比每台主机上primary Segment的数量大于1，这样才能确保Mirror可以平均分配在其他的Segment节点上。例如：如果现在单机primary segment数量为3，则新增机器必须大于等于4。

c) 配置文件内容如下：

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:40000:/data/greenplum/primary/gpseg12:27:12:p:41000

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:50000:/data/greenplum/mirror/gpseg12:51:12:m:51000

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:40001:/data/greenplum/primary/gpseg13:28:13:p:41001

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:50000:/data/greenplum/mirror/gpseg13:55:13:m:51000

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:40002:/data/greenplum/primary/gpseg14:29:14:p:41002

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:50000:/data/greenplum/mirror/gpseg14:59:14:m:51000

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:40003:/data/greenplum/primary/gpseg15:30:15:p:41003

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:50000:/data/greenplum/mirror/gpseg15:63:15:m:51000

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:40000:/data/greenplum/primary/gpseg16:31:16:p:41000

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:50001:/data/greenplum/mirror/gpseg16:56:16:m:51001

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:40001:/data/greenplum/primary/gpseg17:32:17:p:41001

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:50001:/data/greenplum/mirror/gpseg17:60:17:m:51001

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:40002:/data/greenplum/primary/gpseg18:33:18:p:41002

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:50001:/data/greenplum/mirror/gpseg18:64:18:m:51001

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:40003:/data/greenplum/primary/gpseg19:34:19:p:41003

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:50000:/data/greenplum/mirror/gpseg19:47:19:m:51000

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:40000:/data/greenplum/primary/gpseg20:35:20:p:41000

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:50002:/data/greenplum/mirror/gpseg20:61:20:m:51002

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:40001:/data/greenplum/primary/gpseg21:36:21:p:41001

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:50002:/data/greenplum/mirror/gpseg21:65:21:m:51002

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:40002:/data/greenplum/primary/gpseg22:37:22:p:41002

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:50001:/data/greenplum/mirror/gpseg22:48:22:m:51001

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:40003:/data/greenplum/primary/gpseg23:38:23:p:41003

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:50001:/data/greenplum/mirror/gpseg23:52:23:m:51001

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:40000:/data/greenplum/primary/gpseg24:39:24:p:41000

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:50003:/data/greenplum/mirror/gpseg24:66:24:m:51003

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:40001:/data/greenplum/primary/gpseg25:40:25:p:41001

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:50002:/data/greenplum/mirror/gpseg25:49:25:m:51002

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:40002:/data/greenplum/primary/gpseg26:41:26:p:41002

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:50002:/data/greenplum/mirror/gpseg26:53:26:m:51002

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:40003:/data/greenplum/primary/gpseg27:42:27:p:41003

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:50002:/data/greenplum/mirror/gpseg27:57:27:m:51002

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:40000:/data/greenplum/primary/gpseg28:43:28:p:41000

sdw4-xx-41ma83j3:sdw4-xx-41ma83j3:50003:/data/greenplum/mirror/gpseg28:50:28:m:51003

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:40001:/data/greenplum/primary/gpseg29:44:29:p:41001

sdw5-xx-41ma83j3:sdw5-xx-41ma83j3:50003:/data/greenplum/mirror/gpseg29:54:29:m:51003

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:40002:/data/greenplum/primary/gpseg30:45:30:p:41002

sdw6-xx-41ma83j3:sdw6-xx-41ma83j3:50003:/data/greenplum/mirror/gpseg30:58:30:m:51003

sdw8-xx-41ma83j3:sdw8-xx-41ma83j3:40003:/data/greenplum/primary/gpseg31:46:31:p:41003

sdw7-xx-41ma83j3:sdw7-xx-41ma83j3:50003:/data/greenplum/mirror/gpseg31:62:31:m:51003

1.6 初始化sgment并加入集群

1.6.1 执行命令

gpexpand -i gpexpand_inputfile_20180815_210146 -D myexpand

gpexpand_inputfile_20180815_210146 文件为在步骤1.5中生成的扩容配置文件。

1.6.2 异常处理

这里经常会出现问题，需要输入gpexpand -r -D gpexpand让你回滚扩容操作，但是此时数据库关闭了，并且不能直接用gpstart启动。

因此先执行gpstart –R 启动数据库。再执行gpexpand -r -D myexpand命令进行回滚操作。

回滚成功后，再按照1.6.1步骤，进行segment初始化。

1.7 重分布表

执行命令

gpexpand -D myexpand

该命令会对所有的数据库和表进行重分布。按照对应表的分布键，把数据打散到各个节点，包括新增加的机器。从而实现了扩容操作。

1.8 临时数据清理

执行命令：

gpexpand -c -D myexpand

该命令会对步骤1.6中在myexpand数据库中生成的schema进行清理。

二、扩容原理分析

gpexpand命令对集群扩容的原理：首先把新增HOST节点添加到master元表。并按照步骤1.5生成的配置对各机器segment初始化和启动操作。

最后执行alter table操作。

ALTER TABLE ONLY  xx   SET WITH(REORGANIZE=TRUE) DISTRIBUTED by(xx )。

该操作会导致greenplum对表数据进行重分布。从而实现把原集群数据打散分布到新集群中。

2.1 初始化过程分析

在步骤1.6中，执行gpexpand -i gpexpand_inputfile_20180815_210146 -D myexpand对扩容节点初始化。

完成事情有如下三步：

1，把新增加的节点加入到master元素表中。可以通过select * from gp_segment_configuration order by dbid asc;查询到新节点已经被加入到集群中，但新增加节点暂时没有数据。

2，在myexpand数据库中，创建名为gpexpand的schema，这个schema用于保存扩展的所有信息，例如每个表重分布的进度等详细信息。

Status表用于记录扩容进度信息。

 myexpand=# select  * from gpexpand.status;

      status       |          updated           

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

SETUP             | 2018-09-18 11:17:29.807489

SETUP DONE        | 2018-09-18 11:17:35.294699

EXPANSION STARTED | 2018-09-18 11:18:02.816792

expansion_progress记录数据库表重分布速度等信息。

myexpand=# select  * from gpexpand.expansion_progress;

             name             |         value         

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

Bytes Done                   | 53412116448

Estimated Time to Completion | 00:16:55.504644

Tables In Progress           | 1

Bytes Left                   | 59420929408

Bytes In Progress            | 142668912

Tables Left                  | 229

Tables Expanded              | 498

Estimated Expansion Rate     | 55.9369898011315 MB/s

status_detail表记录各个表的重分布过程以及进度。

myexpand=# select  distinct(status) from gpexpand.status_detail where dbname='gpadmincloud';

   status    

\-------------

COMPLETED

NOT STARTED

IN PROGRESS

3，将数据库中的所有表全部修改为随机分布（DISTRIBUTED RANDOMLY），这个状态会在步骤1.7中采用alter方式修改回来。同时会把以前的分布键保存在gpexpand.status_detail中，供后面数据重分布恢复分布键。

修改SQL为：UPDATE gp_distribution_policy SET attrnums = NULL ，通过对数据字典表gp_distribution_policy修改分布键。这种方式避免了数据的重分布。

2.2 数据重分布

在步骤1.7中，命令后gpexpand -D myexpand。会对每一张表执行命令。

ALTER TABLE ONLY t1 SET WITH(REORGANIZE=TRUE) DISTRIBUTED byxxx)。把初始化过程中修改为随机分布的表进行还原。Alter命令会对所有数据重分布。从而实现历史数据分散到所有节点（包括新扩容节点）。

三、扩容性能分析

3.1 原始数据

3.1.1 100G数据

机器配置：

Segment配置：4 核 16 GB 160GB SSD云盘。

Master规格	扩容目标	耗时（分钟）
2核 8GB	3->6	19

3.1.2 300GB数据

机器配置：

Segment配置：4 核 16 GB 160G SSD云盘。

Master规格	扩容目标	耗时（分钟）
4 核 8 GB	5->8	30
4 核 16 GB	8->12	23
4 核 16 GB	12->16	18.5

3.1.3 600GB数据

机器配置：

Segment配置：8 核 32 GB 320G SSD云盘。

Master规格	扩容目标	耗时（分钟）
4 核 8 GB	10->16	36
4 核 16 GB	16->24	22.5
4 核 16 GB	24->32	17.3

3.1.4 1TB数据

机器配置：

Segment配置：8 核 32 GB 640G SSD云盘。

Master规格	扩容目标	耗时
4 核 8 GB	20->40	31.7
4 核 16 GB	40->60	20.5

3.2 结论

1，同样的数据量，节点越多，扩容速度越快。

2，同样的节点数，扩容速度基本上和数据量成反比。

四、常见问题小结

1，执行命令gpexpand，出现Cannot allocate memory 。

原因： master节点内存不足。

解决办法：升级master节点内存数量，或者替换master机器。

最主要是提前规划好master节点规格，包括CPU和内存。

2，执行扩容过程中，已有链接是否会断开？

答：会。

原因：在步骤1.6过程中，需要重启Greeplum集群。所以已有链接会出现断开情况。

解决办法：业务方重新链接即可。

3，重分布过程，数据库是否可用，只读 or 可读可写？

答：可用，可读可写。

原因：

gpexpand是采用表重分布方式来对集群扩容。对于已经重分布的表，则新写入的数据则根据分布键，按规则放置在不同节点。

如果是对还未重分布的表进行写入数据，则这些新写入的数据，按照随机分布方式，分布到各个节点（也包括新增加的机器节点）。最后在执行alter 操作修改分布键时，数据重分布到所有其他节点。

相关阅读
【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识

此文已由作者授权腾讯云+社区发布，更多原文请点击

搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！

海量技术实践经验，尽在云加社区！

gpexpand分析

一、 gp扩容步骤

1.1 初始化机器

1.2 修改host

1.3 修改GP配置文件

1.4 打通ssh互信登录

1.5 生成扩容配置

1.6 初始化sgment并加入集群

1.6.1 执行命令

1.6.2 异常处理

1.7 重分布表

1.8 临时数据清理

二、扩容原理分析

2.1 初始化过程分析

2.2 数据重分布

三、扩容性能分析

3.1 原始数据

3.1.1 100G数据

3.1.2 300GB数据

3.1.3 600GB数据

3.1.4 1TB数据

3.2 结论

四、常见问题小结

并发编程之ThreadLocal源码分析

C#索引属性用法实例分析

jquery实现动态改变css样式的方法分析

Windows环境下的MYSQL5.7配置文件定位图文分析

一个mysql死锁场景实例分析

jQuery实现为动态添加的元素绑定事件实例分析

设计模式之构建(Builder)模式建造房子实例分析

Java UrlRewriter伪静态技术运用深入分析

MySQL慢查询之pt-query-digest分析慢查询日志

ES6 Promise对象的含义和基本用法分析

gpexpand分析

一、 gp扩容步骤

1.1 初始化机器

1.2 修改host

1.3 修改GP配置文件

1.4 打通ssh互信登录

1.5 生成扩容配置

1.6 初始化sgment并加入集群

1.6.1 执行命令

1.6.2 异常处理

1.7 重分布表

1.8 临时数据清理

二、 扩容原理分析

2.1 初始化过程分析

2.2 数据重分布

三、 扩容性能分析

3.1 原始数据

3.1.1 100G数据

3.1.2 300GB数据

3.1.3 600GB数据

3.1.4 1TB数据

3.2 结论

四、 常见问题小结

并发编程之ThreadLocal源码分析

C#索引属性用法实例分析

jquery实现动态改变css样式的方法分析

Windows环境下的MYSQL5.7配置文件定位图文分析

一个mysql死锁场景实例分析

jQuery实现为动态添加的元素绑定事件实例分析

设计模式之构建(Builder)模式 建造房子实例分析

Java UrlRewriter伪静态技术运用深入分析

MySQL慢查询之pt-query-digest分析慢查询日志

ES6 Promise对象的含义和基本用法分析

二、扩容原理分析

三、扩容性能分析

四、常见问题小结

设计模式之构建(Builder)模式建造房子实例分析