gpexpand分析

头像
腾讯云开发者
    阅读 7 分钟
    1

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

    本文由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 送你一份技术课程大礼包！

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

    云计算
    腾讯云开发者
    21.9k 声望17.3k 粉丝
    « 上一篇
    这样玩云函数路由，让你看起来很高级
    下一篇 »
    智能语音技术的深度解析

    引用和评论

    推荐阅读
    头像
    好礼放送 | 当TDSQL-C遇上大模型，训练营带你玩转AI智能数据分析！

    腾讯云开发者阅读 158

    头像
    【Llama3.1-8B-Instruct】Llama Factory 等部署实战

    阳光的鸡蛋阅读 804

    头像
    KubeSphere 最佳实战：Kubernetes 部署集群模式 Nacos 实战指南

    KubeSphere赞 1阅读 306

    头像
    HyperWrite 团队推出 Reflection 70B：性能吊打GPT-4？

    厚德云阅读 566

    头像
    5分钟搞定PPT：通义AI让你秒变办公达人

    厚德云阅读 506

    头像
    AI界的"小钢炮"：MiniCPM-V 2.6 版本震撼发布！

    厚德云阅读 450

    头像
    一键从想法到上线：Bolt.new重新定义全栈开发流程

    厚德云阅读 414

    0 条评论
    得票最新