必备条件（从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
SELECT count(*)::numeric FROM pg_user WHERE usename = ‘gpmigrator’
用户gpmigrator信息，如果存在，则drop user
检查索引
SELECT quote_ident(n.nspname) || ‘.’ ||
quote_ident(c.relname) as index,
m.amname as kind
FROM pg_class c
join pg_namespace n on (c.relnamespace = n.oid)
join pg_am m on (c.relam = m.oid)
WHERE c.relkind = ‘i’ and m.amname in (’gin’, ‘hash’)
如果select 有数据，报错退出
检查数据库字符集，用到Deprecated database也会报错
SELECT datname FROM pg_database WHERE encoding=0
SELECT gpname FROM gp_id
show checkpoint_segments
show client_encoding
show lc_ctype
show max_connections
还有一些其他的信息保存在self.config数组中
4. self.CreateDirectories()
Creates the upgrade/ and backup/ directories on all segments
如果有gpperfmon进程，全部stop掉
5. self.CheckCatalog()：
在每个数据库中执行：
/opt/greenplum/greenplum-db-4.0.3.0/bin/lib//gpcheckcat -p 5432 -U gpadmin -B 16 template1
6. self.SetupLockdown()
修改pg_hba.conf，除了upgrade user，其他用户不给连接
Change pg_hba.conf to disallow access to everyone except the upgrade user.
DROP USER IF EXISTS gpmigrator
CREATE USER gpmigrator with superuser
CMD: mv -f /gpdata/gp3.3/gpmaster/gp-1/pg_ident.conf /gpdata/gp3.3/gpmaster/gp-1/pg_ident.conf.gpmigrator_orig
CMD: mv -f /gpdata/gp3.3/gpmaster/gp-1/pg_hba.conf /gpdata/gp3.3/gpmaster/gp-1/pg_hba.conf.gpmigrator_orig
修改pg_hba.conf
stop -u
active = self.Select(”SELECT count(*) FROM pg_stat_activity”)
检查是否有链接（sql）正在跑，有的话，重启gp
7.self.GenerateConfigFiles()
Creates ‘gp_databases’ ‘gp_array_config’ and ‘gp_config’ files
gp_databases:写入 数据库 oid,name
gp_array_config: 写入gparray类中的信息
gp_config：写入在self.ExtractInfo()中的config数组信息写入
8.self.ExtractCatFiles()
Get the set of data files which are necessary to bring up a skeleton
system: just those necessary for bringing up the system in utility
mode and querying the catalogs — no user data.
We write the set of files to the file system for later use.
a.
SELECT datname
FROM pg_database
WHERE datname != ‘template0′
ORDER BY datname
b.在每个数据库中执行,将结果保存在外部文件（mapfile：’%s_catfiles’ % seg）中：
SELECT d.oid as datoid,
c1.relname as rel1, c1.relfilenode as node1,
c2.relname as rel2, c2.relfilenode as node2,
c3.relname as rel3, c3.relfilenode as node3
FROM pg_class c1
left outer join pg_namespace n
on (c1.relnamespace = n.oid)
left outer join pg_class c2
on (c1.reltoastrelid = c2.oid)
left outer join pg_class c3
on (c2.reltoastidxid = c3.oid),
pg_database d
WHERE d.datname = ‘aligputf8′ and
(nspname = ‘pg_catalog’ or
nspname = ‘information_schema’) and
c1.relkind in (’r', ‘i’) and
not c1.relisshared
c.select oid from pg_database where datname = ‘template0′
d.将一些数据目录文件名字也写道该外部文件mapfile中
9.self.ExtractAosegs()
a.aoseg_template0_rewrite.sql 检查该文件是否存在
b.每个数据库中都生成该空文件
aoseg_%s_rewrite.sql
c.aoseg_template0_rewrite.sql 写入 vacuum freeze;
d.persistent_master.sql 写入 select gp_persistent_build_db(false);
e.persistent_segment.sql 写入 select gp_persistent_build_db(true);（有mirror）
ps:这两个文件在后面的TransformDbs中用到
？ append only segment 是怎么样子的呢？
10.gpstop 关闭数据库
11.self.GetHighestOid()
Get the highest OID declared on the node, according to the control
file. We use this number to reset all the control files in the
new cluster we’re building, so that all the new objects will be
added with the same OID. Since we’re not dispatching the SQL to create
the objects, this is our only way to synchronise the OIDs.
Database must be down.
在每个节点上运行，获取oids，取最高值
pg_controldata ‘segment的数据目录’ | grep Latest checkpoint’s NextOID
12.self.BuildSkel()
Copy data files to build a skeleton database.
self.DeepLink(’SKELETON’)
创建目标文件夹并对文件夹进行修改权限
删除已存在文件夹中的所有数据
self.CallSlaves(’BUILDSKEL’) 在每个segment上都会执行
复制数据文件
修改pg_hba.conf，3.x的pg_hba.conf格式跟4.0的不一样，故不能直接复制
还有pg_ident.conf跟postgresql.conf
最后运行
pg_resetxlog -o 16386 /gpdata/gp3.3/gpmaster/gpmigrator/upgrade/gp-1
设置highest oid
13.self.SetCatVersion(sov, snv)
修改版本信息
‘$newhome/bin/lib/gpmodcatversion’,'–catversion’, to, datadir]
to:4.0版本
datadir：newdatahome
14.self.TransformDbs() 主要是重建一些数据字典,在每个segment上都会执行
Transform the local databases. The temporary copy we’ve made of each
segment is transformed by passing a set of transformation scripts
(stored in share/postgresql/upgrade/). To do the transformation,
we start the backend in –single (non postmaster) mode and send
the scripts via stdin.
在$GPHOME/share/postgresql/upgrade中保存有upg2_conversion32.sql.in等等升级文件
启动postgres –single -O -c gp_session_role=utility -c gp_before_persistence_work=true -c exit_on_error=true -E -D /gpdata/gp3.3/gpmaster/gpmigrator/upgrade/gp-1 template1
15.self.TouchupConfig() 这个只会在master上执行
Touch up the config for a transform method upgrade/downgrade
$GPHOME/sbin/gpsetdbid.py -d /gpdata/gp3.3/gpdata1/gp0 -i 2
UPDATE pg_filespace_entry SET fselocation = regexp_replace(fselocation, E’(/[^/]*)$’, E’/gpmigrator/upgrade//1′)
VACUUM FREEZE pg_filespace_entry
UPDATE gp_segment_configuration SET hostname=’gp01′, replication_port=null WHERE dbid=1
VACUUM FREEZE gp_segment_configuration
16.self.ReleaseLockdown(self.oldenv)
Revert pg_hba.conf to pre-lockdown state
# Two main cases:
# 1) Release lockdown on old environment
# 2) Release lockdown on newly installed environment
# Both cases have the database installed under MASTER_DATA_DIRECTORY
# so we actually treat them exactly the same
# ——–
# Stage 2:
# ——–
# We have no fully upgraded the existing old configuration into a
# new configuration.
#
# The current state of the world is as follows
# DATA_DIR/ = untouched original db
# DATA_DIR/upgrade = fully upgraded new db
# DATA_DIR/backup = empty except for the state and flag files.
#
# We haven’t modified anything under the master directory yet.
# If anything has gone wrong up to this point it is pretty much
# safe to blow away everything under ‘upgrade/’ and ‘backup/’
# (The only thing to be careful about is that we shutdown the
# new db before we remove the storage from under it.)
# —-
# For the 4.0 upgrade we must upgrade from 3.x style logical
# mirroring to 4.0 style file replication.
#
# The first stage of this is to remirror the system while we
# are still in a stage that can rollback.
17.self.RemirrorSystem(withContinue)
Handles re-mirroring the system prior to installing upgraded catalog.
This is done on the system prior to upgrade because we want to allow
for the possibility of a zfs snapshot after the remirroring is complete
(before we get to the point of no return on the upgrade).
/opt/greenplum/greenplum-db-4.0.3.0/sbin/gpupgrademirror.py –verbose –mode=S –gphome=”/opt/greenplum/greenplum-db-3.3.5.0″
18.self.UpgradeMirrors(withContinue) 应该是运行gpupgrademirror.py的第二阶段
/opt/greenplum/greenplum-db-4.0.3.0/sbin/gpupgrademirror.py –verbose –phase2
gpmigrator has completed remirroring the system.
It should now be possible to take a zfs snapshot before finalizing the upgrade.
1) Take zfs snapshots, if desired
2) Complete the upgrade by running:
gpmigrator %s %s % (self.oldhome, self.newhome))
19. self.StampDBId()
Populates the gp_dbid file for every segment
# ——–
# Stage 3:
# ——–
# The current state of the world is as follows
# DATA_DIR/ = contents unreliable
# DATA_DIR/upgrade = fully upgraded new db
# DATA_DIR/backup = untouched original db
# => Make a deep hard link copy of DATA_DIR/upgrade -> DATA_DIR
# => Adjust new pg_configuration to point to DATA_DIR
20. self.DeepLink(’BACKUP’) 创建DATA_DIR -> DATA_DIR/backup的硬连接
self.DeepLink(’INSTALL’) 创建DATA_DIR/upgrade -> DATA_DIR的硬连接
21.self.FixConfig()
After moving the upgraded db from DATA_DIR/upgrade to just DATA_DIR
we need to go and fix the gp_configuration table to point to the
correct location.
UPDATE pg_filespace_entry SET fselocation = regexp_replace(fselocation, E’/gpmigrator/upgrade/’,'/’)
VACUUM FREEZE pg_filespace_entry
22.self.Startup(self.newenv) 在新环境中启动gp4
23.self.PerformPostUpgrade()
Handles various post upgrade tasks including:
– Populates the gp_toolkit schema
– Performs updates for the gpperfmon database
select rolname from pg_authid where oid=10
应用了两个sql文件：
share/postgresql/gp_toolkit.sql
SET SESSION AUTHORIZATION gpadmin
24. # VACUUM FREEZE template1, since we haven’t already
self.Update(’VACUUM FREEZE;’, db=’template1′)
self.ReleaseLockdown(self.newenv)
25.最后一步，删掉用户，结束
DROP USER gpmigrator