移行サービスを使用して、Amazon RDS for PostgreSQL サーバーから Azure Database for PostgreSQL にオンラインで移行する

この記事では、オンプレミスまたは Azure 仮想マシン (VM) からオンライン モードで Azure Database for PostgreSQL フレキシブル サーバーに PostgreSQL インスタンスを移行する方法について説明します。

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

• [前提条件]
• 移行を実行する
• 移行を監視する
• カットオーバーを開始する
• 完了したら移行を確認する

[前提条件]

移行を開始するには、次の前提条件が必要です。

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

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

ソース バージョンを確認する

ソース PostgreSQL サーバーのバージョンは 9.5 以降である必要があります。

移行元の PostgreSQL バージョンが 9.5 未満の場合は、移行を開始する前に 9.5 以上にアップグレードしてください。

test_decodingのインストール - ソースセットアップ

• test_decoding は論理デコード メカニズムを介して WAL を受信し、実行された操作のテキスト表現にデコードします。
• Amazon RDS for PostgreSQL では、test_decoding プラグインがプレインストールされ、論理レプリケーションの準備が整います。 これにより、論理レプリケーション スロットを簡単に設定し、WAL の変更をストリーミングできるため、変更データ キャプチャ (CDC) や外部システムへのレプリケーションなどのユース ケースが容易になります。
• テスト デコード プラグインの詳細については、PostgreSQL のドキュメントを参照してください。

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

• 移行する前に、Azure Database for PostgreSQL - フレキシブル サーバーを作成する必要があります。
• Azure Database for PostgreSQL - フレキシブル サーバー用にプロビジョニングされた SKU は、ソースと一致する必要があります。
• 新しい Azure Database for PostgreSQL を作成するには、「Azure Database for PostgreSQL フレキシブル サーバーの作成」を参照してください。

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

• test_decoding 論理デコード プラグインは、ソースから変更されたレコードをキャプチャします。
• 移行ユーザーがレプリケーション特権にアクセスできるようにするには、次のコマンドを実行します。

GRANT rds_replication TO <<username>>;

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

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

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

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

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

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

拡張機能を有効にする

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

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

詳細については、「 拡張機能とモジュール」を参照してください。

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

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

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

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

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

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

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

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

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

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

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

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

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

移行を実行する

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

ポータル

この記事では、Azure portal を使用して、Amazon RDS for PostgreSQL サーバーから Azure Database for PostgreSQL に PostgreSQL データベースを移行する方法について説明します。 Azure portal では、データベースの移行など、さまざまなタスクを実行できます。 このチュートリアルで説明されている手順に従って、データベースを Azure にシームレスに転送し、その強力な機能とスケーラビリティを活用できます。

移行タスクを構成する

移行サービスには、Azure portal でのウィザードベースのシンプルなエクスペリエンスが用意されています。

Azure portal を使用して以下を実行します。

1. お使いの Azure Database for PostgreSQL フレキシブル サーバーを選択します。

2. リソース メニューで、[移行] を選択 します。

   

3. [ 作成] を選択すると、ウィザードベースの一連のタブが表示され、オンプレミスまたは Azure VM からフレキシブル サーバーへの移行が実行されます。

   注

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

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

   

設定

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

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

• ソース サーバーの種類 - PostgreSQL ソースに応じて、 Azure 仮想マシン または オンプレミス サーバーを選択できます。

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

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

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

事前移行検証の詳細については、premigrationを参照してください。

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

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

ランタイム サーバー

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

ランタイム サーバーの詳細については、「 移行ランタイム サーバー」を参照してください。

[転送元サーバー]

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

• サーバー名 - ホストの名前またはソース PostgreSQL サーバーの IP アドレスを指定します。
• ポート - ソース サーバーのポート番号。
• 管理者ログイン - ソース PostgreSQL サーバーの管理者ユーザーの名前。
• パスワード - ソース PostgreSQL サーバーに接続するために指定された管理者ログインのパスワード。
• SSL モード - サポートされている値は preferred と required。 ソース PostgreSQL サーバーの SSL が OFF場合は、 preferを使用します。 ソース サーバーの SSL が ON場合は、 requireを使用します。 SSL 値は、ソース サーバーの postgresql.conf ファイルで決定できます。
• テスト接続 — ターゲットとソースの間の接続テストを実行します。 接続が成功したら、次のタブに進むことができます。これらのテストは、指定された資格情報を使用した認証の検証など、ターゲット サーバーとソース サーバーの間に存在する可能性のある接続の問題を特定することを目的としています。 テスト接続の確立には数秒かかります。

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

ターゲット サーバー

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

• 管理者ログイン - ターゲット PostgreSQL サーバーの管理者ユーザーの名前。
• パスワード - ターゲット PostgreSQL サーバーに接続するために指定された管理者ログインのパスワード。
• カスタム FQDN または IP アドレス: カスタム FQDN または IP アドレス フィールドは省略可能であり、ターゲットがカスタム DNS サーバーの背後にある場合、またはカスタム DNS 名前空間がある場合に使用でき、特定の FQDN または IP アドレス経由でのみアクセスできます。 たとえば、カスタム DNS サーバーに DNS ゾーンが含まれている場合、 production-flexible-server.example.com、 198.1.0.2、PostgreSQL FQDN ( production-flexible-server.postgres.database.azure.com など) などのエントリが含まれる場合や、この postgres.database.azure.com ゾーンのクエリを 168.63.129.16に転送したりすると、FQDN は Azure パブリックまたはプライベート DNS ゾーンで解決されます。
• テスト接続 — ソースとターゲットの間の接続テストを実行します。 接続が成功したら、次のタブに進むことができます。これらのテストは、指定された資格情報を使用した認証の検証など、ソース サーバーとターゲット サーバーの間に存在する可能性のある接続の問題を特定することを目的としています。 テスト接続の確立には数秒かかります。

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

検証または移行するデータベース

[ 検証または移行するデータベース ] タブで、移行元の PostgreSQL サーバーから移行するユーザー データベースの一覧を選択できます。

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

概要

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

検証または移行を取り消す

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

検証を取り消すと、それ以降の検証アクティビティが停止し、検証が [キャンセル済み ] 状態に移動します。

移行を取り消すと、ターゲット サーバーでの移行アクティビティがさらに停止し、[ キャンセル済み ] 状態に移動します。 ターゲット サーバー上の変更がドロップまたはロールバックされることはありません。 取り消された移行に関係するターゲット サーバー上のデータベースを必ず削除してください。

CLI

この記事では、Azure CLI を使用して、PostgreSQL データベースを Azure 仮想マシンまたはオンプレミスの PostgreSQL インスタンスから Azure Database for PostgreSQL に移行する方法について説明します。 Azure CLI には、データベースの移行など、さまざまなタスクを実行できる強力で柔軟なコマンド ライン インターフェイスが用意されています。 この記事で説明されている手順に従って、データベースを Azure にシームレスに転送し、その強力な機能とスケーラビリティを活用できます。

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

CLI がインストールされたら、コマンド プロンプトを開き、次のコマンドを使用して Azure アカウントにログインします。

az login

移行タスクを構成する

移行を開始するには、移行の詳細を含む JSON ファイルを作成します。 JSON ファイルには、次の情報が含まれています。

• JSON 行に << >> 次のプレースホルダーを編集し、CLI が呼び出されている <<filename>>.json としてローカル コンピューターに格納します。 このチュートリアルでは、ファイルをc:/migration-CLI/migration_body.jsonに保存しました。

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

注

Azure Database for PostgreSQL フレキシブル サーバーへの移行用に JSON プロパティを構成するときに、ソース環境が Azure 仮想マシンの場合は、 "sourceType":"AzureVM" プロパティを使用してソースの種類を指定できます。 これにより、移行サービスは、データの移行元の環境を理解するのに役立ちます。

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

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• 上記の手順では、移行は実行されないため、次のコマンドを実行して新しい移行を開始します。

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• 次のコマンドを実行して、前の手順で開始した移行の状態を確認します。 移行の状態を確認するには、移行名を指定します。

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• 移行の進行状況と状態は、Azure CLI に表示されます。

• Azure portal で進行状況と状態を確認することもできます。

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

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

移行を監視する

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

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

移行の詳細

グリッドで移行名を選択すると、関連する詳細が表示されます。

前の手順では、この移行を作成するときに、移行オプションを [検証して移行] として構成したことを覚えておいてください。 このシナリオでは、最初に検証が実行されてから移行が開始されます。 前提条件ステップの 実行 のサブ状態が完了すると、ワークフローは進行中の検証のサブ状態 に移動します。

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

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

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

• 検証の詳細 (例)
  • 接続チェック、ソース バージョン、つまり PostgreSQL バージョン >= 9.5、およびサーバー パラメーター チェックに関連する検証が含まれています。これは、Azure Database for PostgreSQL フレキシブル サーバーのサーバー パラメーターで拡張機能が有効になっているかどうかです。
• データベースの検証と移行の詳細
  • これには、Azure Database for PostgreSQL フレキシブル サーバーでの拡張機能と照合順序のサポートに関連する個々のデータベースの検証が含まれています。

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

移行の状態として考えられるもの:

移行の状態

ステータス	Description
処理中	移行インフラストラクチャのセットアップが進行中であるか、実際のデータ移行が進行中です。
取り消されました	移行が取り消されるか削除されます。
失敗	移行に失敗しました。
検証に失敗しました	検証に失敗しました。
成功しました	移行が成功し、完了しました。
ユーザーアクションの待機中	カットオーバーの実行には、ユーザーのアクションを待っています。

移行の詳細

副状態	Description
前提条件の手順の実行	データ移行のためのインフラストラクチャのセットアップが進行中です。
検証の進行中	検証が進行中です。
ターゲット上のデータベースの削除	ターゲット サーバー上の既存のデータベースを削除します。
データの移行	データの移行が進行中です。
移行の完了	移行は完了の最終段階にあります。
完了	移行が完了しました。
失敗	移行は失敗しました。

検証サブステータス

副状態	Description
失敗	検証が失敗しました。
成功しました	検証が成功しました。
警告	検証で警告が発生しています。

カットオーバーを開始する

カットオーバーは、Azure portal または Azure CLI を使用して開始できます。

ポータル

[検証と移行] オプションの場合、オンライン移行を完了するには、カットオーバー アクションをトリガーする追加の手順を完了する必要があります。 基本データのコピーまたは複製が完了すると、移行は Waiting for user action の状態と Waiting for cutover trigger の副状態に移動します。 この状態では、ユーザーは移行を選択してポータルからカットオーバーをトリガーできます。

カットオーバーを開始する前に、次のことを確認することが重要です。

• ソースへの書き込みは停止されます。 latency 値は 0 または 0 に近い値です。 latency情報は、次に示すように、移行の詳細画面から取得できます。
• latency 値が 0 に減少するか、0 に近い
• latency値は、ターゲットがソースと最後に同期された日時を示します。 ソースへの書き込みは、この時点で停止でき、カットオーバーを開始できます。 ソースでトラフィックが多い場合は、最初に書き込みを停止して、 latency を 0 に近づけてからカットオーバーを開始することをお勧めします。

カットオーバー操作により、ソース サーバーからターゲット サーバーに保留中のすべての変更が適用され、移行が完了します。 0 以外の latencyでもカットオーバーをトリガーすると、レプリケーションはその時点まで停止します。 ターゲットにカットオーバー ポイントまでのソース上のすべてのデータが適用されます。 カットオーバー ポイントで 15 分の待機時間が発生した場合、過去 15 分間にデータに加えられたすべての変更がターゲットに適用されます。

時間は、過去 15 分間に発生した変更のバックログによって異なります。 そのため、カットオーバーをトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。

• 移行は、Succeededサブステータスまたはカットオーバー (オンライン移行中) が正常に終了すると、Migrating data状態に移動します。 Migrating dataのサブステータスで問題が発生した場合、移行はFailed状態になります。

CLI

[検証と移行] オプションの場合、オンライン移行を完了するには、カットオーバー アクションをトリガーする追加の手順を完了する必要があります。 基本データのコピーまたは複製が完了すると、移行は Waiting for user action の状態と Waiting for cutover trigger の副状態に移動します。 この状態では、ユーザーは次のコマンドを使用して CLI を使用してカットオーバーをトリガーできます。 移行グリッドで移行名を選択することで、ポータルからカットオーバーをトリガーすることもできます。

カットオーバーを開始する前に、次のことを確認することが重要です。

• ソースへの書き込みは停止されます。 latency 値は 0 または 0 に近い値です。 latency情報は、次に示すように、移行の詳細画面から取得できます。
• latency 値が 0 に減少するか、0 に近い
• latency値は、ターゲットがソースと最後に同期された日時を示します。 ソースへの書き込みは、この時点で停止でき、カットオーバーを開始できます。 ソースでトラフィックが多い場合は、最初に書き込みを停止して、 latency を 0 に近づけてからカットオーバーを開始することをお勧めします。

カットオーバー操作により、ソース サーバーからターゲット サーバーに保留中のすべての変更が適用され、移行が完了します。 0 以外の latencyでもカットオーバーをトリガーすると、レプリケーションはその時点まで停止します。 ターゲットにカットオーバー ポイントまでのソース上のすべてのデータが適用されます。 カットオーバー ポイントで 15 分の待機時間が発生した場合、過去 15 分間にデータに加えられたすべての変更がターゲットに適用されます。

時間は、過去 15 分間に発生した変更のバックログによって異なります。 そのため、カットオーバーをトリガーする前に、待機時間をゼロまたはゼロに近い値にすることをお勧めします。

• 移行は、Succeededサブステータスまたはカットオーバー (オンライン移行中) が正常に終了すると、Migrating data状態に移動します。 Migrating dataのサブステータスで問題が発生した場合、移行はFailed状態になります。

カットオーバーをトリガーするには、次のコマンドを使用します。

az postgres flexible-server migration update --subscription <subscription_id> --resource-group <resource_group> --name <server> --migration-name <migration> --cutover

完了したら移行を確認する

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

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

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

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

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

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

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

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

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

関連コンテンツ

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