一、小版本升级¶

PostgreSQL 每次的小版本升级不会改变内部的存储格式，也不会改变数据目录，并且总是向上兼容同一主版本，例如 15.5和15.2 是兼容的，不论他们之间跨越了几个版本升级小版本也很简单，只需要安装新的可执行

文件，并重新启动数据库实例

比如在机器上安装新的版本下载小版本比如之前我们部署的时候是用一个软连接执行 15.5

ln -s /usr/local/pg15.5/ /usr/local/pg

把15.6拷贝到 /usr/local/pg15.6/ 目录下，然后关闭数据库

执行 unlink /usr/local/pg

ln -s /usr/local/pg15.6/ /usr/local/pg

启动数据库

二、大版本升级¶

PostgreSQL 发行的大版本通常不会改变内部数据存储格式，但可能会有一些系统表表结构变更以及内置函数的变化等，使得升级并不像小版本升级那么容易

大版本的升级可以有如下方式

将数据以转储的方式转储到文件，再将转储的数据文件导人新版本中，
也可以通过 pg_upgrad pg_logical 扩展进行升级
通过逻辑复制的方式进行版本升级，

为数据库版本升级提供了更多的便利无论采用哪一种升级方式，升级之前的应用程序测试,数据库功能测试、连接驱动测试都是非常必要的, 在升级大版本前之前也应该仔细阅读它每个大版本的releasenote，关注与上一版本的差异以及升级注意事项

重要点：运维人员在升级之前还应该做好升级失败的应对措施，尽可能保留一份升级前的副本，应对意外时的快速回滚

2.1 通过 pg_dumpall 进行大版本升级¶

使用 pg_dumpall 方式升级，也就是转储方式升级，实际上是将数据库在旧版本中先备份，备份结束后在新版本中进行还原的过程，需要有一定时间的停机维护窗口

优点：

通过一次全库的转储和恢复的过程，新版本数据
库会较“纯净”，一些历史遗留的、未能回收的垃圾都可以清理干净

缺点：

升级持续的时间主要取决于数据量的大小和磁盘的写入速度，如果数据量很大，升级会持续很长时，所以在升级之前一定要规划好停机维护时使用转储方式，

2.2 通过 pg_upgrade 进行大版本升级¶

大版本升级通常使用 pg_upgrade 工具。 pg_upgrade 进行大版本升级不需要费时的储方式，但是升级总是有风险的,例如升级过程中的硬件故障等，所以重要事情

任然是做好备份，升级之前需要检查旧版本已安装的外部扩展，有一些外部拓展要求在升级之前先升级旧版本的外部扩展，例如 PostGIS

通过帮助可以查看 pg_upgrade 数选项，参数选项如下面所示

# PostgreSQL 跨版本升级工具 pg_upgrade 官方参数详解
-b, --old-bindir=BINDIR        旧版本 PostgreSQL 可执行文件目录（bin 路径）
-B, --new-bindir=BINDIR        新版本 PostgreSQL 可执行文件目录（bin 路径）
-c, --check                    仅检查升级兼容性，不执行真实升级（安全预检查）
-d, --old-datadir=DATADIR      旧版本数据目录（data 路径）
-D, --new-datadir=DATADIR      新版本数据目录（data 路径）
-j, --jobs                     并行任务数，建议设置为 CPU 核心数，大幅缩短升级时间
-k, --link                     使用硬链接方式升级（不拷贝数据，秒级升级，生产常用）
-o, --old-options=OPTIONS      传递给旧版 postgres 进程的启动参数
-O, --new-options=OPTIONS      传递给新版 postgres 进程的启动参数
-p, --old-port=PORT            旧版本端口（升级默认使用 50432，避免客户端误连）
-P, --new-port=PORT            新版本端口（检查模式下新旧端口必须不同）
-r, --retain                   升级成功后依然保留 SQL 与日志文件（用于排查问题）

在升级之前应该运行 pg_pgrade 并用参数检查新旧版本的兼容性把每项不兼容的问题都解决了才可以顺利升级,使用 pg_upgrade 时加上-c 参数只会检查新旧版本的兼容性，不会真正运行升级程序，不会修改数据文件，并且在命令结束时，会输出一份检结果的报，还会对需要手动调整的项做出简要的描述

pg_upgrade 模式有两种：

普通模式：在普通模式下，会把旧版本的数据拷贝到新版本中，所以如果使用普通模式升级，要确保有足够的磁盘空间存储新旧两份数据；
link 模式：只是在新版本的数据目录中建立了旧版本数据文件的硬链接，可以有效减少磁盘占用的空

2.3 pg_upgrade的升级步骤¶

第一步：安装新版本 PostgreSQL 初始化数据目录）

第二步：停止旧版本数据库

第三步：检查新旧版本兼容性

#检查输出项全是ok之后，才能表示检查通过
pg_upgrade -b /usr/local/pg14/bin -B /usr/local/pg15/bin -d /data/pg14/pgdata/ -D /data/pg15/data/ -c

最后一行输出 Clusters are compatible ”说明已经通过兼容性测试如果最后一行输出“ Failure, exiting ” 表示错误

第四步：执行升级普通升级方式

time pg_upgrade -b /usr/local/pg14/bin -B /usr/local/pg15/bin -d /data/gp14/pgdata/ -D /data/pg15/pgdata/

如果运行 pg upgrade 失败，必须重新初始化新版的数据目录看到“ Upgrade Complete ，，说明升级已经顺利完成

link升级方式

time pg_upgrade -b /usr/local/pg14/bin -B /usr/local/pg15/bin -d /data/gp14/pgdata/ -D /data/pg15/pgdata/ --link

如果空间够的话推进使用普通方式，主要是为了方便回滚

第五步：启动数据库

2.4 使用 pg_upgrade 升级主从库¶

单机或主库的升级很常规，但如果是一主多从的复制模式，还需要升级对应的从库升级从库的步骤如下：

第一步：配置为同步复制模式

PostgreSQL 的复制模式是异步复制模式，我们需要先确定当前从库的复制模式是同步模式还是异步模式，如下所示

-- 查看流复制同步状态
SELECT application_name, client_addr, sync_state FROM pg_stat_replication;
--在postgresql.cnf 增加 synchronous_commit = on
--pg_ctl reload生效

第二步：关闭集群并校验检查点将复制集群修改为同步复制之后，先关闭主库，再关闭从库，确保：主库和从库的

“ Latest checkpoint location ”一致使用 pg_controldata

第三步：升级主库到新版本：升级主库跟升级单节点一样

第四步：升级从库到新版本：升级主库跟升级单节点一样

第五步：启动主库然后再启动从库，启动前把主备同步结果改为一步方式

第六步：检查升级结果

select version; 查看版本号
SELECT appl cation_name client_addr sync_state FROM pg_stat_replication; 查看复制情况

PostgreSQL 版本升级实践：小版本升级、pg_upgrade 与主从升级