Greenplum数据库升级实务(上)

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

你可能感兴趣的:(PaaS,大数据)