ITPub博客

首页 > Linux操作系统 > Linux操作系统 > GREENPLUM介绍之数据库管理(八)- 数据库阵列扩展

GREENPLUM介绍之数据库管理(八)- 数据库阵列扩展

原创 Linux操作系统 作者:LEE_CHAO 时间:2011-04-25 17:11:00 0 删除 编辑
       GREENPLUM是一个share-nothing架构的数据库集群。因此,它的性能可以随着硬件的添加呈线性增长,这也是share-nothing在数据仓库领域的一个重要优势(对比SHARE ALL数据库集群)。但是传统的SHARE-NOTHING架构,在添加新的节点到数据库集群中,需要长时间的停止整个数据库集群服务,这会严重降低整个系统的可用性。GREENPLUM在系统上进行了改良,可以实现准在线扩容,既保证了系统的高可扩展性,又保证了系统的高可用性。
       要向GREENPLUM中添加新的SEGMENT。在添加新的节点前,应该首先是进行系统规划,这是保证系统扩展成功的前提,从而最小化风险和down机时间。扩展节点的过程主要分为三个阶段
首先是添加,测试新的系统平台,进行添加前的准备工作。比如,对于新添加的物理硬件平台主要考虑如下几个方面。机架上是否有足够空间存放新的服务器,电源和冷却系统,以及其它的一些物理因素是否允许新添服务器可以正常工作。是有有足够的网络端口和网线可供新增服务器的使用。现有IP是否可以满足新增服务器的分配需求等等。
        在构建好新的硬件配置后,接下来应该进行系统准备工作,比如在新的服务器上安装操作系统,创建gpadmin用户,构建用户等效性,验证操作系统设置(gpcheckos),对内存和IO(磁盘和网络)进行测试(gpcheckperf),保证它们可以满足要求。
       在完成新系统配置之后,可以进行初始化新的segment。这个工作通过调用工具gpexpand完成。初始化新的segment,首先需要一个配置文件存放关于新的segment和主机信息。这个配置文件可以按照如下格式,根据具体情况自行定义
hostname:port:fselocation:dbid:content:preferred_role:replication_port
比如
sdw5:50011:/gpdata/primary/gp9:11:9:p:53011
sdw5:50012:/gpdata/primary/gp10:12:10:p:53011
sdw5:60011:/gpdata/mirror/gp9:13:9:m:63011
sdw5:60012:/gpdata/mirror/gp10:14:10:m:63011    
      也可以通过调用gpexpand自动生成。既可以使用交互式方式,也可以用指定主机列表文件方式。应该使用gpadmin用户登录主机,运行gpexpand命令。可以使用-f 选项指定新加主机列表。
$ gpexpand -f /home/gpadmin/new_hosts_file
系统提示进行扩展步骤,请选择退出还是继续,选择y表示继续。如果没有使用-f选项,系统提示新增主机的名称是什么,新增的主机名应该使用逗号分开.
> sdw4-1, sdw5-1, sdw6-1, sdw7-1
如果是在存在原有主机上添加新的segment,这部分什么也不用填,直接回车。
接下来,如果存在镜像策略,请指定镜像策略,spread|grouped|none.默认策略是grouped。要保证有足够的主机满足镜像策略。接下来系统提示添加新的primary segment的数量,默认与原有主机一致。如果想添加新的segment,那么这里输入大于0的值。系统会按照这个值在原有主机上添加新的segment,并在新的主机上添加这个值加原有数量的segment。比如原有主机上有2个segment,这个值输入2,那么原有每个主机添加2个segment。新的主机上添加4个segment。接下来指定新增primary segment的目录,gpexpand会自动在指定的目录下创建新的子目录。比如原有的目录是
/gpdata/primary/gp0
/gpdata/primary/gp1
那么在每个提示符下输入
/gpdata/primary
/gpdata/primary
增加两个新的segment。如果有mirror segment存在,系统会提示输入新的mirror目录,规则与添加primary一样。完成所有提示的输入之后,产生的配置文件格式如下
gpexpand_inputfile_yyyymmdd_145134
    接下来用gpexpand结合配置文件进行初始化操作,调用如下命令
    $ gpexpand -i input_file -D database1
这个命令会在指定的数据库(-D选项,如果不用-D选项,则由PGDATABASE环境变量决定。)创建expansion schema。这个schema中包含两张表和视图用来跟踪扩展过程
gpexpand.status
gpexpand.status_detail
gpexpand.expansion_progress
通过修改gpexpand.status_detail,我们可以对数据平衡进行控制。比如修改rank列的值,可以改变表的平衡顺序,决定哪些表的数据先平衡,哪些表的数据后平衡。在系统比较忙的时候,不进行数据平衡等等。比如
=> UPDATE gpexpand.status_detail SET rank= 10;
UPDATE gpexpand.status_detail SET rank=1 WHERE fq_name = ‘public.lineitem’;
UPDATE gpexpand.status_detail SET rank=2 WHERE fq_name = ‘public.orders’;
rank值越低,优先级越高,通过调整表的平衡顺序,DBA可以限制数据重新平衡对磁盘空间的消耗,以及尽快恢复查询性能。在创建expansion schema的过程中,整个数据库服务会重启,因此数据库服务会有短暂的停止。并且这个过程中,它会检测是否有expansion schema存在,如果有必须先删除,才能进行新的创建。如果遇到故障,可以调用
gpexpand --rollback -D database_name 进行回滚。
    接下来,系统再次联机后,创建的新表或者新分区,将会跨越所有segment。即使原有表的数据没有重新分布到所有segment,查询也会用到这些segment。为了保证系统的性能最优,DBA需要进行对原有表中的数据进行重新条带化,使其均匀分布到所有segment。这可以调用命令gpexpand去实现。比如
$ gpexpand -d 60:00:00
定义连续使用60个小时进行存在表的数据平衡。在进行平衡的过程中,正在进行平衡的表将会被锁定,不能对其进行读写操作。每次平衡表的会话启动或者结束,这个工具会对gpexpand.status中的状态和时间信息进行更新。这个命令直到所有表平衡完成或者指定的时间或者周期到达,才会结束。因此,通过查询gpexpand.expansion_progress,我们可以了解到数据平衡进度的汇总情况。比如
=# select * from gpexpand.expansion_progress;
name | value
------------------------------+-----------------------
Bytes Left | 5534842880
Bytes Done | 142475264
Estimated Expansion Rate | 680.75667095996092 MB/s
Estimated Time to Completion | 00:01:01.008047
Tables Expanded | 4
Tables Left | 4
(6 rows)
如果要查询特定表的平衡情况,可以查询gpexpand.status_detail获取,比如
=> SELECT status, expansion_started, source_bytes FROM gpexpand.status_detail WHERE fq_name = ‘public.sales’;
status | expansion_started | source_bytes
-----------+----------------------------+--------------
COMPLETED | 2009-02-20 10:54:10.043869 | 4929748992
(1 row)

在进行表数据重新平衡时,GP采用类似CTAS(CREATE TABLE AS SELECT)方式进行,所以DBA应该根据存储尺寸考虑表数据的平衡策略。一般的建议是,如果有足够的存储空间(可以存放最大表数据的拷贝),通常应该先平衡最重要的表,以及查询负载比较重的表,为他们分配较高的级别,而且应该尽量选择系统负载较低的周期进行这些操作,并且采用串行方式进行表数据的平衡。如果空闲空间有限,我们可能倾向优先平衡较小的表,这样可以为平衡较大的表节省空间。如果有足够的维护时间窗口,我们也可以用通过并行方式使用全部系统资源进行数据的重新平衡。
       对于AOT和压缩表,由于数据需要先解压,在压缩,因此会对系统产生性能上的影响,增加CPU负载。一般会有这样的规律,没有压缩的AOT表扩展速度比普通表会快10%。采用zlib格式的AOT压缩表会比未压缩的AOT表的扩展速度显著下降,最严重可能会下降80%。如果文件系统是ZFS/LZJB,并采用了文件系统的压缩,数据重新分布会更慢。
       另外,数据分布时还要考虑主键,索引,用户自定义类型的影响。所有表的数据分布策略都会改成随机分布模式,所以有可能导致高度依赖HASH分布策略表的访问性能下降。对于这样的表,干脆从expansion schema中删掉其相关信息,利用CTAS重新建表,并删除原表,并对新表进行更名。
       完成数据重新分布后,应该删除expansion schema,保证下次扩展的顺利进行。这可以以gpadmin用户身份调用$ gpexpand -c命令实现。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25548387/viewspace-693688/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-03-18

  • 博文量
    70
  • 访问量
    379677