チュートリアル: 移行サービスを使用した AWS RDS PostgreSQL から Azure Database for PostgreSQL へのオフラインでの移行

この記事では、PostgreSQL データベースを AWS RDS から 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 サーバーがターゲットの Azure Database for PostgreSQL サーバーと通信できることを確認します。 移行を成功させるには、次のネットワーク構成が不可欠です。

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

拡張機能を有効にする

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

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

拡張機能の詳細については、Azure Database for PostgreSQL の拡張機能に関する記事を参照してください。

Note

shared_preload_libraries パラメーターに変更がある場合は、再起動が必要です。

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

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

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

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

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

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

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

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

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

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

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

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

移行する

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

Azure portal では、シンプルで直感的なウィザードベースのエクスペリエンスが提供され、移行の手順が示されます。 このチュートリアルで説明されている手順に従うと、データベースを Azure Database for PostgreSQL - フレキシブル サーバーにシームレスに転送でき、その強力な機能とスケーラビリティを活用できます。

Azure portal を使用して移行するには、まず移行タスクを構成し、ソースとターゲットに接続してから、移行を実行します。

移行タスクを構成する

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

  1. Web ブラウザーを開き、ポータルに移動します。 資格情報を入力してサインインします。 既定のビューはサービス ダッシュボードです。

  2. お使いの Azure Database for PostgreSQL フレキシブル サーバーに移動します。

  3. フレキシブル サーバーの [概要] タブの左側のメニューで、下にスクロールして [移行] を選択します。

    Azure portal での移行の選択のスクリーンショット。

  4. [作成] ボタンを選択して、AWS RDS からフレキシブル サーバーに移行します。

    Note

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

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

  5. ウィザードベースの一連のタブを移動して移行を実行するには、[作成] ボタンを選択します。

    移行の作成ページのスクリーンショット。

セットアップ

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

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

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

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

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

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

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

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

[次へ: ソースに接続] ボタンを選択します。

開始するための [移行のセットアップ] ページのスクリーンショット。

ランタイム サーバーを選択する

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

ランタイム サーバーについて詳しくは、移行ランタイム サーバーに関する記事を参照してください。

移行ランタイム サーバー ページのスクリーンショット。

ソースに接続する

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

  • サーバー名 - ソース PostgreSQL インスタンスのホスト名または IP アドレスを指定します

  • ポート - ソース サーバーのポート番号

  • サーバー管理者ログイン名 - ソース PostgreSQL サーバーのユーザー名

  • パスワード - ソース PostgreSQL サーバーのパスワード

  • SSL モード - サポートされている値が優先されかつ必要です。 ソース PostgreSQL サーバーの SSL が OFF の場合は、SSLMODE=prefer を使用します。 ソース サーバーの SSL が ON の場合は、SSLMODE=require を使用します。 SSL 値は postgresql.conf ファイルで決定できます。

  • テスト接続 - ターゲットとソースの間の接続テストを実行します。 接続が成功すると、ユーザーは次の手順に進むことができます。ターゲットとソースの間のネットワークの問題を特定し、ソースのユーザー名/パスワードを確認する必要があります。 テスト接続の確立には数分かかります。

テスト接続が成功したら、[次へ: 移行ターゲットの選択] ボタンを選択します。

ソースに接続ページのスクリーンショット。

移行ターゲットを選択する

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

  • 管理者ユーザー名 - ターゲット PostgreSQL サーバーの管理者ユーザー名

  • パスワード - ターゲット PostgreSQL サーバーのパスワード

  • テスト接続 - ターゲットとソースの間の接続テストを実行します。 接続が成功すると、ユーザーは次の手順に進むことができます。 それ以外の場合は、ターゲットとソースの間のネットワークの問題を特定し、ターゲットのユーザー名/パスワードを確認する必要があります。 テスト接続には、ターゲットとソースの間の接続を確立するのに数分かかります

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

移行ターゲットの接続ページのスクリーンショット。

移行するデータベースを選択する

[移行するデータベースの選択] タブで、移行元の PostgreSQL サーバーから移行するユーザー データベースの一覧を選択できます。
データベースを選択した後、[次へ: 概要] を選択します

fetchDB 移行ページのスクリーンショット。

まとめ

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

移行の要約ページのスクリーンショット。

移行を監視する

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

移行の監視ページのスクリーンショット。

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

移行の詳細

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

[セットアップ] タブで、[検証して移行] として移行オプションを選択しました。 このシナリオでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。

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

  • 検証がエラーなしで完了すると、移行が開始され、ワークフローは Migrating Data のサブストレートに移ります。

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

  • インスタンス レベルでの検証

    • 接続チェック、ソース バージョン (つまり PostgreSQL バージョン >= 9.5)、サーバー パラメーター チェック (Azure Database for PostgreSQL - フレキシブル サーバーのサーバー パラメーターで拡張機能が有効になっている場合) に関連する検証が含まれます。
  • データベース レベルでの検証

    • これには、フレキシブル サーバーである Azure Database for PostgreSQL での拡張機能と照合順序のサポートに関連する個々のデータベースの検証が含まれています。

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

検証と移行を示す詳細のスクリーンショット。

移行の状態には、次のものがあります。

移行の状態

State 説明
InProgress 移行インフラストラクチャのセットアップが進行中、または実際のデータ移行が進行中です。
取り消されました 移行が取り消されたか削除されました。
Failed 移行は失敗しました。
Validation Failed 検証が失敗しました。
Succeeded 移行が成功し、完了しました。
WaitingForUserAction オンライン移行にのみ適用されます。 ユーザー アクションがカットオーバーを実行するのを待機しています。

移行サブ状態

下位状態 説明
PerformingPreRequisiteSteps データ移行のためのインフラストラクチャのセットアップが進行中です。
Validation in Progress 検証を実行中です。
MigratingData データ移行が進行中です。
CompletingMigration 移行は完了の最終段階です。
完了 移行が完了しました。
Failed 移行は失敗しました。

検証のサブ状態

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

移行の取り消し

進行中の検証または移行は取り消すことができます。 ワークフローを取り消すには、InProgress 状態である必要があります。 Succeeded または Failed 状態の検証または移行を取り消すことはできません。

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

完了時に移行を確認する

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

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

  • フレキシブル サーバー上のデータを確認し、ソース インスタンスの正確なコピーであることを確認します。
  • 検証後、必要に応じてフレキシブル サーバーで高可用性オプションを有効にします。
  • アプリケーションのニーズに合わせてフレキシブル サーバーの SKU を変更します。 この変更には、データベース サーバーの再起動が必要です。
  • ソース インスタンスの既定値からサーバー パラメーターを変更する場合は、フレキシブル サーバーでこれらのサーバー パラメーターの値をコピーします。
  • タグ、アラート、ファイアウォール規則 (該当する場合) などの他のサーバー設定をソース インスタンスからフレキシブル サーバーにコピーします。
  • 接続文字列がフレキシブル サーバーをポイントするように、アプリケーションに変更を加えます。
  • データベースのパフォーマンスを厳密に監視して、パフォーマンス チューニングが必要かどうかを確認します。