任何系统的升级都有个量变到质变的过渡:版本相差小的时候,通常很简单,版本相差大的时候,就是一场噩梦。不过版本相差小的时候,大伙儿往往安于现状。本文实际记录从GP4.2.7.2到4.3.5.0的升级过程,从版本号看相差不大,但是GP的版本命名中,第二位的变化就已经是大升级了。另需说明的是,本文升级的GP数据库规模不小,用户较多,管理混沌,在加上GP实在是有点儿脆弱(相比oracle等),所以遇到了较多元数据问题(请参加前4篇)。
登录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库到了一定量级,错误几乎是必然的,解决这些错误真的是要花费以星期计的时间。
$ gpstop -M fast
$ gpstart -R
$ $GPHOME/bin/lib/gpcheckcat -p 5432 databasename
原文地址:http://blog.csdn.net/cloudguru/article/details/45822713