次の方法で共有

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

  • [アーティクル]

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

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

重要

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

メンテナンス サイクル

定期メンテナンス

標準メンテナンス サイクルは、30 日おきにスケジュールされます。 この期間により、サービスの中断を最小限に抑えながら、システムの安定性とパフォーマンスを確保できます。

クリティカルなメンテナンス

可用性とデータの整合性を維持するためにクリティカルな緊急のセキュリティ修正プログラムや更新プログラムを展開する必要がある場合などの特定のシナリオでは、メンテナンスがより頻繁に行われる場合があります。 これらの例外は、データを保護し、サービスの継続的な運用を保証するために行われます。

メンテナンスの詳細を確認する

各メンテナンスの更新に伴う具体的な詳細については、リリース ノートを参照してください。 これらのメモは、メンテナンス中に適用される更新プログラムに関する包括的な情報を提供し、環境に影響を与える変更を理解して準備できるようにします。

Note

定期的かクリティカルに関わらず、スケジュールされた更新中に、必ずしもすべてのサーバーにメンテナンスが行われるわけではありません。 Azure MySQL チームは、特定の基準を使用してメンテナンスが必要なサーバーを特定します。 この選択的なアプローチにより、メンテナンスは効率的で不可欠なものとなり、各サーバー環境固有のニーズに合わせて調整され、運用環境のダウンタイムを最小限に抑えることができます。

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

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

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

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

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

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

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

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

重要

2024 年 8 月 31 日から、Azure Database for MySQL では、バースト可能な SKU インスタンスのカスタム メンテナンス期間はサポートされなくなりました。 この変更は、メンテナンス プロセスを簡素化と、最適なパフォーマンス確保の必要性、およびバースト可能な SKU でカスタム メンテナンス期間を使用するユーザーの数が最小限であることを示す分析結果が理由です。 カスタム メンテナンス期間の構成を持つ既存のバースト可能な SKU インスタンスは影響を受けません。ただし、ユーザーは今後、これらのカスタム メンテナンス期間の設定を変更することはできません。

カスタム メンテナンス期間が必要なお客様は、この機能を引き続き使用するために General Purpose または Business Critical SKU にアップグレードすることをお勧めします。

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

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

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

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

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

制限事項と前提条件

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

  • すべてのテーブルの主キー: すべてのテーブルに主キーがあることを確認することが重要です。 主キーが不足していると、レプリケーションの遅延が大幅に増加し、ダウンタイムに影響を与える可能性があります。
  • メンテナンス時間中の低ワークロード: メンテナンス期間は、ダウンタイムを最小限に抑えるために、サーバーのワークロードが低い時間帯と同じになる必要があります。 カスタム メンテナンス期間機能を使って、ピーク外の時間にメンテナンスをスケジュールすることをお勧めします。
  • ダウンタイムの保証: メンテナンス ダウンタイムが可能な限り短くなるようにしていますが、すべての状況で常に 60 秒未満になることは保証されません。 高いワークロードや特定のサーバー構成など、さまざまな要因により、ダウンタイムが長くなる可能性があります。 最悪のシナリオでは、ダウンタイムがスタンドアロン サーバーの場合に近くなる可能性があります。

メンテナンス スケジュール

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

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

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

考慮事項と制限事項

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

  • 需要の制約: 同じリージョン内で多数のメンテナンス アクティビティが同時に発生するため、スケジュール変更されたメンテナンスが取り消される可能性があります。
  • ロックイン期間: サービスの信頼性を維持するため、スケジュール変更は、最初にスケジュールされたメンテナンス時間の 15 分前は行うことができません。
  • スロットルの再スケジュール 同一リージョン内の多数のサーバーが同時にメンテナンスを予定されている場合、再スケジューリング要求が失敗する場合があります。 再スケジュール要求が失敗した場合、エラー通知が送信されます。別のタイム スロットを選択することをお勧めします。 正常に再スケジュールされたメンテナンスは、通常、キャンセルになることはありません。

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

Note

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

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

よく寄せられる質問

Q: 一部のサーバーがメンテナンス通知を受け取ったのに、他のサーバーが受け取らなかったのはなぜですか?

A: メンテナンスの開始時刻はリージョンによって異なるため、異なるリージョンのサーバーは、異なる時間にメンテナンス通知を受け取る可能性があります。

Q: 同じリージョンの一部のサーバーがメンテナンス通知を受け取ったのに、他のサーバーが受け取らなかったのはなぜですか?

A: これは、通知を受け取らなかったサーバーが最近作成され、システムがまだメンテナンスを必要としていないと判断したために、この状況が生じた可能性があります。

Q: スケジュールされたメンテナンスをオプトアウトできますか?

A: いいえ。スケジュールされたメンテナンスのオプトアウトはできません。 ただし、メンテナンスの再スケジュール機能を使用してタイミングを調整したり、高可用性 (HA) 機能を有効にしてダウンタイムを最小限に抑えたりすることはできます。 PaaS データベース製品として、データベースのセキュリティと信頼性を確保するために、適切なタイミングでメンテナンスを実行することが不可欠です。

次のステップ