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

前提条件 (オフライン)

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

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

拡張機能を有効にする

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

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

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

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

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

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

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

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

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

• これらのガイドラインに従うと、高可用性と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、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 バージョン] のボックスが自動的に設定されます。 管理者ロールの資格情報を指定してください。移行サービスでデータベースを正常に移行するためにそれが必要です。

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

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

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

[移行ターゲットの選択] セクションには、[サブスクリプション]、[リソース グループ]、[サーバー名]、[場所]、[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 のサブストレートに移ります。

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

前提条件 (オンライン)

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 サーバーを再起動する必要があります。

ターゲットを設定する

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

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

拡張機能を有効にする

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

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

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

サーバー パラメーター

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

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

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

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

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

• これらのガイドラインに従うと、HA と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、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 レプリケーションのサポート] を [論理] に設定することで、手動でレプリケーションを設定することもできます。 どちらの方法でも、ソースの単一サーバーを再起動します。

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

ランタイム サーバー

移行ランタイム サーバーは、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: 移行が正常に完了しました。

前提条件 (オフライン)

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

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

拡張機能を有効にする

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

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

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

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

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

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

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

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

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

• これらのガイドラインに従うと、高可用性と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、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]

次に例を示します。

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 パラメーターを次に示します。

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

• 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

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

前提条件 (オンライン)

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 サーバーを再起動する必要があります。

ターゲットを設定する

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

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

拡張機能を有効にする

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

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

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

サーバー パラメーター

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

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

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

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

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

• これらのガイドラインに従うと、HA と読み取りレプリカによって導入された変数を追加することなく、スムーズな移行プロセスを実現できます。 移行が完了し、データベースが安定したら、これらの機能を有効にして、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]

次に例を示します。

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 パラメーターを次に示します。

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

• 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

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

一括移行

オンライン移行では、基本データの移行が完了すると、その移行タスクは 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