# 24.1\. SQL轉儲 SQL轉儲的方法是創建一個文本文件，里面都是SQL命令， 當把這個文件回饋給服務器時，將重建與轉儲時狀態一樣的數據庫。 PostgreSQL為這個用途提供了[pg_dump](#calibre_link-437)工具。 這條命令的基本用法是： ``` pg_dump _dbname_ > _outfile_ ``` 正如你所見，pg_dump把結果輸出到標準輸出。 我們下面就可以看到這樣做有什么好處。 pg_dump是一個普通的PostgreSQL 客戶端應用(盡管是個相當聰明的東西)。 這就意味著你可以從任何可以訪問該數據庫的遠端主機上面進行備份工作。 但是請記住pg_dump不會以任何特殊權限運行。具體說來， 就是它必須要有你想備份的表的讀權限，因此， 實際上你幾乎總是要成為數據庫超級用戶。 要聲明pg_dump應該以哪個用戶身份進行連接， 使用命令行選項`-h``_host_`和`-p` `_port_`。 缺省主機是本地主機或環境變量 `PGPORT`聲明的值。類似的，缺省端口是環境變量`PGPORT`或 (如果它不存在的話)編譯好了的缺省值。服務器通常都有相同的缺省， 所以還算方便。 和任何其它PostgreSQL客戶端應用一樣，pg_dump缺省時用 與當前操作系統用戶名同名的數據庫用戶名進行連接。 要覆蓋這個名字，要么聲明`-U`選項， 要么設置環境變量`PGUSER`。請注意pg_dump 的連接也和普通客戶應用一樣要通過客戶認證機制(在[Chapter 19](#calibre_link-14)里描述)。 pg_dump超過后邊描述的其它備份方法的一個重要優點 是pg_dump的輸出通常可以 重新載入PostgreSQL新版本， 然而文件級別備份和連續歸檔都因 服務器版本而異。pg_dump是 將傳輸數據庫到另一臺機器體系結構工作時唯一的方法， 如從32位變到64位服務器。 由pg_dump創建的備份在內部是一致的， 也就是說，在pg_dump運行的時候轉儲的是數據庫的快照。 pg_dump工作的時候并不阻塞其它的對數據庫的操作 (但是會阻塞那些需要排它鎖的操作，比如`ALTER TABLE`)。 > **Important:** 如果你的數據庫結構依賴于OID(比如說用做外鍵)， 那么你必須告訴pg_dump把OID也導出來。要導出OID， 可以使用`-o`命令行選項。 ## 24.1.1\. 從轉儲中恢復 ``` psql _dbname_ < _infile_ ``` 這里的`_infile_` 就是通過pg_dump命令的文件輸出。 這條命令不會創建`_dbname_`數據庫， 你必須在執行psql前自己從 `template0`創建(也就是用`createdb -T template0` `_dbname_`命令)。 psql支持類似pg_dump的選項用以控制數據庫服務器位置和用戶名。 參閱[psql](#calibre_link-23)的手冊獲取更多信息。 在開始運行恢復之前，目標庫和所有在轉儲出來的庫中擁有對象的用戶， 以及曾經在某些對象上被賦予權限的用戶都必須已經存在。如果這些不存在， 那么恢復將失敗，因為恢復過程無法把這些對象恢復成原有的所有權和/或權限。 有時候你希望恢復權限，不過通常你不需要這么做。 缺省時，psql腳本將在遇到錯誤的時候仍然繼續執行。 你可能希望運行帶有`ON_ERROR_STOP`變量設置的 psql以改變操作，并且如果發生SQL錯誤則帶有 退出狀態碼3的psql退出。 ``` psql --set ON_ERROR_STOP=on dbname < infile ``` 不管上述哪種方法都只能得到部分恢復了的數據庫。另外， 你可以將整個恢復過程當成一個單獨的事務，這樣就能夠保證要么全部恢復成功， 要么全部回滾。可以通過向psql傳遞`-1`或者`--single-transaction`命令行 參數達到此目的。使用這個模式的時候即使一個很微小的錯誤也將導致已經運行 了好幾個小時的恢復過程回滾。盡管如此，這種模式也比手動清除哪些不完整的 恢復數據強。 pg_dump和psql可以通過管道讀寫， 這樣我們就可能從一臺主機上將數據庫目錄轉儲到另一臺主機上，比如： ``` pg_dump -h _host1_ _dbname_ | psql -h _host2_ _dbname_ ``` > **Important:** pg_dump生成的轉儲輸出是相對于`template0`的。 這就意味著任何加入到`template1`的語言、 過程等都會經由pg_dump轉儲。 這樣在恢復的時候，如果你使用的是自定義的`template1`， 那么你必須從`template0`中創建空的數據庫， 就像我們上面的例子那樣。 一旦完成恢復，在每個數據庫上運行[ANALYZE](#calibre_link-589)是明智的舉動， 這樣優化器就有可用的統計數據了。 [Section 23.1.3](#calibre_link-446) 和[Section 23.1.6](#calibre_link-77)獲取更多信息。 關于如何有效加載海量數據到PostgreSQL的更多信息， 參考[Section 14.4](#calibre_link-1190)。 ## 24.1.2\. 使用pg_dumpall pg_dump在一個時間只轉儲一個單獨的數據庫， 它不轉儲有關角色或表空間信息（因為這些是集群范圍，而不是每個數據庫）。 為了支持 方便轉儲整個數據庫集群的全部內容。 因此我們提供了[pg_dumpall](#calibre_link-439)程序。 pg_dumpall備份一個給出的集群中 的每個數據庫，同時還確保保留像角色和表空間這樣的全局數據狀態。 這個命令的基本用法是： ``` pg_dumpall > _outfile_ ``` 生成的轉儲可以用psql恢復： ``` psql -f _infile_ postgres ``` 實際上，你可以聲明任意現有的數據庫進行連接， 但是如果你是向一個空的數據庫集群裝載， 那么`postgres`應該是比較好的選擇。 恢復pg_dumpall的轉儲的時候通常需要數據庫超級用戶權限， 因為我們需要它來恢復角色和表空間信息。如果使用了表空間， 需要注意轉儲中的表空間路徑必須適合新的安裝。 pg_dumpall的工作原理是發射命令來重新創建角色， 表空間和空數據庫，然后為每個數據庫調用pg_dump。 這意味著，雖然每個數據庫內部一致， 但不同的數據庫快照可能不是恰好同步。 ## 24.1.3\. 處理大數據庫 當創建大的pg_dump輸出文件時， 限制產生問題的一些操作系統允許最大文件大小。 因為pg_dump輸出到標準輸出， 你可以用標準的Unix工具繞開這個問題：有一些可能的方法： **使用壓縮轉儲.** 使用你熟悉的壓縮程序(比如gzip)： ``` pg_dump _dbname_ | gzip > _filename_.gz ``` 使用下面命令恢復： ``` gunzip -c _filename_.gz | psql _dbname_ ``` 或者： ``` cat _filename_.gz | gunzip | psql _dbname_ ``` **使用`split`.** `split`允許用下面的方法把輸出分解成操作系統可以接受的大小。 比如，讓每個塊大小為1MB： ``` pg_dump _dbname_ | split -b 1m - _filename_ ``` 用下面命令恢復： ``` cat _filename_* | psql _dbname_ ``` **使用pg_dump自定義轉儲格式.** 如果PostgreSQL是在一個安裝了zlib 壓縮庫的系統上制作的， 那么自定義轉儲格式將在寫入輸出文件的時候壓縮數據。 它會生成和使用`gzip`類似大小的轉儲文件，但是還附加了一個優點： 你可以有選擇地恢復庫中的表。下面的命令用自定義轉儲格式轉儲一個數據庫： ``` pg_dump -Fc _dbname_ > _filename_ ``` 自定義格式的轉儲不是腳本，不能用于psql，而是需要使用pg_restore轉儲。 比如： ``` pg_restore -d _dbname_ _filename_ ``` 請參閱[pg_dump](#calibre_link-437)和[pg_restore](#calibre_link-440)手冊獲取細節。 對于非常大的數據庫，你可能需要結合`split`以及其他兩種方法之一。 **使用pg_dump的并行轉儲功能.** 為了加快大數據庫的轉儲，你可以使用pg_dump并行模式。 這將同時轉儲多個表。你可以使用`-j`參數控制并行性程度。 并行轉儲只支持"目錄"歸檔模式。 ``` pg_dump -j _num_ -F d -f _out.dir_ _dbname_ ``` 你可以使用`pg_restore -j`并行恢復轉儲。這將為任何"自定義"或者 "目錄"歸檔模式工作，是否它已經使用`pg_dump -j`創建。