次の方法で共有

Azure Database for PostgreSQL - フレキシブル サーバーでの pg_dump と pg_restore に関するベスト プラクティス

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

この記事では、pg_dump と pg_restore を高速化するためのオプションとベスト プラクティスについて説明します。 また、pg_restore を実行するための最適なサーバー構成についても説明します。

pg_dump に関するベスト プラクティス

pg_dump ユーティリティを使うと、Azure Database for PostgreSQL フレキシブル サーバー データベースをスクリプト ファイルまたはアーカイブ ファイルに抽出できます。 pg_dump を使用して全体的なダンプ時間を短縮するために使用できるコマンド ライン オプションをいくつか次のセクションに示します。

ディレクトリ形式 (-Fd)

このオプションを指定すると、pg_restore へ入力できるディレクトリ形式のアーカイブが出力されます。 既定では、出力は圧縮されます。

並列ジョブ (-j)

pg_dump では、並列ジョブ オプションを使用してダンプ ジョブを同時に実行できます。 このオプションを使用すると、合計ダンプ時間が短縮されますが、データベース サーバーの負荷が増加します。 CPU、メモリ、IOPS (1 秒あたりの入出力操作) の使用状況など、ソース サーバーのメトリックを注意深く監視した後に、並列ジョブ値を決めることをお勧めします。

並列ジョブ オプションの値を設定する場合、pg_dump には次のものが必要です。

  • 接続の数は、並列ジョブの数 +1 と等しくなる必要があるため、必ずそれに応じて max_connections の値を設定してください。
  • 並列ジョブの数は、データベース サーバーに割り当てられた vCPU の数以下にする必要があります。

圧縮 (-Z0)

このオプションでは、使用する圧縮レベルを指定します。 ゼロは、圧縮なしを意味します。 pg_dump プロセス中に圧縮をゼロにすると、パフォーマンスが向上する可能性があります。

テーブルの肥大化とバキューム処理

pg_dump プロセスを開始する前に、テーブルのバキューム処理が必要かどうかを検討してください。 テーブルの肥大化により、pg_dump の時間が大幅に増加します。 テーブルの肥大化を確認するには、次のクエリを実行します。

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

このクエリの dead_pct 列は、有効なタプルと比較した場合の使用不能タプルの割合です。 テーブルの dead_pct 値が高い場合は、テーブルが適切にバキューム処理されていないことを示している可能性があります。 詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーでの自動バキュームのチューニング」を参照してください。

識別するテーブルごとに、次を実行して手動でバキューム処理の分析ができます。

vacuum(analyze, verbose) <table_name>

PITR サーバーを使用する

pg_dump は、オンラインまたはライブ サーバーで実行できます。 データベースが使用されている場合でも、一貫性のあるバックアップが作成されます。 他のユーザーによるデータベースの使用はブロックされません。 pg_dump プロセスを開始する前に、データベースのサイズやその他のビジネスまたは顧客のニーズを検討してください。 運用サーバーで pg_dump を実行するには、小規模なデータベースが適している可能性があります。

大規模なデータベースの場合は、運用サーバーからポイントインタイム リストア (PITR) サーバーを作成し、PITR サーバーで pg_dump プロセスを実行できます。 PITR での pg_dump の実行は、コールド ラン プロセスになります。 このアプローチのトレードオフは、実際の運用サーバーで実行される pg_dump プロセスに付随する追加の CPU、メモリ、または IO 使用率を心配せずに済むことです。 PITR サーバーで pg_dump を実行し、pg_dump プロセスが完了したら PITR サーバーを削除できます。

pg_dump の構文

pg_dump には次の構文を使用します。

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

pg_restore に関するベスト プラクティス

pg_restore ユーティリティを使うと、pg_dump で作成されたアーカイブから Azure Database for PostgreSQL フレキシブル サーバー データベースを復元できます。 全体的な復元時間を短縮するためのコマンド ライン オプションをいくつか次のセクションに示します。

並列復元

複数の同時実行ジョブを使用すると、マルチ仮想コア ターゲット サーバー上の大規模なデータベースを復元する時間を短縮できます。 ジョブの数は、ターゲット サーバーに割り当てられた vCPU の数以下にすることができます。

サーバー パラメーター

新しいサーバーまたは非運用サーバーにデータを復元する場合は、pg_restore を実行する前に、次のサーバー パラメーターを最適化できます。

work_mem = 32 MB
max_wal_size = 65536 (64 GB)
checkpoint_timeout = 3600 #60 分
maintenance_work_mem = 2097151 (2 GB)
autovacuum = off
wal_compression = on

復元が完了したら、これらすべてのパラメーターがワークロード要件に従って適切に更新されていることを確認してください。

Note

十分なメモリとディスク領域がある場合にのみ、上記の推奨事項に従ってください。 仮想コアが 2、4、または 8 個の小規模なサーバーの場合は、それに応じてパラメーターを設定します。

その他の考慮事項

  • pg_restore を実行する前に、高可用性 (HA) を無効にします。
  • 復元が完了した後、移行されたすべてのテーブルを分析します。

pg_restore の構文

pg_restore には次の構文を使用します。

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

  • -Fd: ディレクトリ形式
  • -j: ジョブの数
  • -C: データベース自体を作成して、それに再接続するコマンドで出力を開始する

この構文の例を次に示します。

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

仮想マシンに関する考慮事項

仮想マシンは、なるべくターゲットとソースの両方のサーバーがある同じリージョンおよび可用性ゾーンに作成します。 または、少なくとも、ソース サーバーまたはターゲット サーバーの近くに仮想マシンを作成します。 Azure Virtual Machines は高パフォーマンスのローカル SSD で使用することをお勧めします。

SKU の詳細については、次を参照してください。

Azure Database for PostgreSQL 製品チームと提案やバグを共有します。

関連するコンテンツ