データベースの pg_dump を実行し、結果の .sql ファイルを別のサーバーにインストールしようとしています。
次のコマンドを使用しています。
psql -f databasedump.sql
今日、データベースのインストールを開始しましたが、7 時間経ってもまだデータベースにデータが取り込まれています。これにどれくらいの時間がかかるかはわかりませんが、監視を続けており、これまでに 1,200 万を超える挿入とカウントを確認しています。これを行うためのより速い方法があると思います。
でダンプを作成します
pg_dump -Fc -Z 9 --file=file.dump myDb
Fc
pg_restore への入力に適したカスタム アーカイブを出力します。これは、ロードするデータとオブジェクト定義の順序を変更できるという点で、最も柔軟な形式です。この形式もデフォルトで圧縮されます。
Z 9: --compress=0..9
使用する圧縮レベルを指定します。ゼロは圧縮なしを意味します。カスタム アーカイブ形式の場合、これは個々のテーブル データ セグメントの圧縮を指定し、デフォルトは適度なレベルで圧縮することです。プレーン テキスト出力の場合、0 以外の圧縮レベルを設定すると、出力ファイル全体が gzip を介して供給されたかのように圧縮されます。ただし、デフォルトでは圧縮しません。現在、tar アーカイブ形式は圧縮をまったくサポートしていません。
そしてそれを復元します
pg_restore -Fc -j 8 file.dump
-j: --jobs=number-of-jobs
複数の同時ジョブを使用して、pg_restore の最も時間のかかる部分 (データのロード、インデックスの作成、または制約の作成) を実行します。このオプションを使用すると、大規模なデータベースをマルチプロセッサ マシンで実行されているサーバーに復元する時間を大幅に短縮できます。
各ジョブは、オペレーティング システムに応じて 1 つのプロセスまたは 1 つのスレッドであり、サーバーへの個別の接続を使用します。
このオプションの最適値は、サーバー、クライアント、およびネットワークのハードウェア設定によって異なります。要因には、CPU コアの数とディスクのセットアップが含まれます。サーバーの CPU コアの数から始めるのが適切ですが、それよりも大きな値を設定すると、多くの場合、復元時間が短縮される可能性があります。もちろん、値が高すぎると、スラッシングのためにパフォーマンスが低下します。
このオプションでは、カスタムおよびディレクトリ アーカイブ形式のみがサポートされます。入力は通常のファイルまたはディレクトリでなければなりません (パイプなどではありません)。このオプションは、データベース サーバーに直接接続するのではなくスクリプトを発行する場合は無視されます。また、オプション --single-transaction と一緒に複数のジョブを使用することはできません。
リンク:
PG_DUMP | 常に-jオプション付きの format ディレクトリを使用する
time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external
PG_RESTORE | -jオプション付きのフォーマットディレクトリでpostgres.confのチューニングを常に使用する
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/`
詳細については
https://gitlab.com/yanar/Tuning/wikis/improve-pg-dump&restore
生の .sql ダンプを生成するのはなぜですか? pg_dumpの冒頭の説明では、「カスタム」形式を推奨しています-Fc。
次に、データ (またはその選択した部分) を復元する pg_restore を使用できます。複数のコアを使用できる「ジョブ数」オプション-jがあります (ディスクがまだ制限要因ではない場合)。ほとんどの場合、最新のマシンでは、少なくともある程度の効果が期待できます。
今、あなたは「これにどれくらいの時間がかかるのかわからない」と言います。まあ、いくつかの復元を行うまではわかりません。システムが何をしているか、CPU またはディスク I/O によって制限されているかどうかを監視してください。
最後に、データベースを復元するために必要な構成設定は、データベースを実行するためのものではありません。いくつかの便利なスターター:
ただし、復元後に忘れずにリセットしてください。
の使用法は、通常、 の代わりに ,pg_dumpと組み合わせて使用することをお勧めします。このメソッドをコア間で分割して、フラグをそのまま渡すことで読み込みプロセスを高速化できます。pg_restorepsql--jobs
$ pg_restore --jobs=8 dump.sql
Postgres 自体には、データの一括読み込みに関するガイドがあります。
postgresql.confまた、構成ファイルを大幅に調整し、maintenance_work_memとの値に適切な高い値を設定することをお勧めしcheckpoint_segmentsます。これらの値を大きくすると、書き込みパフォーマンスが劇的に向上する可能性があります。