Greenplum版本4到5升级“避坑”指南

Greenplum数据平台即将发布下一个大版本Greenplum 6,Greenplum 5也已经迭代到5.20+了。Greenplum 5目前已经进入稳定期和维护期。在不久的将来,Greenplum 4将逐渐结束生命周期,Greenplum 5将是Pivotal主要维护的版本。同时,Pivotal从Greenplum 5开始对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的默认优化器

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

set optimizer to off;

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

2. 转义符

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

set standard_conforming_strings=off

3. Text类型隐式转换

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. 外部表错误记录

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

gp_read_error_log('$external_table')
gp_truncate_error_log('$external_table')

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

5. 数据类型变化

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

6. Greenplum 5特性增强

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

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

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

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版本。

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


Greenplum作为全球最知名的开源MPP数据库,被Gartner评为全球排名第三的分析型数据库和排名第四的实时分析数据库。想参加Greenplum 首场公开培训活动?扫描下面二维码报名吧!

“Greenplum版本4到5升级“避坑”指南”的一个回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注