必备条件(从gp的admin手册中翻译)
1.保证你登录到gpmaster节点,并且是gp superuser(gpadmin)
2.在所有gp节点上安装gp4.0的bin文件
3.把用户自定义的模块复制到gp4.0的相应目录下,如一些函数,包等
4.把一些你额外增加的文件或文件夹复制或保存,因为只有gp需要的文件才会被gpmigrator这个命令保存
5.在所有的数据库中运行vacuum,并且删除所有的日志文件,非必须,只是为了节省空间、
6.如果存在gp_jetpack的schema,将其删除,不要在系统中用pg_或gp_前缀的schema,如果存在,将其rename
7.在3.x版本中建表(分区表,列存储)时如果使用了 OIDS=TRUE,修改其变成OIDS=FALSE,因为这在gp4.0中不会被支持
8.使用gpcheckcat命令检验你的系统目录的完整性
9.备份现在原有的数据(gpcondump 或者 ZFS快照)
10.删除master standy节点(gpinitstandby -r)
11.关闭现有系统(gpstop)
12.把环境升级为gp4.0,修改~/.bash_profile
13.通知所有数据库用户升级过程中数据库不可用
gpmigrator python脚本的阅读笔记
# Create a new GPUpgrade – should never throw Exception
初始化GPUpgrade实例
u = GPUpgrade()
# Execute the main upgrade routine, the Run() function itself is
# just a switch on the “cmd”, which switches between the main
# PerformUpgrade() function and all the various subcommands that
# are upgraded by backend executions.
u.Setup()
1.系统获取环境变量
2.处理传入参数
3.检查配置,参数是否确实,合理(从postgresql.conf获取一些参数)
u.run():(run方法的具体内容)
”"”
The main execution method – switches between submodes.
The main frontend will execute the main PerformUpgrade() function,
during which it will execute CallSlaves with various backend operations.
For each one of the main backend operations we will spawn the backend
executables, this switches between each of these operations.
“”"
# ——–
# Stage 1:
# ——–
# We have 1 main restart state which is the state of NEWDB_VALID. This
# is the state we record right before we start remirroring. After the
# first phase of remirroring we stop the script to allow for the
# possibility of a zfs snapshot (which isn’t really feasible before
# remirroring due to the amount of data written during the remirroring
# step).
1. self.CheckVersions() 检查版本是否可升级,catalog版本
2.检查gpmigrator/state文件,判断是否以前运行过gpmigrator,如果运行过分两种情况处理:
检查’BACKUP_VALID’,’NEWDB_VALID’
如果是 ‘BACKUP_VALID’ 会回滚数据 self.Revert()
如果是 ‘NEWDB_VALID’ 会继续 self.ReadInfo():
3.self.ExtractInfo() 从旧的gp中获取我们所需要的全部信息
获取segment信息,数据库信息,检查各节点是否可连接,关于gpperfmon的信息,端口,
SELECT oid, datname from pg_database