Azure Database for MySQL - フレキシブル サーバーでの予定メンテナンス

  • [アーティクル]

適用対象: Azure Database for MySQL - フレキシブル サーバー

Azure Database for MySQL フレキシブル サーバーでは、管理対象のデータベースを安全で安定した最新の状態に保つために定期的なメンテナンスが実行されます。 メンテナンス中に、サーバーでは新しい機能、更新プログラム、パッチが取得されます。

重要

Azure Database for MySQL フレキシブル サーバーのメンテナンス中は、すべてのサーバー操作 (修正、構成の変更、サーバーの起動/停止) は避けてください。 これらのアクティビティに関与すると、予期しない結果を招き、サーバーのパフォーマンスと安定性に影響を与える可能性があります。 サーバー操作を実行する前に、メンテナンスが終了するまでお待ちください。

メンテナンス期間を選択する

特定の曜日とその日の時間帯の間でのメンテナンスをスケジュールできます。 また、システムで自動的に曜日と時間枠が選択されるようにすることもできます。 どちらの場合でも、メンテナンスを実行する 7 日前に通知されます。 また、メンテナンスが開始されたときと、正常に完了したときに通知されるようにすることもできます。

今後の予定メンテナンスについて、次のように通知できます。

  • 特定のアドレスにメールで送信する
  • Azure Resource Manager のロールにメールで送信する
  • テキスト メッセージ (SMS) でモバイル デバイスに送信する
  • 通知として Azure アプリにプッシュする
  • 音声メッセージとして配信する

メンテナンス スケジュールの設定を指定する場合、曜日と時間帯を選択できます。 指定しない場合、システムでは、サーバーのリージョンの時刻で午後 11 時から午前 7 時までの時間が選択されます。 Azure サブスクリプションのフレキシブル サーバーごとに異なるスケジュールを定義できます。

重要

通常、サーバーの正常な予定メンテナンス イベントの間隔は 30 日間以上です。

ただし、重大な脆弱性などのクリティカルな緊急更新プログラムの場合、通知期間は 7 日未満になる可能性があります。 過去 30 日間に予定メンテナンスが正常に実行された場合でも、重要な更新プログラムがサーバーに適用されることがあります。

スケジュール設定はいつでも更新できます。 フレキシブル サーバーのメンテナンスがスケジュールされている場合に、スケジュールの優先順位を更新すると、現在のロールアウトはスケジュールどおりに実行され、スケジュール設定の変更は、次のスケジュールされたメンテナンスが正常に完了した時点で有効になります。

Azure サブスクリプション内のフレキシブル サーバーごとに、システム管理のスケジュールまたはカスタム スケジュールを定義できます。

  • カスタム スケジュールの場合、曜日と 1 時間の時間枠を選択して、サーバーのメンテナンス期間を指定できます。
  • システム管理のスケジュールの場合、サーバーのリージョン時間の午後 11 時から午前 7 時までの任意の 1 時間の期間が選択されます。

重要

以前は、システム マネージドとカスタム マネージド スケジュールの間に 7 日間のデプロイ ギャップがありました。 メンテナンスの需要が高まっていることに加え、メンテナンスのスケジュール変更機能 (パブリック プレビュー) が導入されたため、この 7 日間のギャップを保証できなくなりました。

まれに、メンテナンス イベントがシステムによって取り消されたり、正常に完了しなかったりすることがあります。 更新が失敗した場合、更新は元に戻され、以前のバージョンのバイナリが復元されます。 このような更新プログラムが失敗したシナリオでは、メンテナンス期間中にサーバーの再起動が発生する場合があります。 更新プログラムの取り消しまたは失敗時には、メンテナンスの取り消しまたは失敗に関する通知がそれぞれ作成され、お客様に通知されます。 次にメンテナンスを実行しようとすると、現在のスケジュール設定に従ってスケジュールが設定され、5 日前に通知が届きます。

ほぼゼロ ダウンタイムのメンテナンス (パブリック プレビュー)

Azure Database for MySQL フレキシブル サーバーの "ほぼゼロ ダウンタイムのメンテナンス" 機能は、HA (高可用性) 対応サーバー向けの画期的な開発です。 この機能は、メンテナンスのダウンタイムを大幅に短縮するように設計されており、ほとんどの場合、メンテナンスのダウンタイムは 40 から 60 秒の間になると予想されます。 この機能は、高可用性とデータベース操作の中断を最小限に抑える必要がある企業にとって極めて重要です。

ダウンタイムの正確な予測

  • ダウンタイム期間: ほとんどの場合、メンテナンス中のダウンタイムは 10 から 30 秒の範囲です。
  • 追加の考慮事項: フェールオーバー イベントの後、約 30 秒間の固有の DNS 有効期間 (TTL) が発生します。 この期間はメンテナンス プロセスによって直接制御されませんが、DNS 動作の標準の部分です。 そのため、顧客の観点から見ると、メンテナンス中に発生するダウンタイムの合計が 40 から 60 秒の範囲になる可能性があります。

制限事項と前提条件

この機能によって見込まれる最適なパフォーマンスを達成するには、特定の条件と制限に注意する必要があります。

  • すべてのテーブルの主キー: すべてのテーブルに主キーがあることを確認することが重要です。 主キーが不足していると、レプリケーションの遅延が大幅に増加し、ダウンタイムに影響を与える可能性があります。
  • メンテナンス時間中の低ワークロード: メンテナンス期間は、ダウンタイムを最小限に抑えるために、サーバーのワークロードが低い時間帯と同じになる必要があります。 カスタム メンテナンス期間機能を使って、ピーク外の時間にメンテナンスをスケジュールすることをお勧めします。

メンテナンスのスケジュール変更 (パブリック プレビュー)

重要

メンテナンスのスケジュール変更機能は現在プレビュー段階です。 制限事項と継続的な開発の対象となります。 フィードバックをお寄せください。この機能の強化に向けて参考にさせていただきます。 この機能は、バースト可能 SKU を使用するサーバーでは使うことができません。

メンテナンスのスケジュール変更機能を使うと、Azure Database for MySQL フレキシブル サーバー インスタンスでのメンテナンス アクティビティのタイミングをより細かく制御できます。 メンテナンス通知を受け取った後は、システム マネージドかカスタム マネージドかに関係なく、より都合の良い時間にスケジュールを変更できます。

スケジュール変更のパラメーターと通知

スケジュール変更は、固定タイム スロットに限定されません。これは、現在のメンテナンス サイクルで許容される最も早い時間と最新の時間によって異なります。 スケジュール変更の際は、標準の通知ポリシーに従って、変更を確認するための通知が送信されます。

考慮事項と制限事項

この機能を使うときは、次の点に注意してください。

  • 需要の制約: 同じリージョン内で多数のメンテナンス アクティビティが同時に発生するため、スケジュール変更されたメンテナンスが取り消される可能性があります。
  • ロックイン期間: サービスの信頼性を維持するため、スケジュール変更は、最初にスケジュールされたメンテナンス時間の 15 分前は行うことができません。

メンテナンスを再スケジュールできる回数に制限はなく、メンテナンスが "準備中" 状態にならない限り、いつでもメンテナンスを別の時間に再スケジュールできます。

Note

潜在的な調整に対応するために、プレビュー段階中に通知を厳密に監視することをお勧めします。

重要なデータベース操作中の中断を回避するには、この機能を使います。 この機能は引き続き開発を行っているため、ぜひフィードバックをお寄せください。

次のステップ