ダンプと復元を使用した PostgreSQL データベースの移行

  • [アーティクル]

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

pg_dump を使用して、PostgreSQL データベースをダンプ ファイルに抽出することができます。 次に、pg_restore を使用して、pg_dump によって作成されたアーカイブ ファイルから PostgreSQL データベースを復元することができます。

前提条件

このハウツー ガイドの手順を実行するには、以下が必要です。

読み込まれるデータを格納するダンプ ファイルを作成する

オンプレミスまたは VM の既存の PostgreSQL データベースをバックアップするには、次のコマンドを実行します。

pg_dump -Fc -v --host=<host> --username=<name> --dbname=<database name> -f <database>.dump

たとえば、ローカル サーバーとその中に testdb というデータベースがある場合、以下を実行します。

pg_dump -Fc -v --host=localhost --username=masterlogin --dbname=testdb -f testdb.dump

ターゲット データベースにデータを復元する

ターゲット データベースを作成した後、pg_restore コマンドおよび --dbname パラメーターを使って、ダンプ ファイルからターゲット データベースにデータを復元できます。

pg_restore -v --no-owner --host=<server name> --port=<port> --username=<user-name> --dbname=<target database name> <database>.dump

--no-owner パラメーターを指定すると、復元中に作成されるすべてのオブジェクトは、--username で指定されたユーザーによって所有されます。 詳細については、PostgreSQL のドキュメントを参照してください。

Note

Azure Database for PostgreSQL サーバーでは、TLS/SSL 接続が既定でオンになっています。 お使いの PostgreSQL サーバーで TLS または SSL 接続を必要としているが、それがない場合、pg_restore ツールが TLS で接続するように環境変数 PGSSLMODE=require を設定します。 TLS を使用しない場合、"致命的: SSL 接続が必要です。 SSL のオプションを指定して再試行してください。" のようなエラーが表示されます。Windows コマンド ラインで、コマンド SET PGSSLMODE=require を実行してから、pg_restore コマンドを実行します。 Linux または Bash では、コマンド export PGSSLMODE=require を実行してから、pg_restore コマンドを実行します。

この例では、対象サーバー mydemoserver.postgres.database.azure.com 上のデータベース mypgsqldb に、ダンプ ファイル testdb.dump からデータを復元します。

この pg_restore を単一サーバーで使用する方法の例を、こちらに示します。

pg_restore -v --no-owner --host=mydemoserver.postgres.database.azure.com --port=5432 --username=mylogin@mydemoserver --dbname=mypgsqldb testdb.dump

この pg_restore をフレキシブル サーバーで使用する方法の例を、こちらに示します。

pg_restore -v --no-owner --host=mydemoserver.postgres.database.azure.com --port=5432 --username=mylogin --dbname=mypgsqldb testdb.dump

移行プロセスを最適化する

既存の PostgreSQL データベースを Azure Database for PostgreSQL に移行する方法の 1 つは、ソース側のデータベースをバックアップし、それを Azure で復元することです｡ 移行に要する時間を最小限に抑えるには、バックアップと復元のコマンドに次のパラメーターを使用することを検討してください｡

注意

詳細な構文情報については、pg_dump と pg_restore を参照してください｡

バックアップ

-Fc スイッチを使用してバックアップを実行することで、平行して復元を行い、処理をスピードアップできます。 次に例を示します。

pg_dump -h my-source-server-name -U source-server-username -Fc -d source-databasename -f Z:\Data\Backups\my-database-backup.dump

復元

  • バックアップ ファイルを、移行先の Azure Database for PostgreSQL サーバーと同じリージョンにある Azure VM に移動します。 ネットワーク待機時間を減らすために、その VM から pg_restore を実行します。 高速ネットワークを有効にして VM を作成します。

  • ダンプ ファイルを開き、create index ステートメントがデータの insert の後にあることを確認します。 そのようになっていない場合は、データの insert の後に create index ステートメントを移動します。 これは既定で既に行われているはずですが、確認することをお勧めします。

  • -j N スイッチを使用して復元を行い (ここで N は番号を表す)、復元を並列処理します。 指定する数値は、ターゲット サーバーのコアの数です。 ターゲット サーバーのコア数の 2 倍に設定することで､その影響を確認することもできます｡

    この pg_restore を単一サーバーで使用する方法の例を、こちらに示します。

     pg_restore -h my-target-server.postgres.database.azure.com -U azure-postgres-username@my-target-server -j 4 -d my-target-databasename Z:\Data\Backups\my-database-backup.dump

    この pg_restore をフレキシブル サーバーで使用する方法の例を、こちらに示します。

     pg_restore -h my-target-server.postgres.database.azure.com -U azure-postgres-username -j 4 -d my-target-databasename Z:\Data\Backups\my-database-backup.dump

  • ダンプ ファイルを編集することもできます｡先頭に set synchronous_commit = off; コマンド､最後に set synchronous_commit = on; コマンドを追加してください｡ アプリによってデータが変更される前に､最後にオンにするようにしないと､後続データが失われることがあります。

  • ターゲットの Azure Database for PostgreSQL サーバーで、復元の前に以下を行うことを検討してください。

    • クエリ パフォーマンス追跡をオフにする。 これらの統計は、移行中は必要ありません。 これを行うには、pg_stat_statements.track、pg_qs.query_capture_mode、および pgms_wait_sampling.query_capture_mode を NONE に設定します。

    • 移行の速度を上げるために、32 vCore メモリ最適化のようなハイ コンピューティングとハイ メモリの SKU を使用する。 復元が完了したら、希望する SKU に簡単に戻すことができます。 SKU が大きいほど、pg_restore コマンドの対応する -j パラメーターを増やすことで、より多くの並行処理を実現できます。

    • ターゲット サーバーの IOPS を上げると、復元のパフォーマンスが向上する可能性がある。 サーバーのストレージ サイズを増やすことで、より高い IOPS をプロビジョニングできます。 この設定は元に戻せませんが、IOPS を高くすることで、将来実際のワークロードにメリットがあるかどうか検討してください。

これらのコマンドは､運用環境で使用する前にテスト環境でテスト､検証してください。

次の手順