pg_upgrade from 9.6升级到14.5

素颜马尾好姑娘i 2024-02-19 08:16 22阅读 0赞

pg\_upgrade — 升级PostgreSQL服务器实例

### 大纲 ###

`pg_upgrade` `-b` *`oldbindir`* `-B` *`newbindir`* `-d` *`oldconfigdir`* `-D` *`newconfigdir`* \[*`option`*...\]

### 描述 ###

pg\_upgrade（之前被称为pg\_migrator） 允许存储在PostgreSQL数据文件中的数据被升级到一个较晚 的PostgreSQL主版本而无需进行主版本升级（例如从9.5.8到9.6.4或者从10.7到11.2）通常所需的数据转储/重载。 对于次版本升级（例如从9.6.2到9.6.3或者从10.1到10.2）则不需要这个程序。

PostgreSQL主发行版本通常会加入新的特性，这些新特性常常会更改系统表的 布局，但是内部数据存储格式很少会改变。pg\_upgrade 使用这一事实来通过创建新系统表并且重用旧的用户数据文件来执行快速升级。 如果未来的主发行版本更改了数据存储格式，导致旧数据格式不可读，那么 pg\_upgrade将无法用于此类升级。（社区将努力避免这种情况）。

pg\_upgrade会尽力（例如通过检查兼容的编译时设 置）确保新旧集簇在二进制上也是兼容的，包括 32/64 位二进制。保持 外部模块也是二进制兼容的也很重要，不过 pg\_upgrade无法检查这一点。

pg\_upgrade 支持从 8.4.X 及其后版本升级到当前的 PostgreSQL主发布，包括快照和 beta 发布。

### 选项 ###

pg\_upgrade接受下列命令行参数：

`-b` *`bindir`*  
`--old-bindir=`*`bindir`*

旧的 PostgreSQL 可执行文件目录； 环境变量`PGBINOLD`

`-B` *`bindir`*  
`--new-bindir=`*`bindir`*

新的 PostgreSQL 可执行文件目录； 默认为pg\_upgrade所在的目录； 环境变量`PGBINNEW`

`-c`  
`--check`

只检查集簇，不更改任何数据

`-d` *`configdir`*  
`--old-datadir=`*`configdir`*

旧的集簇数据目录；环境变量 `PGDATAOLD`

`-D` *`configdir`*  
`--new-datadir=`*`configdir`*

新的集簇数据目录；环境变量 `PGDATANEW`

`-j`  
`--jobs=njobs`

要同时使用的进程或线程数

`-k`  
`--link`

使用硬链接来代替将文件拷贝到新集簇

`-o` *`options`*  
`--old-options` *`options`*

直接传送给旧 `postgres`命令的选项，多个选项可以追加在后面

`-O` *`options`*  
`--new-options` *`options`*

直接传送给新 `postgres`命令的选项，多个选项可以追加在后面

`-p` *`port`*  
`--old-port=`*`port`*

旧的集簇端口号；环境变量 `PGPORTOLD`

`-P` *`port`*  
`--new-port=`*`port`*

新的集簇端口号；环境变量 `PGPORTNEW`

`-r`  
`--retain`

即使在成功完成后也保留 SQL 和日志文件

`-s` *`dir`*  
`--socketdir=`*`dir`*

用于升级期间postmaster套接字的目录;默认是当前目录; 环境变量 `PGSOCKETDIR`

`-U` *`username`*  
`--username=`*`username`*

集簇的安装用户名；环境变量 `PGUSER`

`-v`  
`--verbose`

启用详细的内部日志

`-V`  
`--version`

显示版本信息，然后退出

`--clone`

使用有效的文件克隆（在一些系统上也被称为“reflinks”），而不是将文件拷贝到新群集。 这可以导致数据文件接近瞬时的复制，从而获得`-k`/`--link`的速度优势，同时保留旧群集不受影响。

文件克隆仅在某些操作系统和文件系统上得到支持。如果选中但不被支持，则 pg\_upgrade运行将会出错。 目前，它支持在Linux（内核4.5或更高版本）上的Btrfs和XFS（在文件系统创建reflink支持），以及macOS上的APFS。

`-?`  
`--help`

显示帮助，然后退出

### 使用 ###

下面是用pg\_upgrade执行一次升级的步骤：

1.  **移动旧集簇（可选）**
    
    如果你在使用一个与版本相关的安装目录（例如 `/opt/PostgreSQL/14`），你就不需要移动旧的集簇。 图形化的安装程序会使用版本相关的安装目录。
    
    如果你的安装目录不是版本相关的（例如`/usr/local/pgsql`）， 就有必要移动当前的 PostgreSQL 安装目录，以免它干扰新的 PostgreSQL安装。一旦当前的 PostgreSQL服务器被关闭，就可以安全地重命名 PostgreSQL 安装目录。假设旧目录是 `/usr/local/pgsql`，你可以这样：
    
        mv /usr/local/pgsql /usr/local/pgsql.old
    
    来重命名该目录。
2.  **对于源码安装，编译新版本**
    
    用兼容旧集簇的`configure`标记编译新的 PostgreSQL 源码。在开始升级之前，pg\_upgrade 将检查`pg_controldata`来确保所有设置都是兼容的。
3.  **安装新的 PostgreSQL 二进制文件**
    
    安装新服务器的二进制文件和支持文件。pg\_upgrade 会被包含在默认的安装中。
    
    对于源码安装，如果你希望把新服务器安装在一个自定义的位置， 可以使用`prefix`变量：
    
        make prefix=/usr/local/pgsql.new install
4.  **初始化新的 PostgreSQL 集簇**
    
    使用`initdb`初始化新集簇。这里也要使用与 旧集簇相兼容的`initdb`标志。许多预编译的 安装程序会自动做这个步骤。这里没有必要启动新集簇。
5.  **安装扩展共享对象文件**
    
    许多扩展和自定义模块，无论是来自`contrib`或其他源，使用共享对象文件(或DLLs)，例如， `pgcrypto.so`。 如果旧集群使用过这些，匹配新服务器二进制的共享对象文件，必须安装在新集群中。 通常是通过操作系统命令。 不要加载模式定义，例如`CREATE EXTENSION pgcrypto`，因为这些将从旧集群复制。 如果扩展更新是可用的，pg\_upgrade将报告这一点，并创建一个脚本，可以稍后运行来更新它们。
6.  **拷贝定制的全文本检索文件**
    
    从旧集群向新集群拷贝任何定制化全文本检索文件(词典、同义词、辞典、停用词)
7.  **调整认证**
    
    `pg_upgrade`将会多次连接到旧服务器和新服务器，因此 你可能想要在`pg_hba.conf`中把认证设置成 `peer`或者使用一个`~/.pgpass`文件（见 [第 34.16 节][34.16]）。
8.  **停止两个服务器**
    
    确认两个数据库服务器都被停止使用，例如在 Unix 上可以：
    
        pg_ctl -D /opt/PostgreSQL/9.6 stop
        pg_ctl -D /opt/PostgreSQL/14 stop
    
    或者在 Windows 上使用正确的服务名：
    
        NET STOP postgresql-9.6
        NET STOP postgresql-14
    
    直到后面的步骤之前，流复制和日志传送后备服务器可以保持运行。
9.  **为后备服务器升级做准备**
    
    如果正在使用小节[步骤 11][11]中给出的方法升级后备服务器，请对旧的主集簇和后备集簇运行pg\_controldata以验证旧的后备服务器已经完全追上。验证“Latest checkpoint location”值在所有集簇中都匹配（如果旧后备服务器在旧的主服务器之前被关闭或者如果旧的后备服务器仍在运行，则将会出现失配）。此外，请确保在新的主集簇上的`postgresql.conf`文件中，`wal_level`未设置为`minimal`。
10. **运行 pg\_upgrade**
    
    总是应该运行新服务器而不是旧服务器的pg\_upgrade二进制文件。 pg\_upgrade要求制定新旧集簇的数据和可执行文件（`bin`）目录。 你也可以指定用户和端口值，以及你是否想要用链接或克隆来取代默认的复制行为对数据文件进行处理。
    
    如果你使用链接模式，升级将会快很多（不需要文件拷贝）并且将使用 更少的磁盘空间，但是在升级后一旦启动新集簇，旧集簇就无法被访问。 链接模式也要求新旧集簇数据目录位于同一个文件系统中（表空间和 `pg_wal`可以在不同的文件系统中）。 克隆模式提供了相同的速度以及磁盘空间优势，但不会导致新群集启动后旧群集不可用。 克隆模式还需要新旧数据目录位于同一文件系统中。 此模式仅在某些操作系统和文件系统上可用。
    
    `--jobs`选项允许多个 CPU 核心被用来复制/链接文件以及 并行地转储和重载数据库模式。这个选项一个比较好的值是 CPU 核心数 和表空间数的最大值。这个选项可以显著地减少升级运行在一台多处理 器机器上的多数据库服务器的时间。
    
    对于 Windows 用户，你必须以一个超级账号登录，并且以 `postgres`用户启动一个 shell 并且设置正确的路径：
    
        RUNAS /USER:postgres "CMD.EXE"
        SET PATH=%PATH%;C:\Program Files\PostgreSQL\14\bin;
    
    并且用带引号的目录运行pg\_upgrade，例如：
    
        pg_upgrade.exe
                --old-datadir "C:/Program Files/PostgreSQL/9.6/data"
                --new-datadir "C:/Program Files/PostgreSQL/14/data"
                --old-bindir "C:/Program Files/PostgreSQL/9.6/bin"
                --new-bindir "C:/Program Files/PostgreSQL/14/bin"
    
    一旦启动，`pg_upgrade`将验证两个集簇是否兼容并且 执行升级。你可以使用`pg_upgrade --check`来只执行检查， 这种模式即使在旧服务器还在运行时也能使用。 `pg_upgrade --check`也将列出任何在更新后需要做的手工调整。 如果你将要使用链接或克隆模式，你应该使用`--link`或`--clone`选项和`--check`一起来启用链接模式相关的检查。 `pg_upgrade`要求在当前目录中的写权限。
    
    显然，没有人可以在升级期间访问这些集簇。pg\_upgrade 默认会在端口 50432 上运行服务器来避免意外的客户端连接。在做升级时， 可以对两个集簇使用相同的端口号，因为新旧集簇不会在同时被运行。不过， 在检查一个旧的运行中服务器时，新旧端口号必须不同。
    
    如果在恢复数据库模式时发生错误，`pg_upgrade`将会退出 并且你必须按照下文[步骤 17][17]中所说的恢复 旧集簇。要再次尝试`pg_upgrade`，你将需要修改 旧集簇，这样 pg\_upgrade 模式会成功恢复。如果问题是一个 `contrib`模块， 你可能需要从旧集簇中卸载该模块并且在升级后重新把它安装在新集簇中，不过 这样做的前提是该模块没有被用来存储用户数据。
11. **升级流复制和日志传送后备服务器**
    
    如果使用链接模式并且有流复制（见[第 27.2.5 节][27.2.5]）或者日志 传送（见[第 27.2 节][27.2]）后备服务器，你可以遵照下面的 步骤对它们进行快速的升级。你将不用在这些后备服务器上运行 pg\_upgrade，而是在主服务器上运行rsync。 到这里还不要启动任何服务器。
    
    如果你*没有*使用链接模式、没有或不想使用rsync或者想用一种更容易的解决方案，请跳过这一节中的过程并且在pg\_upgrade完成并且新的主集簇开始运行后重建后备服务器。
    
    1.  **在后备服务器上安装新的 PostgreSQL 二进制文件**
        
        确保新的二进制和支持文件被安装在所有后备服务器上。
    2.  **确保*不*存在新的后备机数据目录**
        
        确保新的后备机数据目录*不*存在或者为空。如果 运行过initdb，请删除后备服务器的新数据目录。
    3.  **安装扩展共享对象文件**
        
        在新的后备机上安装和新的主集簇中相同的扩展共享对象文件。
    4.  **停止后备服务器**
        
        如果后备服务器仍在运行，现在使用上述的指令停止它们。
    5.  **保存配置文件**
        
        从旧后备机的配置目录保存任何需要保留的配置文件，例如 `postgresql.conf`（以及它包含的任何文件）、 `postgresql.auto.conf`、`pg_hba.conf`， 因为这些文件在下一步中会被重写或者移除。
    6.  **运行rsync**
        
        在使用链接模式时，后备服务器可以使用rsync快速升级。为了实现这一点，在*主*服务器上一个高于新旧数据库集簇目录的目录中为每个后备服务器运行这个命令：
        
            rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
        
        其中`old_cluster`和`new_cluster`是相对于主服务器上的当前目录的，而`remote_dir`是后备服务器上*高于*新旧集簇目录的一个目录。在主服务器和后备服务器上指定目录之下的目录结构必须匹配。指定远程目录的详细情况请参考rsync的手册，例如：
        
            rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \
                  /opt/PostgreSQL/9.6 standby.example.com:/opt/PostgreSQL
        
        可以使用rsync的`--dry-run`选项验证该命令将做的事情。虽然在主服务器上必须为至少一台后备运行rsync，可以在一台已经升级过的后备服务器上运行rsync来升级其他的后备服务器，只要已升级的后备服务器还没有被启动。
        
        这个命令所做的事情是记录由pg\_upgrade的链接模式创建的链接，它们连接主服务器上新旧集簇中的文件。该命令接下来在后备服务器的旧集簇中寻找匹配的文件并且为它们在该后备的新集簇中创建链接。主服务器上没有被链接的文件会被从主服务器拷贝到后备服务器（通常都很小）。这提供了快速的后备服务器升级。不幸地是，rsync会不必要地拷贝与临时表和不做日志表相关的文件，因为通常在后备服务器上不存在这些文件。
        
        如果有表空间，你将需要为每个表空间目录运行一个类似的rsync命令，例如：
        
            rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \
                  /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp
        
        如果你已经把`pg_wal`放在数据目录外面，也必须在那些目录上运行rsync。
    7.  **配置流复制和日志传送后备服务器**
        
        为日志传送配置服务器（不需要运行`pg_start_backup()` 以及`pg_stop_backup()`或者做文件系统备份，因为从属机 仍在与主机同步）。
12. **恢复 `pg_hba.conf`**
    
    如果你修改了`pg_hba.conf`，则要将其恢复到原始的设置。 也可能需要调整新集簇中的其他配置文件来匹配旧集簇，例如 `postgresql.conf`（以及它包含的任何文件）和 `postgresql.auto.conf`。
13. **启动新服务器**
    
    现在可以安全地启动新的服务器，并且可以接着启动任何 rsync过的后备服务器。
14. **升级后处理**
    
    如果需要做任何升级后处理，pg\_upgrade 将在完成后发出警告。它也将 生成必须由管理员运行的脚本文件。这些脚本文件将连接到每一个需要做 升级后处理的数据库。每一个脚本应该这样运行：
    
        psql --username=postgres --file=script.sql postgres
    
    这些脚本可以以任何顺序运行并且在运行之后立即删除。
    
    #### 小心 ####
    
    通常在重建脚本运行完成之前访问重建脚本中引用的表是不安全的，这样做 可能会得到不正确的结果或者很差的性能。没有在重建脚本中引用的表可以 随时被访问。
15. **统计信息**
    
    由于`pg_upgrade`并未传输优化器统计信息，在升级的尾声 你将被指示运行一个命令来生成这些信息。你可能需要设置连接参数来匹配你 的新集簇。
16. **删除旧集簇**
    
    一旦你对升级表示满意，你就可以通过运行 `pg_upgrade`完成时提到的脚本来删除旧集簇的 数据目录（如果在旧数据目录中有用户定义的表空间就不可能实现自动删除）。 你也可以删除旧安装目录（例如`bin`、`share`）。
17. **恢复到旧集簇**
    
    在运行`pg_upgrade`之后，如果你希望恢复到 旧集簇，有几个选项：
    
     *  如果使用了 `--check` 选项, 则旧集群没有被修改；它可以被重新启动。
     *  如果 `--link` 选项 *没有*被使用, 旧集群没有被修改；它可以被重新启动。
     *  如果使用了`--link` 选项, 数据文件可能在新旧群集之间共享:
        
         *  如果`pg_upgrade`在链接启动之前中止，旧群集没有被修改，它可以重新启动。
         *  如果你*没有*启动新集群，旧集群没有被修改，当链接启动时，一个`.old`后缀会附加到`$PGDATA/global/pg_control`。 如果要重用旧集群，从`$PGDATA/global/pg_control`移除`.old`后缀；你就可以重启旧集群。
         *  如果你已经启动新群集，它已经写入了共享文件，并且使用旧群集会不安全。这种情况下，需要从备份中还原旧群集。

### 注解 ###

pg\_upgrade创建不同的工作文件，如模式转储，在当前工作目录中。为了安全，请确保该目录不可被任何其他用户读取或者写入。

pg\_upgrade在新旧数据目录中启动短期的postmasters。临时 Unix 套接字文件用于与这些postmasters通信，默认情况下，在当前工作目录中进行。 在某些情况下，当前目录的路径名称可能太长，无法成为有效的套接字名称。这种情况下你可以使用`-s`选项将套接字文件放在某些具有较短路径名称的目录中。 为了安全原因，请确保该目录不可被任何其他用户读取或者写入。（这在 Windows 上不受支持。）

如果失败、重建和重新索引会影响你的安装，pg\_upgrade 将会报告这些情况。用来重建表和索引的升级后脚本将会自动被建立。 如果你正在尝试自动升级很多集簇，你应该发现具有相同数据库模式的集簇 对所有集簇升级都要求同样的升级后步骤，这是因为升级后步骤是基于数据 库模式而不是用户数据。

对于部署测试，创建一个只有模式的旧集簇副本，在其中插入假数据并且升级。

pg\_upgrade不支持包含使用这些`reg*` OID-引用 系统数据类型的表列的数据库的升级：

<table> 
 <tbody> 
  <tr> 
   <td><code>regcollation</code></td> 
  </tr> 
  <tr> 
   <td><code>regconfig</code></td> 
  </tr> 
  <tr> 
   <td><code>regdictionary</code></td> 
  </tr> 
  <tr> 
   <td><code>regnamespace</code></td> 
  </tr> 
  <tr> 
   <td><code>regoper</code></td> 
  </tr> 
  <tr> 
   <td><code>regoperator</code></td> 
  </tr> 
  <tr> 
   <td><code>regproc</code></td> 
  </tr> 
  <tr> 
   <td><code>regprocedure</code></td> 
  </tr> 
 </tbody> 
</table>

(`regclass`, `regrole`, and `regtype` can be upgraded.)

如果你在升级一个PostgreSQL 9.2 之前的集簇，并且 它使用一个只有配置文件的目录，你必须向pg\_upgrade 传递真正的数据目录位置，并且把配置目录位置传递给服务器，例如 `-d /real-data-directory -o '-D /configuration-directory'`。

如果正在使用的一个 9.1 之前的旧服务器用的是一个非默认Unix 域套接字目录 或者使用的默认值不同于新集簇的默认值，请把`PGHOST`设置为 指向旧服务器的套接字位置（这与 Windows 无关）。

如果你想要使用链接模式并且你不想让你的旧集簇在新集簇启动时被修改，考虑使用克隆模式。 如果(克隆模式)不可用，可以复制一份旧集簇并且在副本上以链接模式进行升级。要创建旧集簇的一 份合法拷贝，可以在服务器运行时使用`rsync`创建旧集簇的 一份脏拷贝，然后关闭旧服务器并且再次运行`rsync --checksum` 把更改更新到该拷贝以让其一致（`--checksum`是必要的，因为 `rsync`在判断文件修改时间的更改时的精度只能到秒级）。如 [第 26.3.3 节][26.3.3]中所述，你可能想要排除 一些文件，例如`postmaster.pid`。如果你的文件系统支持文 件系统快照或者 copy-on-write 文件副本，你可以使用它们来创建旧集簇和 表空间的一个备份，不过快照和副本必须被同时创建或者在数据库服务器关闭 期间被创建。

\--------------------------------------------------------------------------------------------------------------------------

### 前言 ###

提示：如果是PostgreSQL复制流，需要先升级primary然后升级standby，否则会报错：

[postgres@host72 postgres]$ /usr/local/postgresql-10.22/bin/pg_upgrade -b /usr/local/postgresql-9.6.0/bin/ -B /usr/local/postgresql-10.22/bin/ -d /data/postgres_9.6/ -D /data/postgres_10.22/ -j 8 -p 5432 -P 5432 -k -c
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    
    The source cluster was shut down while in recovery mode.  To upgrade, use "rsync" as documented or shut it down as a primary.
    Failure, exiting

原版本：PostgreSQL 9.6.0

目标版本：PostgreSQL 14.5

### 源码安装PG 14.5 ###

安装依赖包

[root]# yum install -y perl-ExtUtils-Embed python-devel bison flex readline-devel zlib-devel gcc gcc-c++ wget

源码安装uuid

[root]# wget ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz
    [root]# tar -zxvf uuid-1.6.2.tar.gz
    [root]# cd uuid-1.6.2
    [root]# ./configure --with-uuid=ossp
    [root]# make && make install

源码安装PG 14.5

[root]# wget --no-check-certificate https://ftp.postgresql.org/pub/source/v14.5/postgresql-14.5.tar.gz
    [root]# tar -zxvf postgresql-14.5.tar.gz
    [root]# cd postgresql-14.5
    [root]# ./configure --prefix=/usr/local/postgresql-14.5 --with-perl --with-python --enable-thread-safety --with-uuid=ossp
    [root]# make && make install

安装contrib工具

[root]# cd postgresql-14.5/contrib
    [root]# make && make install

更新安装目录用户及属组

[root]# chown -R postgres:postgres /usr/local/postgresql-14.5

软链接libuuid.so.16

[root]# ln -s /usr/local/lib/libuuid.so.16 /usr/local/postgresql-14.5/lib/

创建PGDATA目录

[root]# mkdir /data/postgres_14.5
    [root]# chown postgres:postgres /data/postgres_14.5
    [root]# chmod 0700 /data/postgres_14.5

初始化postgres

[postgres]# /usr/local/postgresql-14.5/bin/initdb -D /data/postgres_14.5
    The files belonging to this database system will be owned by user "postgres".
    This user must also own the server process.
    
    The database cluster will be initialized with locale "en_US.UTF-8".
    The default database encoding has accordingly been set to "UTF8".
    The default text search configuration will be set to "english".
    
    Data page checksums are enabled.
    
    fixing permissions on existing directory /data/postgres_14.5 ... ok
    creating subdirectories ... ok
    selecting default max_connections ... 100
    selecting default shared_buffers ... 128MB
    selecting dynamic shared memory implementation ... posix
    creating configuration files ... ok
    running bootstrap script ... ok
    performing post-bootstrap initialization ... ok
    syncing data to disk ... ok
    
    WARNING: enabling "trust" authentication for local connections
    You can change this by editing pg_hba.conf or using the option -A, or
    --auth-local and --auth-host, the next time you run initdb.
    
    Success. You can now start the database server using:
    
        pg_ctl -D /data/postgres_14.5 -l logfile start

在线修改wal-segsize值为64M（缺省是16M）

[postgres]# pg_ctl start
    [postgres]# /usr/local/postgresql-14.5/bin/pg_resetwal --wal-segsize=64 /data/postgres_14.5
    Write-ahead log reset

### 升级primary ###

安装PostgreSQL 14.5，切记安装目录区分开

PG 9.6.0安装路径：/usr/local/postgresql-9.6.0，然后使用软链接到/usr/local/postgresql

PG 14.5安装路径： /usr/local/postgresql-14.5

关闭postgres服务

[postgres]# pg_ctl stop

使用14.5进行升级前检查（-c是check的意思）

[postgres@host71 postgres]# /usr/local/postgresql-14.5/bin/pg_upgrade -b /usr/local/postgresql-9.6.0/bin/ -B /usr/local/postgresql-14.5/bin/ -d /data/postgres_9.6/ -D /data/postgres_14.5/ -j 8 -p 5432 -P 5432 -c -k
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for system-defined composite types in user tables  ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for user-defined encoding conversions              ok
    Checking for user-defined postfix operators                 ok
    Checking for incompatible polymorphic functions             ok
    Checking for tables WITH OIDS                               ok
    Checking for invalid "sql_identifier" user columns          ok
    Checking for invalid "unknown" user columns                 ok
    Checking for hash indexes                                   ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok
    Checking for new cluster tablespace directories             ok
    
    *Clusters are compatible*

上面检查无问题后，下面进行升级（去掉-c参数）

[postgres@host71 postgres]$ /usr/local/postgresql-14.5/bin/pg_upgrade -b /usr/local/postgresql-9.6.0/bin/ -B /usr/local/postgresql-14.5/bin/ -d /data/postgres_9.6/ -D /data/postgres_14.5/ -j 8 -p 5432 -P 5432 -k
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for system-defined composite types in user tables  ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for user-defined encoding conversions              ok
    Checking for user-defined postfix operators                 ok
    Checking for incompatible polymorphic functions             ok
    Checking for tables WITH OIDS                               ok
    Checking for invalid "sql_identifier" user columns          ok
    Checking for invalid "unknown" user columns                 ok
    Creating dump of global objects                             ok
    Creating dump of database schemas
                                                                ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok
    Checking for new cluster tablespace directories             ok
    
    If pg_upgrade fails after this point, you must re-initdb the
    new cluster before continuing.
    
    Performing Upgrade
    ------------------
    Analyzing all rows in the new cluster                       ok
    Freezing all rows in the new cluster                        ok
    Deleting files from new pg_xact                             ok
    Copying old pg_clog to new server                           ok
    Setting oldest XID for new cluster                          ok
    Setting next transaction ID and epoch for new cluster       ok
    Deleting files from new pg_multixact/offsets                ok
    Copying old pg_multixact/offsets to new server              ok
    Deleting files from new pg_multixact/members                ok
    Copying old pg_multixact/members to new server              ok
    Setting next multixact ID and offset for new cluster        ok
    Resetting WAL archives                                      ok
    Setting frozenxid and minmxid counters in new cluster       ok
    Restoring global objects in the new cluster                 ok
    Restoring database schemas in the new cluster
                                                                ok
    Adding ".old" suffix to old global/pg_control               ok
    
    If you want to start the old cluster, you will need to remove
    the ".old" suffix from /data/postgres_9.6/global/pg_control.old.
    Because "link" mode was used, the old cluster cannot be safely
    started once the new cluster has been started.
    
    Linking user relation files
                                                                ok
    Setting next OID for new cluster                            ok
    Sync data directory to disk                                 ok
    Creating script to delete old cluster                       ok
    Checking for hash indexes                                   ok
    Checking for extension updates                              ok
    
    Upgrade Complete
    ----------------
    Optimizer statistics are not transferred by pg_upgrade.
    Once you start the new server, consider running:
        /usr/local/postgresql-14.5/bin/vacuumdb --all --analyze-in-stages
    
    Running this script will delete the old cluster's data files:
        ./delete_old_cluster.sh

修改PGDATA软链接指向新版本

[root]# unlink /data/postgres
    [root]# ln -s /data/postgres_14.5 /data/postgres

修改安装包的软链接

[root]# unlink /usr/local/postgresql
    [root]# ln -s /usr/local/postgresql-14.5 /usr/local/postgresql

与版本对比调整相关参数文件、启动14.5版本数据库、统计信息收集

[postgres]# vi $PGDATA/postgresql.conf
    [postgres]# vi $PGDATA/pg_hba.conf
    [postgres]# pg_ctl start
    [postgres]# vacuumdb --all --analyze-in-stages

### 升级standby ###

升级standby端，两种方法使用pg\_upgrade升级或者直接安装全新版本，最后始终都需要重新构建复制流。

关闭postgres服务

[postgres]# pg_ctl stop

PG 14.5升级前检查（-c是check的意思）

[postgres]# /usr/local/postgresql-10.22/bin/pg_upgrade -b /usr/local/postgresql-9.6.0/bin/ -B /usr/local/postgresql-10.22/bin/ -d /data/postgres_9.6/ -D /data/postgres_10.22/ -j 8 -p 5432 -P 5432 -k -c
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for system-defined composite types in user tables  ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for invalid "unknown" user columns                 ok
    Checking for hash indexes                                   ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok
    Checking for new cluster tablespace directories             ok
    
    *Clusters are compatible*

升级（去掉-c参数）

[postgres@host72 postgres]# /usr/local/postgresql-10.22/bin/pg_upgrade -b /usr/local/postgresql-9.6.0/bin/ -B /usr/local/postgresql-10.22/bin/ -d /data/postgres_9.6/ -D /data/postgres_10.22/ -j 8 -p 5432 -P 5432 -k
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for system-defined composite types in user tables  ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for invalid "unknown" user columns                 ok
    Creating dump of global objects                             ok
    Creating dump of database schemas
                                                                ok
    Checking for presence of required libraries                 ok
    Checking database user is the install user                  ok
    Checking for prepared transactions                          ok
    Checking for new cluster tablespace directories             ok
    
    If pg_upgrade fails after this point, you must re-initdb the
    new cluster before continuing.
    
    Performing Upgrade
    ------------------
    Analyzing all rows in the new cluster                       ok
    Freezing all rows in the new cluster                        ok
    Deleting files from new pg_xact                             ok
    Copying old pg_clog to new server                           ok
    Setting oldest XID for new cluster                          ok
    Setting next transaction ID and epoch for new cluster       ok
    Deleting files from new pg_multixact/offsets                ok
    Copying old pg_multixact/offsets to new server              ok
    Deleting files from new pg_multixact/members                ok
    Copying old pg_multixact/members to new server              ok
    Setting next multixact ID and offset for new cluster        ok
    Resetting WAL archives                                      ok
    Setting frozenxid and minmxid counters in new cluster       ok
    Restoring global objects in the new cluster                 ok
    Restoring database schemas in the new cluster
                                                                ok
    Adding ".old" suffix to old global/pg_control               ok
    
    If you want to start the old cluster, you will need to remove
    the ".old" suffix from /data/postgres_9.6/global/pg_control.old.
    Because "link" mode was used, the old cluster cannot be safely
    started once the new cluster has been started.
    
    Linking user relation files
                                                                ok
    Setting next OID for new cluster                            ok
    Sync data directory to disk                                 ok
    Creating script to analyze new cluster                      ok
    Creating script to delete old cluster                       ok
    Checking for hash indexes                                   ok
    Checking for extension updates                              ok
    
    Upgrade Complete
    ----------------
    Optimizer statistics are not transferred by pg_upgrade so,
    once you start the new server, consider running:
        ./analyze_new_cluster.sh
    
    Running this script will delete the old cluster's data files:
        ./delete_old_cluster.sh

修改相关软链接

[root]# unlink /data/postgres
    [root]# ln -s /data/postgres_14.5 /data/postgres
    [root]# unlink /usr/local/postgresql
    [root]# ln -s /usr/local/postgresql-14.5 /usr/local/postgresql

然后根据实际情况相关参数。

### 构建复制流 ###

同步primary端的PGDATA到standby端������到�������端PGDATA（可使用pg\_basebackup和rsync进行同步。）

[postgres]# rsync -avz postgres@192.168.1.71:/data/postgres_14.5/ /data/postgres_14.5

standby端创建standby.signal

[postgres]# touch $PGDATA/standby.signal
    [postgres]# chmod 0600 $PGDATA/standby.signal

standby端将复制流primary\_conninfo配置到postgresql.auto.conf中

[postgres]# vi $PGDATA/postgresql.auto.conf
    primary_conninfo = 'host=192.168.1.71 port=5432 user=repl password=postgres'

standby端启动standby端postgres

[postgres]# pg_ctl start

primary端查看复制流信息

### 升级检查报错 ###

升级前检查

根据提示查看pg\_upgrade\_server.log

[postgres]# cat pg_upgrade_server.log
    -----------------------------------------------------------------
      pg_upgrade run on Fri Sep 23 15:59:45 2022
    -----------------------------------------------------------------
    
    command: "/usr/local/postgresql-9.6.0/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/data/postgres_9.6" -o "-p 5432 -b  -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/data/postgres_9.6'" start >> "pg_upgrade_server.log" 2>&1
    waiting for server to start....LOG:  redirecting log output to logging collector process
    HINT:  Future log output will appear in directory "pg_log".
     done
    server started
    
    
    command: "/usr/local/postgresql-9.6.0/bin/pg_ctl" -w -D "/data/postgres_9.6" -o "" -m smart stop >> "pg_upgrade_server.log" 2>&1
    waiting for server to shut down.... done
    server stopped
    
    
    command: "/usr/local/postgresql-14.5/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/data/postgres_14.5" -o "-p 5432 -b -c synchronous_commit=off -c fsync=off -c full_page_writes=off -c vacuum_defer_cleanup_age=0  -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/data/postgres_9.6'" start >> "pg_upgrade_server.log" 2>&1
    waiting for server to start....2022-09-23 15:59:48.021 CST [62615] FATAL:  "min_wal_size" must be at least twice "wal_segment_size"
    2022-09-23 15:59:48.021 CST [62615] LOG:  database system is shut down
     stopped waiting
    pg_ctl: could not start server
    Examine the log output.

从上面的日志输出中截取重要报错部分：

FATAL:  "min_wal_size" must be at least twice "wal_segment_size"

安装PostgreSQL 14.5后，使用了pg\_resetwal修改了wal-segsize为=64M，默认min\_wal\_size值为80M，而根据报错提示min\_wal\_size=wal-segsize \* 2，也就是最少为128。将min\_wal\_size更改为128后

[postgres]# vi $PGDATA/postgresql.conf
    min_wal_size = 128

重新检查升级

无异常。

[34.16]: http://postgres.cn/docs/14/libpq-pgpass.html
[11]: http://postgres.cn/docs/14/pgupgrade.html#PGUPGRADE-STEP-REPLICAS
[17]: http://postgres.cn/docs/14/pgupgrade.html#PGUPGRADE-STEP-REVERT
[27.2.5]: http://postgres.cn/docs/14/warm-standby.html#STREAMING-REPLICATION
[27.2]: http://postgres.cn/docs/14/warm-standby.html
[26.3.3]: http://postgres.cn/docs/14/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP