任何系统的升级都有个量变到质变的过渡：版本相差小的时候，通常很简单，版本相差大的时候，就是一场噩梦。不过版本相差小的时候，大伙儿往往安于现状。本文实际记录从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将会生成纠错脚本，与数据库用户确认内容后执行脚本纠错，然后重复检查，如果没有纠错脚本产生，你就只能靠你自己了，如果运气好，你的错误可能在我下面列出的几个错误中。重复解决和检查直到没有错误产生
  
  • 《如何解决Greenplum的gpcheckcat关于persistent的错误》
  • 《如何解决Greenplum中无法通过标准命令修复的元数据错误》
  • 《如何解决Greenplum master node与seg node元数据不一致》

$ $GPHOME/bin/lib/gpcheckcat  -p 5432 databasename 

• 使用GP管理员用户登陆master，执行gpstate检查seg node状态，如有failed seg，执行gprecoverseg和gprecoverseg -R修复