Azure Database for MySQL は、マネージド データベースをセキュリティで保護され、安定した最新の状態に保つために、定期的なメンテナンスを実行します。 メンテナンス中に、サーバーでは新しい機能、更新プログラム、パッチが取得されます。
重要
Azure Database for MySQL のメンテナンス中に、すべてのサーバー操作 (変更、構成の変更、開始/停止) を回避します。 これらのアクティビティに関与すると、サーバーのパフォーマンスと安定性に影響を与える可能性のある予期しない結果につながる可能性があります。 メンテナンスが終了するまで待ってから、サーバー操作を実行してください。
メンテナンス サイクル
以降のセクションでは、メンテナンスの種類について説明します。 各メンテナンス更新プログラムに必要な内容の詳細については、リリース ノートを参照してください。 これらのメモは、メンテナンス中に適用される更新プログラムに関する包括的な情報を提供します。これにより、環境に影響を与える変更を理解し、準備することができます。
注
スケジュールされた更新中に、すべてのサーバーが必ずしもメンテナンスを受けるわけではありません。これは、ルーチンでもクリティカルでもです。 Azure MySQL チームは、特定の基準を使用してメンテナンスが必要なサーバーを特定します。 この選択的アプローチにより、メンテナンスが効率的で不可欠であり、各サーバー環境の固有のニーズに合わせて調整され、運用のダウンタイムを最小限に抑えることができます。
定期メンテナンス
当社の標準的なメンテナンスサイクルは、30日ごとに最低1回行われます。 この期間は、サービスの中断を最小限に抑えながら、システムの安定性とパフォーマンスを確保するのに役立ちます。
重要なメンテナンス
可用性とデータの整合性を維持するために重要な緊急のセキュリティ修正プログラムや更新プログラムを展開する必要がある場合など、特定のシナリオでは、メンテナンスがより頻繁に行われる場合があります。 これらの例外は、データを保護し、サービスの継続的な運用を保証するのに役立ちます。
仮想カナリア メンテナンス
Virtual Canary は、更新プログラムへの早期アクセスを提供する試験的なメンテナンス プログラムです。 これにより、お客様は新しい Azure Database for MySQL バージョンとのワークロードの互換性をテストし、新機能に関するフィードバックを提供できます。
定期的なメンテナンスとは異なり、Virtual Canary は 30 日間の最小ギャップまたは 7 日間の通知期間に従いません。 このプログラムは、お客様が新しい機能を事前に検証し、製品改善のための早期フィードバックを提供するのに役立ちます。 非運用環境でよく使用されるバースト可能レベルのサーバーは、Virtual Canary プログラムに自動的に登録されます。
Virtual Canary 登録
Azure Database for MySQL を使用することで、お客様は Virtual Canary プログラムへの参加を柔軟に管理できます。 お客様は、必要に応じて、運用要件に合わせてプログラムをオプトインまたはオプトアウトできます。
サーバーが Virtual Canary プログラムに登録されているかどうかを確認するには、次のコマンドを使用します。 結果に "patchStrategy": "VirtualCanary"が含まれている場合、サーバーはプログラムに登録されます。
az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"
Virtual Canary プログラムにサーバーを登録するには、次のコマンドを実行します。
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
Virtual Canary プログラムを終了し、標準メンテナンス ポリシーに戻すには、次のコマンドを使用します。
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular
メンテナンス期間
特定の曜日とその日の時間帯の間でのメンテナンスをスケジュールできます。 また、システムで自動的に曜日と時間帯が選択されるようにすることもできます。 いずれの場合も、メンテナンスが実行される 7 日前にシステムから警告が表示されます。 また、メンテナンスがいつ開始され、正常に完了するかを通知します。
今後の予定メンテナンスについて、次のように通知できます。
- 特定のアドレスにメールで送信する。
- Azure Resource Manager のロールにメールで送信する。
- テキスト メッセージ (SMS) でモバイル デバイスに送信されます。
- Azure アプリに通知としてプッシュする。
- 音声メッセージとして配信する。
メンテナンス スケジュールの設定を指定する場合は、曜日と時間枠を選択できます。 ユーザー設定を指定しない場合、システムはサーバーのリージョン時間の午後 11 時から午前 7 時の間の時刻を選択します。 Azure サブスクリプションのフレキシブル サーバーごとに異なるスケジュールを定義できます。
スケジュール設定はいつでも更新できます。 フレキシブル サーバーのメンテナンスがスケジュールされていて、スケジュール設定を更新すると、現在のロールアウトはスケジュールどおりに進みます。 スケジュール設定の変更は、次回のスケジュールされたメンテナンスが正常に完了すると有効になります。
Azure サブスクリプション内のフレキシブル サーバーごとに、システム管理のスケジュールまたはカスタム スケジュールを定義できます。
- カスタム スケジュールでは、曜日と 1 時間の時間枠を選択して、サーバーのメンテナンス期間を指定できます。
- システムが管理するスケジュールでは、システムは、サーバーのリージョン時間の午後 11 時から午前 7 時までの任意の 1 時間の時間枠を選択します。
重要
2024 年 8 月 31 日の時点で、Azure Database for MySQL では、Burstable 層インスタンスのカスタム メンテナンス期間はサポートされなくなりました。 この変更は、メンテナンス プロセスを簡素化し、最適なパフォーマンスを確保するのに役立ちます。 また、バースト対応のサービス階層でカスタムメンテナンス期間を使用するユーザーの数が少ないことも分析で示されました。
カスタム メンテナンス期間を設定している既存のバーストブルインスタンスは影響を受けません。 ただし、ユーザーはカスタム メンテナンス期間に対してこれらの設定を変更できなくなりました。
カスタム メンテナンス期間が必要な場合は、General Purpose レベルまたは Business Critical レベルにアップグレードすることをお勧めします。
まれに、システムによってメンテナンス イベントが取り消されたり、正常に完了できなかったりすることがあります。 メンテナンス イベントが失敗した場合、更新プログラムは元に戻され、以前のバージョンのバイナリが復元されます。 更新が失敗した場合でも、メンテナンス期間中にサーバーの再起動が発生する可能性があります。
メンテナンス イベントが取り消されたか失敗した場合、システムから通知が送信されます。 次にメンテナンスを実行する試みは、現在の設定に従ってスケジュールされます。 5 日前に次の試行に関する通知を受け取ります。
ほぼゼロダウンタイムのメンテナンス (プレビュー)
Azure Database for MySQL の ほぼダウンタイムなしのメンテナンス 機能は、高可用性サーバーの画期的な開発です。 この機能は、メンテナンスのダウンタイムを大幅に削減するように設計されています。 この機能は、高可用性とデータベース操作の中断を最小限に抑える必要がある企業にとって極めて重要です。
ダウンタイムの正確な予測
- ダウンタイム期間: ほとんどの場合、メンテナンス中のダウンタイムの範囲は 10 ~ 30 秒です。
- 追加の考慮事項: フェールオーバー イベントの後、DNS の有効期間 (TTL) 期間は約 30 秒です。 この期間はメンテナンス プロセスによって直接制御されませんが、DNS 動作の標準の部分です。 そのため、顧客の観点から見ると、メンテナンス中に発生したダウンタイムの合計は 40 ~ 60 秒になる可能性があります。
条件と制限事項
この機能が提供する最適なパフォーマンスを実現するには、次の条件と制限事項に注意してください。
- すべてのテーブルの主キー: すべてのテーブルに主キーがあることを確認することが重要です。 主キーが不足すると、レプリケーションの遅延が大幅に増加し、ダウンタイムに影響を与える可能性があります。
- メンテナンス時間中のワークロードが少ない: ダウンタイムを最小限に抑えるために、メンテナンス期間はサーバーのワークロードが少ない時間と一致する必要があります。 カスタム メンテナンス期間を使用して、ピーク外の時間帯にメンテナンスをスケジュールすることをお勧めします。
- ダウンタイムの保証: メンテナンスのダウンタイムを可能な限り低く保つように努めていますが、すべての状況で 60 秒未満になるとは限りません。 高いワークロードや特定のサーバー構成など、さまざまな要因によってダウンタイムが増加する可能性があります。 最悪のシナリオでは、ダウンタイムがスタンドアロン サーバーの場合に近くなる可能性があります。
メンテナンスの再スケジュール
メンテナンスの再スケジュール機能を使用すると、Azure Database for MySQL フレキシブル サーバーでのメンテナンス アクティビティのタイミングをより詳細に制御できます。 メンテナンス通知を受け取った後は、システム管理またはカスタム管理のいずれであったかにかかわらず、より便利な時間にスケジュールを変更できます。
重要なデータベース操作中の中断を回避するには、この機能を使います。 この機能は引き続き開発を行っているため、ぜひフィードバックをお寄せください。
パラメーターと通知の再調整
再スケジュールは、固定タイム スロットに限定されません。 これは、現在のメンテナンス サイクルで許容される最も早い時間と最新の時間によって異なります。 通常、このサイクルは、リージョンのメンテナンス期間の最初の日から最後の日までにわたって行われます。 スケジュールを変更すると、標準の通知ポリシーに従って変更を確認する通知が表示されます。
考慮事項と制限事項
この機能に関する次の点に注意してください。
- レベルの可用性: バースト可能なコンピューティング レベルでは、メンテナンスの再スケジュールは使用できません。 この機能は運用環境のサーバーを対象としていますが、Burstable レベルは非運用環境向けに設計されています。
- 需要の制約: 同じリージョンで多数のメンテナンス アクティビティが同時に発生した場合、再スケジュールされたメンテナンスが取り消される可能性があります。
- ロックイン期間: サービスの信頼性を維持するために、最初に予定された保守時間の15分前には再スケジュールはできません。
- 再スケジュール制限: 同じリージョン内で同時にメンテナンスを予定しているサーバーが多すぎる場合、再スケジュールの要求が失敗する可能性があります。 このエラーが発生した場合は、別のタイム スロットを選択するよう勧めるエラー通知が表示されます。 正常に再スケジュールされたメンテナンスは、通常、キャンセルになることはありません。
メンテナンス イベントを再スケジュールできる回数に制限はありません。 メンテナンス イベントが 準備 中状態に入っていない限り、いつでも別の時刻にスケジュールを変更できます。
注
潜在的な調整に対応するために、プレビュー 段階で通知を注意深く監視することをお勧めします。
よく寄せられる質問
一部のサーバーがメンテナンス通知を受け取ったのに、他のサーバーが受信しなかったのはなぜですか?
メンテナンスの開始時刻はリージョンによって異なります。 異なるリージョン内のサーバーは、異なる時刻にメンテナンス通知を受け取る場合があります。
同じリージョン内の一部のサーバーがメンテナンス通知を受け取ったのに、他のサーバーが受信しなかったのはなぜですか?
通知を受信しなかったサーバーが最近作成され、システムでまだメンテナンスが必要ないと判断された可能性があります。
スケジュールされたメンテナンスをオプトアウトできますか?
いいえ。スケジュールされたメンテナンスのオプトアウトは許可されません。 ただし、メンテナンスの再スケジュール機能を使用してタイミングを調整できます。 または、高可用性機能を有効にしてダウンタイムを最小限に抑えることができます。 Azure Database for MySQL はサービスとしてのプラットフォーム (PaaS) データベース製品であるため、タイムリーなメンテナンスを実行すると、データベースのセキュリティと信頼性が確保されます。