Azure サブスクリプションの Azure Database for MySQL フレキシブル サーバー インスタンスごとにメンテナンス オプションを指定できます。 オプションには、これから実行されるメンテナンス イベントと、終了したメンテナンス イベントのメンテナンス スケジュールと通知設定が含まれます。
注
これらの新しいメンテナンス機能は、Azure リージョン間で段階的にロールアウトされています。 Azure Portal にすぐに表示されない場合は、完全なデプロイにしばらく時間を置いてください。 可用性は、サブスクリプションとリージョンによって異なる場合があります。
前提条件
このハウツー ガイドを完了するには、次が必要です。
メンテナンスの構成とエクスペリエンス
Azure Database for MySQL – フレキシブル サーバーでは、サーバーが更新プログラムを受け取る方法をより詳細に制御および可視化できる、強化されたメンテナンス エクスペリエンスが提供されるようになりました。 [設定>メンテナンス] の下には、次の 3 つの主要な領域があります。
- メンテナンス ポリシー
- カスタム スケジュール構成
- メンテナンスの状態とスケジュールの変更
メンテナンス ポリシーのオプション
ワークロードの要件に応じて、次のメンテナンス ポリシーの種類から選択できます。
仮想カナリア
Virtual Canary は、更新プログラムを早期に検証する非運用環境のワークロードを対象としています。 このポリシーの下のサーバーは、一般提供前に更新プログラムを受け取り、標準の更新間隔に従 っていません 。30 日間の間隔は保証されず、7 日前の通知もありません。
バースト可能 SKU サーバーは、既定で仮想カナリア ポリシーに登録されます。
システム管理メンテナンス期間 (SMW)
このメンテナンス ポリシーは、 General Purpose コンピューティング レベルと Business Critical コンピューティング レベルのサーバーの既定のオプションです。 メンテナンスは、ランダムな日時 (通常は 午後 11:00 から午前 7:00 のサーバーローカル時刻) に自動的にスケジュールされます。 このポリシーは、標準のメンテナンス動作に従います。更新プログラムは 30 日に 1 回以上発生せず、少なくとも 7 日前に発表されます。
カスタム管理メンテナンスウィンドウ (CMW)
メンテナンスのタイミングを制御する場合は、このメンテナンス ポリシーを選択します。 CMW を使用すると、 希望する曜日 と 開始時刻 (60 分 UTC ウィンドウ) を定義できます。 これは、更新のタイミングが変更制御ポリシーと一致する必要がある運用環境で特に役立ちます。
また、サーバーを バッチ (Batch 1 または Batch 2) に割り当てて、TEST や PROD などの環境間でメンテナンスを分散させることもできます。
- バッチ 1: メンテナンスは、リージョンのメンテナンス期間の 最初の 7 日間 に行われます。
- バッチ 2: メンテナンスは 2 回目の 7 日間に行われます。
注
7 日間のメンテナンス バッチは、カレンダーの週 (日曜日や月曜日など) に 合わせて調整されません 。 代わりに、最初の 7 日間は、サーバーのリージョンのメンテナンス サイクルの実際の開始日から開始されます。
CMW が構成されると、新しいスケジュールは 次のリージョンメンテナンス サイクルで有効になります。
現在スケジュールされているメンテナンスのタイミングを変更するには、メンテナンスのスケジュール変更機能を使用します。
今後のメンテナンスの表示と管理
[ メンテナンス状態] セクションには、サーバーの現在スケジュールされているメンテナンス イベントまたは最近完了したメンテナンス イベントが表示されます。 通常、一度に 1 つのエントリが表示されます。
再スケジュール
メンテナンスがまだ開始されていない場合は、[ 再スケジュール] を選択して新しい日付と時刻を選択できます。 これにより、ビジネス運用や計画されたデプロイとの競合を回避できます。
再スケジュールされた機能は、 General Purpose コンピューティング レベルと Business Critical コンピューティング レベルのサーバーでのみ使用できます。 バースト可能 SKU サーバーではサポートされていません。
今すぐスケジュールを変更する
今すぐ再スケジュールをクリックすると、メンテナンスが即座に開始されます。 これは、更新プログラムをすぐに適用する場合や、メンテナンスがいつ行われるかをより正確に制御する場合に便利です。 現在に再スケジュール できるのは、サーバーが スケジュール 済みまたは スケジュール変更済みの 状態の場合のみです。 [今すぐ再スケジュール] をクリックすると、サーバーは 準備中の状態に入ります。 つまり、サーバーはメンテナンス イベントの準備をしており、数分後にメンテナンスが開始されます。
注
場合によっては、[今すぐ再スケジュール] が準備中状態でしばらく応答しなくなることがあります。 これは通常、同じリージョン内のサーバーの数が多すぎて、同時にメンテナンスがスケジュールされていることが原因です。 このような場合は、サーバーの準備が完了するのを待つか、サポート チケットを発行してヘルプを受けることができます。
スケジュールの変更に関する考慮事項と制限事項
この機能に関する次の点に注意してください。
- レベルの可用性: バースト可能なコンピューティング レベルでは、メンテナンスの再スケジュールは使用できません。 この機能は運用環境のサーバーを対象としていますが、Burstable レベルは非運用環境向けに設計されています。
- 需要の制約: 同じリージョンで多数のメンテナンス アクティビティが同時に発生した場合、再スケジュールされたメンテナンスが取り消される可能性があります。
- ロックイン: サービスの信頼性を維持するために、最初に予定されたメンテナンスの15分前からは再スケジュールができません。
- 再スケジュールのスロットル: 同じリージョンで同時にメンテナンスを予定しているサーバーが多すぎる場合、再スケジュールの要求が失敗することがあります。 このエラーが発生した場合は、別のタイム スロットを選択するよう勧めるエラー通知が表示されます。 正常に再スケジュールされたメンテナンスは、通常、キャンセルになることはありません。
メンテナンス イベントを再スケジュールできる回数に制限はありません。 メンテナンス イベントが 準備 中状態に入っていない限り、いつでも別の時刻にスケジュールを変更できます。
メンテナンス ロールアウトの進行状況ビュー (パブリック プレビュー)
各メンテナンス イベントには 、追跡 ID が含まれています。 この ID をクリックすると、同じメンテナンス ロールアウトの一部であるサブスクリプション内のすべてのサーバーの詳細ビューが開きます。 これにより、各サーバーを個別に確認したり、電子メール通知のみに依存したりする必要なく、フリート全体の統合された概要が得られます。
メンテナンスが保留中か既に完了しているかに関係なく、追跡 ID ビューにいつでもアクセスできます。
スケジュールされたメンテナンス イベントに関する通知
Azure Service Health を使用すると、Azure Database for MySQL フレキシブル サーバー インスタンスでの、これから、および実行済みの予定メンテナンスに関する通知を確認できます。 また、Azure Service Health でアラートを設定して、メンテナンス イベントに関する通知を受け取ることもできます。