PostgreSQL数据库的升级

小版本升级

小版本升级基本上差不多，具体看postgresql的release note，注意其中的注意事项。

以9.2.4升级到9.2.7为例

1、备份原数据目录文件，以防万一。
2、下载9.2.7：wget http://get.enterprisedb.com/postgresql/postgresql-9.2.7-1-linux-x64.run
3、安装到新目录：./postgresql-9.2.7-1-linux-x64.run
4、暂停原数据库，修改$PGHOME 环境变量，比如/opt/PostgreSQL/9.2.7/
5、使用新版本的PostgreSQL程序启动服务（ $PGDATA还是和原来一样）

总结：先安装新版本程序后再升级，这种办法停数据库时间比直接覆盖原安装目录的方式短些，少了安装的时间。编译安装postgresql的话可以参考这篇文章：https://zhangnq.com/1535.html。

大版本升级

一、使用pg_dump方法升级

1、导出数据库全局对象数据和各个数据库的数据
pg_dumpall -g >globle_dbk.sql //导出数据库全局对象
pg_dump -c forummon >forummon_dbk.sql //导出forummon数据
...... //多个数据库多次导出备份

数据量小的话可以用pg_dumpall导出整个数据库。
pg_dumpall >dbk.sql
2、安装最新版的postgresql数据库
3、导入备份的数据到最新版数据库
4、修改postgresql相关环境变量，重启数据库

如果数据库做了hot standby，需要先对备份数据库升级，然后再升级主数据库。

总结：基于pg_dump备份恢复的升级比单纯用pg_upgrade升级减少了停止数据库时间。但是缺点也很明显，即使数据库在线，备份到升级完成这段时间内的数据仍然保存在旧的数据库。这种办法适合一段时间内数据不变的数据库。

二、使用pg_upgrade方法升级

以9.2.7升级到9.3.3为例

1、下载、安装最新版的postgresql数据库
2、备份数据库数据文件到/data/pgsql92/
rsync -azv /data/pgsql/* /data/pgsql92/
关闭原postgresql 9.2数据库，再次运行rsync，确保数据文件一致。
rsync -azv /data/pgsql/* /data/pgsql92/
3、修改pg_hba.conf认证文件，把postgresql 9.2和postgresql 9.3的本地登录都改成trust。
比如：
# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all postgres trust

如果出现类似下面这种错误都是认证的原因，因为pg_upgrade在升级过程中会多次连接新旧数据库。

postgres@vm231:~$ /opt/PostgreSQL/9.3/bin/pg_upgrade -b /opt/PostgreSQL/9.2/bin -B /opt/PostgreSQL/9.3/bin -d /data/pgsql/ -D /data/pgsql93/ -p 3500 -P 3600 -c
Performing Consistency Checks
-----------------------------
Checking cluster versions ok

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or directory
 Is the server running locally and accepting
 connections on Unix domain socket "/home/postgres/.s.PGSQL.3500"?


could not connect to old postmaster started with the command:
"/opt/PostgreSQL/9.2/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/data/pgsql/" -o "-p 3500 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/home/postgres'" start
Failure, exiting

4、运行升级测试
这一步可以在数据库运行的情况下操作

postgres@vm231:~$ /opt/PostgreSQL/9.3/bin/pg_upgrade -b /opt/PostgreSQL/9.2/bin -B /opt/PostgreSQL/9.3/bin -d /data/pgsql/ -D /data/pgsql93/ -p 3500 -P 3600 -c
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for presence of required libraries ok
Checking database user is a superuser ok
Checking for prepared transactions ok

*Clusters are compatible*

出现以上内容说明可以升级。
5、分别关闭postgresql 9.2和postgresql 9.3数据库
6、开始运行pg_upgrade

postgres@vm231:~$ /opt/PostgreSQL/9.3/bin/pg_upgrade -b /opt/PostgreSQL/9.2/bin -B /opt/PostgreSQL/9.3/bin -d /data/pgsql/ -D /data/pgsql93/ -p 3500 -P 3600
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Creating dump of global objects ok
Creating dump of database schemas
 ok
Checking for presence of required libraries ok
Checking database user is a superuser 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 on the new cluster ok
Deleting files from new pg_clog ok
Copying old pg_clog to new server ok
Setting next transaction ID for new cluster ok
Setting oldest multixact ID on new cluster ok
Resetting WAL archives ok
Setting frozenxid counters in new cluster ok
Restoring global objects in the new cluster ok
Adding support functions to new cluster ok
Restoring database schemas in the new cluster
 ok
Removing support functions from 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

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

出现这个提示说明升级成功。
7、修改postgresql相关环境变量到新数据库，还原第3步中的pg_hba.conf配置。
8、启动新数据库，运行analyze_new_cluster.sh脚本。

postgres@vm231:~$ ./analyze_new_cluster.sh
This script will generate minimal optimizer statistics rapidly
so your system is usable, and then gather statistics twice more
with increasing accuracy. When it is done, your system will
have the default level of optimizer statistics.

If you have used ALTER TABLE to modify the statistics target for
any tables, you might want to remove them and restore them after
running this script because they will delay fast statistics generation.

If you would like default statistics as quickly as possible, cancel
this script and run:
 "/opt/PostgreSQL/9.3/bin/vacuumdb" --all --analyze-only

Generating minimal optimizer statistics (1 target)
--------------------------------------------------
vacuumdb: vacuuming database "postgres"
vacuumdb: vacuuming database "template1"
vacuumdb: vacuuming database "zhangnq"

The server is now available with minimal optimizer statistics.
Query performance will be optimal once this script completes.

Generating medium optimizer statistics (10 targets)
---------------------------------------------------
vacuumdb: vacuuming database "postgres"
vacuumdb: vacuuming database "template1"
vacuumdb: vacuuming database "zhangnq"

Generating default (full) optimizer statistics (100 targets?)
-------------------------------------------------------------
vacuumdb: vacuuming database "postgres"
vacuumdb: vacuuming database "template1"
vacuumdb: vacuuming database "zhangnq"

Done

9、进入数据库，确认成功升级。

postgres=# select version() ;
 version
---------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit
(1 row)

如果数据库做了hot standby，需要先对备份数据库升级，然后再升级主数据库。

总结：这种升级方法缺点有以下几点：1、必须关闭数据库升级；2、升级中需要确保磁盘空间至少和数据库大小一样，升级时需要生成数据的复制；3、如果数据量太大，那么升级过程会很慢；4、升级前没有对新数据进行测试，无法知晓是否和应用兼容。单纯pg_upgrade升级适合对数据库在线时间要求不严，而且数据量不大的系统。

三、使用主从复制工具在线升级

因为postgresql的热备要求数据库版本，操作系统版本一致，所以主从复制需要使用第三方工具，可以选择Londiste或者Slony。因为slony和PostgreSQL的版本相关，相对没有londiste灵活，所以这里我选择用Londiste作为跨数据库版本的复制工具。

这个升级的基本步骤如下：
1、在从服务器上安装最新版的postgresql；
2、配置londiste主从复制；
3、测试从服务器postgresql是否和应用兼容；
4、测试没问题后修改连接池到新的服务器。