任何系统的升级都有个量变到质变的过渡：版本相差小的时候，通常很简单，版本相差大的时候，就是一场噩梦。不过版本相差小的时候，大伙儿往往安于现状。本文实际记录从GP4.2.7.2到4.3.5.0的升级过程，从版本号看相差不大，但是GP的版本命名中，第二位的变化就已经是大升级了。另需说明的是，本文升级的GP数据库规模不小，用户较多，管理混沌，在加上GP实在是有点儿脆弱（相比oracle等），所以遇到了较多元数据问题（请参加前4篇）。
起点
- 数据库版本：Greenplum Database 4.2.7.2 build 1（PostgreSQL 8.2.15）
- 自定义函数：$GPHOME/lib有使用uuid-1.6.2.tar.gz编译的oracle自定义函数
- 没有append-only tables
- ETL里有使用external tables
- 没有使用extensions，但安装了pljava和plr，没有安装madlib
- 图形管理界面版本：Greenplum Command Center 1.2.0.1 build 2
- 有standby master，有mirror
目标
- 数据库版本：Greenplum Database 4.3.5.0 build 1（PostgreSQL 8.2.15）
- 图形管理界面版本：Greenplum Command Center 1.3.0.0 build 91
准备
介质
- GP数据库服务器：greenplum-db-4.3.5.0-build-1-RHEL5-x86_64.zip
- GP管理图形界面：greenplum-cc-web-1.3.0.0-build-91-RHEL5-x86_64.zip
- ETL需要的gpfdist工具包：greenplum-connectivity-4.3.5.0-build-1-WinXP-x86_32.msi和greenplum-loaders-4.3.5.0-build-1-WinXP-x86_32.msi
- R语言扩展包：plr-ossv8.3.0.15_pv2.1_gpdb4.3orca-rhel5-x86_64.gppkg
- Java语言扩展包：pljava-ossv1.4.0_pv1.2_gpdb4.3orca-rhel5-x86_64.gppkg
- Madlib扩展包：madlib-ossv1.7.1_pv1.9.3_gpdb4.3orca-rhel5-x86_64.tar
- 预估升级时间的脚本：estimate_42_to_43_migrate_time.zip
- Oracle兼容包的源代码和编译发布步骤：uuid-1.6.2.tar.gz
时间估计
登录master节点，上传并解压estimate_42_to_43_migrate_time.zip，得到estimate_42_to_43_migrate_time.sql，切换到gpadmin用户
$ psql -d databasename -f estimate_42_to_43_migrate_time.sql
$ psql -d databasename -c "select estimate_42_to_43_migrate_time();"
WARNING: "work_mem": setting is deprecated, and may be removed in a future release.
estimate_42_to_43_migrate_time
-----------------------------------------------------------------------------------------------------------------------------
---------------------------------------
estimate_42_to_43_migrate_time() version: 0.3 run at 2015-05-07 13:52:48
GPDB version: PostgreSQL 8.2.15 (Greenplum Database 4.2.7.2 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.4.2 compiled on Feb 25 2014 18:05:04
Database: databasename
Number of primary segments: 88
Num of AO objects: 0
Num of heap objects: 102593
Estimated migrate time: 01:07:14
(7 rows)如果有多个数据库，需要针对每个数据运行上面的脚本，并加和时间。
文件备份
通知所有数据库用户备份自己copy到服务器上的文件
数据一致性检查
这一检查非常重要，虽然官方文档上写的是推荐，但是只要存在错误，基本上就不能升级了，必须想办法解决。官方文档上写的“a few weeks”之前执行这一操作的建议，非常必要，GP库到了一定量级，错误几乎是必然的，解决这些错误真的是要花费以星期计的时间。
- 使用GP管理员用户登陆master
- 重启数据到restricted mode
$ gpstop -M fast
$ gpstart -R- 执行数据库一致性检查，如果执行发现错误，gpcheckcat将会生成纠错脚本，与数据库用户确认内容后执行脚本纠错，然后重复检查，如果没有纠错脚本产生，你就只能靠你自己了，如果运气好，你的错误可能在我下面列出的几个错误中。重复解决和检查直到没有错误产生
$ $GPHOME/bin/lib/gpcheckcat -p 5432 databasename - 使用GP管理员用户登陆master，执行gpstate检查seg node状态，如有failed seg，执行gprecoverseg和gprecoverseg -R修复