Azure SQL データベースのメンテナンス期間
適用対象:
Azure SQL Database
メンテナンス期間機能を使用すると、Azure SQL Database と Azure SQL Managed Instance リソースのメンテナンス スケジュールを構成して、影響のあるメンテナンス イベントを予測可能にし、ワークロードの中断を減らすことができます。
Note
メンテナンス期間機能では、アップグレードや予定メンテナンスから見込まれる予定される影響のみを防ぎます。 フェールオーバーのあらゆる原因を防ぐことはありません。メンテナンス期間の外で短い接続中断を引き起こしうる例外には、ハードウェア障害、クラスターの負荷分散、データベースの Service Level Objective の変更などのイベントに起因するデータベース再構成などがあります。
事前通知は、既定以外のメンテナンス期間を使用するように構成されたデータベースで使用できます。 事前通知を使用すると、顧客は、計画されたイベントの 24 時間前までに通知が送信されるように構成できます。
概要
Azure では、SQL Database リソースの計画メンテナンスを定期的に実行します。 Azure SQL メンテナンス イベントの間、データベースは完全に利用可能ですが、SQL Database と SQL マネージド インスタンスのそれぞれの可用性サービス レベル アグリーメント (SLA) SQL Database 内で短時間の再構成が行われる可能性があります。
メンテナンス期間は、データベースの再構成に対して回復性がなく、計画メンテナンス イベントによる短時間の接続中断を許容できない運用環境のワークロードを対象としています。 希望するメンテナンス期間を選択することで、計画メンテナンスの影響を最小限に抑えることができます。それが営業時間のピーク時以外に行われるためです。 回復性があるワークロードと非運用環境ワークロードは、Azure SQL の既定のメンテナンス ポリシーに依存できます。
メンテナンス期間は無料で、作成時に構成することも、既存の リソースに対して構成することもできます。 これは、Azure portal、PowerShell、CLI、または Azure API を使用して構成できます。
重要
メンテナンス期間の構成は、Azure SQL リソースのサービス レベルの変更と同様に、時間のかかる非同期操作です。 操作の終了時に発生する短い再構成を除いて、操作中にリソースを使用できます。これは、長時間のトランザクションが中断された場合でも、通常は最大 8 秒です。 再構成の影響を最小限に抑えるには、ピーク時以外に操作を実行する必要があります。
メンテナンス期間の予測可能性を高める
既定では、Azure SQL のメンテナンス ポリシーは、一般的な営業時間のピーク時の中断を回避するために、毎日現地時刻で午前 8 時から午後 5 時までの間、最も影響のある更新をブロックします。 現地時刻は、リソースをホストする Azure リージョンの場所によって決定され、ローカル タイム ゾーンの定義に従って夏時間が適用される場合があります。
メインテナント中は、データベースメイン再び使用可能になりますが、一部の更新ではフェールオーバーが必要になる場合があります。 システムの既定のメインテナント ウィンドウ (午後 5 時から午前 8 時) は、ほとんどのアクティビティをこの時間に制限しますが、緊急の更新がそれ以外で発生する可能性があります。 メインテナント ウィンドウ内でのみすべての更新が行われるようにするには、既定以外のオプションを選択します。
次の 2 つの追加メンテナンスウインドウスロットから選択することにより、メンテナンスの更新をウインドウを Azure SQL リソースに適した時間に調整できます。
- 平日 のウィンドウ: 現地時間の午後 10:00 から午前 6:00、月曜日から木曜日
- 週末 のウィンドウ: 現地時間の午後 10:00 から午前 6:00、金曜日から日曜日
一覧リストされているメンテナンスウィンドウの日数は、各 8 時間のメンテナンス時間の開始日を示します。 たとえば、"10:00 PM to 6:00 AM local time, Monday – Thursday" は、メンテナンス期間が毎日 (月曜日から木曜日) の現地時刻の午後 10:00 に開始され、次の日 (火曜日から金曜日) の現地時刻の午前 6 時に完了します。
メンテナンス期間を選択し、サービスの構成が完了すると、計画メンテナンスは、選択した期間中のみ行われます。 通常、メンテナンス イベントは 1 つの期間内で完了しますが、一部のイベントは 2 つ以上の隣接する期間にまたがる場合があります。
Note
Azure SQL データベースは、Azure ペア リージョンが同時にデプロイされないことを保証する安全なデプロイ プラクティスに従います。 ただし、最初にアップグレードされるリージョンを予測することはできないため、デプロイの順序は保証されません。 プライマリ データベースが最初にアップグレードされる場合もあれば、セカンダリが最初になる場合もあります。
- データベースで geo レプリケーションまたはフェールオーバー グループが有効になっており、geo レプリケーションが Azure リージョンのペアリングと一致しない場合、プライマリ データベースとセカンダリ データベースに対して異なるメンテナンス期間のスケジュールを設定する必要があります。 たとえば、geo セカンダリ データベースのメンテナンス期間には [平日] を選択し、geo プライマリ データベースのメンテナンス期間には [週末] を選択できます。
重要
重要なセキュリティ パッチの適用など、アクションの延期によって重大な影響が生じる可能性がある非常にまれな状況では、構成されたメンテナンス期間が一時的にオーバーライドされることがあります。
事前通知
メンテナンス通知は、今後予定されている Azure SQL Database のメンテナンスイベントを通知するように構成できます。 アラートは、24 時間前、メンテナンス期間が始まる前、そしてメンテナンス期間の終了時に届きます。 詳しくは、「事前通知」をご覧ください。
使用可能な機能
サポートされているサブスクリプションの種類
メンテナンス期間の構成と使用は、従量課金制、クラウド ソリューション プロバイダー (CSP)、マイクロソフトエンタープライズ契約、または Microsoft 顧客契約のプランの種類で使用できます。
開発やテストの使用に限定されたプランは対象外です (開発テスト用の従量課金制プランや Enterprise Dev/Test など)。
Note
Azure オファーとは、ご利用の Azure サブスクリプションの種類です。 たとえば、従量課金制料金、Azure イン オープン プラン、および Visual Studio Enterprise のサブスクリプションはすべて Azure プランです。 オファーまたはプランごとに、使用条件と利点は異なります。 オファーまたはプランは、サブスクリプションの概要に表示されます。 サブスクリプションを別のオファーに変更する方法について詳しくは、「Azure サブスクリプションを別のオファーに変更する」を参照してください。
サポートされるサービス レベル目標
既定以外のメンテナンス期間は、すべての SLO で選択できますが、次の場合を除きます。
- SLO はサポートされていません。
- Azure SQL Database DTU Basic、S0、S1 レベル
- DC ハードウェア
- Fsv2 ハードウェア
Hyperscale エラスティック プールのメンテナンス期間はプレビュー段階であり、特定のリージョンと構成で利用できます。 詳細については、「ブログ: Azure SQL Database Hyperscale エラスティック プールのメンテナンス期間のサポート」を参照してください。
メンテナンス期間に対する Azure SQL データベース リージョンのサポート
既定以外の Azure SQL データベース のメンテナンス期間は、現在、購入モデルごとに次のリージョンで選択できます。
次の表は、ゾーン冗長ではないデータベースを対象としています。 Azure Availability Zones 内のデータベースについては、ゾーン冗長データベースの表を参照してください。
| Azure リージョン | Hyperscale Premium シリーズと Premium シリーズのメモリ最適化 | Hyperscale Standard シリーズ | その他のすべての Azure SQL データベースの購入モデルとリソース |
|---|---|---|---|
| オーストラリア東部 | はい | イエス | はい |
| オーストラリア南東部 | はい | はい | |
| ブラジル南部 | はい | はい | |
| ブラジル南東部 | はい | はい | |
| カナダ中部 | はい | イエス | はい |
| カナダ東部 | はい | Yes | |
| インド中部 | Yes | はい | |
| 米国中部 | はい | イエス | はい |
| 中国東部 2 | はい | はい | |
| 中国北部 2 | はい | はい | |
| 米国東部 1 | はい | イエス | はい |
| 米国東部 2 | はい | イエス | はい |
| 東アジア | はい | はい | |
| フランス中部 | はい | はい | |
| フランス南部 | はい | はい | |
| ドイツ中西部 | はい | はい | |
| 東日本 | はい | イエス | はい |
| 西日本 | はい | はい | |
| 米国中北部 | はい | はい | |
| 北ヨーロッパ | はい | イエス | イエス |
| 南アフリカ北部 | イエス | イエス | |
| 米国中南部 | はい | イエス | はい |
| インド南部 | はい | はい | |
| 東南アジア | はい | はい | |
| スイス北部 | はい | はい | |
| アラブ首長国連邦北部 | はい | はい | |
| 英国南部 | はい | イエス | はい |
| 英国西部 | はい | はい | |
| US Gov テキサス | はい | はい | |
| US Gov バージニア州 | Yes | はい | |
| 米国中西部 | はい | はい | |
| 西ヨーロッパ | はい | イエス | はい |
| 米国西部 | はい | イエス | はい |
| 米国西部 2 | はい | イエス | はい |
| 米国西部 3 | はい | イエス | イエス |
次の表は、ゾーン冗長データベースを対象としています。
| Azure リージョン | Hyperscale Premium シリーズと Premium シリーズのメモリ最適化 | Hyperscale Standard シリーズ | その他のすべての Azure Availability Zones 内 Azure SQL データベースの購入モデルとリソース |
|---|---|---|---|
| オーストラリア東部 | はい | イエス | はい |
| カナダ中部 | はい | イエス | はい |
| 米国中部 | はい | イエス | イエス |
| 米国東部 1 | イエス | イエス | はい |
| 米国東部 2 | はい | ||
| 東日本 | はい | ||
| 北ヨーロッパ | はい | イエス | イエス |
| 米国中南部 | イエス | ||
| 東南アジア | イエス | ||
| 英国南部 | イエス | ||
| 西ヨーロッパ | はい | イエス | はい |
| 米国西部 2 | はい | ||
| 米国西部 3 | はい | イエス | イエス |
ゲートウェイのメンテナンス
メンテナンス期間の最大のメリットを得るには、クライアント アプリケーションでリダイレクト接続ポリシーを使用していることが必要です。 リダイレクトは推奨の接続ポリシーであり、このときクライアントはデータベースをホストしているノードへの直接接続を確立します。これにより、待機時間が短縮され、スループットが向上します。
Azure SQL Database では、プロキシ接続ポリシーを使用した接続は、選択したメンテナンス期間とゲートウェイ ノードのメンテナンス期間の両方の影響を受ける可能性があります。 ただし、推奨のリダイレクト接続ポリシーを使用したクライアント接続であれば、ゲートウェイ ノードのメンテナンス再構成の影響を受けません。
Azure SQL Database でのクライアント接続ポリシーについて詳しくは、Azure SQL Database の接続ポリシーに関するページをご覧ください。
メンテナンス イベントの一覧の取得
Azure Resource Graph は、Azure Resource Management を拡張するように設計された Azure サービスです。 Azure Resource Graph Explorer は、効率的でパフォーマンスの高いリソース探索を提供し、環境を効果的に管理できるように、特定のサブスクリプションのセットにわたって大規模なクエリを実行する機能を備えています。
Azure Resource Graph Explorer を使用して、メンテナンス イベントのクエリを実行できます。 これらのクエリを実行する方法の概要については、「クイック スタート: Azure Resource Graph Explorer を使用して最初の Resource Graph クエリを実行する」を参照してください。
サブスクリプション内のすべての SQL データベースのメンテナンス イベントを確認するには、Azure Resource Graph Explorer で次のサンプル クエリを使用します。
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
サンプル クエリの完全なリファレンスと、PowerShell や Azure CLI など、ツール間でそれらを使用する方法については、「Azure Service Health 用の Azure Resource Graph サンプル クエリ」を参照してください。
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示