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

  • [アーティクル]

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

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

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

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

Note

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

特典を受ける条件

  • Basic、General Purpose、またはメモリ最適化 SKU を使用し、使用されているデータ ストレージが <= 20 GiB で、複雑な機能 (CMK、AAD、読み取りレプリカ、Private Link) が有効になっていない単一サーバー ワークロードを所有している場合、このフォームを通してサーバーの詳細を送信することで、自分自身で自動移行を申し込めるようになりました (サービスによってまだスケジュールされていない場合)。

移行アラートを構成し、移行スケジュールを確認する

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

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

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

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

Note

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

  • インスタンスの単一サーバーの概要ページには、移行スケジュールに関する情報を含むポータル バナーが表示されます。
  • 自動移行用にスケジュールされた単一サーバーの場合、ポータル上の新しい [移行] ブレードが点灯します。 移行スケジュールを確認するには、単一サーバー インスタンスの [移行] ブレードに移動します。
  • 移行を延期する場合は、Azure portal 上の単一サーバー インスタンスの [移行] ブレードに移動し、1 か月以内の別の移行期間を選択して移行を再スケジュールすることで、一度に 1 か月ずつ延期できます。
  • 単一サーバーに General Purpose SKU がある場合は、移行スケジュールを確認するときに高可用性を有効にするもう 1 つのオプションがあります。 高可用性は MySQL フレキシブル サーバーの作成時間中にのみ有効にできるため、移行スケジュールを確認するときにこの機能を有効にすることを強くお勧めします。

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

  • シングル サーバー インスタンスが準備完了状態である必要があり、自動移行を行うために計画メンテナンス期間中は停止状態にしてはいけません。
  • 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 単一サーバーのファイアウォール規則名が 80 文字を超える場合は、名前の長さが 80 文字未満になるように名前を変更します。 (フレキシブル サーバーでサポートされるファイアウォール規則名の長さは 80 文字ですが、単一サーバーでは 128 文字が許可されます)。

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

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

    単一サーバーの価格レベル 単一サーバーの仮想コア数 フレキシブル サーバーのレベル フレキシブル サーバーの SKU 名
    Basic 1 バースト可能 Standard_B1s
    Basic 2 バースト可能 Standard_B2s
    General Purpose 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' に設定してください。

移行後の手順

注意

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

  • インプレース移行操作が正常に完了した後、移行元単一サーバーから移行先フレキシブル サーバーに次のプロパティをコピーします。
    • 監視ページの設定 (アラート、メトリック、診断の設定)
    • フレキシブル サーバーの参照を使用して、単一サーバーのインスタンスを管理するためにホストされているすべての Terraform/CLI スクリプトを更新する必要があります。
  • クエリ ストアが有効な単一サーバー インスタンスの場合、フレキシブル サーバーへの移行時に機能パリティを確保するために、ターゲット インスタンスのサーバー パラメーター 'slow_query_log' が 'ON' に設定されます。 ワークロードによっては、これがパフォーマンスに影響する可能性があることに注意してください。パフォーマンスの低下を確認した場合は、フレキシブル サーバー インスタンスでこのサーバー パラメーターを 'OFF' に設定してください。
  • Advanced Threat Protection が有効になっている単一サーバー インスタンスの場合は、Azure Defender for Cloud に自動移行するときにパリティを維持するために、自動移行後に次の表にあるプロパティを構成することを検討してください。
プロパティ Configuration
properties.disabledAlerts Microsoft Defender for Cloud プラットフォームを使用して、特定のアラートの種類を無効にすることができます。 詳細については、「Microsoft Defender for Cloud からのアラートを抑制する」のガイドを参照してください。
properties.emailAccountAdmins, properties.emailAddresses サブスクリプション内のすべてのリソースに対する Microsoft Defender for Cloud アラートの電子メール通知を一元的に定義できます。 詳細については、「クイック スタート: セキュリティ アラートの電子メール通知を構成する」を参照してください。
properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint Microsoft Defender for Cloud プラットフォームは、Azure Resource Graph を介してアラートを公開します。 アラートを別のストアにエクスポートし、保持期間を個別に管理できます。 連続エクスポートの詳細については、「Azure portal での連続エクスポートの設定 - Microsoft Defender for Cloud」の記事を参照してください。

よく寄せられる質問 (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 ドル) は、フレキシブル サーバーの方が単一サーバーよりもわずかに高くなります。 影響を受けるサーバーの場合、フレキシブル サーバーでのこの価格の上昇により、単一サーバーと比較してスループットとパフォーマンスが向上します

次のステップ