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

应用实例

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

2019-07-19

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的主要特性增强

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

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版本增强方面主要包括如下内容：

ANALYZE命令改进，性能有极大提升
UUID和JSON等新数据类型的支持
匿名代码块的支持
其他伴随PostgreSQL版本升级带来的新特性等
Resource Group资源组的引入，可以更精确的控制资源使用效率
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。