移行サービスを使用して、Google Cloud SQL for PostgreSQL から Azure Database for PostgreSQL にオフラインで移行する

この記事では、オフライン モードで Google Cloud SQL for PostgreSQL インスタンスを Azure Database for PostgreSQL フレキシブル サーバーに移行する方法について説明します。

Azure Database for PostgreSQL の移行サービスは、Azure portal と Azure CLI に統合されたフル マネージド サービスです。 Azure Database for PostgreSQL フレキシブル サーバーへの移行を簡略化するように設計されています。

• 前提条件
• 移行を実行する
• 移行を監視する
• 完了時に移行を確認する

前提条件

移行を完了するには、次の前提条件が必要です。

Azure Database for PostgreSQL 移行サービスを使用して移行を開始する前に、オフライン移行シナリオ用に特に設計された次の前提条件を満たすことが重要です。

• ソース バージョンを確認する
• ターゲット セットアップを構成する
• ネットワーク セットアップを構成する
• 拡張機能を有効にする
• サーバー パラメーターを確認する
• ユーザーとロールを確認する
• ターゲットで高可用性 (信頼性) と読み取りレプリカを無効にする

ソース バージョンの確認

ソースの PostgreSQL サーバーのバージョンが 9.5 以降である必要があります。

ソース PostgreSQL のバージョンが 9.5 よりも古い場合は、移行を開始する前に 9.5 以上にアップグレードします。

ターゲット セットアップを構成する

移行を開始する前に、Azure で Azure Database for PostgreSQL を設定する必要があります。

Azure Database for PostgreSQL 用に選択された SKU は、互換性と適切なパフォーマンスを確保するために、ソース データベースの仕様に対応している必要があります。

PostgreSQL のバージョン (メジャーまたはマイナー) 間で移行する場合、リリースノートで破壊的変更の可能性を確認し、データベースとアプリケーション間の互換性を確保してください。

ネットワーク セットアップを構成する

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの PostgreSQL サーバーがターゲットの Azure Database for PostgreSQL サーバーと通信できることを確認します。 移行を成功させるには、次のネットワーク構成が不可欠です。

ネットワーク セットアップの詳細については、移行サービスのネットワーク ガイドを参照してください。

ネットワークに関するその他の考慮事項

ソースとターゲットの PostgreSQL インスタンス間の接続を容易にするには、ソース サーバーの pg_hba.conf ファイルを検証して変更する必要があります。 このファイルにはクライアント認証が含まれており、ターゲット PostgreSQL がソースに接続できるように構成する必要があります。 pg_hba.conf ファイルに変更を加える場合、通常、ソース PostgreSQL インスタンスを再起動して有効にする必要があります。

pg_hba.conf ファイルは、PostgreSQL インストールのデータ ディレクトリにあります。 ソース データベースがオンプレミスの PostgreSQL サーバーまたは Azure VM でホストされている PostgreSQL サーバーである場合は、このファイルを確認して構成する必要があります。

拡張機能を有効にする

Azure Database for PostgreSQL の移行サービスを使用して移行を確実に成功させるには、ソース PostgreSQL インスタンスの拡張機能を検証することが必要な場合があります。 拡張機能は、アプリケーションに必要になる可能性がある機能を提供します。 移行プロセスを開始する前に、ソース PostgreSQL インスタンス上の拡張機能を必ず検証してください。

Azure Database for PostgreSQL フレキシブル サーバーのターゲット インスタンスで、ソース PostgreSQL インスタンスで識別されるサポートされている拡張機能を有効にします。

詳細については、「 拡張機能とモジュール」を参照してください。

サーバー パラメーターを確認する

これらのパラメーターはターゲット環境に自動的に移行されないため、手動で構成する必要があります。

• Azure portal の [サーバー パラメーター] ページにアクセスし、それに応じて値を手動で更新することで、ソース PostgreSQL データベースの サーバー パラメーター 値を Azure Database for PostgreSQL と照合します。

• 必要に応じて、パラメーターの変更を保存し、Azure Database for PostgreSQL を再起動して新しい構成を適用します。

ユーザーとロールを確認する

Azure Database for PostgreSQL に移行する場合は、ユーザーとロールの移行には手動による介入が必要なので、個別に対処することが不可欠です:

• ユーザーとロールの手動移行: ユーザーとロールは、Azure Database for PostgreSQL に手動で移行する必要があります。 このプロセスを容易にするために、 pg_dumpall ユーティリティと --globals-only フラグを使用して、ロールやユーザーなどのグローバル オブジェクトをエクスポートできます。 次のコマンドを実行し、 <<username>> を実際のユーザー名に置き換え、 <<filename>> を目的の出力ファイル名に置き換えます。

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• スーパーユーザー ロールの制限: Azure Database for PostgreSQL では、スーパーユーザー ロールはサポートされていません。 そのため、スーパーユーザー特権を持つユーザーは、移行前にこれらの特権を削除する必要があります。 必要に応じてアクセス許可とロールを調整してください。

これらの手順に従うことで、スーパーユーザーの制限に関連する問題が発生することなく、ユーザー アカウントとロールが Azure Database for PostgreSQL に正しく移行することができます。

ターゲットで高可用性 (信頼性) と読み取りレプリカを無効にする

• ターゲット環境で高可用性 (信頼性) と読み取りレプリカを無効にすることは必須です。 これらの機能は、移行が完了した後にのみ有効にする必要があります。

• これらのガイドラインに従うことで、高可用性や読み取りレプリカに伴う変数を避け、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、Azure のデータベース環境の可用性とスケーラビリティを向上させることができます。

移行を実行する

Azure portal または Azure CLI を使用して移行できます。

ポータル

この記事では、Azure portal を使用して、PostgreSQL データベースを Google Cloud SQL for PostgreSQL サーバーから Azure Database for PostgreSQL に移行する方法について説明します。 Azure portal では、データベースの移行など、さまざまなタスクを実行できます。 このチュートリアルで説明されている手順に従って、データベースを Azure にシームレスに転送し、その強力な機能とスケーラビリティを活用できます。

移行タスクを構成する

移行サービスには、Azure portal に関する簡単なウィザード ベースのエクスペリエンスが付属しています。

Azure portal を使用して以下を実行します。

1. お使いの Azure Database for PostgreSQL フレキシブル サーバーを選択します。

2. リソース メニューで、[移行] を選択 します。

   

3. [ 作成] を選択すると、ウィザードベースの一連のタブが表示され、Google Cloud SQL for PostgreSQL からフレキシブル サーバーへの移行が実行されます。

   注

   移行サービスを初めて使用すると、最初の移行を開始するためのプロンプトが表示された空のグリッドが表示されます。

   フレキシブル サーバー ターゲットへの移行が既に作成されている場合、グリッドには、試行された移行に関する情報が含まれるようになりました。

   

セットアップ

移行名、ソース サーバーの種類、オプション、モードなど、移行に関連する複数の詳細を指定する必要があります。

• 移行名 は、このフレキシブル サーバー ターゲットへの移行ごとに一意の識別子です。 このフィールドで使用できる文字は英数字のみで、ハイフン (-) 以外の特殊文字は使用できません。 名前はハイフンから開始できず、1 つのターゲット サーバーに対して一意である必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行で同じ名前を持つ必要はありません。

• ソース サーバーの種類 - PostgreSQL ソースに応じて、 Google Cloud SQL for PostgreSQL を選択できます。

• 移行オプション - 移行 をトリガーする前に検証を実行できます。 次のいずれかのオプションを選択できます。

  • [検証] - サーバーとデータベースがターゲットに移行できる状態になっていることを調べます。
  • 検証と移行 - 移行をトリガーする前に検証を実行します。 検証エラーがない場合は、移行が開始されます。

移行を実行する前に、事前移行検証を実行するには、常に [ 検証 ] または [ 検証と移行 ] オプションを選択することをお勧めします。

事前移行の検証の詳細については、事前移行に関するページを参照してください。

• 移行モードでは、移行のモードを選択できます。 [オフライン] が既定のオプションです。 この場合は、既定値を使用します。

[次へ: ランタイム サーバー] を選択します。

ランタイム サーバー

移行ランタイム サーバーは、移行中に中間サーバーとして機能するように設計された 、Azure Database for PostgreSQL の移行サービス内の特殊な機能です。 これは、ターゲット サーバーではない別の Azure Database for PostgreSQL フレキシブル サーバー インスタンスですが、プライベート ネットワーク経由でのみアクセスできるソース環境からのデータベースの移行を容易にするために使用されます。

ランタイム サーバーの詳細については、「 移行ランタイム サーバー」を参照してください。

[転送元サーバー]

[ ソース サーバー ] タブでは、データベースのソースである [セットアップ ] タブで選択したソースに関連する詳細を指定するように求められます。

• サーバー名 - ホストの名前またはソース PostgreSQL サーバーの IP アドレスを指定します。
• ポート - ソース サーバーのポート番号。
• 管理者ログイン - ソース PostgreSQL サーバーの管理者ユーザーの名前。
• パスワード - ソース PostgreSQL サーバーに接続するために指定された管理者ログインのパスワード。
• SSL モード - サポートされている値は preferred と required。 ソース PostgreSQL サーバーの SSL が OFF場合は、 preferを使用します。 ソース サーバーの SSL が ON場合は、 requireを使用します。 SSL 値は、ソース サーバーの postgresql.conf ファイルで決定できます。
• テスト接続 — ターゲットとソースの間の接続テストを実行します。 接続が成功したら、次のタブに進むことができます。これらのテストは、指定された資格情報を使用した認証の検証など、ターゲット サーバーとソース サーバーの間に存在する可能性のある接続の問題を特定することを目的としています。 テスト接続の確立には数秒かかります。

テスト接続が成功したら、[ 次へ: ターゲット サーバー] を選択します。

ターゲット サーバー

[ ターゲット サーバー ] タブには、サブスクリプション名、リソース グループ、サーバー名、場所、PostgreSQL バージョンなど、フレキシブル サーバー ターゲットのメタデータが表示されます。

• 管理者ログイン - ターゲット PostgreSQL サーバーの管理者ユーザーの名前。
• パスワード - ターゲット PostgreSQL サーバーに接続するために指定された管理者ログインのパスワード。
• カスタム FQDN または IP アドレス: カスタム FQDN または IP アドレス フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはカスタム DNS 名前空間がある場合に使用でき、特定の FQDN または IP アドレス経由でのみアクセスできます。 たとえば、カスタム DNS サーバーに DNS ゾーンが含まれている場合、 production-flexible-server.example.com、 198.1.0.2、PostgreSQL FQDN ( production-flexible-server.postgres.database.azure.com など) などのエントリが含まれる場合や、この postgres.database.azure.com ゾーンのクエリを 168.63.129.16に転送したりすると、FQDN は Azure パブリックまたはプライベート DNS ゾーンで解決されます。
• テスト接続 — ソースとターゲットの間の接続テストを実行します。 接続が成功したら、次のタブに進むことができます。これらのテストは、指定された資格情報を使用した認証の検証など、ソース サーバーとターゲット サーバーの間に存在する可能性のある接続の問題を特定することを目的としています。 テスト接続の確立には数秒かかります。

テスト接続が成功したら、[次へ: 検証または移行するデータベース] を選択します

検証または移行するデータベース

[ 検証または移行するデータベース ] タブで、移行元の PostgreSQL サーバーから移行するユーザー データベースの一覧を選択できます。

データベースを選択したら、[ 次へ: 概要] を選択します。

まとめ

[ 概要 ] タブには、検証または移行を作成するためのソースとターゲットの詳細がすべてまとめられます。 詳細を確認し、[ 検証と移行の開始] を選択します。

検証または移行を取り消す

進行中の検証または移行は取り消すことができます。 ワークフローを取り消すことができるように、ワークフローは 進行中 の状態である必要があります。 [成功] または [失敗] 状態の検証または移行を取り消すことはできません。

• 検証を取り消すと、さらに検証アクティビティが停止し、検証が Canceled 状態に移動します。
• 移行を取り消すと、ターゲット サーバーでそれ以上移行アクティビティは行われなくなり、Canceled 状態になります。 キャンセル アクションは、移行サービスがターゲット サーバーで行ったすべての変更を返します。

CLI

この記事では、Azure CLI を使用して、PostgreSQL データベースを Azure 仮想マシンまたはオンプレミスの PostgreSQL インスタンスから Azure Database for PostgreSQL に移行する方法について説明します。 Azure CLI には、データベースの移行など、さまざまなタスクを実行できる強力で柔軟なコマンド ライン インターフェイスが用意されています。 この記事で説明されている手順に従うと、データベースを Azure にシームレスに転送でき、その強力な機能とスケーラビリティを活用できます。

移行サービスでの Azure CLI の詳細については、移行サービス用に Azure CLI を設定する方法に関するページを参照してください。

CLI がインストールされたら、コマンド プロンプトを開き、以下のコマンドを使用して自分の Azure アカウントにログインします。

az login

移行タスクを構成する

移行を開始するには、移行の詳細を含む JSON ファイルを作成します。 この JSON ファイルには、次の情報が含まれています:

• 以下のプレースホルダー << >> を JSON 行で編集し、CLI が呼び出されている <<filename>>.json としてローカル コンピューター内にこれらを格納します。 このチュートリアルでは、ファイルをc:/migration-CLI/migration_body.jsonに保存しました。

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "AWS_AURORA",
        "sslMode": "Prefer"
    }
}

• 次のコマンドを実行して、移行が実行されているかどうかを確認します。 移行名は、Azure Database for PostgreSQL フレキシブル サーバー ターゲット内の移行全体で一意です。

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• 上記の手順では、移行は実行されないため、次のコマンドを実行して新しい移行を開始します。

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• 次のコマンドを実行して、前の手順で開始した移行の状態を確認します。 移行の状態を確認するには、移行名を指定します。

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• 移行の進行状況と状態は、Azure CLI に表示されます。

• Azure portal で進行状況と状態を確認することもできます。

• cancel コマンドを使用して、進行中の移行の試行を取り消すことができます。 このコマンドは、特定の移行試行を停止し、ターゲット サーバーで行われた可能性のあるすべての変更をロールバックします。 "進行中" 状態の移行を取り消す CLI コマンドを次に示します。

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

移行を監視する

[ 検証と移行の開始 ] ボタンを選択すると、検証または移行の作成が成功したことを示す通知が数秒で表示されます。 フレキシブル サーバーの [移行 ] ページに自動的にリダイレクトされます。 エントリに [状態] が [進行中] と表示されます。 このワークフローは、移行インフラストラクチャを設定し、ネットワーク接続を確認するのに 2 ~ 3 分かかります。

移行を表示するグリッドには、 名前、 状態、 移行モード、移行の 種類、 移行元サーバー、ソース サーバーの 種類、 データベース、 期間、 開始時刻の列があります。 エントリは 、開始時刻 順に降順に並べ替えられて表示され、最新のエントリが先頭に表示されます。 ツール バーの [更新 ] ボタンを使用して、検証または移行の実行の状態を更新できます。

移行の詳細

グリッドで移行の名前を選んで、関連する詳細を表示します。

前の手順では、この移行を作成するときに、移行オプションを [検証して移行] として構成したことを覚えておいてください。 このシナリオでは、最初に検証が実行されてから移行が開始されます。 前提条件ステップの 実行 のサブ状態が完了すると、ワークフローは進行中の検証のサブ状態 に移動します。

• 検証にエラーがある場合、移行は Failed 状態になります。

• 検証がエラーなしで完了すると、移行が開始され、ワークフローはデータの 移行のサブ状態に移動します。

検証の詳細は、インスタンス レベルとデータベース レベルで使用できます。

• 検証の詳細 (例)
  • 接続チェック、ソース バージョン、つまり PostgreSQL バージョン >= 9.5、およびサーバー パラメーター チェックに関連する検証が含まれています。これは、Azure Database for PostgreSQL フレキシブル サーバーのサーバー パラメーターで拡張機能が有効になっているかどうかです。
• データベースの検証と移行の詳細
  • これには、Azure Database for PostgreSQL フレキシブル サーバーでの拡張機能と照合順序のサポートに関連する個々のデータベースの検証が含まれています。

[移行の詳細] ページで、[ 検証の状態 ] と [移行の 状態 ] を確認できます。

移行の状態として考えられるもの:

移行の状態

ステータス	説明
進行中	移行インフラストラクチャのセットアップが進行中、または実際のデータ移行が進行中です。
取り消されました	移行が取り消されたか削除されました。
失敗	移行は失敗しました。
検証に失敗しました	検証が失敗しました。
成功	移行が成功し、完了しました。

移行のサブステータス

副状態	説明
前提条件の手順の実行	データ移行のためのインフラストラクチャのセットアップが進行中です。
検証の進行中	検証を実行中です。
データの移行	データ移行が進行中です。
移行の完了	移行は完了の最終段階です。
完了	移行が完了しました。
失敗	移行は失敗しました。

検証サブステータス

副状態	説明
失敗	検証が失敗しました。
成功	検証が成功しました。
警告	検証で警告が発生しています。

完了時に移行を確認する

データベースを完了したら、ソースとターゲットの間のデータを手動で検証し、ターゲット データベース内のすべてのオブジェクトが正常に作成されたことを確認する必要があります。

移行後、次のタスクを実行できます:

• フレキシブル サーバー上のデータを確認し、ソース インスタンスの正確なコピーであることを確認します。

• 検証後、必要に応じてフレキシブル サーバーで高可用性オプションを有効にします。

• アプリケーションのニーズに合わせてフレキシブル サーバーの SKU を変更します。 この変更には、データベース サーバーの再起動が必要です。

• ソース インスタンスの既定値からサーバー パラメーターを変更する場合は、フレキシブル サーバーでこれらのサーバー パラメーターの値をコピーします。

• タグ、アラート、ファイアウォール規則 (該当する場合) などの他のサーバー設定をソース インスタンスからフレキシブル サーバーにコピーします。

• 接続文字列がフレキシブル サーバーを指すように、アプリケーションを変更してください。

• データベースのパフォーマンスを厳密に監視して、パフォーマンス チューニングが必要かどうかを確認します。

関連するコンテンツ

• Google Cloud SQL for PostgreSQL からオンラインで移行する
• 移行サービス
• 既知の問題と制限事項