任何系统的升级都有个量变到质变的过渡：版本相差小的时候，通常很简单，版本相差大的时候，就是一场噩梦。不过版本相差小的时候，大伙儿往往安于现状。本文实际记录从GP4.2.7.2到4.3.5.0的升级过程，从版本号看相差不大，但是GP的版本命名中，第二位的变化就已经是大升级了。另需说明的是，本文升级的GP数据库规模不小，用户较多，管理混沌，在加上GP实在是有点儿脆弱（相比oracle等），所以遇到了较多元数据问题（请参加前4篇）。
起点目标数据库版本：Greenplum Database 4.3.5.0 build 1（PostgreSQL 8.2.15）图形管理界面版本：Greenplum Command Center 1.3.0.0 build 91准备介质时间估计
登录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() -05-07 13:52:48 GPDB build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) :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修复
为什么？答：点线杆上贴着”“此处不许小便！”
