gpexpand分析
欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~
一、 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 操作修改分布键时,数据重分布到所有其他节点。
此文已由作者授权腾讯云+社区发布,更多原文请点击
搜索关注公众号「云加社区」,第一时间获取技术干货,关注后回复1024 送你一份技术课程大礼包!
海量技术实践经验,尽在云加社区!
gpexpand分析的更多相关文章
- alias导致virtualenv异常的分析和解法
title: alias导致virtualenv异常的分析和解法 toc: true comments: true date: 2016-06-27 23:40:56 tags: [OS X, ZSH ...
- 火焰图分析openresty性能瓶颈
注:本文操作基于CentOS 系统 准备工作 用wget从https://sourceware.org/systemtap/ftp/releases/下载最新版的systemtap.tar.gz压缩包 ...
- 一起来玩echarts系列(一)------箱线图的分析与绘制
一.箱线图 Box-plot 箱线图一般被用作显示数据分散情况.具体是计算一组数据的中位数.25%分位数.75%分位数.上边界.下边界,来将数据从大到小排列,直观展示数据整体的分布情况. 大部分正常数 ...
- 应用工具 .NET Portability Analyzer 分析迁移dotnet core
大多数开发人员更喜欢一次性编写好业务逻辑代码,以后再重用这些代码.与构建不同的应用以面向多个平台相比,这种方法更加容易.如果您创建与 .NET Core 兼容的.NET 标准库,那么现在比以往任何时候 ...
- UWP中新加的数据绑定方式x:Bind分析总结
UWP中新加的数据绑定方式x:Bind分析总结 0x00 UWP中的x:Bind 由之前有过WPF开发经验,所以在学习UWP的时候直接省略了XAML.数据绑定等几个看着十分眼熟的主题.学习过程中倒是也 ...
- 查看w3wp进程占用的内存及.NET内存泄露,死锁分析
一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方 ...
- ZIP压缩算法详细分析及解压实例解释
最近自己实现了一个ZIP压缩数据的解压程序,觉得有必要把ZIP压缩格式进行一下详细总结,数据压缩是一门通信原理和计算机科学都会涉及到的学科,在通信原理中,一般称为信源编码,在计算机科学里,一般称为数据 ...
- ABP源码分析一:整体项目结构及目录
ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module ...
- HashMap与TreeMap源码分析
1. 引言 在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Ja ...
随机推荐
- MySQL查询练习(45道)
题目:设有一数据库,包括四个表:学生表(Student).课程表(Course).成绩表(Score)以及教师信息表(Teacher). 四个表的结构分别如表1-1的表(一)~表(四)所示,数据如表1 ...
- day05_雷神_函数进阶
#day05 1.迭代器 1.1可迭代对象 str,list,tuple,dict,set,range,文件句柄 等都是可迭代对象 第一种方法:在该对象中,含有__iter__方法的就是可迭代对象,遵 ...
- ORACLE EBS常用表
http://www.cnblogs.com/quanweiru/archive/2012/09/26/2704628.html call fnd_global.APPS_INITIALIZE(131 ...
- Delphi程序带参数运行
程序1 program E1; uses Forms,Dialogs,SysUtils, EndM1 in 'EndM1.pas' {Form2}; {$R *.res} begin Applicat ...
- MAC系统下用Idea创建spring boot工程 基于maven
1.创建项目 打开idea编辑器,选择file -> new -> project 点击next 依次填入group,artifact 填写完成之后再点击“next” 根据自己的需求在最 ...
- 第一章 在.net mvc生成EF入门
一. 打开Visual Studio 2017(我使用的是2017) 新建一个mvc项目 命名为StudentEntity 二.1)建立完项目后在项目中右击选择新建项,找到ADO.NET实体数据模型 ...
- 迁移桌面程序到MS Store(6)——.NET Portability Analyzer
上一篇我们简单介绍了.NET Standard,本篇我们来实践.NET Framework 4.5 Class Library到.NET Standard 2.0的转换. 首先让我们来做 ...
- python项目飞机大战
实现步骤 1.创建窗口 2.创建一个玩家飞机,按方向键可以左右移动 3.给玩家飞机添加按空格键发射子弹功能 4.创建一个敌机 5.敌机自动左右移动 6.敌机自动发射子弹 1.创建窗口 import p ...
- day02 基本数据类型与运算符
day02 1.基本数据类型 2.算术运算符 +,-,*,/,%,++,-- 3.赋值运算符 =,+=,-=,*=,/=,%= 4.关系运算符 +=,-=,*=,/=,%= 结果是boolean类型 ...
- Select count(*)、Count(1)、Count(0)的区别和执行效率比较
记得很早以前就有人跟我说过,在使用count的时候要用count(1)而不要用count(*),因为使用count(*)的时候会对所有的列进行扫描,相比而言count(1)不用扫描所有列,所以coun ...