PostgreSQL數據庫備份與恢復

PostgreSQL備份與恢復

    PostgreSQL提供了三種備份和恢復的方式:SQL dump、文件系統複製和聯機熱備份。 每一種備份方式都有自己的優點和缺點，下面將詳細介紹。

9.1 SQL Dump
     這種備份方式產生一個文本文件，裏面包含創建各種數據庫對象的SQL語句和每個表中的數據。另外，表上創建的索引中的數據不會被導出，只會導出 索引的定義信息。在恢復數據庫的時候，索引會被重建。可以使用數據庫提供的工具pg_dumpall和pg_dump來進行備份。pg_dumpall會 備份一個數據庫集羣中的所有信息和數據。pg_dump只備份數據庫集羣中的某個數據庫的數據，它不會導出角色和表空間相關的信息，因爲這些信息是整個數 據庫集羣共用的，不屬於某個單獨的數據庫。pg_dump的基本用法如下：

pg_dump 數據庫名 > 備份文件名

pg_dump將結果寫到標準輸出中，可以用操作系統的重定向命令將結果寫到文件中。

 

    可以在運行數據庫的機器上執行pg_dump命令，也可以在其它的機器上執行pg_dump命令。 可以使用選項-h和-p來指定運行數據庫的主機名和數據庫監聽的端口。例如：

pg_dump -h db_server1 -p 5432  product > backup_file 

該命令連接機器db_server1上在端口5432處監聽的數據庫，將數據庫product的數據備份到文件backup_file中。如果 pg_dump命令沒有使用-h和-p選項，將使用環境變量PGHOST的值作爲機器名，使用環境變量PGPORT的值作爲數據庫的端口。如果用戶沒有定 義環境變量PGHOST，默認使用本機名作爲運行數據庫的機器名。

 

     默認的情況下，pg_dump使用當前的操作系統用戶作爲連接數據庫時使用的用戶。可以使用選項-U或者設置環境變量PGUSER來指定連接數據庫時使用的用戶名。例如：

pg_dump -U liming -h db_server1 -p 5432  product > backup_file 

該命令使用用戶liming連接機器db_server1上在端口5432處監聽的數據庫，將數據庫product的數據備份到文件backup_file中。

 

一般情況下，應該使用超級用戶連接數據庫進行備份操作，因爲超級用戶可以訪問數據庫中的任何信息。使用普通數據用戶連接數據庫，有些表可能無法訪問。

 

運行pg_dump時，數據可以正常地執行其它操作。但ALTER TABLE這類修改數據庫對象定義的操作會受到影響，可能會長時間處於等待狀態而無法執行，所以在運行pg_dump命令時，不要在數據庫中運行修改數據庫對象定義的操作。

 

    另外要注意的是，如果數據庫中有些表使用OID來實現外鍵約束，應當在備份數據庫時同時備份表的OID信息，使用pg_dump時加上選項–o即可達到這個目的。

9.1.1 恢復數據庫
    pg_dump創建的備份文件可以被工具psql識別。因此可以使用psql來讀取pg_dump創建的備份文件，實現恢復數據庫的功能。例如：

psql dbname < backup_file

psql後面的參數dbname指定的數據庫必須已經存在。如果不存在，用戶應當先創建dbname指定的數據庫，然後再執行恢復數據的命令。psql也 支持和pg_dump一樣的命令行選項，如-h和-p等。創建數據庫dbname時，必須使用template0作爲模板數據庫，可以使用工具 createdb創建數據庫，也可以在psql中執行SQL命令create database來創建數據庫。下面是兩個實例：

（1）createdb -T template0 dbname

（2）create database dbname template=template0

 

    另外，在執行恢復數據的操作以前，那些擁有數據庫備份中的數據庫對象或則對這些對象有訪問權限的數據庫的用戶必須已經在數據庫中存在，否則，恢復數據庫以後，數據庫備份中的數據庫對象的所有者會發生改變。

 

    默認的情況下，psql命令會一直執行下去直到結束，即使中間遇到SQL錯誤，恢復操作也會繼續執行。如果想讓psql在執行過程中遇到錯誤以後，停止恢復操作，可以在執行恢復操作以前，在psql中運行下面的命令：

\set ON_ERROR_STOP

 

    如果psql在執行過程中遇到錯誤，則只有一部分數據被正確地恢復，這時被恢復數據庫中的數據是不完整的。psql提供了另外一種恢復模式，在這 種模式下，一旦恢復操作執行過程中遇到任何錯誤，已經恢復的數據都會自動從數據庫中被刪除。可以使用psql的命令行選項-l或--single- transaction來打開這種模式。

在恢復操作結束以後，應該使用ANALYZE命令來重新收集查詢優化器統計數據。

9.1.2 使用pg_dumpall
    pg_dump只備份數據庫集羣中的某個數據庫的數據，它不會導出角色和表空間相關的信息。pg_dumpall則可以導出整個數據庫集羣中所有的數據庫中的數據，同時也會導出角色、用戶和表空間的定義信息。使用pg_dumpall的一般命令格式如下：

pg_dumpall > backup_file

 

pg_dumpall也支持和pg_dump一樣的命令行選項，如-h和-p等。同樣可以使用psql來從pg_dumpall創建的備份文件中恢復數據庫。應該使用數據庫超級用戶來進行恢復數據庫的操作。命令格式如下：

psql -f backup_file postgres

 

     pg_dumpall在執行的過程中，用postgres作爲用戶名來連接數據庫。系統自動創建的數據庫postgres中的內容也會被導出來，數據庫template0和template1中的內容不會被導出來。

 

9.1.3 大型數據庫的備份和恢復
     如果數據庫的規模比較大，產生的備份文件的大小超級了操作系統能夠允許的單個文件的大小的最大值，可以使用壓縮和將備份文件分成對個部分這兩個方法來解決這個問題。

（1）採用壓縮的方法，可以採用操作系統提供的任何一種壓縮工具來實現，常用的是gzip。例如：

pg_dump dbname | gzip > filename.gz

恢復時，使用下面的命令：

gunzip -c filename.gz | psql dbname

也可以使用下面的命令來恢復數據庫：

cat filename.gz | gunzip | psql dbname

 

（2）將備份文件分成多個部分。使用操作系統的工具split來實現。例如:

pg_dump dbname | split -b 1m - filename

在這個例子中，數據庫備份被分成多個大小爲1MB的文件。

使用下面的命令進行恢復操作：

cat filename* | psql dbname

 

（3）使用pg_dump自帶的壓縮功能。這種方法產生的備份文件也是被壓縮的，同第一種方法相比，它有一個優點，就是可以只恢復備份文件中的某個表的數據。這種方法的命令格式如下，就是增加了選項-Fc：

pg_dump -Fc dbname > filename

不能使用psql命令恢復用這種方法備份的數據，必須使用pg_restore來進行恢復操作。命令格式如下：

pg_restore -d dbname filename

 

     對於非常大的數據庫，可以將壓縮與分割的方法同時使用（同時使用第一種和第二種方法，或者同時使用第二種和第三種方法）。

9.2文件系統複製
    文件系統複製這種方法是直接複製所有的數據庫文件，存放到其它的存儲介質上。這是最簡單的備份數據庫的方法。可以使用操作系統的命令來完成備份，例如：

tar -cf backup.tar /usr/local/pgsql/data

 

    複製數據文件以前，必須關閉數據庫。這種備份方法產生的備份文件比較大，因爲索引數據也會被備份。恢復數據庫時只要把備份文件複製到存放數據文件的目錄中即可。

 

9.3 聯機熱備份與歸檔恢復
9.3.1 聯機熱備份
     進行聯機熱備份時，不用關閉數據庫。數據庫可以正常地執行其它操作。如果要使聯機熱備份，數據庫必須運行在歸檔模式下，將參數數據庫 archive_mode設爲on，然後再將參數archive_dir設成一個啓動數據庫的操作系統用戶有讀寫權限的目錄，數據庫就會運行在歸檔模式。 要使這兩個參數生效，必須重新啓動數據庫。

 

    進行聯機熱備份的步驟如下：

（1）檢查數據庫是否運行在歸檔模式下。

（2）用超級用戶連接數據庫（推薦使用psql），然後執行下面的命令：
SELECT pg_start_backup('label');

label是一個字符串，用來確定創建的備份，可以選取一個有明顯的含義的名字作爲label。

pg_start_backup命令可能會執行比較長的時間纔會結束，因爲數據庫會自動開始一個檢查點操作。

（3）使用操作系統命令(如cp)，將所有的數據庫文件複製到其它的存儲介質上。

（4）執行下面的命令結束備份操作：

SELECT pg_stop_backup();

 

    備份操作結束以後，會在pg_xlog子目錄下產生一個備份描述文件，該文件以“.backup”結尾，例如 000000010000000000000000.004535C0.backup。注意數據庫歸檔進程會自動將備份操作產生的備份描述文件從 pg_xlog子目錄複製到存放歸檔事務日誌的目錄中（參數archive_dir指定的目錄），如果在pg_xlog目錄中找不到備份描述文件，應該在 存放歸檔事務日誌的目錄中去尋找它。恢復數據庫的時候需要使用備份描述文件中的信息。備份描述文件中存放有下列信息：

（1）開始事務日誌文件名。

（2）結束事務日誌文件名。

（3）檢查點位置。

（4）備份操作開始的時間。

（5）備份操作結束的時間。

（6）備份的名字（就是pg_start_backup命令中指定的名字）。

 

    下面是一個備份描述文件的實例：

START WAL LOCATION: 0/4535C0 (file 000000010000000000000000)

STOP WAL LOCATION: 0/453A98 (file 000000010000000000000000)

CHECKPOINT LOCATION: 0/4535C0

START TIME: 2009-03-28 23:02:34 CST

LABEL: b1

STOP TIME: 2009-03-28 23:04:05 CST

 

從該文件中可以看出備份操作開始的時間是2009-03-28 23:02:34，結束的時間是2009-03-28 23:04:05，備份的名字是 b1，開始事務日誌的名字是 000000010000000000000000，結束事務日誌的名字也 是 000000010000000000000000，檢查點的位置是0/4535C0。

 

從開始事務日誌文件到結束事務日誌文件之間的所有事務日誌文件（包括這兩個事務日誌文件）必須被保存好，不能丟失，否則創建的數據庫備份將是無效的，不能將數據庫恢復到一個一致的狀態。

 

     備份操作在執行的過程中會在數據文件目下產生一個名爲backup_label的文件，該文件叫做備份標號文件。備份標號文件在備份操作結束以 後會被系統自動刪除。在執行上面的第三步操作的過程中，必須同時複製備份標號文件，因爲恢復數據庫的時候需要使用備份標號文件中的信息。

 

 

9.3.2 歸檔恢復
    進行歸檔恢復以前，應該準備好一個名爲recovery.conf的文件，該文件中包含一些恢復操作的配置參數，這些參數決定恢復操作如何進行。下面詳細介紹這些參數：

 

（1）archive_log_dir

該參數指定存放歸事務日誌的目錄，所有需要的歸檔事務日誌都應該存放在該目錄中，系統在進行恢復操作時會自動從該目錄中讀取需要的事務日誌文件。

 

（2）recovery_target_time

該參數指定一個時間，恢復操作進行到該時間時會自動停止。該參數用來實現時間點恢復（point-In-Time Recovery）。recovery_target_time和下面的recovery_target_xid只能指定一個。

 

（3）recovery_target_xid

該參數指定一個事務id，恢復操作進行到該事務時會自動停止。recovery_target_xid和上面的recovery_target_time只能指定一個。

 

（4）recovery_target_inclusive

該參數的值是true或false。默認值是true。它影響參數recovery_target_time和recovery_target_xid， 如果它的值爲true，恢復操作在指定的目標（時間或事務ID）以後停止，如果它的值爲false，恢復操作在指定的目標以後停止。

 

    參數archive_log_dir必須出現在recovery.conf的文件中，其它的參數則是可選的，如果 recovery_target_xid和recovery_target_time都沒有被指定，則默認恢復到最後一個事務日誌文件確定的數據庫的最近 的狀態。如果想進行時間點恢復，應該指定參數recovery_target_time。

 

    下面是一個recovery.conf文件的實例，所有的參數的值都必須用兩個單引號引起來：

 

archive_log_dir = '/home/yan/archive_log'

recovery_target_time = '2004-07-14 22:39:00 EST'

recovery_target_xid = '1100842'

recovery_target_inclusive = 'true'        

 

 

    下面介紹進行歸檔恢復的具體步驟：

（１）停止數據庫服務器。將當前數據庫備份到其它目錄中。

（２）準備好recovery.conf文件，將所有恢復操作需要的歸檔事務日誌都存放在參數archive_log_dir指定的目錄中，備份描述文件也必須被存放在參數archive_log_dir指定的目錄中。

（３）將以前創建的數據庫備份複製到數據文件目錄中（必須與以前的數據文件目錄相同）。如果數據庫使用了表空間，請驗證pg_tblspc子目錄下面的每 個符號鏈接是否有效。將準備好的recovery.conf文件存放到數據文件目錄中。編輯文件pg_hba.conf，不允許任何用戶在恢復的過程中連 接數據庫。

（４） 確保數據文件目錄中存在一個名爲backup_label的文件。刪除pg_xlog子目錄中的所有文件，重新在pg_xlog中創建一個名爲archive_status的子目錄。

（５）啓動數據庫，數據庫在啓動以後將自動進行恢復操作，恢復操作成功完成以後，數據庫將自動打開，進入正常的工作狀態。恢復操作成功以後，系統會將文件recovery.conf重命名爲recovery.done。

（６）檢查數據庫中的內容是否正確。

 

     歸檔恢復成功結束以後，數據庫會自動打開，進入正常的工作狀態，可以開始響應用戶的連接請求，應該修改pg_hba.conf文件，允許用戶連接數據庫。歸檔恢復成功結束以後，在數據庫的運行日誌中會有下面的提示信息：

……

日誌： 00000： 歸檔恢復結束。

    

    文件backup_label在恢復操作執行結束以後會被自動重命名爲backup_label.old。確定歸檔恢復成功以後，應該刪除backup_label.old，因爲它已經沒有任何作用。

9.3.3 注意事項
    進行歸檔恢復時，有下面幾個注意事項：

（１）哈希索引上面的操作沒有被記錄到事務日誌中，歸檔恢復完成以後，必須對每個哈希索引執行REINDEX操作。

（２）在創建數據庫備份時不要修改模板數據庫。

 

9.3.4 時間線（timeline）
     時間線是PostgreSQL獨有的概念。它是一個整數值，與歸檔恢復有關。在用initdb創建一個初始的數據庫集羣以後，該數據庫集羣的時 間線是１。每進行一次歸檔恢復，就會產生一個新的時間線，新的時間線的值在上一個時間線的值的基礎上加一。每次歸檔恢復完成以後，都會產生一個時間線歷史 文件，該文件以“.history”結尾，例如00000002.history。時間線歷史文件首先被存放在pg_xlog目錄中，數據庫歸檔進程以後 會自動將時間線歷史文件從pg_xlog子目錄複製到存放歸檔事務日誌的目錄中（參數archive_dir指定的目錄）。