PostgreSQL：提高 pg_dump、pg_restore 性能

Question

開始時，我使用了默認純格式的pg_dump 。 我沒有開悟。

研究向我揭示了使用pg_dump -Fc | gzip -9 -c > dumpfile.gz pg_dump -Fc | gzip -9 -c > dumpfile.gz 。 我開悟了。

當需要重新創建數據庫時，

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

我感到茫然：還原花了 12 個小時來創建數據庫，而這只是它的一小部分：

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

因為有人預測這個數據庫會有幾 TB，所以我現在需要考慮提高性能。

請賜教。

Answer 1

首先檢查您的磁盤設置是否獲得了合理的 IO 性能。 然后檢查您的 PostgreSQL 安裝是否已適當調整。 特別是shared_buffers應該正確設置， maintenance_work_mem在恢復期間應該增加， full_page_writes在恢復期間應該關閉， full_page_writes在恢復期間應該增加到 16MB， checkpoint_segments在恢復期間應該增加到wal_buffers 16，你不應該有任何不合理的登錄（例如記錄每個執行的語句），在恢復期間應禁用auto_vacuum 。

如果您使用的是 8.4，還可以嘗試並行還原，pg_restore 的 --jobs 選項。

Answer 2

改進 pg dump&restore

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

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

PG_RESTORE | 始終對 postgres.conf 和 format-directory 以及-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/

Answer 3

兩個問題/想法：

1. 通過指定 -Fc，pg_dump 輸出已經被壓縮。 壓縮不是最大的，因此您可能會發現使用“gzip -9”可以節省一些空間，但我敢打賭這不足以保證用於壓縮和解壓縮備份的 -Fc 版本的額外時間（和 I/O） .

2. 如果您使用的是 PostgreSQL 8.4.x，您可以使用新的 pg_restore 命令行選項“-jn”潛在地加快從 -Fc 備份的還原速度，其中 n=用於還原的並行連接數。 這將允許 pg_restore 加載多個表的數據或同時生成多個索引。

Answer 4

我假設您需要備份，而不是數據庫的重大升級。

對於大型數據庫的備份，您應該設置連續歸檔而不是pg_dump 。

1. 設置 WAL 歸檔。

2. 例如，每天使用以下方法進行基本備份
   psql template1 -c "select pg_start_backup(' `date +%F-%T``')" rsync -a --delete /var/lib/pgsql/data/ /var/backups/pgsql/base/ psql template1 -c "選擇 pg_stop_backup()"`

恢復就像從備份位置恢復不早於pg_start_backup時間的數據庫和 WAL 日志並啟動 Postgres 一樣簡單。 而且會快很多。

Answer 5

zcat dumpfile.gz | pg_restore -d db_name

刪除未壓縮數據到磁盤的完整寫入，這是當前的瓶頸。

Answer 6

您可能已經猜到了壓縮備份會帶來更快的性能這一事實，您的備份受 I/O 限制。 這應該不足為奇，因為備份幾乎總是受 I/O 限制。 壓縮數據會用 I/O 負載換取 CPU 負載，而且由於大多數 CPU 在大量數據傳輸期間處於空閑狀態，因此壓縮是一種凈勝。

因此，要加快備份/恢復時間，您需要更快的 I/O。 除了將數據庫重組為一個龐大的單個實例之外，您幾乎可以做的就是這些。

Answer 7

如果您遇到pg_restore的速度問題，請檢查您是否使用INSERT或COPY語句轉儲了數據。

如果您使用INSERT （使用--column-inserts參數調用pg_dump ），數據的恢復會明顯變慢。

使用INSERT非常適合制作加載到非 Postgres 數據庫的轉儲。 但是，如果您在使用pg_dump時使用--column-inserts參數對 Postgres 進行還原。