实战系列Greenplum-版本4到5升级避坑指南

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 的默认优化器

在 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。