postgresql夸版本升级方案

postgresql夸版本升级方案

测试PG数据库夸版本升级方案，从PG9.5升级到最新的PG12。
方案主要包括三种：
1，pg_upgrade方案，使用pg_upgrade升级工具进行升级
2，pg_dumpall方案，使用pg_dumpall工具对9.5的旧库全备份，然后还原到12
3，pglogical 复制方案

方案1 pg_upgrade升级工具

• 停止旧库和新库的运行

bash-4.2$ ./pg_ctl stop -D /usr/pgsql-9.5/data/
waiting for server to shut down.... done
server stopped
bash-4.2$ exit

bash-4.2$ ./pg_ctl stop -D /usr/pgsql-12/data/
waiting for server to shut down.... done
server stopped

• 执行升级检查

cd /usr/pgsql-12/bin/
su postgres

#看一下pg_upgrade的帮助
./pg_upgrade --help
pg_upgrade upgrades a PostgreSQL cluster to a different major version.

Usage:
 pg_upgrade [OPTION]...

Options:
 -b, --old-bindir=BINDIR       old cluster executable directory
 -B, --new-bindir=BINDIR       new cluster executable directory
 -c, --check                   check clusters only, don't change any data
 -d, --old-datadir=DATADIR     old cluster data directory
 -D, --new-datadir=DATADIR     new cluster data directory
 -j, --jobs                    number of simultaneous processes or threads to use
 -k, --link                    link instead of copying files to new cluster
 -o, --old-options=OPTIONS     old cluster options to pass to the server
 -O, --new-options=OPTIONS     new cluster options to pass to the server
 -p, --old-port=PORT           old cluster port number (default 50432)
 -P, --new-port=PORT           new cluster port number (default 50432)
 -r, --retain                  retain SQL and log files after success
 -s, --socketdir=DIR           socket directory to use (default current dir.)
 -U, --username=NAME           cluster superuser (default "postgres")
 -v, --verbose                 enable verbose internal logging
 -V, --version                 display version information, then exit
 --clone                       clone instead of copying files to new cluster
 -?, --help                    show this help, then exit

Before running pg_upgrade you must:
 create a new database cluster (using the new version of initdb)
 shutdown the postmaster servicing the old cluster
 shutdown the postmaster servicing the new cluster

When you run pg_upgrade, you must provide the following information:
 the data directory for the old cluster  (-d DATADIR)
 the data directory for the new cluster  (-D DATADIR)
 the "bin" directory for the old version (-b BINDIR)
 the "bin" directory for the new version (-B BINDIR)

For example:
 pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin
or
 $ export PGDATAOLD=oldCluster/data
 $ export PGDATANEW=newCluster/data
 $ export PGBINOLD=oldCluster/bin
 $ export PGBINNEW=newCluster/bin
 $ pg_upgrade

Report bugs to .

#执行检查
./pg_upgrade -c -b /usr/pgsql-9.5/bin/ -B /usr/pgsql-12/bin/ -d /usr/pgsql-9.5/data/ -D /usr/pgsql-12/data/ -p 5432 -P 5433
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 reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       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 roles starting with "pg_"                      ok
Checking for presence of required libraries                 fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
   loadable_libraries.txt

Failure, exiting
bash-4.2$ exit

根据上述日期可以看出，未通过检查，根据日志内容，确定是由于旧库中安装了pg_pathman插件，而新库中未安装，导致失败。对新库安装pg_pathman插件后再执行检查

#对新库安装pg_pathman插件
省略安装步骤。。。。

bash-4.2$ ./pg_upgrade -c -b /usr/pgsql-9.5/bin/ -B /usr/pgsql-12/bin/ -d /usr/pgsql-9.5/data/ -D /usr/pgsql-12/data/ -p 5432 -P 5433
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 reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       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 roles starting with "pg_"                      ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

*Clusters are compatible*

检查通过

• 执行升级
  升级方式有两种，一种是使用 --link参数，升级时，不拷贝数据文件，直接使用硬链接
  另一种是不使用 --link参数，需要拷贝拷贝文件。
  此次测试不使用 --link参数

bash-4.2$ ./pg_upgrade -b /usr/pgsql-9.5/bin/ -B /usr/pgsql-12/bin/ -d /usr/pgsql-9.5/data/ -D /usr/pgsql-12/data/ -p 5432 -P 5433
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 reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for invalid "unknown" user columns                 ok
Checking for roles starting with "pg_"                      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

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 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
Copying 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

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

升级完成，并生成了analyze_new_cluster.sh和delete_old_cluster.sh两个文件，分别为对新库执行analyze以及删除旧库的功能；

analyze_new_cluster.sh文件中的命令为：
“/usr/pgsql-12/bin/vacuumdb” --all --analyze-in-stages
增加连接参数手动执行上述命令

"/usr/pgsql-12/bin/vacuumdb" --all --analyze-in-stages -h localhost -p 5433

对所有的库执行vacuum操作，统计数据库信息；

至此，升级完成。

方案2 pg_dumpall备份恢复升级

使用pg_dumpall工具对旧库做全备份，之后在新库上恢复即可，不再详细演示。
说明：

• pg_dumpall备份恢复需要一定的时间，特别是对数据量较大的库，此时无法做到旧库和新库之间的无缝切换，对于频繁写数据的场景，有丢数据的风险，需要特别注意。

方案3 pglogical 复制升级

• pglogical 官网：
  https://www.2ndquadrant.com/

• 官网安装说明：
  https://www.2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/

• 环境准备
  对PG9.5和PG12 分别安装对应的pglogical插件，根据上述安装说明，在服务器上安装pglogical的yum源

安装pg9.5的pglogical的yum源：
curl https://access.2ndquadrant.com/api/repository/dl/default/release/9.5/rpm | bash

安装pg12的pglogical的yum源：
curl https://access.2ndquadrant.com/api/repository/dl/default/release/12/rpm | bash


分别安装pg9.5和pg12的pglogical插件:
yum install postgresql9.5-pglogical.x86_64

yum install postgresql12-pglogical.x86_64

修改postgresql.conf配置文件：
wal_level = logical
shared_preload_libraries = 'pglogical'

max_worker_processes = 10   # one per database needed on provider node 需大于max_wal_senders + 其他进程个数
                            # one per node needed on subscriber node
max_replication_slots = 10  # one per node needed on provider node	每一个订阅消耗一个slot
max_wal_senders = 10        # one per node needed on provider node 每一个slot对应一个sender
shared_preload_libraries = 'pglogical'

上述配置为官方文档中的建议。注意：上述参数的名称在不同版本的pg库中，命名会有变化。

修改pg_hba.conf文件

#因为主备库都在本机，所以此配置即可
local   replication     all                                     trust

#如果不是本机，则需要配置：

host  replication     all                x.x.x.x/x           trust

保存重启数据库服务

• 创建provide提供者节点配置

#创建节点
huajie_data_energysystem=# SELECT pglogical.create_node(node_name := 'provider', dsn := 'host=localhost port=5432 dbname=huajie_data_energysystem');
 create_node 
-------------
  3171898924
(1 row)

#创建复制集，把public下的所有表添加到复制集
huajie_data_energysystem=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']);
ERROR:  table _c3p0_test cannot be added to replication set default
DETAIL:  table does not have PRIMARY KEY and given replication set is configured to replicate UPDATEs and/or DELETEs
HINT:  Add a PRIMARY KEY to the table

#报错，原因是_c3p0_test表没有主键。解决无主键表的问题后，再次执行成功
huajie_data_energysystem=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']);
 replication_set_add_all_tables 
--------------------------------
 t
(1 row)

#如果需要同步序列，则把序列add到复制集
huajie_data_energysystem=# select pglogical.replication_set_add_all_sequences('ddl_sql', ARRAY['public'], true);

• 创建订阅者配置

#创建节点
huajie_data_energysystem=# SELECT pglogical.create_node(node_name := 'subscriber', dsn := 'host=localhost port=5433 dbname=huajie_data_energysystem');
 create_node 
-------------
  2941155235
(1 row)

huajie_data_energysystem=# SELECT pglogical.create_subscription( subscription_name := 'subscriber', provider_dsn := 'host=localhost port=5432 dbname=huajie_data_energysystem');
 create_subscription
---------------------
         2941155235

#创建完成后，系统即开始同步操作，如果数据表中数据较多，需要一定时间做基础数据同步。

• 维护

#在提供者服务上查询当前同步表：
select * from pglogical.replication_set_table；

#如何创建新表：
1）在提供者服务上创建了新表
2）同步在订阅服务上创建对应的表
3）在提供者服务上把新表添加到复制集，如：
select pglogical.replication_set_add_table( set_name := 'default', relation := 'test2',synchronize_data := true);
即把test2表添加奥default复制集，同时同步数据
4）如果使用了pg_pathman做了分表处理，那么需要把每个子表也添加到复制集

5）删除订阅信息
select pglogical.drop_subscription(subscription_name := 'subscriber',ifexists := true);
 drop_subscription 
-------------------
                 1
(1 row)

6）删除两个库上的pglogical节点
select pglogical.drop_node(node_name := 'subscriber', ifexists := true);
 drop_node 
-----------
 t
(1 row)

select pglogical.drop_node(node_name := 'provider', ifexists := true);
 drop_node 
-----------
 t
(1 row)

• 冲突解决
  冲突检测需要 PostgreSQL 9.5 +
  如果节点订阅多个提供程序，或当本地写入在订阅服务器上发生，可能会发生冲突，尤其是对传入的变化。这些都自动检测，并可以就此采取行动取决于配置。
  解决冲突的办法是通过配置 pglogical.conflict_resolution 参数。
  pglogical.conflict_resolution 支持的配置参数选项为︰

  error - 复制将停止上错误如果检测到冲突和手动操作需要解决
  apply_remote - 总是应用与本地数据有冲突的更改，这是默认值
  keep_local - 保留数据的本地版本，并忽略来自远程节点相互冲突的更改
  last_update_wins - 时间戳为提交最新的版本(newest commit timestamp)的数据将会被保存(这可以是本地或远程版本）
  first_update_wins - 时间戳为最旧的版本(oldest timestamp)的数据将会被保存(这可以是本地或远程版本）
  当参数track_commit_timestamp被禁用时，唯一允许的配置值是 apply_remote。 PostgreSQL 9.4 不支持 track_commit_timestamp 配置参数只能配置参数apply_remote(该参数是默认值)。

	#修改订阅者的postgresql.conf配置文件
	track_commit_timestamp = on
	pglogical.conflict_resolution = 'last_update_wins'

• 数据检查
  检查提供者和订阅者之间的数据是否一致，如一致则可进行业务切换。

• 业务切换
  1）停止PG9.5服务的运行；
  2）修改PG12监听的端口为5432；
  3）重启PG12服务；
  4）观察系统是否运行正常；
  5）如果升级后，系统运行异常，则可停止PG12服务运行，重启PG9.5，继续使用旧库；

三种升级方案优缺点

方案	优点	缺点
pg_upgrade方案	操作简单	1）需要停库，不适合数据量大、频繁写入的业务 2）–link方式升级较快，但影响回退
pg_dumpall方案	操作简单	1）对于数据量较大的库，备份和还原需要一定时间，前进写入的数据会丢失
pglogical方案	停库时间短，可实现秒级的切换，对业务影响小	1）配置较复杂，需要对每个库都配置同步

参考资料

1）pglogical官方文档：官方文档
2）https://www.dazhuanlan.com/2019/09/29/5d8f931a2d902/
3）https://www.cnblogs.com/lottu/p/10972773.html