チュートリアル: 移行サービスを使用して Azure Database for PostgreSQL - 単一サーバー から 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 を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

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

移行中にソースとターゲットの間の接続を正常に行うためには、適切なネットワーク設定が不可欠です。 さまざまなシナリオでネットワーク接続を確立するのに役立つガイドを次に示します:

移行のネットワーク要件:

• ExpressRoute/IPsec VPN/VPN トンネリング: オンプレミス/AWS ソースを Azure に接続する場合、セキュリティで保護されたデータ転送を容易にするために、ExpressRoute、IPsec VPN、または VPN トンネリングを設定することが必要になる場合があります。

• VNET ピアリング: 2 つの異なる VNet 間に仮想ネットワーク ピアリングを確立して、直接ネットワーク接続を有効にします。これは、Azure VM と Azure Database for PostgreSQL の間の移行の前提条件です。

接続のシナリオ:

次の表は、ソースとターゲット間のネットワークの設定に役立ちます。

source	移行先	接続に関するヒント
公開	公開	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
Private	Public	この構成はサポートされていません。データ転送には pg_dump/pg_restore を使用します。
パブリック	プライベート	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
プライベート	プライベート	ソースとターゲットの間に ExpressRoute、IPsec VPN、VPN トンネリング、または仮想ネットワーク ピアリングを確立します。
プライベート	プライベート エンドポイント	この構成はサポートされていません。Microsoft サポートにお問い合わせください。

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

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

Note

pg_hba.conf ファイルは、PostgreSQL インストールのデータ ディレクトリにあります。 ソース データベースがオンプレミスの PostgreSQL サーバーまたは Azure VM でホストされている PostgreSQL サーバーである場合は、このファイルを確認して構成する必要があります。 AWS RDS または同様のマネージド サービス上の PostgreSQL インスタンスの場合、pg_hba.conf ファイルに直接アクセスしたり、適用したりすることはできません。 代わりに、サービスの提供されるセキュリティとネットワーク アクセスの構成によってアクセスが制御されます。

ネットワークセットアップの詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーの移行サービスのネットワーク ガイド」にアクセスしてください。

Extensions

拡張機能は、その機能を強化するために PostgreSQL に追加できる追加の機能です。 拡張機能は Azure Database for PostgreSQL でサポートされていますが、手動で有効にする必要があります。 拡張機能を有効にするには、次の手順に従います:

• ソースの select コマンドを使用して、使用されているすべての拡張機能を一覧表示します - select extname,extversion from pg_extension;

• Azure Database for PostgreSQL の [サーバー パラメーター] ページで azure.extensions サーバー パラメーターを検索します。 PostgreSQL 内のソースにある拡張機能を有効にします。

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

  

• リストに次のいずれかの拡張機能が含まれているかどうかを確認します。

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

"はい" の場合は、サーバー パラメーター ページで shared_preload_libraries パラメーターを検索します。 このパラメーターは、サーバーの再起動時に事前に読み込まれる拡張ライブラリのセットを示します。

サーバー パラメーター

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

• 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 単一サーバーから移行プロセスを開始することもできます。

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

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

   

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

   

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

   

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

セットアップ タブ

最初のタブは [セットアップ] です。 行わなかった場合は、「移行を始める前に、拡張機能を許可リストに載せておくことが不可欠です」で示されているように、必要な拡張機能を許可リストに載せます。

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

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

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

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

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

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

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

[ソース] タブ

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

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

シングル サーバー ソースを選ぶと、[場所]、[PostgreSQL バージョン]、[サーバー管理者ログイン名] の各ボックスが自動的に設定されます。 サーバー管理者のサインイン名は、単一サーバーの作成に使われた管理者ユーザー名です。 [パスワード] ボックスに、管理者ユーザーのパスワードを入力します。 移行サービスは、管理者ユーザーとして単一サーバー データベースを移行します。

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

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

[ターゲット] タブ

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

タブの [サーバー管理者ログイン名] には、フレキシブル サーバー ターゲットの作成時に使われた管理者ユーザー名が表示されます。 管理者ユーザーに対応するパスワードを入力します。 パスワードを入力した後、[ターゲットに接続する] リンクを選びます。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。

[次へ] ボタンを選んで、移行するデータベースを選びます。

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

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

[次へ] ボタンを選んで、詳細を確認します。

まとめ

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

移行監視ポータル

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

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

[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。 グリッドで移行の名前を選んで、関連する詳細を見ることもできます。

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

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

検証

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

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

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

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

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

移行

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

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

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 以上にアップグレードします。

ターゲット設定

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

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

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

オンライン移行パラメータの設定

オンライン移行の場合、ソース PostgreSQL サーバーのレプリケーション設定で、レプリケーションのサポートを [論理] に設定する必要があります。 さらに、サーバー パラメータ max_wal_senders および max_replication_slots の値は、移行する必要があるデータベースの数と同じである必要があります。 これらは、次のコマンドを使用してコマンド ラインで構成することもできます。

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

オンライン移行のすべての前提条件が整った後、ソース PostgreSQL サーバーを再起動する必要があります。

Note

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

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

移行中にソースとターゲットの間の接続を正常に行うためには、適切なネットワーク設定が不可欠です。 さまざまなシナリオでネットワーク接続を確立するのに役立つガイドを次に示します:

移行のネットワーク要件:

• ExpressRoute/IPsec VPN/VPN トンネリング: オンプレミス/AWS ソースを Azure に接続する場合、セキュリティで保護されたデータ転送を容易にするために、ExpressRoute、IPsec VPN、または VPN トンネリングを設定することが必要になる場合があります。

• VNET ピアリング: 2 つの異なる VNet 間に仮想ネットワーク ピアリングを確立して、直接ネットワーク接続を有効にします。これは、Azure VM と Azure Database for PostgreSQL の間の移行の前提条件です。

接続のシナリオ:

次の表は、ソースとターゲット間のネットワークの設定に役立ちます。

source	移行先	接続に関するヒント
公開	公開	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
Private	Public	この構成はサポートされていません。データ転送には pg_dump/pg_restore を使用します。
パブリック	プライベート	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
プライベート	プライベート	ソースとターゲットの間に ExpressRoute、IPsec VPN、VPN トンネリング、または仮想ネットワーク ピアリングを確立します。
プライベート	プライベート エンドポイント	この構成はサポートされていません。Microsoft サポートにお問い合わせください。

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

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

Note

pg_hba.conf ファイルは、PostgreSQL インストールのデータ ディレクトリにあります。 ソース データベースがオンプレミスの PostgreSQL サーバーまたは Azure VM でホストされている PostgreSQL サーバーである場合は、このファイルを確認して構成する必要があります。 AWS RDS または同様のマネージド サービス上の PostgreSQL インスタンスの場合、pg_hba.conf ファイルに直接アクセスしたり、適用したりすることはできません。 代わりに、サービスの提供されるセキュリティとネットワーク アクセスの構成によってアクセスが制御されます。

ネットワークセットアップの詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーの移行サービスのネットワーク ガイド」にアクセスしてください。

Extensions

拡張機能は、その機能を強化するために PostgreSQL に追加できる追加の機能です。 拡張機能は Azure Database for PostgreSQL でサポートされていますが、手動で有効にする必要があります。 拡張機能を有効にするには、次の手順に従います:

• ソースの select コマンドを使用して、使用されているすべての拡張機能を一覧表示します - select extname,extversion from pg_extension;

• Azure Database for PostgreSQL の [サーバー パラメーター] ページで azure.extensions サーバー パラメーターを検索します。 PostgreSQL 内のソースにある拡張機能を有効にします。

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

  

• リストに次のいずれかの拡張機能が含まれているかどうかを確認します。

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

"はい" の場合は、サーバー パラメーター ページで shared_preload_libraries パラメーターを検索します。 このパラメーターは、サーバーの再起動時に事前に読み込まれる拡張ライブラリのセットを示します。

サーバー パラメーター

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

• 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 単一サーバーから移行プロセスを開始することもできます。

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

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

   

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

   

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

   

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

セットアップ タブ

最初のタブは [セットアップ] です。 行わなかった場合は、「移行を始める前に、拡張機能を許可リストに載せておくことが不可欠です」で示されているように、必要な拡張機能を許可リストに載せます。

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

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

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

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

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

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

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

[ソース] タブ

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

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

シングル サーバー ソースを選ぶと、[場所]、[PostgreSQL バージョン]、[サーバー管理者ログイン名] の各ボックスが自動的に設定されます。 サーバー管理者のサインイン名は、単一サーバーの作成に使われた管理者ユーザー名です。 [パスワード] ボックスに、管理者ユーザーのパスワードを入力します。 移行サービスは、管理者ユーザーとして単一サーバー データベースを移行します。

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

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

[ターゲット] タブ

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

タブの [サーバー管理者ログイン名] には、フレキシブル サーバー ターゲットの作成時に使われた管理者ユーザー名が表示されます。 管理者ユーザーに対応するパスワードを入力します。 パスワードを入力した後、[ターゲットに接続する] リンクを選びます。 これにより、入力されたターゲット サーバーの詳細が正しく、ターゲット サーバーに到達可能であることが検証されます。

[次へ] ボタンを選んで、移行するデータベースを選びます。

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

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

[次へ] ボタンを選んで、詳細を確認します。

まとめ

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

Azure portal を使用して移行を監視する

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

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

[最新の情報に更新] ボタンを使って、検証または移行の状態を更新できます。 グリッドで移行の名前を選んで、関連する詳細を見ることもできます。

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

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

検証

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

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

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

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

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

移行

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

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

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

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

検証と移行

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

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

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

一括移行

[移行] と [検証と移行] の場合にオンライン移行を完了するには、ユーザーが一括移行アクションというもう 1 つのステップを実行する必要があります。 基本データのコピーまたは複製が完了すると、移行は WaitingForUserAction 状態と WaitingForCutoverTrigger サブ状態になります。 この状態では、ユーザーはポータルで移行を選んで一括移行をトリガーできます。

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

• ソースへの書き込みが停止されています。つまり、Latency (minutes) パラメーターが 0 または 0 に近い値です。Latency (minutes) の情報は、次に示すように、移行詳細画面から取得できます。

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

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

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

• 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 を作成する方法の詳細については、次の「クイック スタート: サーバー の作成」リンクを参照してください。

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

移行中にソースとターゲットの間の接続を正常に行うためには、適切なネットワーク設定が不可欠です。 さまざまなシナリオでネットワーク接続を確立するのに役立つガイドを次に示します:

移行のネットワーク要件:

• ExpressRoute/IPsec VPN/VPN トンネリング: オンプレミス/AWS ソースを Azure に接続する場合、セキュリティで保護されたデータ転送を容易にするために、ExpressRoute、IPsec VPN、または VPN トンネリングを設定することが必要になる場合があります。

• VNET ピアリング: 2 つの異なる VNet 間に仮想ネットワーク ピアリングを確立して、直接ネットワーク接続を有効にします。これは、Azure VM と Azure Database for PostgreSQL の間の移行の前提条件です。

接続のシナリオ:

次の表は、ソースとターゲット間のネットワークの設定に役立ちます。

source	移行先	接続に関するヒント
公開	公開	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
Private	Public	この構成はサポートされていません。データ転送には pg_dump/pg_restore を使用します。
パブリック	プライベート	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
プライベート	プライベート	ソースとターゲットの間に ExpressRoute、IPsec VPN、VPN トンネリング、または仮想ネットワーク ピアリングを確立します。
プライベート	プライベート エンドポイント	この構成はサポートされていません。Microsoft サポートにお問い合わせください。

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

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

Note

pg_hba.conf ファイルは、PostgreSQL インストールのデータ ディレクトリにあります。 ソース データベースがオンプレミスの PostgreSQL サーバーまたは Azure VM でホストされている PostgreSQL サーバーである場合は、このファイルを確認して構成する必要があります。 AWS RDS または同様のマネージド サービス上の PostgreSQL インスタンスの場合、pg_hba.conf ファイルに直接アクセスしたり、適用したりすることはできません。 代わりに、サービスの提供されるセキュリティとネットワーク アクセスの構成によってアクセスが制御されます。

ネットワークセットアップの詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーの移行サービスのネットワーク ガイド」にアクセスしてください。

Extensions

拡張機能は、その機能を強化するために PostgreSQL に追加できる追加の機能です。 拡張機能は Azure Database for PostgreSQL でサポートされていますが、手動で有効にする必要があります。 拡張機能を有効にするには、次の手順に従います:

• ソースの select コマンドを使用して、使用されているすべての拡張機能を一覧表示します - select extname,extversion from pg_extension;

• Azure Database for PostgreSQL の [サーバー パラメーター] ページで azure.extensions サーバー パラメーターを検索します。 PostgreSQL 内のソースにある拡張機能を有効にします。

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

  

• リストに次のいずれかの拡張機能が含まれているかどうかを確認します。

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

"はい" の場合は、サーバー パラメーター ページで shared_preload_libraries パラメーターを検索します。 このパラメーターは、サーバーの再起動時に事前に読み込まれる拡張ライブラリのセットを示します。

サーバー パラメーター

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

• 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]

パラメーター	説明
subscription	フレキシブル サーバー ターゲットのサブスクリプション ID。
resource-group	フレキシブル サーバー ターゲットのリソース グループ。
name	フレキシブル サーバー ターゲットの名前。
migration-name	フレキシブル サーバーに対して試行された移行に対する一意識別子。 このフィールドで使用することができる文字は英数字のみで、かつハイフン (-) 以外の特殊文字は使用することができません。 名前の先頭に - を付けることはできません。1 つのフレキシブル サーバー ターゲットへの 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 "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

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

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

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

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 "C:\Users\Administrator\Documents\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	移行が成功し、完了しました。

移行サブ状態	説明
PerformingPreRequisiteSteps	インフラストラクチャが設定され、データ移行の準備ができています。
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 サーバーのレプリケーション設定で、レプリケーションのサポートを [論理] に設定する必要があります。 さらに、サーバー パラメータ max_wal_senders および max_replication_slots の値は、移行する必要があるデータベースの数と同じである必要があります。 これらは、次のコマンドを使用してコマンド ラインで構成することもできます。

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

オンライン移行のすべての前提条件が整った後、ソース PostgreSQL サーバーを再起動する必要があります。

Note

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

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

移行中にソースとターゲットの間の接続を正常に行うためには、適切なネットワーク設定が不可欠です。 さまざまなシナリオでネットワーク接続を確立するのに役立つガイドを次に示します:

移行のネットワーク要件:

• ExpressRoute/IPsec VPN/VPN トンネリング: オンプレミス/AWS ソースを Azure に接続する場合、セキュリティで保護されたデータ転送を容易にするために、ExpressRoute、IPsec VPN、または VPN トンネリングを設定することが必要になる場合があります。

• VNET ピアリング: 2 つの異なる VNet 間に仮想ネットワーク ピアリングを確立して、直接ネットワーク接続を有効にします。これは、Azure VM と Azure Database for PostgreSQL の間の移行の前提条件です。

接続のシナリオ:

次の表は、ソースとターゲット間のネットワークの設定に役立ちます。

source	移行先	接続に関するヒント
公開	公開	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
Private	Public	この構成はサポートされていません。データ転送には pg_dump/pg_restore を使用します。
パブリック	プライベート	ソースがターゲットのファイアウォール規則でホワイトリストに登録されている場合、他のアクションは必要ありません。
プライベート	プライベート	ソースとターゲットの間に ExpressRoute、IPsec VPN、VPN トンネリング、または仮想ネットワーク ピアリングを確立します。
プライベート	プライベート エンドポイント	この構成はサポートされていません。Microsoft サポートにお問い合わせください。

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

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

Note

pg_hba.conf ファイルは、PostgreSQL インストールのデータ ディレクトリにあります。 ソース データベースがオンプレミスの PostgreSQL サーバーまたは Azure VM でホストされている PostgreSQL サーバーである場合は、このファイルを確認して構成する必要があります。 AWS RDS または同様のマネージド サービス上の PostgreSQL インスタンスの場合、pg_hba.conf ファイルに直接アクセスしたり、適用したりすることはできません。 代わりに、サービスの提供されるセキュリティとネットワーク アクセスの構成によってアクセスが制御されます。

ネットワークセットアップの詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーの移行サービスのネットワーク ガイド」にアクセスしてください。

Extensions

拡張機能は、その機能を強化するために PostgreSQL に追加できる追加の機能です。 拡張機能は Azure Database for PostgreSQL でサポートされていますが、手動で有効にする必要があります。 拡張機能を有効にするには、次の手順に従います:

• ソースの select コマンドを使用して、使用されているすべての拡張機能を一覧表示します - select extname,extversion from pg_extension;

• Azure Database for PostgreSQL の [サーバー パラメーター] ページで azure.extensions サーバー パラメーターを検索します。 PostgreSQL 内のソースにある拡張機能を有効にします。

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

  

• リストに次のいずれかの拡張機能が含まれているかどうかを確認します。

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

"はい" の場合は、サーバー パラメーター ページで shared_preload_libraries パラメーターを検索します。 このパラメーターは、サーバーの再起動時に事前に読み込まれる拡張ライブラリのセットを示します。

サーバー パラメーター

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

• 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]

パラメーター	説明
subscription	フレキシブル サーバー ターゲットのサブスクリプション ID。
resource-group	フレキシブル サーバー ターゲットのリソース グループ。
name	フレキシブル サーバー ターゲットの名前。
migration-name	フレキシブル サーバーに対して試行された移行に対する一意識別子。 このフィールドで使用することができる文字は英数字のみで、かつハイフン (-) 以外の特殊文字は使用することができません。 名前の先頭に - を付けることはできません。1 つのフレキシブル サーバー ターゲットへの 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 "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

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

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

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

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 "C:\Users\Administrator\Documents\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	移行が成功し、完了しました。

移行サブ状態	説明
PerformingPreRequisiteSteps	インフラストラクチャが設定され、データ移行の準備ができています。
MigratingData	データ移行が進行中です。
CompletingMigration	一括移行が進行中です。
Completed	一括移行が成功し、移行は完了しています。

一括移行

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

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

移行後の処理

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

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

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

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

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

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

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

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

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

関連するコンテンツ

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