PG版本升级

pg生命周期:5个版本,bug不会再修
https://why-upgrade.depesz.com/show?from=9.4&to=9.6.6&keywords=            

查看升级修补的漏洞

1、小版本升级

1.1、如果data、home都没有版本号

只需要替换bin
如果都有版本号

1.2、如果data、home有版本号

编译安装新版本数据库,停止旧版本数据库,
将旧版本数据库的'数据目录'移动到新装的数据库的对应路径,启动该数据库即可。
    例如: mv /pgccc/pgdata_5432 /pgccc/pgdata_5432_19

此种场景下需要修改环境变量信息,设置成新版本的路径
        vim .bash_profile

        source
        （然后先从pghome的地方,bin里面./pg_ctl启动,因为我首次直接pg_ctl启动成别的库了）

        （听老师说要把PATH=$PATH:$PGHOME/bin 写在最上面）
另外如果设置了pg的开机自启服务,还需要修改对应的service文件,防止开机自启服务失效

 

 最后去老的postgres-xx.xx文件下make clean（root用户）

2、大版本升级

2.1、总结

~~
    pg_dump/pg_dumpall+restore/psql
    不适用于大数据库
~~
    pg_upgrade
    速度快,搭配并行和link模式,但是需要停机
~~
    逻辑复制
    最平滑

2.2、总结2

~~
dump/dumpall + restore/psql：
        由于dump+restore总体相对耗时较长,因此不适用于大数据量的数据库,或是写入比较频繁的场景使用。
        尤其是对于核心的业务程序（特别是有99.999保证的程序）来说是不可接受的,好处就是十分安全,
        当然也可以不停机,使用逻辑复制搭配decoder_raw等Plugins解析出备份之后的操作SQL,不过不能保证一致性。
~~
pg_upgrade：
        此方案优势是速度非常快,
        搭配并行和link模式,pg_upgrade –link –jobs xxx,
        但是必须停机升级,并且link模式,会无法使用以前的版本,因此不适用于7x24的场景,
        若使用默认模式,就地升级会导致磁盘使用率增倍,
        好处就是源端还可以用,
        同时假如还有standby或者流复制的场景下,可能还会丢失备库,可以使用官方推荐的rsync模式。
        同时值得注意的是,升级过程目前不会复制数据分布的任何统计数据,
        比如像直方图、最常见的值及其频率之类的东西,
        所以这也是“vacuumdb –analyze-only –analyze-in-stage”的重要性,
        不然复杂查询的性能会受到相当大的影响,还有就是make 、configure编译的参数得保持一致
~~
逻辑复制：
        此方案是最平滑的方案,比较适用于7x24小时以及大数据量场景,停机时间非常短,只有几秒钟,
        同时源端和目标端升级之后假如有需求,还是可以使用的。
        但是配置繁琐,尤其是v10以前的版本,还没有原生逻辑复制,需要第三方扩展,
        第三方扩展除了问题还是黑盒,增加了运维成本,同时还要有集群环境,
        但是原生逻辑复制又不支持序列、DDL（搭配插件pg_ddl_deploy,不过又回到了黑盒来了）、视图等等。

2.3、pg_upgrade

2.31~~~~~~~~~~~~~~
~~~①参数
    pg_upgrade --help
    -b、 --old-bindir=bindir旧集群可执行目录
    -B、 --new bindir=bindir新的集群可执行目录
    -c、 --只检查集群，不更改任何数据
    -d、 --old-datadir=datadir旧集群数据目录
    -D、 --new datadir=datadir新集群数据目录
    -j、 --jobs=要使用的同时进程或线程的数量
    -k、 --链接链接，而不是将文件复制到新群集
    -o、 --旧选项=options要传递到服务器的旧群集选项
    -O、 --new options=options要传递到服务器的新群集选项
    -p、 --旧端口=端口旧集群端口号（默认50432）
    -P、 --新端口=port新集群端口号（默认50432）
    -r、 --成功后保留保留SQL和日志文件
    -U、 --username=NAME集群超级用户（默认为“postgres”）
    -v、 --verbose启用详细的内部日志记录
    -V、 --版本显示版本信息，然后退出
    -？、--帮助显示此帮助，然后退出
~~~②简单介绍:
    关闭新、老库
    再从新库$PGHOME/bin下执行
    ./pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin
    执行完毕后,清理旧库脚本:
    ./delete_old_cluster.sh    

2.32~~~~~~~~~~~~~~

实践:

~~~①

        我搭建了一套v11.19版本的pg,port=5432

        并在里面创建了表zcj、插入数据如图:

~~~②

        我又搭建了一套v14.2版本的pg

        然后关闭两边的库。

~~~③        

        在新版本PGDATA/bin下面执行pg_upgrade脚本:

    ./pg_upgrade -d /pgccc/pgdata_5432 -D /pgccc/pgdata_5432_14 -b /pgccc/pgdata2/bin -B /pgccc/pgdata_14/bin --j 2 -k 

~~~④

        执行完毕,起库查看是否更新完成