我做了一個數據庫的pg_dump，現在正試圖將生成的.sql文件安裝到另一臺服務器上。複製postgresql數據庫的更快方法（或最好的方法）

我正在使用以下命令。

psql -f databasedump.sql

我今天早些時候啓動了數據庫安裝，現在7小時後數據庫仍在填充。我不知道這是否應該持續多長時間，但是我繼續監測它，到目前爲止，我已經看到了超過12萬個插入物並計數。我懷疑有一個更快的方法來做到這一點。

來源

2013-03-28 David Bain

無論哪種方式，1200萬個刀片，這是正常的東西像半路出家一分鐘的事硬件，即使使用psql和普通的SQL轉儲。如果花了7個小時，那麼你的設置有些不合適。 –

這可能是顯而易見的，但請檢查您是否向轉儲提供了交叉數據庫兼容性選項'--inserts'或'--column-inserts'。您還可以檢查您的ASCII腳本是否使用「COPY」來重新載入數據。 –

有關更多信息，我正在使用EC2微型實例，因此它的內存限制有點。這是Postgresql 7.4（必須自己編譯它），因爲數據來自舊的7.4版本。 –

通常推薦使用pg_dump與pg_restore配對，而不是psql。這種方法可以核心之間通過傳遞--jobs標誌作爲這樣被分開，以加快加載過程：

$ pg_restore --jobs=8 dump.sql

POSTGRES本身上的數據的批量加載有guide。

我也會推薦大量調整你的postgresql.conf配置文件，併爲maintenance_work_mem和checkpoint_segments值設置適當的高值;較高的值可能會顯着提高寫入性能。

來源

2013-03-28 22:00:47 hoxworth

請不要發佈明顯的錯誤信息。如果你不知道問題的答案，那麼不要回答。你的回答不僅僅是不正確，任何追隨它的人都會發現他們的生活變得更加困難並不容易。 –

我道歉;我發佈答案後意識到這是相當不正確的。我已經更新了答案，盡我所知，但如果我對pg_restore的理解和使用不正確，我將簡單地刪除答案。 – hoxworth

您編輯的答案似乎更有用。我已經刪除了我的downvote。我會刪除我的評論，但我不認爲這條鏈會很有意義。 –

你爲什麼生產原始的.sql轉儲？ pg_dump的開放說明建議使用「自定義」格式-Fc。

然後你可以使用pg_restore來恢復你的數據（或者它的選定部分）。有一個「作業數量」選項-j，它可以使用多個內核（假設您的磁盤不是限制因素）。在大多數情況下，在現代化的機器上，您至少可以從中獲得一些收益。

現在你說「我不知道這應該花多少時間」。那麼，直到你做了一些恢復，你不會知道。請監視您的系統正在做什麼以及您是否受cpu或磁盤I/O的限制。

最後，要恢復數據庫的配置設置不是您想要運行它的那些設置。一對夫婦有用首發：

增加maintenance_work_mem這樣你就可以在更大的塊
關閉fsync。如果你的機器崩潰了，無論如何你都會從頭開始。

請記住在恢復後重置它們。

來源

2013-03-28 22:31:35

這是非常有用的信息。即使我過去使用Postgresql，我也顯然無能爲力。我發現你的反饋非常有啓發性。 –

使用psql花了大約9個小時。我想用pg_restore來測試，我應該運行pg_restore還是更好地擦除我的數據目錄並從頭開始（這是一個測試框，關鍵任務數據都在活動框中）？ –

你需要一個新的轉儲（-Fc），如果你有磁盤空間，你可以用不同的名字恢復數據庫，如果你喜歡。此次計劃進行監視 - 索引可能比表格數據容易花費更長的時間。你可能會發現創建一個更小的測試數據庫（相同的結構）和多次轉儲/恢復以更好地感知事物的相互作用是很有用的。 –

與

pg_dump -Fc -Z 9 --file=file.dump myDb

的Fc創建轉儲：輸出適合輸入到pg_restore裏的自定義歸檔。這是最靈活的格式，它允許重新排序加載數據以及對象定義。這種格式也是默認壓縮的。

Z 9：--compress = 0..9 指定要使用的壓縮級別。零意味着沒有壓縮。對於自定義存檔格式，這指定了個別表格數據段的壓縮，並且默認爲壓縮在中等水平。對於純文本輸出，設置非零壓縮級別會導致整個輸出文件被壓縮，就像它已通過gzip進行饋送一樣;但默認不壓縮。 tar檔案格式目前根本不支持壓縮。

，並將其與

pg_restore -Fc -j 8 file.dump

-j還原：--jobs =數的的作業運行pg_restore的最耗時的部分 - 的那些負載數據，創建索引，或創建約束 - 使用多個併發作業。此選項可以顯着減少將大型數據庫還原到在多處理器計算機上運行的服務器的時間。

每個作業都是一個進程或一個線程，具體取決於操作系統，並使用到服務器的單獨連接。

此選項的最佳值取決於服務器，客戶端和網絡的硬件設置。因素包括CPU核心數量和磁盤設置。一個好的起點是服務器上的CPU核心數量，但是大於這個值的核心數量在很多情況下也會導致更快的恢復時間。當然，太高的值會導致性能下降，因爲顛簸。

此選項僅支持自定義存檔格式。輸入文件必須是常規文件（不是例如管道）。發佈腳本時忽略此選項，而不是直接連接到數據庫服務器。此外，多個作業不能與選項 - 單一事務一起使用。

鏈接：

pg_dump

pg_restore

來源

2014-06-04 23:45:44 mullerivan

，你也可以做使用pg_basebackup和pigz一致的數據庫備份，並行解壓縮過，請參閱：

https://brunomgalmeida.wordpress.com/2016/09/26/faster-pg_basebackup/

來源

2016-09-26 22:58:36 Bruno

改善pg轉儲&恢復

PG_DUMP |始終使用格式的目錄與-j選項

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

pg_restore的|始終使用調諧postgres.conf與格式目錄中-j選項

work_mem = 32MB 
shared_buffers = 4GB 
maintenance_work_mem = 2GB 
full_page_writes = off 
autovacuum = off 
wal_buffers = -1 

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/`

來源

2016-12-30 15:53:57

複製postgresql數據庫的更快方法（或最好的方法）

回答

改善pg轉儲&恢復

相關問題