チュートリアル: 移行サービスを使用して Amazon Aurora PostgreSQL から Azure Database for PostgreSQL にオンラインで移行する

この記事では、PostgreSQL データベースを Amazon Aurora から Azure Database for PostgreSQL にオンラインで移行する方法について説明します。

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

このチュートリアルでは、次の作業を行いました。

• 前提条件を満たす
• 移行を開始する
• 移行を監視する
• 一括移行を開始する
• 移行を検証する

前提条件

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

• ソース バージョンを確認する
• ソース セットアップ用の test_decoding をインストールする
• ターゲット セットアップを構成する
• ソースとして CDC を有効にする
• ネットワーク セットアップを構成する
• 拡張機能を有効にする
• サーバー パラメーターを確認する
• ユーザーとロールを確認する

ソース バージョンの確認

ソースの PostgreSQL サーバーのバージョンが 9.5 以降である必要があります。 ソース PostgreSQL のバージョンが 9.5 より前の場合は、移行を開始する前にバージョンを 9.5 以降にアップグレードします。

ソース セットアップ用の test_decoding をインストールする

• test_decoding プラグインは、論理デコード メカニズムを介して Write-Ahead Logging (WAL) を受け取ります。 WAL は、このプラグインによって、実行される操作のテキスト表現にデコードされます。
• Amazon RDS for PostgreSQL では、test_decoding プラグインがプレインストールされており、論理レプリケーションの準備ができています。 たとえば、変更データ キャプチャ (CDC) や外部システムへのレプリケーションなどのために、論理レプリケーション スロットを簡単に設定し、WAL の変更をストリーミングできます。

test_decoding プラグインの詳細については、PostgreSQL のドキュメントを参照してください。

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

移行を開始する前に、Azure 内に Azure Database for PostgreSQL のインスタンスを作成する必要があります。 Azure Database for PostgreSQL - フレキシブル サーバー用にプロビジョニングされる SKU はソースと一致する必要があります。

詳細については、Azure Database for PostgreSQL のインスタンスの作成に関するページを参照してください。

ソースとして CDC を有効にする

• test_decoding 論理デコード プラグインは、変更されたレコードをソースからキャプチャします。

• 移行ユーザーに、レプリケーションにアクセスするためのアクセス許可を付与するには、次のコマンドを実行します。

  GRANT rds_replication TO <username>;
  

• ソース PostgreSQL のインスタンスで、新しいパラメーター グループを作成して、DB Clusters パラメーター グループ内の次のパラメーターを変更します。

  • rds.logical_replication を 1 に設定します。
  • max_replication_slots を 1 より大きい値に設定します。 この値は、移行対象として選んだデータベースの数より大きい値にする必要があります。
  • max_wal_senders を 1 より大きい値に設定します。 これは、少なくとも max_replication_slots の値と同じ値に、インスタンスで既に使用されている送信者の数を加えた値である必要があります。
  • wal_sender_timeout パラメーターは、指定されたミリ秒数より長い非アクティブなレプリケーション接続を終了します。 Amazon Aurora PostgreSQL インスタンスの既定値は 30000 milliseconds (30 seconds) です。 値を 0 (zero) に設定すると、タイムアウト メカニズムが無効になり、移行に有効な設定になります。

• ターゲット フレキシブル サーバーで、オンライン移行でログを格納するストレージが不足しないようにするために、プロビジョニングされたマネージド ディスクを使用してテーブルスペースに十分な記憶域があることを確認します。 移行の期間中、サーバー パラメーター azure.enable_temp_tablespaces_on_local_ssd を無効にします。 移行後、このパラメーターを元の状態に復元します。

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

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

ネットワーク セットアップの詳細については、移行サービスのネットワーク シナリオに関するページを参照してください。

拡張機能を有効にする

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

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

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

Note

shared_preload_libraries パラメーターに何らかの変更を加えた場合は、再起動が必要になります。

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

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

• ソース PostgreSQL データベースのサーバー パラメーター値を Azure Database for PostgreSQL のインスタンスと一致させます。 Azure portal で、[サーバー パラメーター] に移動し、値を手動で更新します。

• パラメーターの変更を保存し、必要に応じて 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 に正しく移行されるようにすることができます。

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

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

移行を開始する

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

Azure Portal

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

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

移行タスクを構成する

Azure portal で移行タスクを構成するには、次の手順を行います。

1. Web ブラウザーを開き、Azure portal に移動します。 資格情報を入力してサインインします。

2. Azure Database for PostgreSQL - フレキシブル サーバーのインスタンスに移動します。

3. サービス メニューで、[移行] を選択します。

   

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

   移行サービスを初めて使用すると、最初の移行を開始するためのプロンプトが表示された空のグリッドが表示されます。 フレキシブル サーバー ターゲットへの移行が既に作成されている場合、グリッドに、試行された移行に関する情報が表示されます。

5. [作成] を選択して、一連のタブを順に進んで移行を設定します。

   

セットアップ

次の情報を入力または選択します。

• 移行名: このフレキシブル サーバー ターゲットへの各移行の一意識別子を入力します。 移行名で使用できるのは、英数字とハイフン (-) のみです。 名前はハイフンで開始することはできません。また、ターゲット サーバーに対して一意である必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行に、同じ名前を付けることはできません。

• ソース サーバーの種類: クラウドベースの PostgreSQL サービス、オンプレミスのセットアップ、仮想マシンなど、PostgreSQL ソースと一致するソースの種類を選択します。

• 移行オプション: 移行前の検証について、次のいずれかのオプションを選択します。

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

  移行前の検証については [検証] または [検証と移行] オプションを選択することをお勧めします。

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

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

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

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

移行ランタイム サーバーは、移行サービスの特殊な機能です。 ランタイム サーバーは、移行時の中継サーバーとして機能します。 これは、ターゲット サーバーではない Azure Database for PostgreSQL - フレキシブル サーバーの別個のインスタンスです。 ランタイム サーバーは、プライベート ネットワークを経由してのみアクセスできるソース環境からのデータベースの移行を支援します。

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

ソースに接続する

[ソースに接続] タブで、データベース ソースについて次の情報を入力または選択します。

• サーバー名: ソース PostgreSQL インスタンスのホスト名または IP アドレスを入力します。
• ポート: ソース サーバーのポート番号を入力します。
• サーバー管理者ログイン名: ソース PostgreSQL サーバーのユーザー名を入力します。
• パスワード: ソース PostgreSQL サーバーのパスワードを入力します。
• SSL モード: サポートされている値は [優先] と [必須] です。 ソース PostgreSQL サーバーの Secure Sockets Layer (SSL) がオフになっている場合は、[優先] を選択します。 ソース サーバーの SSL がオンになっている場合は、[必須] を選択します。 SSL 値は、postgresql.conf ファイル内で設定されます。
• 接続のテスト: ターゲットとソース間の接続テストを開始します。 接続が成功したら、次の手順に進み、ターゲットとソースの間のネットワークの問題を特定し、ソースのユーザー名とパスワードを検証します。 テスト接続の確立には数分かかります。

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

移行ターゲットを選んでください

[移行ターゲットの選択] タブで、サブスクリプション、リソース グループ、サーバー名に加えて、フレキシブル サーバー ターゲットについて次の情報を入力または選択します。

• 管理者ユーザー名: ターゲット PostgreSQL サーバーの管理者ユーザー名。
• パスワード: ターゲット PostgreSQL サーバーのパスワード。
• カスタム FQDN/IP (省略可能): カスタム FQDN/IP フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはカスタム DNS 名前空間がある場合に使用でき、特定の FQDN または IP アドレス経由でのみアクセスできます。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com が含まれる場合、またはこのゾーンのクエリを 168.63.129.16 に転送し、FQDN が Azure パブリック DNS ゾーンまたはプライベート DNS ゾーンで解決される場合、これには、flexibleserver.example.com や 198.1.0.2、または flexibleserver.postgres.database.azure.com のような PostgreSQL FQDN などのエントリを含めることができます。
• 接続のテスト: ターゲットとソース間の接続テストを開始します。 接続が成功したら、次の手順に進み、ターゲットとソースの間のネットワークの問題を特定し、ターゲット サーバーのユーザー名とパスワードを検証します。 テスト接続の確立には数分かかります。

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

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

[移行するデータベースの選択] タブで、ソース PostgreSQL サーバーから移行するユーザー データベースを一覧から選択します。

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

まとめ

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

移行を監視する

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

移行を表示するグリッドには、次の列があります。

• 名前
• Status
• 移行モード
• 移行の種類
• ソース サーバー
• ソース サーバーの種類
• データベース
• 期間
• [開始時刻]

エントリは、開始時刻の降順に表示され、最新のエントリが一番上に表示されます。 メニュー バーの [更新] を選択すると、検証または移行の実行の状態を更新できます。

移行の詳細

関連する詳細を表示するには、移行の一覧で移行の名前を選択します。

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

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

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

検証の詳細は、以下のようにインスタンス レベルとデータベース レベルで確認できます。

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

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

• データベース レベルでの検証:

  • Azure Database for PostgreSQL - フレキシブル サーバー内の拡張機能と照合順序のサポートに関連する個々のデータベースの検証を確認します。

移行と検証の現在の状態は、[移行の詳細] ペインで確認できます。

次の表は、いくつかの発生する可能性のある移行の状態とサブ状態を示しています。

移行の状態

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

移行サブ状態

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

検証のサブ状態

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

一括移行を開始する

[移行] と [検証と移行] の両方が表示される場合、オンライン移行を完了するには、一括移行を開始する追加の手順が必要です。 基本データのコピーまたは複製が完了すると、移行は WaitingForUserAction 状態に移り、サブ状態は WaitingForCutoverTrigger になります。 この状態では、ユーザーは移行を選ぶことでポータルから一括移行をトリガーできます。

一括移行を開始する前に、次の点を確認することが重要です。

• ソースへの書き込みが停止されている。
• latency の値が 0 または 0 に近い値まで低下している。

latency の値は、[移行の詳細] ペインで取得できます。

latency 値は、ターゲットが最後にソースと同期した時期を示します。 この時点で、ソースへの書き込みを停止し、一括移行を開始できます。 ソース サーバー上のトラフィックが多い場合は、まず書き込みを停止して、latency を 0 に近い値にすることをお勧めします。 その後、一括移行を開始します。

一括移行操作は、ソースからターゲットに保留中のすべての変更を適用して、移行を完了します。 latency がゼロ以外の場合でも、一括移行をトリガーすると、レプリケーションはその時点で停止します。 一括移行の時点までのソース上のすべてのデータがターゲットに適用されます。 たとえば、一括移行の時点で待機時間が 15 分の場合、過去 15 分間に変更されたすべてのデータがターゲットに適用されます。 一括移行が完了するまでの時間は、その 15 分間に発生した変更のバックログによって異なります。 そのため、一括移行をトリガーする前に、待機時間を 0 または 0 に近い値にすることをお勧めします。

Migrating Data サブ状態または一括移行 (オンライン移行の場合) が正常に完了すると、移行は Succeeded 状態に移ります。 Migrating Data サブ状態で問題が発生した場合、移行は Failed 状態に移ります。

Azure CLI

この記事では、Azure CLI を使用して、PostgreSQL データベースを Amazon Aurora から Azure Database for PostgreSQL に移行する方法について説明します。 Azure CLI は、データベースの移行を含め、さまざまなタスクを実行するために使用できる強力で柔軟なコマンド ライン インターフェイスです。

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

Azure CLI がインストールされたら、コマンド ラインで、次のコマンドを使用して Azure アカウントにサインインします。

az login

移行タスクを構成する

1. 移行を開始するには、移行の詳細を保持するための JSON ファイルを作成します。 JSON ファイルを <filename>.json としてローカル コンピューターに保存します。 たとえば、ファイルを C:\migration-CLI\migration_body.json として保存します。

   次の JSON をコピーし、それを JSON ファイルに貼り付けます。 <placeholders> を、実際のシナリオに該当する情報に置き換えます。

   {
   "properties": {
   "SourceDBServerResourceId": "<source host name or IP address>:<port>@<username>",
           "SecretParameters": {
               "AdminCredentials": {
                   "SourceServerPassword": "<source password>",
                   "TargetServerPassword": "<target password>"
               },
               "targetServerUserName": "<target username>"
           },
           "DBsToMigrate": "<a comma-separated list of databases in an array, similar to the example "ticketdb","timedb","inventorydb">",
           "OverwriteDBsInTarget": "true",
           "sourceType": "AWS_AURORA",
           "sslMode": "Require"
       }
   }
   

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

   az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
   

3. 前述の手順では、実行される移行はありません。 次のコマンドを実行して新しい移行を開始します。

   az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
   

4. 次のコマンドを実行して、前の手順で移行状態を開始します。 移行名を指定すると、移行の状態を確認できます。

   az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
   

   移行の状態が Azure CLI に表示されます。 Azure portal で Azure Database for PostgreSQL - フレキシブル サーバーのインスタンスの状態を確認することもできます。

移行をキャンセルまたは削除する

cancel コマンドを使用すると、進行中の移行の試行を取り消すことができます。 このコマンドは、特定の移行の試行を停止し、ターゲット サーバー上のすべての変更をロールバックします。

移行を削除する Azure CLI コマンドを次に示します。

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1

カットオーバー

オンライン移行で基本データの移行が完了すると、移行タスクは WaitingForCutoverTrigger サブ状態に移ります。 この状態で、Azure CLI で次のコマンドを使用すると、一括移行をトリガーできます。

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --cutover

また、ポータルの移行グリッドで移行の名前を選択して、一括移行をトリガーすることもできます。

移行を検証する

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

移行後、以下のタスクを実行できます。

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

関連するコンテンツ

• Amazon Aurora PostgreSQL からオフラインで移行する
• 移行サービス
• オンプレミスと Azure VM からの移行
• 既知の問題と制限事項