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

  • [アーティクル]

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

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

重要

この記事で説明する手順とコマンドは、bash ターミナルで実行するように設計されています。 これには、Linux 用 Windows サブシステム (WSL)、Azure Cloud Shell、その他の bash 互換インターフェイスなどの環境が含まれます。 bash ターミナルを使用して手順に従い、このガイドで詳しく説明されているコマンドを実行していることを確認してください。 異なる種類のターミナルまたはシェル環境を使用すると、コマンドの動作が異なる場合があり、意図した結果が得られない可能性があります。

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

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

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

    Screenshot showing the placement of Connect blade in Azure portal.

  2. データベースを選択する: [接続] ブレードで、データベースのドロップダウン リストを見つけます。 ダンプを実行するデータベースを選択します。

    Screenshot showing the dropdown where specific database can be chosen.

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

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

    Screenshot showing two possible dump methods.

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

前提条件

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

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

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

重要

データのエクスポートまたはデータのpg_dumppsqlpg_restoreインポートの対象となるデータベース サーバーとpg_dumpall同じメジャー バージョンまたは上位のメジャー バージョンのユーティリティ、およびユーティリティを使用することが不可欠です。 これを行わないと、データの移行に失敗する可能性があります。 ターゲット サーバーのメジャー バージョンがソース サーバーよりも高い場合は、ターゲット サーバーと同じメジャー バージョンまたはそれより高いユーティリティを使用します。

Note

一度にエクスポートできるデータベースは 1 つだけであることに pg_dump 注意してください。 この制限は、選択した方法に関係なく、単一のファイルまたは複数のコアを使用しているかどうかに関係なく適用されます。

を使用してユーザーとロールをダンプする pg_dumpall -r

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

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

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

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

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

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

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

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

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

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

たとえば、ユーザーという名前mydemoservermyuserのサーバーがある場合は、次のコマンドを実行します。

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

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

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

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

  • サービス固有ユーザーの除外: 単一サーバー サービス ユーザーを除外します (例azure_superuserazure_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_pg_adminazuresuで始まる行を含むazure_superuser行をCREATE ROLE replication削除しALTER ROLE replication、ステートメントからALTER ROLE属性とNOBYPASSRLS属性をNOSUPERUSER削除します。

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

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

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

たとえば、サーバー名、名前付きmydemoserverユーザー、およびデータベースというtestdb名前myuserのサーバーがある場合は、次のコマンドを実行します。

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

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

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

ロールとユーザーを復元する

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

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

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

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

たとえば、ユーザーという名前mydemoservermyuserのサーバーがある場合は、次のコマンドを実行します。

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

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

Note

移行元の単一サーバーまたはオンプレミス サーバーとターゲット サーバーに同じ名前のユーザーが既にある場合は、この復元プロセスによってこれらの役割のパスワードが変更される可能性があることに注意してください。 そのため、後続のコマンドを実行する必要がある場合は、更新されたパスワードが必要になる場合があります。 これは、ソース サーバーがフレキシブル サーバーの場合は適用されません。フレキシブル サーバーでは、セキュリティ対策が強化されているため、ユーザーのパスワードのダンプは許可されません。

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

データベースを復元する前に、新しい空のデータベースを作成することが必要になる場合があります。 これを行うには、使用しているユーザーにアクセス許可が 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

たとえば、名前が付いたサーバー、ユーザー名mydemoservermyuser、および新しいデータベースが呼び出されているtestdb_copy場合は、次のコマンドを実行します。

psql -f testdb_dump.sql testdb_copy -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」 (データベースの移行ガイド) を参照してください。