小版本升级基本上差很少，具体看postgresql的release note，注意其中的注意事项。html
以9.2.4升级到9.2.7为例linux
一、备份原数据目录文件，以防万一。
二、下载9.2.7：wget http://get.enterprisedb.com/postgresql/postgresql-9.2.7-1-linux-x64.run
三、安装到新目录：./postgresql-9.2.7-1-linux-x64.run
四、暂停原数据库，修改$PGHOME 环境变量，好比/opt/PostgreSQL/9.2.7/
五、使用新版本的PostgreSQL程序启动服务（ $PGDATA仍是和原来同样）sql
总结：先安装新版本程序后再升级，这种办法停数据库时间比直接覆盖原安装目录的方式短些，少了安装的时间。编译安装postgresql的话能够参考这篇文章：http://www.sijitao.net/1535.html。数据库
一、导出数据库全局对象数据和各个数据库的数据
pg_dumpall -g >globle_dbk.sql //导出数据库全局对象
pg_dump -c forummon >forummon_dbk.sql //导出forummon数据
…… //多个数据库屡次导出备份api
数据量小的话能够用pg_dumpall导出整个数据库。
pg_dumpall >dbk.sql
二、安装最新版的postgresql数据库
三、导入备份的数据到最新版数据库
四、修改postgresql相关环境变量，重启数据库服务器
若是数据库作了hot standby，须要先对备份数据库升级，而后再升级主数据库。dom
总结：基于pg_dump备份恢复的升级比单纯用pg_upgrade升级减小了中止数据库时间。可是缺点也很明显，即便数据库在线，备份到升级完成这段时间内的数据仍然保存在旧的数据库。这种办法适合一段时间内数据不变的数据库。socket
以9.2.7升级到9.3.3为例ide
一、下载、安装最新版的postgresql数据库
二、备份数据库数据文件到/data/pgsql92/
rsync -azv /data/pgsql/* /data/pgsql92/
关闭原postgresql 9.2数据库，再次运行rsync，确保数据文件一致。
rsync -azv /data/pgsql/* /data/pgsql92/
三、修改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
四、运行升级测试
这一步能够在数据库运行的状况下操做
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*
出现以上内容说明能够升级。
五、分别关闭postgresql 9.2和postgresql 9.3数据库
六、开始运行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
出现这个提示说明升级成功。
七、修改postgresql相关环境变量到新数据库，还原第3步中的pg_hba.conf配置。
八、启动新数据库，运行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
九、进入数据库，确认成功升级。
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，须要先对备份数据库升级，而后再升级主数据库。
总结：这种升级方法缺点有如下几点：一、必须关闭数据库升级；二、升级中须要确保磁盘空间至少和数据库大小同样，升级时须要生成数据的复制；三、若是数据量太大，那么升级过程会很慢；四、升级前没有对新数据进行测试，没法知晓是否和应用兼容。单纯pg_upgrade升级适合对数据库在线时间要求不严，并且数据量不大的系统。
由于postgresql的热备要求数据库版本，操做系统版本一致，因此主从复制须要使用第三方工具，能够选择Londiste或者Slony。由于slony和PostgreSQL的版本相关，相对没有londiste灵活，因此这里我选择用Londiste做为跨数据库版本的复制工具。
这个升级的基本步骤以下：
一、在从服务器上安装最新版的postgresql；
二、配置londiste主从复制；
三、测试从服务器postgresql是否和应用兼容；
四、测试没问题后修改链接池到新的服务器。
原文连接：http://www.sijitao.net/1597.html