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

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

pg_dump を使用して、PostgreSQL データベースをダンプ ファイルに抽出することができます。 データベースを復元する方法は、選択したダンプの形式によって異なります。 ダンプがプレーン形式 (規定の -Fp であり、特定のオプションを指定する必要がない) で取得される場合、それを復元するための唯一のオプションは、プレーンテキスト ファイルを出力する psql を使用することです。 他の 3 つのダンプ方法 (カスタム、ディレクトリ、tar) では、pg_restore を使用する必要があります。

この記事では、プレーン (既定) とディレクトリの形式について説明します。 処理に複数のコアを使用できるディレクトリの形式の場合、効率を大幅に向上できるため、特に大規模なデータベースの場合で便利です。

Azure portal の [接続] ブレードを使用してこのプロセスを効率化することが可能であり、ここから、値がユーザー データに置き換えた状態で提供される、サーバーに合わせて調整された事前構成済みのコマンドを利用できます。 [接続] ブレードは Azure DB for PostgreSQL - フレキシブル サーバーでのみ使用でき、単一サーバーでは使用できないことに注意してください。 この機能を使用する方法を次に示します。

1. Azure portal にアクセスする: まず、Azure portal に移動して、[接続] ブレードを選択します。

   

2. データベースを選択する: [接続] ブレードに、データベースのドロップダウン リストが表示されます。 ダンプを実行するデータベースを選択します。

   

3. 適切な方法を選択する: データベースのサイズに応じて、次の 2 つの方法から選択できます。

   • pg_dump & psql - 単一のテキスト ファイルを使用する: 小規模なデータベースに最適です。このオプションでは、ダンプと復元のプロセスに単一のテキスト ファイルを使用します。
   • pg_dump & pg_restore - 複数のコアを使用する: この方法の場合、ダンプと復元のプロセスの処理に複数のコアを使用できるため、大規模なデータベースの場合でより効率的になります。

   

4. コマンドをコピーして貼り付ける: ポータルには、すぐに使用できる pg_dump および psql コマンド、あるいは pg_restore コマンドが用意されています。 これらのコマンドには、選択したサーバーとデータベースに応じて置き換えられた後の値が含まれています。 これらのコマンドをコピーして貼り付けます。

前提条件

単一サーバーを使用している場合、またはフレキシブル サーバー ポータルへのアクセス権がない場合、このドキュメント ページを参照してください。 ポータルのフレキシブル サーバーの [接続] ブレードに表示される情報と似た情報が含まれます。

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

• アクセスを許可するファイアウォール規則のある Azure Database for PostgreSQL サーバー。
• pg_dump、psql、pg_restore、pg_dumpall。ロールとアクセス許可、コマンド ライン ユーティリティをインストールした状態で移行する場合。
• ダンプの場所を決定する: ダンプを実行する場所を選択します。 これは、別の VM、 Cloud Shell (コマンド ライン ユーティリティは既にインストールされているものの、適切なバージョンではない可能性があります。そのため、psql --version などを使用してバージョンを常にチェックしてください)、自分のノート PC など、さまざまな場所から実行できます。 PostgreSQL サーバーとダンプや復元を実行する場所との間の距離と待ち時間を、常に考慮するようにしてください。

pg_dumpall -r を使用したユーザーとロールのダンプ

pg_dump は、PostgreSQL データベースをダンプ ファイルに抽出するために使用されます。 ただ、pg_dump はロールやユーザー定義をダンプしないため、これを把握することが重要です。これらは、PostgreSQL 環境内のグローバル オブジェクトとみなされます。 ユーザーとロールを含む包括的な移行の場合は、pg_dumpall -r を使用する必要があります。 このコマンドを使用すると、PostgreSQL 環境からすべてのロールとユーザーの情報をキャプチャできます。 同じサーバー上のデータベース内で移行する場合は、この手順を省略して、「新しいデータベースの作成」のセクションに移動してください。

pg_dumpall -r -h <server name> -U <user name> > roles.sql

たとえば、サーバーの名前が mydemoserver で、ユーザーの名前が myuser の場合、次のコマンドを実行します。

pg_dumpall -r -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

単一サーバーを使用している場合、ユーザー名にはサーバー名コンポーネントが含まれます。 そのため、myuser の代わりに myuser@mydemoserver を使用します。

フレキシブル サーバーからのロールのダンプ

フレキシブル サーバー環境の場合はセキュリティ対策が強化されているため、ユーザーは、ロール パスワードが格納されている pg_authid テーブルにアクセスできません。 標準の pg_dumpall -r コマンドは、このテーブルへのアクセスを試みてパスワードを取得しようとしますが、アクセス許可がないため失敗します。そのため、この制限がどのようにロール ダンプを実行するかに影響します。

フレキシブル サーバーからロールをダンプする場合は、pg_dumpall コマンドに --no-role-passwords オプションを含める必要があります。 このオプションは、セキュリティ制限のために読み取ることができない pg_authid テーブルへのアクセスを pg_dumpall が試みることを防止します。

フレキシブル サーバーからロールを正常にダンプするには、次のコマンドを使用します。

pg_dumpall -r --no-role-passwords -h <server name> -U <user name> > roles.sql

たとえば、サーバーの名前が mydemoserver で、ユーザーの名前が myuser の場合、次のコマンドを実行します。

pg_dumpall -r --no-role-passwords -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

ロール ダンプのクリーンアップ

移行時、出力ファイル roles.sql には、新しい環境では適用できない、または許容されない特定のロールや属性が含まれている可能性があります。 考慮すべきことを次に示します。

• スーパーユーザーによってのみ設定できる属性を削除する: スーパーユーザーの特権がない環境に移行する場合、ロール ダンプから NOSUPERUSER や NOBYPASSRLS などの属性を削除します。

• サービス固有のユーザーを除外する: azure_superuser や azure_pg_admin などの単一サーバー サービス ユーザーを除外します。 これらはサービスに固有であり、新しい環境で自動的に作成されます。

次の sed コマンドを使用してロール ダンプをクリーンアップします。

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql

このコマンドは、azure_superuser、azure_pg_admin、azuresu を含む行、CREATE ROLE replication、ALTER ROLE replication で始まる行を削除し、NOSUPERUSER および NOBYPASSRLS 属性を ALTER ROLE ステートメントから削除します。

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

オンプレミスまたは VM 内にある既存の PostgreSQL データベースを SQL スクリプト ファイルにエクスポートするには、既存の環境で次のコマンドを実行します。

pg_dump <database name> -h <server name> -U <user name> > <database name>_dump.sql

pg_dump testdb -h mydemoserver.postgres.database.azure.com -U myuser > testdb_dump.sql

pg_dump -Fd -j <number of cores> <database name> -h <server name> -U <user name> -f <database name>.dump

pg_dump -Fd -j 2 testdb -h mydemoserver.postgres.database.azure.com -U myuser -f testdb.dump

単一サーバーを使用している場合、ユーザー名にはサーバー名コンポーネントが含まれます。 そのため、myuser の代わりに myuser@mydemoserver を使用します。

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

ロールとユーザーの復元

データベース オブジェクトを復元する前に、ロールを適切にダンプしてクリーンアップできていることを確認してください。 同じサーバー上のデータベース内で移行する場合、ロールのダンプと復元の両方が必要ない場合があります。 ただし、異なるサーバーまたは環境間での移行の場合、この手順は非常に重要です。

ロールとユーザーをターゲット データベースに復元するには、次のコマンドを使用します。

psql -f roles.sql -h <server_name> -U <user_name>

<server_name> をターゲット サーバーの名前に置き換え、<user_name> をユーザー名に置き換えます。 このコマンドは、psql ユーティリティを使用して roles.sql ファイルに含まれる SQL コマンドを実行し、ロールとユーザーをターゲット データベースに効果的に復元します。

たとえば、サーバーの名前が mydemoserver で、ユーザーの名前が myuser の場合、次のコマンドを実行します。

psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser

単一サーバーを使用している場合、ユーザー名にはサーバー名コンポーネントが含まれます。 そのため、myuser の代わりに myuser@mydemoserver を使用します。

新しい データベースを作成します。

データベースを復元する前に、新しい空のデータベースを作成することが必要になる場合があります。 これを行うには、使用しているユーザーに CREATEDB アクセス許可が必要です。 一般的に使用される 2 つの方法を以下に示します。

1. createdb ユーティリティを使用する createdb プログラムを使用すると、PostgreSQL にログインしたり、オペレーティング システム環境から離れたりすることなく、bash コマンド ラインから直接データベースを作成できます。 次に例を示します。

   createdb <new database name> -h <server name> -U <user name>
   

   たとえば、サーバーの名前が mydemoserver、ユーザーの名前が myuser の場合で、作成する新しいデータベースが testdb_copy の場合、次のコマンドを実行します。

   createdb testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser
   

   単一サーバーを使用している場合、ユーザー名にはサーバー名コンポーネントが含まれます。 そのため、myuser の代わりに myuser@mydemoserver を使用します。

2. SQL コマンドを使用する SQL コマンドを使用してデータベースを作成するには、コマンド ライン インターフェイスまたはデータベース管理ツールを使用して PostgreSQL サーバーに接続する必要があります。 接続したら、次の SQL コマンドを使用して新しいデータベースを作成できます。

CREATE DATABASE <new database name>;

<new database name> は、新しいデータベースに付ける名前に置き換えます。 たとえば、testdb_copy という名前のデータベースを作成する場合、コマンドは次のようになります。

CREATE DATABASE testdb_copy;

ダンプの復元

ターゲット データベースを作成した後、ダンプ ファイルからこのデータベースにデータを復元できます。 復元中にエラーを errors.log ファイルに記録し、復元が完了した後にその内容を確認してエラーを調べます。

psql -f <database name>_dump.sql <new database name> -h <server name> -U <user name> 2> errors.log

psql -f testdb_dump.sql testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log

pg_restore -Fd -j <number of cores> -d <new database name> <database name>.dump -h <server name> -U <user name> 2> errors.log

pg_restore -Fd -j 2 -d testdb_copy testdb.dump -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log

復元後のチェック

復元プロセスが完了した後に errors.log ファイルを確認して、エラーが発生しているかを確認することが重要です。 この手順は、復元されたデータの整合性と完全性を確保するために重要です。 データベースの信頼性を維持するために、ログ ファイルで見つかったすべての問題に対処します。

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

大規模なデータベースを扱う場合で、ダンプと復元のプロセスに時間がかかる場合があり、また、効率性と信頼性を確保するための最適化が必要になることがあります。 これらの操作のパフォーマンスに影響を与える可能性があるさまざまな要因に着目し、それらを最適化するための手順を実行することが重要です。

ダンプと復元のプロセスの最適化に関する詳細なガイダンスについては、「pg_dump と pg_restore のベスト プラクティス」の記事を参照してください。 このリソースでは、大規模なデータベースを扱う際に役立つ可能性のある包括的な情報と戦略を確認できます。

次のステップ

• pg_dump と pg_restore のベスト プラクティス。
• Azure Database for PostgreSQL へのデータベースの移行については、「Database Migration Guide」 (データベースの移行ガイド) を参照してください。