ダンプと復元を使用した 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 - フレキシブル サーバーでのみ使用でき、単一サーバーでは使用できない点に注意してください。 この機能を使用する方法は次のとおりです。
Azure portal にアクセスする: まず、Azure portal に移動し、[接続] ブレードを選択します。
データベースを選択する: [接続] ブレードで、データベースのドロップダウン リストを見つけます。 ダンプを実行するデータベースを選択します。
適切な方法を選択します。データベースのサイズに応じて、次の 2 つの方法から選択できます。
pg_dump
>psql
- 単一のテキスト ファイルの使用: 小規模なデータベースに最適です。このオプションでは、ダンプと復元のプロセスに 1 つのテキスト ファイルを使用します。pg_dump
>pg_restore
- 複数のコアを使用する: 大規模なデータベースでは、複数のコアを使用してダンプと復元のプロセスを処理するため、この方法の方が効率的です。
コマンドのコピーと貼り付け: ポータルには、すぐに使用
pg_dump
できるコマンドやpsql
pg_restore
コマンドが用意されています。 これらのコマンドには、選択したサーバーとデータベースに応じて既に置き換えた値が含まれています。 これらのコマンドをコピーして貼り付けます。
前提条件
単一サーバーを使用している場合、またはフレキシブル サーバー ポータルにアクセスできない場合は、このドキュメント ページを参照してください。 ポータルのフレキシブル サーバーの [接続] ブレードに表示される情報と似た情報が含まれています。
このハウツー ガイドの手順を実行するには、以下が必要です。
- アクセスを許可するファイアウォール規則のある Azure Database for PostgreSQL サーバー。
- pg_dump、psql、pg_restore、およびpg_dumpall。ロールとアクセス許可を使用して移行する場合は、コマンド ライン ユーティリティがインストールされます。
- ダンプの場所を決定する: ダンプを実行する場所を選択します。 これは、別の VM、クラウド シェル (コマンド ライン ユーティリティが既にインストールされているが、適切なバージョンにない可能性があるため、常にバージョンを使用してチェック)、独自のラップトップなど、
psql --version
さまざまな場所から実行できます。 PostgreSQL サーバーとダンプまたは復元を実行している場所との間の距離と待機時間は、常に念頭に置いておきます。
重要
データのエクスポートまたはデータのpg_dump
psql
pg_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
たとえば、ユーザーという名前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_pg_admin
azuresu
で始まる行を含む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
実行し、ロールとユーザーをターゲット データベースに効果的に復元します。
たとえば、ユーザーという名前mydemoserver
myuser
のサーバーがある場合は、次のコマンドを実行します。
psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser
単一サーバーを使用している場合、ユーザー名にはサーバー名コンポーネントが含まれます。 したがって、代わりに myuser
、 を使用します myuser@mydemoserver
。
Note
移行元の単一サーバーまたはオンプレミス サーバーとターゲット サーバーに同じ名前のユーザーが既にある場合は、この復元プロセスによってこれらの役割のパスワードが変更される可能性があることに注意してください。 そのため、後続のコマンドを実行する必要がある場合は、更新されたパスワードが必要になる場合があります。 これは、ソース サーバーがフレキシブル サーバーの場合は適用されません。フレキシブル サーバーでは、セキュリティ対策が強化されているため、ユーザーのパスワードのダンプは許可されません。
新しい データベースを作成します。
データベースを復元する前に、新しい空のデータベースを作成することが必要になる場合があります。 これを行うには、使用しているユーザーにアクセス許可が CREATEDB
必要です。 一般的に使用される 2 つの方法を次に示します。
ユーティリティ
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
。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
たとえば、名前が付いたサーバー、ユーザー名mydemoserver
myuser
、および新しいデータベースが呼び出されている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」 (データベースの移行ガイド) を参照してください。