次の方法で共有

Azure Database for MySQL からのインプレース自動移行 - 単一サーバーからフレキシブル サーバーへ移行する

  • [アーティクル]

適用対象: Azure Database for MySQL - シングル サーバー

重要

一部の単一サーバー インスタンスでは、インプレース自動移行を正常に実行するための必須入力が必要になる場合があります。 これらの入力を提供するには、Azure portal の [移行] ブレードで移行の詳細を確認します。 スケジュールされた移行の 7 日前までに必須入力を指定しないと、移行は後日に再スケジュールされます。

Azure Database for MySQL の単一サーバーからフレキシブル サーバーへのインプレース自動移行は、計画メンテナンス期間にサービスによって開始されるインプレース移行であり、Basic、General Purpose、またはメモリ最適化 SKU を使用し、複雑な機能 (読み取りレプリカ、仮想ネットワーク、二重インフラ暗号化、サービス エンドポイント/VNet ルール) が有効になっていない単一サーバー データベースのワークロードを対象としています。 対象となるサーバーがサービスによって識別され、移行の詳細を確認するための手順を詳細に示す事前通知が送信されます。

インプレース移行では、計画メンテナンス期間中に回復性が高く自己復旧性の高いオフライン移行エクスペリエンスが提供され、ダウンタイムは 5 分未満です。 バックアップと復元のテクノロジを使用して、移行時間を短縮します。 この移行により、サーバーを手動で移行するためのオーバーヘッドがなくなり、価格とパフォーマンスの向上、データベース構成の詳細な制御、カスタム メンテナンス期間など、フレキシブル サーバーの利点を確実に活用できるようになります。 移行の主要なフェーズを次に示します。

  • ターゲット フレキシブル サーバーがデプロイされ、ソースの単一サーバーからすべての機能セットとプロパティ (サーバー パラメーターとファイアウォール規則を含む) が継承されます。 ソース単一サーバーは読み取り専用に設定され、ソース単一サーバーからのバックアップはターゲット フレキシブル サーバーにコピーされます。
  • DNS スイッチと一括移行は、最小限のダウンタイムで計画メンテナンス期間内に正常に実行され、移行後に同じ接続文字列をメンテナンスできます。 クライアント アプリケーションは、ユーザー主導の手動更新を行わずに、ターゲット フレキシブル サーバーにシームレスに接続します。 移行されたフレキシブル サーバーでサポートされている接続文字列形式 (単一サーバーとフレキシブル サーバー) の両方に加えて、移行されたフレキシブル サーバーでは、username@server_name とユーザー名の両方のユーザー名形式もサポートされます。
  • 移行されたフレキシブル サーバーはオンラインであり、Azure portal/CLI を使用して管理できるようになりました。 停止した単一サーバーは、移行から 7 日後に削除されます。

Note

単一サーバー インスタンスに General Purpose V1 ストレージがある場合、スケジュールされたインスタンスでは、スケジュールされた移行時刻の 12 時間前に追加の再起動操作が実行されます。 この再起動操作により、インプレース自動移行を行う前にインスタンスを General Purpose V2 ストレージにアップグレードするために必要な log_bin サーバー パラメーターが有効になります。

特典を受ける条件

複雑な機能 (読み取りレプリカ、仮想ネットワーク、二重インフラ暗号化、サービス エンドポイント/VNet ルール) が有効になっていない単一サーバー ワークロードを所有している場合は、こちらのフォームからサーバーの詳細情報を提出すことで、ご自身で自動移行を申請できるようになりました (サービスによって既にスケジュールされていない場合)。

移行アラートを構成する

インプレース自動移行の対象となるサーバーは、サービスによって事前通知が送信されます。

自動移行通知をチェックして構成する方法を次に示します。

  • 自動移行がスケジュールされている単一サーバーのサブスクリプション所有者は、電子メール通知を受け取ります。
  • こちらの手順に従って、インプレース移行スケジュールと進行状況通知を電子メール/SMS 経由で受信するようにサービス正常性アラートを構成します。
  • こちらの手順に従って、Azure portal のインプレース移行通知を確認します。

移行スケジュールを確認する

インプレース自動移行通知を受信した後に、移行スケジュールを確認する方法を次に示します。

Note

移行スケジュールはスケジュールされた移行期間の 7 日前にロックされ、それ以降はスケジュールを変更できなくなります。

  • インスタンスの単一サーバーの概要ページには、移行スケジュールに関する情報を含むポータル バナーが表示されます。

  • 自動移行用にスケジュールされた単一サーバーの場合、ポータル上の新しい [移行] ブレードが点灯します。 移行スケジュールを確認するには、単一サーバー インスタンスの [移行] ブレードに移動します。

  • 移行を延期する場合は、Azure portal 上の単一サーバー インスタンスの [移行] ブレードに移動し、1 か月以内の別の移行期間を選択して移行を再スケジュールすることで、一度に 1 か月ずつ延期できます。

  • 単一サーバーに General Purpose SKU がある場合は、移行スケジュールを確認するときに高可用性を有効にするもう 1 つのオプションがあります。 高可用性は MySQL フレキシブル サーバーの作成時間中にのみ有効にできるため、移行スケジュールを確認するときにこの機能を有効にすることを強くお勧めします。

  • 単一サーバー インスタンスで Private Link、カスタマー マネージド キー (CMK)、Microsoft Entra Admin の内の 1 つ以上が有効になっている場合、インプレース自動移行では、プライベート エンドポイント、CMK、および Microsoft Entra Admin の必須入力を、単一サーバー インスタンスからターゲットのフレキシブル サーバー インスタンスに移行する必要があります。 ユーザー入力は、スケジュールされた移行期間の 7 日前までに指定する必要があります。 移行の詳細がロックされるまでにユーザー入力が指定されないと、移行は後のある時点に再スケジュールされます。 すべての入力を指定したら、自動移行ウィザード内で構成を [保存] することを忘れないでください。 ユーザー入力を提供する手順:

    • 単一サーバー インスタンスの [移行ブレード] に移動し、スケジュールされた移行の [編集] を選択します。
    • [自動移行の詳細セクション] で [認証] ボタンをクリックして、サーバーを移行するための ARM API 接続を認証して保存します。
    • サーバーで Microsoft Entra Admin が構成されている場合は、以下のように自動移行ウィザードの [Microsoft Entra Admin] セクションで入力を指定できます。
      • ターゲット サーバーへ Microsoft Entra Admin を移行するには、Azure Database for MySQL - フレキシブル サーバーに ID を追加する必要があります。 ID には User.Read.All、GroupMember.Read.All、および Application.Read.All の各特権が付与されている必要があります。 適切なユーザー割り当てマネージド ID を選択してください。
    • サーバーでカスタマー マネージド キーが構成されている場合は、以下のように自動移行ウィザードの [データ暗号化] セクションで入力を指定できます。
      • カスタマー マネージド キー暗号化を移行するには、Azure Database for MySQL - フレキシブル サーバーに ID を追加する必要があります。 適切なユーザー割り当てマネージド ID を選択してください。 一覧表示されたキー ID/キーはソース サーバーからターゲット サーバーに移行されることになるので、キー コンテナーにアクセスするための Get、Wrap Key、Unwrap Key の各特権を付与する必要があります。
    • 単一サーバーにプライベート エンドポイントがある場合は、スケジュールされた移行の少なくとも 7 日前に移行スケジュールを確認するときに、以下の必須手順を実行します。
      • 移行対象として一覧表示されているプライベート エンドポイントを確認します。 移行準備完了としてマークされていることを確認します。 不適格としてマークされている場合は、適切なサブスクリプションとプライベート DNS ゾーンを選択します。
        • カスタム プライベート DNS ゾーンは、自動移行ではサポートされていません。 プライベート DNS ゾーンは privatelink.mysql.database.azure.com である必要があります。
        • プライベート エンドポイントの接続の承認方法は、手動承認ではなく自動承認として設定する必要があります。 手動承認プライベート エンドポイントは、自動移行ではサポートされていません。
      • 一覧表示されたプライベート エンドポイントを移行するための前提条件のチェックを実行した後、[確認チェックボックス] を選択します。

    Note

    移行のための必須入力が、スケジュールされた移行の少なくとも 7 日前までに提供されない場合、移行は後日に再スケジュールされます。

インプレース自動移行の前提条件チェック

インプレース自動移行を成功させるには、次の前提条件を確認します。

  • シングル サーバー インスタンスが準備完了状態である必要があり、自動移行を行うために計画メンテナンス期間中は停止状態にしてはいけません。
  • SSL が有効になっている単一サーバー インスタンスに対しては、信頼されたルート ストアで 3 つの証明書すべて (BaltimoreCyberTrustRoot、DigiCertGlobalRootG2 Root CA、DigiCertGlobalRootCA Root CA) が利用可能であることを確認します。 さらに、接続文字列にピン留めされた証明書がある場合は、移行後のビジネス継続性を確保するために、スケジュールされた自動移行の前に、3 つの証明書をすべて使用して結合 CA 証明書を作成します。
  • クエリに 'SORT' 句が存在しない場合、MySQL エンジンは並べ替え順序を保証しません。 インプレース自動移行の後は、並べ替え順序に変化がある場合があります。 並べ替え順序の保持が重要な場合は、スケジュールされたインプレース自動移行の前に、クエリが 'SORT' 句を含むように更新されていることを確認してください。
  • ソースの Azure Database for MySQL 単一サーバーのエンジン バージョンが v8.x である場合は、フレキシブル サーバーへの移行後に何らかのエンコードの非互換性が発生しないように、ソース サーバーの .NET クライアント ドライバー バージョンを 8.0.32 にアップグレードするようにしてください。
  • ソース Azure Database for MySQL 単一サーバーにエンジン バージョン v8.x がある場合は、移行前にソース サーバーの TLS バージョンを v1.0 または v1.1 から TLS v1.2 にアップグレードしてください。以前の TLS バージョンはフレキシブル サーバーで非推奨になりました。
  • ソースの Azure Database for MySQL 単一サーバーのファイアウォール規則名が 80 文字を超える場合は、名前の長さが 80 文字未満になるように名前を変更します。 (フレキシブル サーバーでサポートされるファイアウォール規則名の長さは 80 文字ですが、単一サーバーでは 128 文字が許可されます)。
  • 移行元の Azure Database for MySQL シングル サーバーで既定以外のポート (3308、3309、3310 など) が使用されている場合は、接続ポートを 3306 に変更してください。これらの既定以外のポートは、フレキシブル サーバーではサポートされていないためです。

ターゲット MySQL フレキシブル サーバーはどのように自動プロビジョニングされますか?

次の表の詳細を参照して、移行元単一サーバーの価格レベルと仮想コア数に基づいて移行先フレキシブル サーバーのコンピューティング レベルと SKU がプロビジョニングされます。

単一サーバーの価格レベル 単一サーバーの仮想コア数 フレキシブル サーバーのレベル フレキシブル サーバーの SKU 名
Basic 1 バースト可能 Standard_B1s
Basic 2 バースト可能 Standard_B2s
汎用 2 GeneralPurpose Standard_D2ds_v4
汎用 4 GeneralPurpose Standard_D4ds_v4
General Purpose 8 GeneralPurpose Standard_D8ds_v4
General Purpose 16 GeneralPurpose Standard_D16ds_v4
General Purpose 32 GeneralPurpose Standard_D32ds_v4
General Purpose 64 GeneralPurpose Standard_D64ds_v4
メモリ最適化 4 MemoryOptimized Standard_E4ds_v4
メモリ最適化 8 MemoryOptimized Standard_E8ds_v4
メモリ最適化 16 MemoryOptimized Standard_E16ds_v4
メモリ最適化 32 MemoryOptimized Standard_E32ds_v4
  • 移行先フレキシブル サーバーの MySQL バージョン、リージョン、*ストレージ サイズ、サブスクリプションおよびリソース グループは、移行元単一サーバーと同じです。
  • 20 GiB 未満のストレージを持つ単一サーバーの場合、ストレージ サイズは 20 GiB に設定されます。これは、Azure Database for MySQL - フレキシブル サーバーの最小ストレージ制限です。
  • 移行されたフレキシブル サーバーでは、username@server_name (単一サーバー) とユーザー名 (フレキシブル サーバー) の両方のユーザー名形式がサポートされます。
  • 両方の接続文字列形式 – 単一サーバーとフレキシブル サーバーは、移行されたフレキシブル サーバーでサポートされています。
  • クエリ ストアが有効な単一サーバー インスタンスの場合、フレキシブル サーバーへの移行時に機能パリティを確保するために、ターゲット インスタンスのサーバー パラメーター 'slow_query_log' が 'ON' に設定されます。 ワークロードによっては、これがパフォーマンスに影響する可能性があります。パフォーマンスの低下を確認した場合は、フレキシブル サーバー インスタンスでこのサーバー パラメーターを 'OFF' に設定してください。

移行後の手順

インプレース移行後に知っておく必要がある情報を次に示します。

Note

移行後、停止されたシングル サーバー インスタンスは再起動されません。これは再起動によりクライアントとアプリケーションの接続が妨げられる場合があるためです。

  • インプレース移行操作が正常に完了した後、移行元単一サーバーから移行先フレキシブル サーバーに次のプロパティをコピーします。
    • 監視ページの設定 (アラート、メトリック、診断の設定) とロックの設定
    • フレキシブル サーバーの参照を使用して、単一サーバーのインスタンスを管理するためにホストされているすべての Terraform/CLI スクリプトを更新する必要があります。
  • クエリ ストアが有効な単一サーバー インスタンスの場合、フレキシブル サーバーへの移行時に機能パリティを確保するために、ターゲット インスタンスのサーバー パラメーター 'slow_query_log' が 'ON' に設定されます。 ワークロードによっては、これがパフォーマンスに影響する可能性があることに注意してください。パフォーマンスの低下を確認した場合は、フレキシブル サーバー インスタンスでこのサーバー パラメーターを 'OFF' に設定してください。
  • Microsoft Defender for Cloud が有効になっている単一サーバー インスタンスの場合は、有効化状態が移行されます。 単一サーバーで構成できるプロパティについて、フレキシブル サーバーの自動移行後でも同等の状態にするには、次の表に示す詳細情報を参照してください。
プロパティ Configuration
特定のアラートの種類を抑制する Microsoft Defender for Cloud プラットフォームで特定のアラートの種類を無効にします。 詳細については、Microsoft Defender for Cloud からのアラートの抑制ガイドを参照してください。

単一サーバー ユーザーは次の API プロパティを使用できます。
properties.disabledAlerts
メール通知 サブスクリプション内のすべてのリソースに対する Microsoft Defender for Cloud アラートの電子メールによる通知を定義します。 詳細については、セキュリティ アラートの電子メールによる通知の構成に関するページを参照してください。

単一サーバー ユーザーは次の API プロパティを使用できます。
properties.emailAccountAdmins,
properties.emailAddresses
アラートをエクスポートして、処理やアーカイブをさらに行う アラートは Microsoft Defender for Cloud プラットフォームに保存され、Azure Resource Graph を介して公開されます。
アラートを別のストアにエクスポートし、保持期間を個別に管理できます。 詳細については、Azure portal での連続エクスポートの設定 - Microsoft Defender for Cloud に関するページを参照してください。

単一サーバー ユーザーは次の API プロパティを使用できます。
properties.retentionDays,
properties.storageAccountAccessKey,
properties.storageEndpoint

よく寄せられる質問 (FAQ)

Q. 自動移行されるのはなぜですか?

A. Azure Database for MySQL - シングル サーバー インスタンスは、主力製品である Azure Database for MySQL - フレキシブル サーバーへのインプレース移行の対象となります。 このインプレース移行により、サーバーを手動で移行するためのオーバーヘッドがなくなり、価格 & のパフォーマンスの向上、データベース構成のきめ細かな制御、カスタム メンテナンス期間などのフレキシブル サーバーの利点を確実に活用できるようになります。

Q. 自動統合はどのように行われますか? 何が移行されますか?

A. フレキシブル サーバーは、単一サーバーと同じ仮想コアとストレージになるようにプロビジョニングされます。 次に、ソース単一サーバーが停止状態になり、データ ファイルのスナップショットが取得され、ターゲット フレキシブル サーバーにコピーされます。 DNS スイッチが実行されて、既存のすべての接続がターゲットにルーティングされ、ターゲットのフレキシブル サーバーがオンラインになります。 自動移行では、サーバー パラメーター (ソース上のすべての変更されたサーバー パラメーターがターゲットにコピーされ、変更されていないサーバー パラメーターはフレキシブル サーバーで定義された既定値を取ります) とファイアウォール規則に加えて、サーバーのデータ ファイル全体 (スキーマ、データ、ログインを含む) が移行されます。 これは、最大 5 分以下のダウンタイムが発生するオフライン移行です。

Q. インプレース移行アラートを設定または表示するにはどうすればよいですか?

A. アラートを設定する方法を次に示します。

  • こちらの手順に従って、インプレース移行スケジュールと進行状況通知を電子メール/SMS 経由で受信するようにサービス正常性アラートを構成します。
  • こちらの手順に従って、Azure portal のインプレース移行通知を確認します。

Q. スケジュールされた移行を延期するにはどうすればよいですか?

A. 移行スケジュールを確認するには、単一サーバー インスタンスの [移行] ブレードに移動します。 移行を延期する場合は、Azure portal 上の単一サーバー インスタンスの [移行] ブレードに移動し、1 か月以内の別の移行期間を選択して移行を再スケジュールすることで、最大 1 か月ずつ延期できます。 移行の詳細は、スケジュールされた移行期間の 7 日前にロックされ、その後は再スケジュールできません。 このインプレース移行は、2024 年 9 月 16 日まで毎月延期できます。

Q. 移行されたフレキシブル サーバーでサポートされるユーザー名と接続文字列は何ですか? ​​

A. 移行されたフレキシブル サーバーでは、username@server_name (単一サーバー形式) とユーザー名 (フレキシブル サーバー形式) の両方のユーザー名形式がサポートされるため、移行後にアプリケーションの継続性を維持するために更新する必要はありません。 また、移行されたフレキシブル サーバーでは、両方の接続文字列形式 (単一サーバーとフレキシブル サーバー形式) もサポートされます。

Q. 自動移行されたサーバーに対して HA (高可用性) を有効にする方法

A. 既定では、自動移行によって HA 以外のインスタンスへの移行が設定されます。 HA はサーバーの作成時にのみ有効にできるため、ポータルの自動移行スケジュール編集オプションを使用して、スケジュールされた自動移行の前に HA を有効にする必要があります。 Basic からバースト可能な SKU への移行では HA 構成がサポートされていないため、HA はターゲット フレキシブル サーバーでは、汎用\メモリ最適化 SKU でのみ有効にすることができます。

Q. MySQL Basic 単一サーバーから MySQL フレキシブル サーバーへの移行する場合、価格には違いがありますか?

A. 両方のオファリングの最小ストレージ制限が異なるため (単一サーバーでは 5 GiB、フレキシブル サーバーでは 20 GiB)、一部のサーバーでは移行後にわずかな価格上昇が発生する可能性があります (推定コストは、ポータルで自動移行スケジュールの編集オプションを選択すると確認できます)。ストレージ コスト (単一サーバーで 0.1 ドル、フレキシブル サーバーで 0.115 ドル) は、フレキシブル サーバーの方が単一サーバーよりもわずかに高くなります。 影響を受けるサーバーの場合、フレキシブル サーバーでのこの価格の上昇により、単一サーバーと比較してスループットとパフォーマンスが向上します

関連するコンテンツ