大家好，我是只谈技术不剪发的 Tony 老师。对于企业而言，将数据库系统升级到新版本通常可以获得更好的性能、更多的功能、最新的安全补丁和错误修复等。因此，本文就来介绍一下 PostgreSQL 数据库版本升级的 3 种常用方案。

如果觉得文章有用，欢迎评论📝、点赞👍、推荐🎁

升级方案概述

PostgreSQL 版本号由主要版本和次要版本组成。例如，PostgreSQL 12.4 中的 12 是主要版本，4 是次要版本；PostgreSQL 10.0 之前的版本由 3 个数字组成，例如 9.6.19，其中 9.6 是主要版本，19 是次要版本。

发布次要版本是不会改变内存的存储格式，因此总是和相同的主要版本兼容。例如，PostgreSQL 12.4 和 PostgreSQL 12.0 以及后续的 PostgreSQL 12.x 兼容。对于这些兼容版本的升级非常简单，只需要关闭数据库服务，安装替换二进制的可执行文件，重新启动服务即可。

接下来，我们主要讨论 PostgreSQL 的跨版本升级问题，例如从 PostgreSQL 12.x 升级到 PostgreSQL 13.y。主要版本的升级可能会修改内部数据的存储格式，因此需要执行额外的操作。常用的跨版本升级方法和适用场景如下：

📝如果使用厂商提供的 PostgreSQL 定制版本，也可能通过他们提供的工具实现版本升级，具体参考相关文档。

注意事项：升级主要版本通过会导致用户可见的不兼容性，因此应用程序可能需要进行相应的修改。具体的变化可以参考发行说明，尤其是“Migration”部分的内容；如果跨多个主要版本进行升级，需要阅读每个中间版本的发行说明。

通过逻辑备份与还原进行升级

传统的跨版本升级方法利用 pg_dump/pg_dumpall 逻辑备份导出数据库，然后在新版本中通过 pg_restore 进行还原。导出旧版本数据库时推荐使用新版本的 pg_dump/pg_dumpall 工具，可以利用最新的并行导出和还原功能，同时可以减少数据库膨胀问题。

逻辑备份与还原非常简单但速度比较慢，停机时间取决于数据库的大小，因此适合中小型数据库的升级。

下面我们介绍这种升级方法的具体操作，假如当前 PostgreSQL 软件的安装目录位于 /usr/local/pgsql，同时数据目录位于 /usr/local/pgsql/data，我们在同一台服务器上进行升级。

1. 执行逻辑备份之前停止应用程序，确保没有数据更新，因为备份开始后的更新不会被导出。如有必要，可以修改 /usr/local/pgsql/data/pg_hba.conf 文件禁止其他人访问数据库。

   然后备份数据库：

   pg_dumpall > outputfile
   

   如果已经安装了新版本的 PostgreSQL，可以使用新版本的 pg_dumpall 命令备份旧版本数据库。

2. 停止旧版本的后台服务：

   pg_ctl stop
   

   或者通过其他方式停止后台服务。

3. 如果安装目录没有包含特定版本标识，可以将目录改名，必要时可以再修改回来。可以使用类似以下的命令重命名目录：

   mv /usr/local/pgsql /usr/local/pgsql.old
   

4. 安装新版本 PostgreSQL 软件，假如安装目录仍然是 /usr/local/pgsql。

5. 初始化一个新的数据库集群，需要使用数据库专用用户（通常是 postgres；如果是升级版本，应该已经存在该用户）执行操作：

   /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
   

6. 将旧版本配置文件 pg_hba.conf 和 postgresql.conf 等中的改动在对应的新配置文件中再次进行修改。

7. 使用数据库专用用户启动新版本的后台服务：

    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
   

8. 最后，利用新版本的 psql 命令还原数据：

   /usr/local/pgsql/bin/psql -d postgres -f outputfile
   

为了减少停机时间，可以将新版本的 PostgreSQL 安装到另一个目录（例如 /usr/local/pgsql-13），同时使用不同的端口启动服务。然后同时执行数据库的导出和导入：

pg_dumpall -p 5432 | psql -d postgres -p 5433

执行以上操作时，新旧版本的后台服务同时运行，新版本使用 5433 端口，旧版本使用 5432 端口。

利用 pg_upgrade 工具进行升级

pg_upgrade 工具可以支持 PostgreSQL 跨版本的就地升级，不需要执行导出和导入操作。pg_upgrade 可以支持 PostgreSQL 8.4.X 到最新版本的升级，包括快照版本和测试版本。

pg_upgrade 提供了升级前的兼容性检查（-c 或者 --check 选项）功能， 可以发现插件、数据类型不兼容等问题。如果指定了 --link 选项，新版本服务可以直接使用原有的数据库文件而不需要执行复制，通常可以在几分钟内完成升级操作。

下面我们介绍这种升级方法的具体操作，假如当前 PostgreSQL 软件的安装目录位于 /usr/pgsql-12/，同时数据目录位于 /var/lib/pgsql/12/data/，我们将其升级为 PostgreSQL 13。

1. 确定没有客户端访问之后备份数据库，然后停止旧版本的后台服务。例如 CentOS 可以执行以下命令：

   sudo systemctl stop postgresql-12
   sudo systemctl disable postgresql-12
   

2. 安装新版本的 PostgreSQL 软件。例如 PostgreSQL 13.0，安装目录位于 /usr/pgsql-13/。

3. 初始化新版本的数据库集群。数据目录设置为 /var/lib/pgsql/13/data/。

4. 如果旧版本中安装了扩展模块，在新版本中也需要安装相应的共享对象文件或者 DLL 文件。但是不要执行CREATE EXTENSION命令，因为会从旧数据库中进行升级。另外，如果使用了任何自定义的全文搜索文件（字典、同义词、词库、停用词），也需要复制到新的数据库集群目录中。

5. 停止新版本的后台服务。例如 CentOS 可以执行以下命令：

   sudo systemctl stop postgresql-13
   

6. 通过 pg_upgrade 执行升级操作，使用数据库专用用户（通常是 postgres）执行以下操作：

   /usr/pgsql-13/bin/pg_upgrade \
     --old-datadir /var/lib/pgsql/12/data/ \
     --new-datadir /var/lib/pgsql/13/data/ \
     --old-bindir /usr/pgsql-12/bin/ \
     --new-bindir /usr/pgsql-13/bin/ \
     --check
   

   其中 --check 表示执行升级检查，而不会真的执行升级操作。通过检查之后，可以去掉该参数执行升级：

   /usr/pgsql-13/bin/pg_upgrade \
     --old-datadir /var/lib/pgsql/12/data/ \
     --new-datadir /var/lib/pgsql/13/data/ \
     --old-bindir /usr/pgsql-12/bin/ \
     --new-bindir /usr/pgsql-13/bin/ \
     --link
   

   其中 --link 表示将新版本的数据目录硬链接到旧版本的数据目录，而不会复制一份新的数据文件，可以快速进行升级。

7. 将旧版本配置文件 pg_hba.conf 和 postgresql.conf 等中的改动在对应的新配置文件中再次进行修改。

8. 启动新版本的后台服务。例如 CentOS 可以执行以下命令：

   sudo systemctl start postgresql-13
   sudo systemctl enable postgresql-13
   

9. 连接服务器查看数据库的版本信息：

   SELECT version();
   version                                                                                                |
   -------------------------------------------------------------------------------------------------------|
   PostgreSQL 13.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit|
   

10. 收集统计信息。pg_upgrade 不会生成新版本数据库的统计信息，但是会创建一个脚本文件，执行该文件：

    ./analyze_new_cluster.sh
    

11. 如果确认升级成功，可以选择删除或者保留旧的数据库软件和集群。pg_upgrade 同样提供了一个删除旧数据库集群的脚本：

      ./delete_old_cluster.sh
    

    然后可以删除旧版本的 PostgreSQL 软件，例如 CentOS 可以执行以下命令：

    yum remove postgresql12*
    

12. 如果想要回退到旧版本的数据库，可以分为不同的情况：

    • 如果只运行了 --check 选项命令，表示没有真正执行升级，重新启动服务即可；
    • 如果升级时没有使用 --link 选项，旧版本的数据库集群没有任何修改，重新启动服务即可；
    • 如果升级时使用了 --link 选项，数据库文件可能已经被新版本的集群使用：
      • 如果 pg_upgrade 在链接操作之前终止，旧版本的数据库集群没有任何修改，重新启动服务即可；
      • 如果没有启动过新版本的后台服务，旧版本的数据库集群没有修改，但是链接过程已经将 $PGDATA/global/pg_control 文件重命名为 $PGDATA/global/pg_control.old；此时需要将该文件名中的 .old 后缀去掉，然后重新启动服务即可；
      • 如果已经启动了新版本的数据库集群，已经修改了数据库文件，再启动旧版本的服务可能导致数据损坏；此时需要通过备份文件还原旧版本的数据库。

关于 pg_upgrade 的详细使用和升级注意事项，例如流复制结构和日志传输复制结构中备用节点的升级，可以参考官方文档。

使用逻辑复制功能进行升级

PostgreSQL 逻辑复制支持跨版本之间的数据复制，而且支持不同平台之间的复制，因此也可以用于实现版本升级。我们可以安装一个新版本的数据库作为复制的从节点，当数据已经同步时执行一次主从切换，然后关闭旧版本的主节点。主从切换的升级方法通常只需要几秒钟就能完成，利用第三方高可用组件甚至可以实现零停机时间升级。

PostgreSQL 10 开始提供了内置的逻辑复制功能，或者也可以使用 pglogical、Slony、Londiste 以及 Bucardo 等逻辑复杂工具。

关于 PostgreSQL 逻辑复制结构的创建和主从切换，可以参考官方文档。

总结

PostgreSQL 小版本升级只需要替换二进制文件即可，跨版本升级的方案主要有 3 种：通过 pg_dump/pg_dumpall 逻辑备份与还原进行升级，利用 pg_upgrade 工具进行升级，使用逻辑复制功能进行升级。了解它们的优缺点和适用场景可以帮助我们选择最佳的升级方式。

1.全量升级：

  完整的下载新版本固件，下载完成后将固件搬运到APP程序运行的位置。（一般来说是将APP从片外flash搬运到片内flash上）。搬运完成后校验通过后重启APP。

2.差分升级：

  利用算法，做出原版APP和新版APP程序的差分包，将差分包下载到flash，内部的BootLoader程序在利用算法将新版APP合成，合成后在搬运，搬运后校验，重启。
  一般制作出来的差分包只有原包的5%左右。省空间！

服务器端： 生成差分包，bsdiff算法

1．对old文件中所有子字符串形成一个字典；
2．对比old文件和new文件，产生diff string和extra string；

3．将diff string 和extra string 以及相应的控制字用zip压缩成一个patch包。

设备端： 生成new File，bspatch算法

1．接收patch包；

2．解压patch包；

3．还原new文件。

3.原地升级：

相比差分升级，合包的过程，直接搬运。
容错率低。

4.AB面升级（AB系统升级）

  Android从7.0开始，引入了新的OTA升级方式：A/B System Updates
  A/B系统是指设备上有A和B两套可以工作的系统(用户数据只有一份，为两套系统共用)，我们可以理解为一套系统分区，另外一套为备份分区。其系统版本可能一样，也可能不一样；通过升级，可以将旧版本也更新为新版本。当然，设备出厂时这两套系统肯定是一样的。

如图所示：

A/B 系统更新可带来以下好处：

• OTA 更新可以在系统运行期间进行，而不会打断用户。用户可以在 OTA 期间继续使用其设备。在更新期间，唯一的一次宕机发生在设备重新启动到更新后的磁盘分区时。
• 更新后，重新启动所用的时间不会超过常规重新启动所用的时间。
• 如果 OTA 无法应用（例如，因为刷机失败），用户将不会受到影响。用户将继续运行旧的操作系统，并且客户端可以重新尝试进行更新。
• 如果 OTA 更新已应用但无法启动，设备将重新启动回旧分区，并且仍然可以使用。客户端可以重新尝试进行更新。
• 任何错误（例如 I/O 错误）都只会影响未使用的分区组，并且用户可以进行重试。由于 I/O 负载被特意控制在较低水平，以免影响用户体验，因此发生此类错误的可能性也会降低。
  更新包可以流式传输到 A/B 设备，因此在安装之前不需要先下载更新包。流式更新意味着用户没有必要在 /data 或 /cache 上留出足够的可用空间来存储更新包。
• 缓存分区不再用于存储 OTA 更新包，因此无需确保缓存分区的大小要足以应对日后的更新。
• dm-verity 可保证设备将使用未损坏的启动映像。如果设备因 OTA 错误或 dm-verity问题而无法启动，则可以重新启动到旧映像。（Android 验证启动不需要 A/B 更新。）

Recovery系统升级

Recovery系统安卓7.0以前传统的OTA方式：设备上有一个Android主系统和一个Recovery系统，Android主系统运行时检测是否需要升级，如果需要升级，则将升级的数据包下载并存放到cache分区，重启系统后进入Recovery系统，并用cache分区下载好的数据更新Android主系统，更新完成后重新启动进入Android主系统。如果更新失败，设备重启后就不能正常使用了，唯一的办法就是重新升级，直到成功为止。