任何系统的升级都有个量变到质变的过渡:版本相差小的时候,通常很简单,版本相差大的时候,就是一场噩梦。不过版本相差小的时候,大伙儿往往安于现状。本文实际记录从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修复
时间: 2024-10-03 09:35:48