チュートリアル: 移行サービスを使用して Azure Database for PostgreSQL - 単一サーバーからフレキシブル サーバーに移行する

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

Azure portal を使って、Azure Database for PostgreSQL – 単一サーバーのインスタンスを Azure Database for PostgreSQL – フレキシブル サーバーに移行できます。 このチュートリアルでは、Azure portal を使用して、Azure Database for PostgreSQL シングル サーバーから PostgreSQL フレキシブル サーバーへのサンプル データベースの移行を実行します。

• Azure Database for PostgreSQL - フレキシブル サーバーを構成する
• 移行タスクを構成する
• 移行を監視する
• 移行の取り消し
• 移行後の処理

ポータル

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

オフライン

前提条件 (オフライン)

Azure Database for PostgreSQL の移行サービスを使用して移行を開始する前に、オフライン移行シナリオに適用される次の前提条件を満たす必要があります。

ソース バージョンの確認

ソース PostgreSQL のバージョンは >= 9.5 である必要があります。 ソース PostgreSQL のバージョンが 9.5 より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5 以上にアップグレードします。

ターゲット設定

• 移行プロセスを開始する前に、Azure Database for PostgreSQL フレキシブル サーバーを Azure にデプロイし、適切に構成する必要があります。

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

• 新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

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

ネットワークのセットアップ

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの 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 フレキシブル サーバーを再起動して新しい構成を適用します。

重要

移行を開始する前に、フレキシブル サーバーのpassword_encryption サーバー パラメーターを SCRAM-SHA-256 から MD5 に変更します。 これは、単一サーバーの既存の資格情報をフレキシブル サーバーで機能させるために不可欠です。

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

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

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

Azure Database for PostgreSQL フレキシブル サーバーを構成する

• ターゲット フレキシブル サーバーを作成します。 ガイド付きの手順については、ポータルを使用した Azure Database for PostgreSQL フレキシブル サーバーの作成に関するクイックスタートをご覧ください。

• サーバーの起動時にライブラリを読み込む必要がある拡張機能を許可リストに載せます。 移行を始める前に、拡張機能を許可リストに載せておくことが不可欠です。

• データベースのテーブル間のデータの分散が偏っている (ほとんどのデータが 1 つ (または少数) のテーブルに存在する) かどうかを調べます。 偏っている場合、移行の速度が予想より遅くなることがあります。 その場合は、大きなテーブルを並列に移行すると、移行の速度を上げることができます。

移行タスクを構成する

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

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

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

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

   

4. [作成] ボタンを選んで、単一サーバーからフレキシブル サーバーへの移行を始めます。 初めて移行サービスを使う場合、空のグリッドと最初の移行の開始を促すプロンプトが表示されます。

   

   フレキシブル サーバー ターゲットへの移行を既に作成してある場合は、単一サーバーからこのターゲットに対して試みられた移行に関する情報がグリッドに含まれます。

5. ウィザードベースの一連のタブを使用して、考えられるさまざまなソースからこのフレキシブル サーバー ターゲットへの移行を作成します。 既定では、[ソース サーバーの種類] は [Azure Database for PostgreSQL 単一サーバー] に設定されています。このシナリオでは、これを取り上げます。

または、Azure Database for PostgreSQL 単一サーバーから移行プロセスを開始することもできます。

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

2. シングル サーバーを選択すると、概要タブで移行に関連するバナーを確認できます。[今すぐ移行する] を選択して開始します。

   

3. 2 つのオプションがあるページが表示されます。 フレキシブル サーバーを既に作成してあり、それをターゲットとして使う場合は、[既存から選択] を選んで、対応する [サブスクリプション]、[リソース グループ]、[サーバー名] の詳細を選択します。 選択が完了したら、[移行ウィザードに移動] を選択し、[セットアップ] セクションの手順に進みます。

   

4. 新しいフレキシブル サーバーを作成することを選んだ場合は、[新規作成] を選択し、[作成ウィザードに移動] を選択します。 このアクションにより、フレキシブル サーバーの作成プロセスが実行され、フレキシブル サーバーがデプロイされます。

   

フレキシブル サーバーをデプロイした後、「移行タスクを構成する」のステップ 3 から 5 を行います。

セットアップ

最初のタブは [セットアップ] です。 これを行っていなかった場合は、移行を開始する前に、「Azure Database for PostgreSQL フレキシブル サーバーを構成する」の説明に従って、必要な拡張機能を許可リストに載せてください。

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

[ソース サーバーの種類] はソースを示します。 この場合は、Azure Database for PostgreSQL 単一サーバーです

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

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

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

[移行モード] では、オンラインとオフラインのどちらかの移行を選択できます。ここでは、[オフライン] に設定する必要があります。

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

ランタイム サーバー

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

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

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

ソースに接続する

[ソース] セクションでは、データベースのソースである単一サーバーに関連する詳細の指定を求められます。

[サブスクリプション] と [リソース グループ] を選ぶと、サーバー名のドロップダウン リストに、リージョン全体のそのリソース グループの下にシングル サーバーが表示されます。 データベースの移行元のソースを選びます。 単一サーバーから同じリージョン内のターゲットのフレキシブル サーバーに、データベースを移行できます。 リージョン間の移行は、インド、中国、UAE のサーバーについてのみ有効になります。

単一サーバー ソースを選ぶと、[場所] と [PostgreSQL バージョン] のボックスが自動的に設定されます。 データベースを正常に移行するために移行サービスで必要となるため、管理者ロールの資格情報を必ず指定してください。

[カスタム FQDN/IP] フィールドは省略可能であり、ソースがカスタム DNS サーバーの背後にある場合、またはソースにカスタム DNS 名前空間がある場合に使用できます。これにより、特定の FQDN または IP アドレス経由でのみソースにアクセスできるようにすることができます。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com が含まれている場合、またはサーバーによってこのゾーンのクエリが 168.63.129.16 に転送される場合、このフィールドには singleserver.example.com や 198.1.0.2 などのエントリ、または singleserver.postgres.database.azure.com のような PostgreSQL FQDN を含めることができます。その場合、FQDN は、Azure パブリックまたはプライベート DNS ゾーンで解決されます。

すべてのフィールドに入力したら、[ソースに接続する] リンクを選びます。 これにより、入力されたソース サーバーの詳細が正しく、ソース サーバーに到達可能であることが検証されます。

[次: 移行ターゲットを選択] ボタンを選択して続行します。

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

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

[カスタム FQDN/IP] フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはターゲットにカスタム DNS 名前空間がある場合に使用できます。これにより、特定の FQDN または IP アドレス経由でのみターゲットにアクセスできるようにすることができます。 たとえば、カスタム DNS サーバーに DNS ゾーン postgres.database.azure.com が含まれている場合、またはサーバーによってこのゾーンのクエリが 168.63.129.16 に転送される場合、このフィールドには flexibleserver.example.com や 198.1.0.2 などのエントリ、または flexibleserver.postgres.database.azure.com のような PostgreSQL FQDN を含めることができます。その場合、FQDN は、Azure パブリックまたはプライベート DNS ゾーンで解決されます。

[認証方法] とすべての認証関連フィールドの適切な値を選択します。 指定した ID はターゲット サーバーの管理者ユーザーのものであることが必要です。 必要なすべての情報を入力した後、[ターゲットに接続] リンクを選択します。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。

[次: 移行するデータベースの選択] ボタンを選択して、移行するデータベースを選択します。

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

このタブには、単一サーバー内のユーザー データベースの一覧が表示されます。 1 回の移行試行で最大 8 つのデータベースを選択して移行できます。 ユーザー データベースが 8 つを超える場合は、ソース サーバーとターゲット サーバーの間で、次のデータベース セットに対して移行プロセスが繰り返されます。 ターゲット サーバー上に存在する正確に同じ名前の選択したデータベースが上書きされます。

[次: サマリー] ボタンを選択して詳細を確認します。

まとめ

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

移行監視ポータル

移行を開始すると、検証または移行の作成が成功したことを示す通知が表示されます。 フレキシブル サーバーの [移行] ページに、自動的にリダイレクトされます。 ここには、最近作成された検証または移行に関する新しいエントリがあります。

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

[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。

グリッドで特定の移行の名前を選んで、関連する詳細を表示することもできます。

作成された検証または移行は、InProgress 状態と PerformingPreRequisiteSteps サブ状態になります。 ワークフローで移行インフラストラクチャとネットワーク接続が設定されるまで、2 から 3 分かかります。

移行の各オプションについて、移行を監視する方法を見てみましょう。

検証

PerformingPreRequisiteSteps サブ状態が完了すると、検証は Validation in Progress サブ状態になります。このサブ状態では、ソース サーバーとターゲット サーバーで移行の準備状況を評価するチェックが行われます。

すべての検証が Succeeded または Warning 状態の場合、検証は Succeeded 状態になります。

検証グリッドには次の情報があります

• [インスタンスの検証の詳細] と [データベースの検証の詳細] セクション: 移行の準備状況の確認に使われる検証ルールを表します。
• [検証名] - 特定の各検証規則の名前。
• [検証状態] - 各規則の結果を表し、3 つの値のいずれかになります。
  • [成功] - エラーが見つからなかった場合。
  • [失敗] - 検証エラーがある場合。
  • [警告] - 検証の警告がある場合。
• [実行時間] - 検証操作にかかった時間。
• [開始時刻 (UTC)] と [終了時刻 (UTC)] - 検証操作の UTC での開始時刻と終了時刻。

検証中にエラーが発生した場合、[検証状態] は [失敗] 状態になります。 失敗した [検証名] または [データベース名] の検証を選ぶと、ファンアウト ペインに、詳細と、このエラーを回避するために実行する必要がある是正措置が表示されます。

移行

PerformingPreRequisiteSteps というサブ状態が完了すると、移行は、データベースの複製/コピーが行われる [データを移行しています] のサブ状態に移ります。 移行が完了するまでの時間は、移行するデータベースのサイズと形状によって異なります。 データがすべてのテーブルにほぼ均等に分散されている場合、移行はすぐに完了します。 テーブル サイズにスキューがあると、相対的に長い時間がかかります。

移行中のいずれかのデータベースを選ぶと、ファンアウト ペインが表示されます。 すべてのテーブル数 (コピー済み、キュー済み、コピー中、エラー) と、データベースの移行状態が表示されます。

MigratingData 状態が正常に完了すると、移行は Succeeded 状態に移ります。 Migrating Data 状態で問題が発生した場合、移行は Failed 状態に移ります。

移行が Succeeded 状態になると、単一サーバーからフレキシブル サーバー ターゲットへのスキーマとデータの移行が完了します。 ページを更新して進行状況を確認できます。

検証と移行

このオプションでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。

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

操作が完了したら、[検証と移行] の結果を表示できます。

オンライン

前提条件 (オンライン)

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

ソース バージョンの確認

ソース PostgreSQL のバージョンは >= 9.5 である必要があります。 ソース PostgreSQL のバージョンが 9.5 より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5 以上にアップグレードします。

オンライン移行パラメータを設定する

オンライン移行の場合、ソース PostgreSQL サーバーのレプリケーション設定で、レプリケーションのサポートを [論理] に設定する必要があります。 さらに、サーバー パラメータ max_wal_senders と max_replication_slots は、移行する必要があるデータベースの数より大きい値になっている必要があります。 パラメーターは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

実行時間の長いトランザクションがないことを確認します。 実行時間の長いトランザクションがあると、レプリケーション スロットを作成できません。 実行時間の長いトランザクションがすべてコミットまたはロールバックされた場合、レプリケーション スロットの作成は成功します。 オンライン移行のすべての前提条件が整った後、ソース PostgreSQL サーバーを再起動する必要があります。

Note

Azure Database for PostgreSQL 単一サーバーでのオンライン移行の場合、Azure portal の単一サーバー ページのレプリケーション設定で、Azure レプリケーションのサポートを論理に設定します。

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

ターゲットを設定する

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

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

• 新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

• サーバー パラメータ max_replication_slots は、移行する必要があるデータベースの数より大きい値になっている必要があります。 それは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

重要

移行を開始する前に、フレキシブル サーバーのpassword_encryption サーバー パラメーターを SCRAM-SHA-256 から MD5 に変更します。 これは、単一サーバーの既存の資格情報をフレキシブル サーバーで機能させるために不可欠です。

ネットワークを設定する

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの 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 を再起動して新しい構成を適用します。

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

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

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

Note

オンライン移行には、こちらに記載されている特定の制限が適用されます。 データベースがオンライン移行の実行に準拠していることを確認してください。

Azure Database for PostgreSQL フレキシブル サーバーを構成する

• ターゲット フレキシブル サーバーを作成します。 ガイド付きの手順については、ポータルを使用した Azure Database for PostgreSQL フレキシブル サーバーの作成に関するクイックスタートをご覧ください。

• サーバーの起動時にライブラリを読み込む必要がある拡張機能を許可リストに載せます。 移行を始める前に、拡張機能を許可リストに載せておくことが不可欠です。

• データベースのテーブル間のデータの分散が偏っている (ほとんどのデータが 1 つ (または少数) のテーブルに存在する) かどうかを調べます。 偏っている場合、移行の速度が予想より遅くなることがあります。 その場合は、大きなテーブルを並列に移行すると、移行の速度を上げることができます。

移行タスクを構成する

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

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

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

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

   

4. [作成] ボタンを選んで、単一サーバーからフレキシブル サーバーへの移行を始めます。 初めて移行サービスを使う場合、空のグリッドと最初の移行の開始を促すプロンプトが表示されます。

   

   フレキシブル サーバー ターゲットへの移行を既に作成してある場合は、単一サーバーからこのターゲットに対して試みられた移行に関する情報がグリッドに含まれます。

5. ウィザードベースの一連のタブを使用して、考えられるさまざまなソースからこのフレキシブル サーバー ターゲットへの移行を作成します。 既定では、[ソース サーバーの種類] は [Azure Database for PostgreSQL 単一サーバー] に設定されています。このシナリオでは、これを取り上げます。

または、Azure Database for PostgreSQL 単一サーバーから移行プロセスを開始することもできます。

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

2. シングル サーバーを選択すると、概要タブで移行に関連するバナーを確認できます。[今すぐ移行する] を選択して開始します。

   

3. 2 つのオプションがあるページが表示されます。 フレキシブル サーバーを既に作成してあり、それをターゲットとして使う場合は、[既存から選択] を選んで、対応する [サブスクリプション]、[リソース グループ]、[サーバー名] の詳細を選択します。 選択が完了したら、[移行ウィザードに移動] を選択し、[セットアップ] セクションの手順に進みます。

   

4. 新しいフレキシブル サーバーを作成することを選んだ場合は、[新規作成] を選択し、[作成ウィザードに移動] を選択します。 このアクションにより、フレキシブル サーバーの作成プロセスが実行され、フレキシブル サーバーがデプロイされます。

   

フレキシブル サーバーをデプロイした後、「移行タスクを構成する」のステップ 3 から 5 を行います。

セットアップ

最初のタブは [セットアップ] です。 これを行っていなかった場合は、移行を開始する前に、「Azure Database for PostgreSQL フレキシブル サーバーを構成する」の説明に従って、必要な拡張機能を許可リストに載せてください。

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

[ソース サーバーの種類] はソースを示します。 この場合は、Azure Database for PostgreSQL 単一サーバーです

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

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

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

[移行モード] では、オンラインとオフラインのどちらかの移行を選択できます。ここでは、[オンライン] に設定する必要があります。

[オンライン] 移行モードを選ぶ場合は、移行元の単一サーバーで論理レプリケーションが有効になっている必要があります。 有効にされていない場合は、移行サービスによって移行元の単一サーバーで論理レプリケーションが自動的に有効にされます。 また、単一サーバーのリソース メニューの [設定] で [レプリケーション] 項目を選択し、[Azure レプリケーションのサポート] を [論理] に設定することで、手動でレプリケーションを設定することもできます。 どちらの方法でも、ソースの単一サーバーを再起動します。

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

ランタイム サーバー

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

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

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

ソースに接続する

[ソース] セクションでは、データベースのソースである単一サーバーに関連する詳細の指定を求められます。

[サブスクリプション] と [リソース グループ] を選ぶと、サーバー名のドロップダウン リストに、リージョン全体のそのリソース グループの下にシングル サーバーが表示されます。 データベースの移行元のソースを選びます。 単一サーバーから同じリージョン内のターゲットのフレキシブル サーバーに、データベースを移行できます。 リージョン間の移行は、インド、中国、UAE のサーバーについてのみ有効になります。

単一サーバー ソースを選ぶと、[場所] と [PostgreSQL バージョン] のボックスが自動的に設定されます。 データベースを正常に移行するために移行サービスで必要となるため、管理者ロールの資格情報を必ず指定してください。

すべてのフィールドに入力したら、[ソースに接続する] リンクを選びます。 これにより、入力されたソース サーバーの詳細が正しく、ソース サーバーに到達可能であることが検証されます。

[次: 移行ターゲットを選択] ボタンを選択して続行します。

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

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

[認証方法] とすべての認証関連フィールドの適切な値を選択します。 指定した ID はターゲット サーバーの管理者ユーザーのものであることが必要です。 必要なすべての情報を入力した後、[ターゲットに接続] リンクを選択します。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。

[次: 移行するデータベースの選択] ボタンを選択して、移行するデータベースを選択します。

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

このタブには、単一サーバー内のユーザー データベースの一覧が表示されます。 1 回の移行試行で最大 8 つのデータベースを選択して移行できます。 ユーザー データベースが 8 つを超える場合は、ソース サーバーとターゲット サーバーの間で、次のデータベース セットに対して移行プロセスが繰り返されます。 ターゲット サーバー上に存在する正確に同じ名前の選択したデータベースが上書きされます。

[次: サマリー] ボタンを選択して詳細を確認します。

まとめ

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

移行監視ポータル

移行を開始すると、検証または移行の作成が成功したことを示す通知が表示されます。 フレキシブル サーバーの [移行] ページに、自動的にリダイレクトされます。 ここには、最近作成された検証または移行に関する新しいエントリがあります。

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

[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。

グリッドで特定の移行の名前を選んで、関連する詳細を表示することもできます。

作成された検証または移行は、InProgress 状態と PerformingPreRequisiteSteps サブ状態になります。 ワークフローで移行インフラストラクチャとネットワーク接続が設定されるまで、2 から 3 分かかります。

移行の各オプションについて、移行を監視する方法を見てみましょう。

検証

PerformingPreRequisiteSteps サブ状態が完了すると、検証は Validation in Progress サブ状態になります。このサブ状態では、ソース サーバーとターゲット サーバーで移行の準備状況を評価するチェックが行われます。

すべての検証が Succeeded または Warning 状態の場合、検証は Succeeded 状態になります。

検証グリッドには次の情報があります

• [インスタンスの検証の詳細] と [データベースの検証の詳細] セクション: 移行の準備状況の確認に使われる検証ルールを表します。
• [検証名] - 特定の各検証規則の名前。
• [検証状態] - 各規則の結果を表し、3 つの値のいずれかになります。
  • [成功] - エラーが見つからなかった場合。
  • [失敗] - 検証エラーがある場合。
  • [警告] - 検証の警告がある場合。
• [実行時間] - 検証操作にかかった時間。
• [開始時刻 (UTC)] と [終了時刻 (UTC)] - 検証操作の UTC での開始時刻と終了時刻。

検証中にエラーが発生した場合、[検証状態] は [失敗] 状態になります。 失敗した [検証名] または [データベース名] の検証を選ぶと、ファンアウト ペインに、詳細と、このエラーを回避するために実行する必要がある是正措置が表示されます。

移行

PerformingPreRequisiteSteps というサブ状態が完了すると、移行は、データベースの複製/コピーが行われる [データを移行しています] のサブ状態に移ります。 移行が完了するまでの時間は、移行するデータベースのサイズと形状によって異なります。 データがすべてのテーブルにほぼ均等に分散されている場合、移行はすぐに完了します。 テーブル サイズにスキューがあると、相対的に長い時間がかかります。

移行中のいずれかのデータベースを選ぶと、ファンアウト ペインが表示されます。 すべてのテーブル数 (コピー済み、キュー済み、コピー中、エラー) と、データベースの移行状態が表示されます。

MigratingData 状態が正常に完了すると、移行は Succeeded 状態に移ります。 Migrating Data 状態で問題が発生した場合、移行は Failed 状態に移ります。

移行が Succeeded 状態になると、単一サーバーからフレキシブル サーバー ターゲットへのスキーマとデータの移行が完了します。 ページを更新して進行状況を確認できます。

検証と移行

このオプションでは、最初に検証が実行されてから移行が開始されます。 PerformingPreRequisiteSteps サブ状態が完了すると、ワークフローは Validation in Progress サブ状態になります。

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

操作が完了したら、[検証と移行] の結果を表示できます。

一括移行

[移行] および [検証と移行] の移行オプションの場合、オンライン移行を完了するには、一括移行アクションをトリガーする追加の手順をユーザーが完了する必要があります。 基本データのコピー/複製が完了すると、移行は WaitingForUserAction 状態かつ `WaitingForCutoverTrigger サブ状態に移行します。 この状態では、ユーザーはポータルで移行を選び、[一括移行] ボタンを選択して一括移行をトリガーできます。

一括移行を始める前に、次のことを確認する必要があります。

• ソースへの書き込みが停止している - Latency (minutes) パラメーターが 0 または 0 に近い。Latency (minutes) の情報は、移行の詳細画面から取得できます。

Latency (minutes) パラメーターは、ターゲットがソースと最後に同期されたタイミングを示します。 たとえば、上の Orders データベースの場合は 0.33333 です。 これは、Orders データベースの場合、ソースで過去約 0.3 分間に発生した変更が、まだターゲットまで送信されていないことを意味します。 この時点で、ソースへの書き込みを停止し、一括移行を開始することができます。 ソースに大量のトラフィックがある場合は、最初に書き込みを停止して、Latency (minutes) が 0 に近づくようにしてから、その後に一括移行を開始することをお勧めします。 一括移行操作は、ソースからターゲットに保留中のすべての変更を適用して、移行を完了します。 待機時間がゼロではない状態で一括移行をトリガーした場合、レプリケーションはその時点までで停止します。 その場合、一括移行の時点までのソース上のすべてのデータが、ターゲットに適用されます。 たとえば、一括移行の時点で待機時間が 15 分の場合、過去 15 分間に変更されたすべてのデータがターゲットに適用されます。 所要時間は、その過去 15 分間に発生した変更のバックログによって異なります。 そのため、一括移行をトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。

[データを移行しています] サブ状態または一括移行 (オンライン移行モードの場合) が正常に完了するとすぐに、移行は [成功しました] 状態になります。 [データを移行しています] サブ状態で問題が発生した場合、移行は [失敗しました] 状態に移ります。

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

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

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

• PerformingPreRequisiteSteps: データ移行のためのインフラストラクチャのセットアップが進行中です。
• Validation in Progress: 検証は進行中です。
• MigratingData: データ移行が進行中です。
• CompletingMigration: 移行が完了の最終段階にあります。
• Completed: 移行が正常に完了しました。

ポータルを使って移行を取り消す

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

検証を取り消すと、検証アクティビティはそれ以上行われなくなり、検証は Canceled 状態になります。

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

CLI

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

オフライン

前提条件 (オフライン)

Azure Database for PostgreSQL の移行サービスを使用して移行を開始する前に、オフライン移行シナリオに適用される次の前提条件を満たす必要があります。

ソース バージョンの確認

ソース PostgreSQL のバージョンは >= 9.5 である必要があります。 ソース PostgreSQL のバージョンが 9.5 より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5 以上にアップグレードします。

ターゲット設定

• 移行プロセスを開始する前に、Azure Database for PostgreSQL フレキシブル サーバーを Azure にデプロイし、適切に構成する必要があります。

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

• 新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

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

ネットワークのセットアップ

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの 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 フレキシブル サーバーを再起動して新しい構成を適用します。

重要

移行を開始する前に、フレキシブル サーバーのpassword_encryption サーバー パラメーターを SCRAM-SHA-256 から MD5 に変更します。 これは、単一サーバーの既存の資格情報をフレキシブル サーバーで機能させるために不可欠です。

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

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

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

作業の開始

1. Microsoft Azure を初めて使う場合は、オファリングを評価するためのアカウントを作成します。

2. Azure CLI のインストール ページから、お使いのオペレーティング システム用の最新の Azure CLI をインストールします。

   Azure CLI が既にインストールされている場合は、az version コマンドを使用してバージョンを確認します。 移行 CLI コマンドを使用するには、バージョンが 2.50.0 以降である必要があります。 そうでない場合は、Azure CLI のバージョンを更新します。

3. az login コマンドを実行します。

   az login
   

   ブラウザー ウィンドウが開き、Azure サインイン ページが表示されます。 認証を成功させるために Azure 資格情報を入力します。 Azure CLI でサインインするその他の方法については、こちらの記事をご覧ください。

移行の CLI コマンド (オフライン)

移行サービスには、移行関連のタスクを実行するための使いやすい CLI コマンドが付属しています。 すべての CLI コマンドは、az postgres flexible-server migration から始まります。 移行を始める前に、拡張機能を許可リストに載せることが重要です。

--help パラメーターを使用すると、コマンドに関連付けられているオプションを理解し、適切な構文をフレーミングするのに役立ちます。

az postgres flexible-server migration --help

前のコマンドを実行すると、次の出力が返されます。

出力には、サポートされている移行コマンドとそのアクションが一覧表示されます。 これらのコマンドを詳しく見てみましょう。

Azure CLI を使用して移行を作成する

create コマンドは、ソース サーバーからターゲット サーバーへの移行の作成に役立ちます。

az postgres flexible-server migration create --help

前のコマンドを実行すると、次の出力が返されます。

必要な引数が一覧表示され、ソース サーバーからターゲット サーバーへの移行を適切に作成するための構文例が示されます。 新しい移行を作成する CLI コマンドを次に示します。

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

パラメーター	説明
subscription	フレキシブル サーバー ターゲットのサブスクリプション ID。
resource-group	フレキシブル サーバー ターゲットのリソース グループ。
name	フレキシブル サーバー ターゲットの名前。
migration-name	このフレキシブル サーバー ターゲットへの移行ごとの一意識別子。 このフィールドで使用できる文字は英数字のみで、アンダースコア (_) とハイフン (-) 以外の特殊文字は使用できません。 名前は先頭と末尾が英数字である必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行の名前を同じにすることはできないため、名前はターゲット サーバーに対して一意である必要もあります。
migration-mode	これは省略可能なパラメーターです。 既定値: オフライン。 オフライン移行では、ソース データベースを特定の時点でターゲット サーバーにコピーします。
properties	シングル サーバー ソースに関する情報を持つ JSON ファイルへの絶対パス。

次に例を示します。

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode offline

create コマンドで使われる migration-name 引数は、update、delete、show. などの他の CLI コマンドで使われます。これは、それらすべてのコマンドでの対応するアクションで、移行の試行を一意に識別します。

最後に、properties 引数の一部として渡す JSON ファイルが create コマンドに必要です。

JSON の構造体は次のとおりです。

{
	"properties": {
		"sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
		"secretParameters": {
			"adminCredentials": {
				"sourceServerPassword": "<password>",
				"targetServerPassword": "<password>"
			},
			"sourceServerUserName": "<username>@<servername>",
			"targetServerUserName": "<username>"
		},
		"dbsToMigrate": [
			"<db1>",
			"<db2>"
		],
		"overwriteDbsInTarget": "true"
	}
}

JSON ファイル形式に含められる create パラメーターを次に示します。

パラメーター	型	内容
sourceDbServerResourceId	必須	このパラメーターは単一サーバー ソースのリソース ID です。
adminCredentials	必須	このパラメーターは、シングル サーバー ソースとフレキシブル サーバー ターゲットの両方の管理者ユーザーのパスワードを一覧表示します。 これらのパスワードは、ソース サーバーとターゲットの両方のサーバーに対する認証に役立ちます。
sourceServerUserName	必須	既定値は単一サーバーの作成時に指定された管理者ユーザーであり、指定されたパスワードは、このユーザーの認証に使われます。 既定のユーザーを使っていない場合、このパラメーターは移行を実行するためのソース サーバー上でのユーザーまたはロールです。 このユーザーは、移行に関連するデータベース オブジェクトで必要な特権と所有権を持ち、azure_pg_admin ロールのメンバーである必要があります。
targetServerUserName	必須	既定値は、フレキシブル サーバーの作成時に作成された管理者ユーザーであり、指定されたパスワードは、このユーザーの認証に使われます。 既定のユーザーを使用していない場合、このパラメーターはこの移行の実行に使用されるターゲット サーバー上のユーザーまたはロールです。 このユーザーは、azure_pg_admin、pg_read_all_settings、pg_read_all_stats、pg_stat_scan_tables ロールのメンバーであり、Create ロールである Create DB 属性を持っている必要があります。
dbsToMigrate	必須	フレキシブル サーバーに移行するデータベースのリストを指定します。 移行されるのはユーザー データベースだけです。 システム データベース、または template0 や template1 などのテンプレート データベースは移行されません。
overwriteDbsInTarget	必須	true に設定すると、移行しようとしているものと同じ名前の既存のデータベースがターゲット サーバーにある場合、移行サービスはそのデータベースを自動的に上書きします。
setupLogicalReplicationOnSourceDBIfNeeded	省略可能	このプロパティを true に設定して、ソース サーバーで論理レプリケーションを自動的に有効にできます。 サーバー設定のこの変更には、サーバーを再起動する必要があり、2 から 3 分のダウンタイムが発生します。
sourceDBServerFullyQualifiedDomainName	省略可能	仮想ネットワークの名前解決にカスタム DNS サーバーを使用する場合に使用します。 このプロパティのカスタム DNS サーバーに従って、シングル サーバー ソースの FQDN を指定します。
targetDBServerFullyQualifiedDomainName	オプション	仮想ネットワーク内の名前解決にカスタム DNS サーバーを使用する場合に使用します。 カスタム DNS サーバーに従ってフレキシブル サーバー ターゲットの FQDN を指定します。 sourceDBServerFullyQualifiedDomainName と targetDBServerFullyQualifiedDomainName を JSON の一部として含めるのは、名前解決のために Azure 提供の DNS ではなくカスタム DNS サーバーを使用するまれなシナリオに限られます。 それ以外の場合は、これらのパラメーターを JSON ファイルに含めないでください。

コマンド応答に関しては、次の重要な点に注意してください。

• create コマンドがトリガーされると、移行は InProgress 状態と PerformingPreRequisiteSteps サブ状態に移ります。 移行ワークフローで、移行インフラストラクチャをデプロイし、ソースとターゲットの間の接続を設定するには、数分かかります。
• PerformingPreRequisiteSteps サブ状態が完了すると、移行は Migrating Data, サブ状態に遷移し、データベースの複製やコピーが行われます。
• 移行される各データベースには、テーブル数、増分挿入、削除、保留中のバイトなど、すべての移行の詳細を含む独自のセクションがあります。
• Migrating Data サブ状態が完了するまでにかかる時間は、移行するデータベースのサイズによって異なります。
• 移行は、Migrating Data サブ状態が正常に完了するとすぐ、Succeeded 状態に遷移します。 Migrating Data サブ状態で問題が発生した場合、移行は Failed 状態に移行します。

移行の一覧を表示する

list コマンドは、フレキシブル サーバー ターゲットへのすべての移行の試行を一覧表示します。

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

filter パラメーターには、次の 2 つのオプションがあります。

• Active: ターゲット サーバーへの現在のアクティブな (進行中である) 移行の試行を一覧表示します。 失敗、キャンセル、または成功した移行は含まれません。
• All: ターゲット サーバーへのすべての移行の試行を一覧表示します。 これには、状態に関係なく、アクティブな移行と完了した移行の両方が含まれます。

このコマンドの詳細を確認するには、--help パラメーターを使用します。

az postgres flexible-server migration list --help

移行を監視する

--show コマンドは、進行中の移行を監視するのに役立ち、移行の現在の状態とサブ状態を示します。

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

migration_name パラメーターは、create コマンド中に移行に割り当てられた名前です。 詳細を示す CLI コマンドからのサンプル応答のスナップショットを次に示します。

このコマンドの詳細を確認するには、--help パラメーターを使用します。

 az postgres flexible-server migration show --help

次の表で、移行の状態とサブ状態について説明します。

移行の状態	説明
InProgress	移行インフラストラクチャが設定されているか、実際のデータ移行が進行中です。
Canceled	移行が取り消されたか削除されました。
Failed	移行は失敗しました。
Succeeded	移行が成功し、完了しました。
ValidationFailed	移行は移行前の検証中に失敗しました。

移行サブ状態	説明
PerformingPreRequisiteSteps	インフラストラクチャが設定され、データ移行の準備ができています。
MigratingData	データ移行が進行中です。
CompletingMigration	移行を完了しています。
Completed	成功した状態かどうかは別として、移行は完了しています。
CancelingRequestedDBMigrations	移行を取り消しています。
ValidationInProgress	検証を実行中です。

オンライン

前提条件 (オンライン)

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

ソース バージョンの確認

ソース PostgreSQL のバージョンは >= 9.5 である必要があります。 ソース PostgreSQL のバージョンが 9.5 より小さい場合は、移行前にソース PostgreSQL のバージョンを 9.5 以上にアップグレードします。

オンライン移行パラメータを設定する

オンライン移行の場合、ソース PostgreSQL サーバーのレプリケーション設定で、レプリケーションのサポートを [論理] に設定する必要があります。 さらに、サーバー パラメータ max_wal_senders と max_replication_slots は、移行する必要があるデータベースの数より大きい値になっている必要があります。 パラメーターは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

実行時間の長いトランザクションがないことを確認します。 実行時間の長いトランザクションがあると、レプリケーション スロットを作成できません。 実行時間の長いトランザクションがすべてコミットまたはロールバックされた場合、レプリケーション スロットの作成は成功します。 オンライン移行のすべての前提条件が整った後、ソース PostgreSQL サーバーを再起動する必要があります。

Note

Azure Database for PostgreSQL 単一サーバーでのオンライン移行の場合、Azure portal の単一サーバー ページのレプリケーション設定で、Azure レプリケーションのサポートを論理に設定します。

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

ターゲットを設定する

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

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

• 新しい Azure Database for PostgreSQL を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

• サーバー パラメータ max_replication_slots は、移行する必要があるデータベースの数より大きい値になっている必要があります。 それは、Azure portal の [設定] > [サーバー パラメーター] で設定するか、次のコマンドを使ってコマンド ラインで構成できます。

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

重要

移行を開始する前に、フレキシブル サーバーのpassword_encryption サーバー パラメーターを SCRAM-SHA-256 から MD5 に変更します。 これは、単一サーバーの既存の資格情報をフレキシブル サーバーで機能させるために不可欠です。

ネットワークを設定する

ネットワーク セットアップは、移行サービスが正しく機能するために重要です。 ソースの 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 を再起動して新しい構成を適用します。

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

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

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

Note

オンライン移行には、こちらに記載されている特定の制限が適用されます。 データベースがオンライン移行の実行に準拠していることを確認してください。

作業の開始

1. Microsoft Azure を初めて使う場合は、オファリングを評価するためのアカウントを作成します。

2. Azure CLI のインストール ページから、お使いのオペレーティング システム用の最新の Azure CLI をインストールします。

   Azure CLI が既にインストールされている場合は、az version コマンドを使用してバージョンを確認します。 移行 CLI コマンドを使用するには、バージョンが 2.50.0 以降である必要があります。 そうでない場合は、Azure CLI のバージョンを更新します。

3. az login コマンドを実行します。

   az login
   

   ブラウザー ウィンドウが開き、Azure サインイン ページが表示されます。 認証を成功させるために Azure 資格情報を入力します。 Azure CLI でサインインするその他の方法については、こちらの記事をご覧ください。

移行の CLI コマンド (オンライン)

移行サービスには、移行関連のタスクを実行するための使いやすい CLI コマンドが付属しています。 すべての CLI コマンドは、az postgres flexible-server migration から始まります。 移行を始める前に、拡張機能を許可リストに載せることが重要です。

--help パラメーターを使用すると、コマンドに関連付けられているオプションを理解し、適切な構文をフレーミングするのに役立ちます。

az postgres flexible-server migration --help

前のコマンドを実行すると、次の出力が返されます。

出力には、サポートされている移行コマンドとそのアクションが一覧表示されます。 これらのコマンドを詳しく見てみましょう。

Azure CLI を使用して移行を作成する

create コマンドは、ソース サーバーからターゲット サーバーへの移行の作成に役立ちます。

az postgres flexible-server migration create --help

前のコマンドを実行すると、次の出力が返されます。

必要な引数が一覧表示され、ソース サーバーからターゲット サーバーへの移行を適切に作成するための構文例が示されます。 新しい移行を作成する CLI コマンドを次に示します。

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

パラメーター	説明
subscription	フレキシブル サーバー ターゲットのサブスクリプション ID。
resource-group	フレキシブル サーバー ターゲットのリソース グループ。
name	フレキシブル サーバー ターゲットの名前。
migration-name	このフレキシブル サーバー ターゲットへの移行ごとの一意識別子。 このフィールドで使用できる文字は英数字のみで、アンダースコア (_) とハイフン (-) 以外の特殊文字は使用できません。 名前は先頭と末尾が英数字である必要があります。 同じフレキシブル サーバー ターゲットへの 2 つの移行の名前を同じにすることはできないため、名前はターゲット サーバーに対して一意である必要もあります。
migration-mode	これは省略可能なパラメーターです。 既定値は Offline。 オンライン移行の場合は、Online を渡す必要があります。
properties	シングル サーバー ソースに関する情報を持つ JSON ファイルへの絶対パス。

次に例を示します。

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

create コマンドで使われる migration-name 引数は、update、delete、show. などの他の CLI コマンドで使われます。これは、それらすべてのコマンドでの対応するアクションで、移行の試行を一意に識別します。

最後に、properties 引数の一部として渡す JSON ファイルが create コマンドに必要です。

JSON の構造体は次のとおりです。

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "secretParameters": {
      "adminCredentials": {
        "sourceServerPassword": "<password>",
        "targetServerPassword": "<password>"
      }
    },
    "sourceServerUserName": "<username>@<servername>",
    "targetServerUserName": "<username>",
    "dbsToMigrate": ["<db1>", "<db2>"],
    "overwriteDbsInTarget": "true"
  }
}

JSON ファイル形式に含められる create パラメーターを次に示します。

パラメーター	型	内容
sourceDbServerResourceId	必須	このパラメーターは単一サーバー ソースのリソース ID です。
adminCredentials	必須	このパラメーターは、シングル サーバー ソースとフレキシブル サーバー ターゲットの両方の管理者ユーザーのパスワードを一覧表示します。 これらのパスワードは、ソース サーバーとターゲットの両方のサーバーに対する認証に役立ちます。
sourceServerUserName	必須	既定値は単一サーバーの作成時に指定された管理者ユーザーであり、指定されたパスワードは、このユーザーの認証に使われます。 既定のユーザーを使っていない場合、このパラメーターは移行を実行するためのソース サーバー上でのユーザーまたはロールです。 このユーザーは、移行に関連するデータベース オブジェクトで必要な特権と所有権を持ち、azure_pg_admin ロールのメンバーである必要があります。
targetServerUserName	必須	既定値は、フレキシブル サーバーの作成時に作成された管理者ユーザーであり、指定されたパスワードは、このユーザーの認証に使われます。 既定のユーザーを使用していない場合、このパラメーターはこの移行の実行に使用されるターゲット サーバー上のユーザーまたはロールです。 このユーザーは、azure_pg_admin、pg_read_all_settings、pg_read_all_stats、pg_stat_scan_tables ロールのメンバーであり、Create ロールである Create DB 属性を持っている必要があります。
dbsToMigrate	必須	フレキシブル サーバーに移行するデータベースのリストを指定します。 移行されるのはユーザー データベースだけです。 システム データベース、または template0 や template1 などのテンプレート データベースは移行されません。
overwriteDbsInTarget	必須	true に設定すると、移行しようとしているものと同じ名前の既存のデータベースがターゲット サーバーにある場合、移行サービスはそのデータベースを自動的に上書きします。
setupLogicalReplicationOnSourceDBIfNeeded	省略可能	このプロパティを true に設定して、ソース サーバーで論理レプリケーションを自動的に有効にできます。 サーバー設定のこの変更には、サーバーを再起動する必要があり、2 から 3 分のダウンタイムが発生します。
sourceDBServerFullyQualifiedDomainName	省略可能	仮想ネットワークの名前解決にカスタム DNS サーバーを使用する場合に使用します。 このプロパティのカスタム DNS サーバーに従って、シングル サーバー ソースの FQDN を指定します。
targetDBServerFullyQualifiedDomainName	オプション	仮想ネットワーク内の名前解決にカスタム DNS サーバーを使用する場合に使用します。 カスタム DNS サーバーに従ってフレキシブル サーバー ターゲットの FQDN を指定します。 sourceDBServerFullyQualifiedDomainName と targetDBServerFullyQualifiedDomainName を JSON の一部として含めるのは、名前解決のために Azure 提供の DNS ではなくカスタム DNS サーバーを使用するまれなシナリオに限られます。 それ以外の場合は、これらのパラメーターを JSON ファイルに含めないでください。

コマンド応答に関しては、次の重要な点に注意してください。

• create コマンドがトリガーされると、移行は InProgress 状態と PerformingPreRequisiteSteps サブ状態に移ります。 移行ワークフローで、移行インフラストラクチャをデプロイし、ソースとターゲットの間の接続を設定するには、数分かかります。
• PerformingPreRequisiteSteps サブ状態が完了すると、移行は Migrating Data, サブ状態に遷移し、データベースの複製やコピーが行われます。
• 移行される各データベースには、テーブル数、増分挿入、削除、保留中のバイトなど、すべての移行の詳細を含む独自のセクションがあります。
• Migrating Data サブ状態が完了するまでにかかる時間は、移行するデータベースのサイズによって異なります。
• 移行は、Migrating Data サブ状態が正常に完了するとすぐ、Succeeded 状態に遷移します。 Migrating Data サブ状態で問題が発生した場合、移行は Failed 状態に移行します。

レプリケーションの設定

オンライン移行モードの場合は、移行元の単一サーバーで論理レプリケーションが有効になっている必要があります。 それが有効になっていない場合は、付属の JSON ファイルで値が true に設定された setupLogicalReplicationOnSourceDBIfNeeded パラメーターが渡されると、移行サービスはソースの単一サーバーで論理レプリケーションを自動的にオンにします。 ソースでのレプリケーションは、移行を開始した後で、次のコマンドを使って手動で設定することもできます。 どちらの方法で論理レプリケーションを有効にしても、ソースの単一サーバーが再起動されます。

次に例を示します。

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

フレキシブル サーバーが WaitingForLogicalReplicationSetupRequestOnSourceDB 状態で待機している場合は、その移行を進めるためにこのコマンドが必要です。

オンライン移行を実行するには、以下を使用します。

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

移行の一覧を表示する

list コマンドは、フレキシブル サーバー ターゲットへのすべての移行の試行を一覧表示します。

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

filter パラメーターには、次の 2 つのオプションがあります。

• Active: ターゲット サーバーへの現在のアクティブな (進行中である) 移行の試行を一覧表示します。 失敗、キャンセル、または成功した移行は含まれません。
• All: ターゲット サーバーへのすべての移行の試行を一覧表示します。 これには、状態に関係なく、アクティブな移行と完了した移行の両方が含まれます。

このコマンドの詳細を確認するには、--help パラメーターを使用します。

az postgres flexible-server migration list --help

移行を監視する

show コマンドは、進行中の移行を監視するのに役立ち、移行の現在の状態とサブ状態を示します。

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

migration_name パラメーターは、create コマンド中に移行に割り当てられた名前です。 移行を監視する CLI コマンドからの応答のサンプルのスナップショットを次に示します。

このコマンドの詳細を確認するには、--help パラメーターを使用します。

 az postgres flexible-server migration show --help

次の表で、移行の状態とサブ状態について説明します。

移行の状態	説明
InProgress	移行インフラストラクチャが設定されているか、実際のデータ移行が進行中です。
Canceled	移行が取り消されたか削除されました。
Failed	移行は失敗しました。
Succeeded	移行が成功し、完了しました。
ValidationFailed	移行は移行前の検証中に失敗しました。

移行サブ状態	説明
PerformingPreRequisiteSteps	インフラストラクチャが設定され、データ移行の準備ができています。
MigratingData	データ移行が進行中です。
WaitingForCutoverTrigger	データ移行タスクが完了し、ユーザーによる一括移行のトリガーを待機しています。
CompletingMigration	移行を完了しています。
Completed	成功した状態かどうかは別として、移行は完了しています。
CancelingRequestedDBMigrations	移行を取り消しています。
ValidationInProgress	検証を実行中です。

一括移行

オンライン移行では、基本データの移行が完了すると、その移行タスクは WaitingForCutoverTrigger サブ状態に移ります。 この状態では、ユーザーは以下のコマンドを使用して、CLI を通じて一括移行をトリガーすることができます。 ポータルから移行グリッド内の移行名を選択することで、一括移行をトリガーすることもできます。

次に例を示します。

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

一括移行を始める前に、次のことを確認する必要があります。

• ソースへの書き込みが停止している - latency パラメーターが 0 または 0 に近い

latency パラメーターは、ターゲットがソースと最後に同期されたタイミングを示します。 たとえば、以下の画像に示すように、これら 2 つのデータベースの場合は 201 と 202 です。 これは、ソースで過去約 200 秒間に発生した変更が、まだターゲットに同期されていないことを意味します。 この時点で、ソースへの書き込みを停止し、一括移行を開始することができます。 ソースで大量のトラフィックが発生する場合は、まず書き込みを停止して、Latency が 0 に近づいてから一括移行を開始することをお勧めします。 一括移行操作は、ソースからターゲットに保留中のすべての変更を適用して、移行を完了します。 Latency がゼロではなくても "一括移行" をトリガーした場合、レプリケーションはその時点までで停止します。 その場合、一括移行の時点までのソース上のすべてのデータが、ターゲットに適用されます。 たとえば、一括移行の時点で待ち時間が 15 分の場合、過去 15 分間のすべての変更データがターゲットに適用されます。 所要時間は、その過去 15 分間に発生した変更のバックログによって異なります。 そのため、一括移行をトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。 latency の情報は、migration show コマンドを使用して取得することができます。

一括移行を開始する前の、移行のスナップショットを次に示します。

一括移行が開始された後、基本コピーの間に発生したすべてのトランザクションが順番にターゲットにコピーされて、移行が完了されます。

一括移行が成功しなかった場合、その移行は Failed 状態になります。

このコマンドの詳細を確認するには、--help パラメーターを使用します。

 az postgres flexible-server migration update --help

CLI を使って移行を取り消す

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

az postgres flexible-server migration update cancel [--subscription]
                                                    [--resource-group]
                                                    [--name]
                                                    [--migration-name]

次に例を示します。

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

このコマンドの詳細を確認するには、--help パラメーターを使用します。

 az postgres flexible-server migration update cancel --help

このコマンドを実行すると、次の出力が得られます。

完了時に移行を確認する

移行が成功したら、単一サーバーと同じ資格情報を使用してフレキシブル サーバーにログインできることを確認します。 単一サーバーから移行した後にフレキシブル サーバーで認証エラーが発生した場合は、原因として、フレキシブル サーバーの VM が FIPS 準拠になっていること、または単一サーバーの MD5 暗号化とは異なるパスワード暗号化アルゴリズム (SCRAM-SHA-256) を使用していることが考えられます。 この問題を軽減するには、次の手順に従います。

1. フレキシブル サーバーの password_encryption サーバー パラメーターを SCRAM-SHA-256 から MD5 に変更します。
2. 単一サーバーからフレキシブル サーバーへの移行を再開します。
3. 認証の問題が解決しない場合は、既存のフレキシブル サーバーを削除し、新しいサーバーをプロビジョニングしますい。 手順 1 と 2 を繰り返して問題を解決します。

これにより、認証エラーが解決されるはずです。

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

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

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

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

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

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

• 接続文字列がフレキシブル サーバーをポイントするように、アプリケーションに変更を加えます。

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

関連するコンテンツ

• 移行サービス
• AWS RDS からの移行
• ベスト プラクティス
• 既知の問題と制限事項
• ネットワーク設定
• 移行前の検証