获得Greenplum更多干货内容,欢迎前往Greenplum中文社区网站

Greenplum大数据分析平台 6版本 已经于2019年9月4号在 Greenplum 用户大会上正式发布了,Greenplum 5 已经进入稳定期和维护期,在不久的将来,Greenplum 4 将逐渐结束生命周期。同时,从 5版本,Greenplum 持续对 PostgreSQL 内核进行升级,新的PostgreSQL内核将带来更多的功能和性能的体验。因此从用户长期使用和维护Greenplum的角度来说,升级是不可避免的。

在本文中,我们分两个部分来介绍 Greenplum 4 升级到 Greenplum 5 的经验分享:

  • Greenplum 5 相对于 Greenplum 4 的主要特性增强
  • Greenplum 4 到 Greenplum 5 版本升级过程中可能遇到的问题以及如何解决

一、Greenplum 5相对于Greenplum 4的主要特性增强

  1. ORCA默认优化器
  2. 转义符
  3. Text类型隐式转换
  4. 外部表错误记录
  5. 数据类型变化
  6. 功能增强

1. ORCA成为Greenplum 5的默认优化器

7.14 01.png

在Greenplum 5中 ORCA 成为默认的优化器。ORCA是Pivotal历经多年研发的新一代查询优化器,在多表关联,复杂分区表,复杂查询等场景更有优势。经用户生产验证,ORCA开启的情况下,查询性能有显著的提升。当然,目前ORCA并不能完全替代legacy优化器,SQL的复杂情况是各种各样的,在少数场景,可能legacy优化器会表现的更好,有时我们需要通过设置参数显式的在SQL中关闭ORCA,就像这样:

set optimizer to off;  

当然,您也可以把这样的设置包在一个function中,也可以在View中调用这个function,这样都可以使得设置在SQL中生效。

2. 转义符

7.14 02.png

关于转义符,在Greenplum 5之前,字符串内的反斜线[\]缺省被作为转义符,而从Greenplum 5开始,为了遵循更规范的PostgreSQL标准,字符串内的反斜线缺省将作为字符本身对待,除非您使用[E’…’]这样的格式以明确指定字符串内进行转译。您还可以通过如下操作使得数据库与之前版本表现一致,但我们并不建议你这样做:

set standard\_conforming\_strings=off

3. Text类型隐式转换

7.14 03.png

Text类型隐式转换,这可能是Greenplum 5升级过程中对现有语句影响最为广泛的变化,在Greenplum 5发布初期,我们也探索过创建一些Operator以兼容以前版本的隐式类型转换,但是,我们需要明确强调的是,我们不推荐这么做,明确的类型匹配将有利于避免难以发现的潜在BUG,因为有时候,一些类型的隐式转换会导致匹配失效,这种问题往往是难以发现的。

不过,在实施过程中,我们发现,有些类型转换的场景可以通过补充一些Function来解决,比如:

create or replace function substr(numeric, integer,integer )returns text as $$  
select substr($1::text,$2,$3);  
$$ language sql IMMUTABLE strict;  
​  
create or replace function pg\_catalog.btrim(str numeric) returns text as $$  
return $\_\[0\];  
$$ language plperl IMMUTABLE strict;  
  
create or replace function to\_date(timestamp, text) returns date as $$  
select to\_date($1::text,$2);  
$$ language sql IMMUTABLE strict;  
  
create or replace function to\_date(integer, text) returns date as $$  
select to\_date($1::text,$2);  
$$ language sql IMMUTABLE strict;

而有些场景将难以避免的需要修改SQL以适应Greenplum 5的特点。所以,在Greenplum 5之前,我们需要进行必要的测试验证,以确保所有的SQL都可以在Greenplum 5正常运行,虽然这个验证的工作量可能不会很大,但是很有必要。

4. 外部表错误记录

7.14 04.png

外部表方面,Greenplum 5做了一些改变,不再支持[INTO error_table]子句,因为这种模式不是ACID安全的,在我们以往的工作中也的确遭遇过并发外部表共用同一个error table时发生偶发性的报错。取而代之的对于error数据处理的是两个函数:

gp\_read\_error\_log('$external\_table')  
gp\_truncate\_error\_log('$external\_table')

7.14 05.png

所以,在升级时,需要对使用外部表的脚本进行修改,以适应新的模式。

5. 数据类型变化

7.14 06.png

7.14 07.png

在5版本中,对数字类型进行了优化,主要是存储格式方面的改变和性能提升,所以,在升级中,数字类型的分布键的分布规律会发生变化,这也是我们不建议使用备份恢复的方式升级的一方面原因。我们推荐的升级方式是,跨库传输数据,即,新建一个Cluster,然后将ddl恢复到新的Cluster,再将数据跨集群传输过去,以完成升级过程。

6. Greenplum 5 特性增强

Greenplum 5版本增强方面主要包括如下内容:

  1. ANALYZE命令改进,性能有极大提升
  2. UUID和JSON等新数据类型的支持
  3. 匿名代码块的支持
  4. 其他伴随PostgreSQL版本升级带来的新特性等
  5. Resource Group资源组的引入,可以更精确的控制资源使用效率
  6. PXF的引入,增强了Hadoop集成的能力

7.14 08.png

7.14 09.png

7.14 10.png

7.14 11.png

二、Greenplum 4到Greenplum 5版本升级中可能遇到的问题以及如何解决

7.14 12.png

7.14 13.png

1. 难以原地升级

由于4版本和5版本在底层数据方面已经发生了很大的变化,官方并未提供任何的升级工具,所以,我们在实践中就更难以做到原地平滑升级,而是需要重建一个新集群来完成升级目标。

因此我们要尽可能避免原地升级的模式,也就是说,我们要尽可能保持原有Cluster不动,只有这样,我们才有足够的信心面对任何可能性的发生。当然,如果老的Cluster有足够的容量空间,可以在同一套物理设备上建立一个新版的Cluster进行升级。不过,这种模式,也不推荐,这种模式下,将无法完全抛弃原有设备的包袱,比如,操作系统版本陈旧等问题,无法在升级中得到解决。

2. TEXT隐式转换问题

升级过程中经常遇到的一个问题是TEXT隐式转换问题会导致较多的SQL出现报错现象。

关于TEXT隐式转换的问题,建议在正式进行升级迁移之前,做足测试调整,确保所有SQL都能够顺利的在Greenplum 5运行。可以将生产的ddl备份出来,恢复到5版本的测试环境,将全部的业务SQL在Greenplum 5环境进行测试,并固定修改后的版本,为正式升级做好准备。

3. 外部表的 Error 表语法不再支持

外部表的Error表语法不再支持所以,原有的外部表的加载脚本不能继续使用。外部表的Error表问题,也需要进行测试和修改,确保所有关于外部表的脚本可以在5版本正确执行。不建议打开gp_ignore_error_table参数,如果使用了这个参数,只是将问题延后,并不是解决,以后还会再次面对这个问题。

4. Catalog 问题

原有运行时间很久的老系统可能存在诸多的Catalog问题,这样的话,如果使用pg_dump进行ddl备份可能会有不可预测的异常信息。

对于Catalog有问题的系统,我们不建议解决这些问题,可能会有很多很多的问题需要解决,而且,可能面对的是超过服务期的版本,所以,我们建议使用兼容异常Catalog的ddl备份工具进行备份,比如gpddlbackup+gpddlrestore。

5. 数据迁移

gptransfer命令由于固有的设计缺陷,无法满足大批量数据迁移的需要。对于4.3.26+版本,可以考虑使用gpcopy,其他版本可以使用gpdbtransfer命令,这是一个兼容所有4.2、4.3和5.x版本的命令。

在4.3.26版本之前,无法使用gpcopy命令做数据迁移,而升级4.3版本到最新小版本也存在一定的风险。

gpdbtransfer命令目前已经经过多次生产升级验证,易用性,性能,稳定性,都经过了大规模的验证。对于无法使用gpcopy的版本,不建议做版本升级以期使用gpcopy命令,升级总是有一定的风险,既然已经要升级到5版本,最好不要再动现有Cluster。

6. 慎用备份恢复方案

备份恢复方案不是万能方案,gpcrondump备份可能会失败,而且,即便gpcrondump成功了,gpdbrestore也可能会失败。

使用gpmcbackup和gpmcrestore也是可以尝试的,毕竟,这一套命令是表隔离的,可以确保单个表的备份或者恢复的失败不会影响其他表。如果你很熟悉这套命令,可以尝试,否则,也还是建议同步数据以完成升级。

7. 升级后的运维管理

升级之后,由于Greenplum 4到Greenplum 5有很多的特性发生了变化,无法避免的是有些SQL可能会有些问题,即便已经做足了SQL兼容性测试,但毕竟测试与生产有一定的差异,而且,语法无误也不等于运行就一切顺畅,可能还会有执行计划不够优化等问题存在,所以,强烈建议升级之后,结合配套的gpcc版本,做好实时的SQL执行监控,及时诊断执行时间过长的SQL的实时执行计划,帮助我们尽快发现问题并找到解决方法。

三、数据迁移工具 gpdbtransfer

gpdbtransfer是Pivotal资深工程师陈淼开发的Greenplum数据迁移工具。下图是gpdbtransfer命令的工作原理图,命令支持任意规模的不同集群,支持任意4.2、4.3版本和5版本。

7.14 14.png

7.14 15.png

7.14 16.png

关于gpdbtransfer的详细信息,请参阅https://github.com/water32

image!


Greenplum
153 声望66 粉丝

Greenplum 是全球领先的开源、多云大数据分析平台,被广泛运用于大规模商业智能和分析中,具有极高的稳定性。