PG_版本升级

概念

　　本节讨论如何把数据库数据从一个PostgreSQL版本升级到一个更新的版本。

　　当前PostgreSQL版本号由主要版本号和次要版本号组成。例如，在版本号10.1中，10是主要版本号，1是次要版本号，这意味着这将是主版本10的第一个次要版本。对于PostgreSQL版本10.0之前的版本，版本号由三个数字组成，例如9.5.3。在这些情况下，主要版本由版本号的前两个数字组（例如9.5）组成，次要版本是第三个数字，例如3，这意味着这将是主要版本9.5的第三次要版本。

　　次要发行从来不改变内部存储格式并且总是向前并向后兼容同一主版本号中的次要发行。例如版本10.1与版本10.0和版本10.6兼容。类似的，例如9.5.3与9.5.0、9.5.1和9.5.6兼容。

要在兼容的版本间升级，你只需要简单地在服务器关闭时替换可执行文件并重启服务器。数据目录则保持不变--次要升级就这么简单。

　　对于PostgreSQL的主发行，内部数据存储格式常被改变，这使升级复杂化。传统的把数据移动到新主版本的方法是先转储然后重新载入到数据库，不过这可能会很慢。一种更快的方式是pg_upgrade。如下文所讨论的，复制方法也能被用于升级。

通过pg_dumpall升级数据

　　直接用pg_dumpall转储就行了

通过pg_upgrade升级数据

描述

　　主 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 可执行文件目录；环境变量PGBINNEW

-c

--check

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

-d configdir

--old-datadir=configdir

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

-D configdir

--new-datadir=configdir

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

-j

--jobs

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

-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

显示帮助，然后退出

--注释

-k/--link 硬链接是有着相同inode号文件名不同的文件，删除一个硬链接文件不影响其他有相同inode号的文件。

升级前准备

在升级前进行备份，任何对库操作前必须进行备份，留有后路。
用兼容旧集簇的configure标记编译新的 PostgreSQL 源码。
安装新的PostgreSQL 二进制文件：make prefix=/usr/local/pgsql.new install
初始化，使用与旧集簇相兼容的initdb标志；这里没有必要启动新集簇。
安装自定义的共享对象文件，把旧集簇使用的所有自定义共享对象文件（或者 DLL）安装到新集簇中，例如pgcrypto.so，不管它们是来自于 contrib还是某些其他源码。不要安装模式定义 （例如CREATE EXTENSION pgcrypto），因为这些将会从旧集簇升级得到。还有，任何自定义的全文搜索文件（词典、同义词、辞典、停用词）也必须被复制到新集簇中。
调整认证；pg_upgrade将会多次连接到旧服务器和新服务器，因此你可能想要在pg_hba.conf中把认证设置成 peer或者使用一个~/.pgpass文件

升级

本文以9.6版本升级到13.0为例。

1.准备好新版本环境，见“升级前准备”；

2. 停数据库服务。

# su - postgres -c "/opt/pgsql/bin/pg_ctl -D /pgsql/data_10 stop"

waiting for server to shut down....2020-11-02 15:32:22.968 CST [61378] LOG: received fast shutdown request

2020-11-02 15:32:22.970 CST [61378] LOG: aborting any active transactions

2020-11-02 15:32:22.970 CST [61485] FATAL: terminating autovacuum process due to administrator command

2020-11-02 15:32:22.970 CST [61614] FATAL: terminating autovacuum process due to administrator command

2020-11-02 15:32:22.971 CST [61378] LOG: worker process: logical replication launcher (PID 61385) exited with exit code 1

2020-11-02 15:32:22.976 CST [61380] LOG: shutting down

2020-11-02 15:32:23.142 CST [61378] LOG: database system is shut down

done

server stopped

3. pg_upgrade -c 验证两个集簇是否兼容（出现标红内容表示兼容）

#/opt/pgsql/13/bin/pg_upgrade -c -k -b /opt/pgsql/bin -B /opt/pgsql/13/bin -d /pgsql/data_10 -D /pgsql/data -p 5432 -P 5433 –v

….

*Clusters are compatible*

"/opt/pgsql/13/bin/pg_ctl" -w -D "/pgsql/data" -o "" -m smart stop >> "pg_upgrade_server.log" 2>&1

4. 执行升级

pg_upgrade升级有三种方式。

常规复制方式；不会对旧集簇产生影响，但是当数据文件大时速度慢。

/opt/pgsql/13/bin/pg_upgrade -b /opt/pgsql/bin -B /opt/pgsql/13/bin -d /pgsql/data_10 -D /pgsql/data -p 5432 -P 5433 -v

-k/--link链接方式；以硬链接方式重用旧的用户数据文件来执行快速升级，节省磁盘空间，但升级后旧集簇不可用，恢复耗时。

/opt/pgsql/13/bin/pg_upgrade -k -b /opt/pgsql/bin -B /opt/pgsql/13/bin -d /pgsql/data_10 -D /pgsql/data -p 5432 -P 5433 -v

--clone 克隆方式；结合以上两者的优势，它支持在Linux（内核4.5或更高版本）上的Btrfs和XFS（在文件系统创建reflink支持）。

/opt/pgsql/13/bin/pg_upgrade --clone -b /opt/pgsql/bin -B /opt/pgsql/13/bin -d /pgsql/data_10 -D /pgsql/data -p 5432 -P 5433 -v

以-k/--link链接方式为例：（出现标红的字段表示升级成功）

#/opt/pgsql/13/bin/pg_upgrade -k -b /opt/pgsql/bin -B /opt/pgsql/13/bin -d /pgsql/data_10 -D /pgsql/data -p 5432 -P 5433 -v

……

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

5. 恢复配置文件

新版本的postgresql.conf和pg_hba.conf等配置文件匹配旧集簇参数。

启动新数据库服务
升级后处理；如果需要做任何升级后处理，pg_upgrade 将在完成后发出警告。它也将生成必须由管理员运行的脚本文件。这些脚本文件将连接到每一个需要做升级后处理的数据库。每一个脚本应该这样运行

psql --username=postgres --file=script.sql postgres

#这些脚本可以以任何顺序运行并且在运行之后立即删除。删除之前不应该访问引用的表。

6. 收集统计信息

在升级的尾声你将被指示运行一个命令来生成这些信息。如“步骤4”黄色背景部分。./analyze_new_cluster.sh；如果报错，可以手动配置连接参数执行。

#/opt/pgsql/13/bin/vacuumdb --all --analyze-in-stages

vacuumdb: error: could not connect to database template1: could not connect to server: No such file or directory

Is the server running locally and accepting

connections on Unix domain socket "/tmp/.s.PGSQL.28375"?

[postgres@dgZH8118 ~]$ /opt/pgsql/13/bin/vacuumdb --all --analyze-in-stages -p 5433

vacuumdb: processing database "postgres": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "template1": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "postgres": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "template1": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "postgres": Generating default (full) optimizer statistics

vacuumdb: processing database "template1": Generating default (full) optimizer statistics

7. 删除旧集簇

一旦你对升级表示满意，你就可以通过运行 pg_upgrade完成时提到的脚本来删除旧集簇的数据目录（如果在旧数据目录中有用户定义的表空间就不可能实现自动删除）。你也可以删除旧安装目录（例如bin、share）。

8. 恢复到旧集簇

在运行pg_upgrade之后，如果你希望恢复到旧集簇，有几个选项：

如果使用了 --check 选项, 则旧集群没有被修改；它可以被重新启动。
如果 --link 选项没有被使用, 旧集群没有被修改；它可以被重新启动。
如果使用了--link 选项, 数据文件可能在新旧群集之间共享:

如果pg_upgrade在链接启动之前中止，旧群集没有被修改，它可以重新启动。
如果你没有启动新集群，旧集群没有被修改，当链接启动时，一个.old后缀会附加到$PGDATA/global/pg_control。如果要重用旧集群，从$PGDATA/global/pg_control移除.old后缀；你就可以重启旧集群。
如果你已经启动新群集，它已经写入了共享文件，并且使用旧群集会不安全。这种情况下，需要从备份中还原旧群集。
插件引起升级失败。

FAQ

1. 插件引起升级失败。

　　你可能需要从旧集簇中卸载该模块并且在升级后重新把它安装在新集簇中，不过这样做的前提是该模块没有被用来存储用户数据。

2. 升级完成后，执行更新统计信息失败。

　　可能需要设置连接参数来匹配你的新集簇

通过复制升级数据

　　可以用PostgreSQL的已更新版本逻辑复制来创建一个~ 后备服务器，逻辑复制支持在不同主版本的PostgreSQL之间~ 的复制。后备服务器可以在同一台计算机或者不同的计算机上。一旦它和主服务器（运行旧版本的PostgreSQL）同步好，你可以切换主机并且将后备服~ 务器作为主机，然后关闭旧的数据库实例。这样一种切换使得一次升级的停机时间只有数秒。

　　这种升级方法可以用内置的逻辑复制工具和外部的逻辑复制系统如pglogical，Slony，Londiste，和Bucardo。

底线返回TOP

posted @ 2020-11-03 21:19 DUAN的博客阅读(894) 评论(0) 收藏举报

刷新页面返回顶部

段磊的博客