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 的次要个性加强
- 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。