PostgreSQL數據庫的升級

小版本升級

小版本升級基本上差很少,具體看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。數據庫

大版本升級

1、使用pg_dump方法升級

一、導出數據庫全局對象數據和各個數據庫的數據
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

2、使用pg_upgrade方法升級

以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升級適合對數據庫在線時間要求不嚴,並且數據量不大的系統。

3、使用主從複製工具在線升級

由於postgresql的熱備要求數據庫版本,操做系統版本一致,因此主從複製須要使用第三方工具,能夠選擇Londiste或者Slony。由於slony和PostgreSQL的版本相關,相對沒有londiste靈活,因此這裏我選擇用Londiste做爲跨數據庫版本的複製工具。

這個升級的基本步驟以下:
一、在從服務器上安裝最新版的postgresql;
二、配置londiste主從複製;
三、測試從服務器postgresql是否和應用兼容;
四、測試沒問題後修改鏈接池到新的服務器。

原文連接:http://www.sijitao.net/1597.html

相關文章
相關標籤/搜索