88

私が始めたとき、私pg_dumpはデフォルトのプレーンフォーマットで使用しました。私は悟りがありませんでした。

調査の結果、。を使用すると時間とファイルサイズが改善されたことがわかりました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

このデータベースは数テラバイトになると予測されているので、今すぐパフォーマンスの向上を検討する必要があります。

教えてください。

4

6 に答える 6

63

まず、ディスク設定から妥当なIOパフォーマンスが得られていることを確認します。次に、PostgreSQLのインストールが適切に調整されていることを確認します。特にshared_buffers、正しく設定する必要がありますmaintenance_work_mem。復元中に増やす必要がfull_page_writesあります。復元中にオフにする必要があります。復元wal_buffers中に16MBに増やすcheckpoint_segments必要があります。復元中に、16のように増やす必要があります。不当なログオンが発生しないようにする必要があります。 （実行されたすべてのステートメントをログに記録するなど）、auto_vacuum復元中は無効にする必要があります。

8.4を使用している場合は、並列復元も試してください。pg_restoreの--jobsオプション。

于 2010-01-19T17:01:32.430 に答える
35

pgダンプと復元を改善する

PG_DUMP | 常にformat-directoryと-jオプションを使用します

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

PG_RESTORE | postgres.confとformat-directoryおよび-joptionsには常にチューニングを使用してください

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-30T21:08:09.623 に答える
14

2つの問題/アイデア：

  1. -Fcを指定することにより、pg_dump出力はすでに圧縮されています。圧縮率が最大ではないため、「gzip -9」を使用するとスペースを節約できる場合がありますが、バックアップの-Fcバージョンの圧縮と解凍に使用される余分な時間（およびI / O）を保証するのに十分ではないと思います。 。

  2. PostgreSQL 8.4.xを使用している場合は、新しいpg_restoreコマンドラインオプション「-jn」を使用して、-Fcバックアップからの復元を高速化できる可能性があります。n=復元に使用する並列接続の数。これにより、pg_restoreは複数のテーブルのデータをロードしたり、同時に複数のインデックスを生成したりできます。

于 2010-01-19T16:47:18.100 に答える
10

データベースのメジャーアップグレードではなく、バックアップが必要だと思います。

大規模なデータベースのバックアップには、の代わりに継続的なアーカイブ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 "select pg_stop_backup（）" `

pg_start_backup復元は、バックアップ場所から時間より前のデータベースとWALログを復元し、Postgresを起動するのと同じくらい簡単です。そして、それははるかに高速になります。

于 2010-01-19T18:15:01.610 に答える
7 
zcat dumpfile.gz | pg_restore -d db_name

現在ボトルネックとなっている、ディスクへの非圧縮データの完全な書き込みを削除します。

于 2010-01-22T02:34:03.160 に答える
3

バックアップを圧縮するとパフォーマンスが向上するという事実からお察しのとおり、バックアップはI/Oバウンドです。バックアップはほとんど常にI/Oバウンドになるため、これは当然のことです。データの圧縮はI/O負荷をCPU負荷と交換し、ほとんどのCPUはモンスターデータ転送中にアイドル状態になるため、圧縮は正味の勝利として出てきます。

したがって、バックアップ/復元時間を短縮するには、より高速なI/Oが必要です。データベースを再編成して1つの巨大な単一インスタンスにならないようにするだけでなく、できることはほとんどすべてです。

于 2010-01-19T16:31:47.090 に答える