Azure Database for MySQL Flexible Server でポイントインタイム復元を実行した際に「ProvisioningDisabled」で失敗する――クラウド運用では珍しくない落とし穴です。本記事では、原因の本質（リージョン側の容量制限）と、最短で復旧するための現実的な打ち手、サポート申請時のコツ、再発を防ぐための設計・監視までを一気通貫で解説します。現場で使えるチェックリストとコマンド例も用意しました。
エラーの現象と再現条件
同一リージョン内でバックアップのポイントインタイム復元（PITR: Point-in-Time Restore）を「新しいサーバーに復元」で実行すると、以下のように失敗します。
status : Failed
code : ProvisioningDisabled
message : Provisioning is restricted in this region.
Please choose a different region. For exceptions to this rule
please open a support request with Issue type of
'Service and subscription limits'. （URL省略）
このメッセージは「そのリージョンで新規の MySQL Flexible Server を作る行為が、一時的に制限されている」ことを意味します。PITR は内部的に “新規インスタンスの作成＋対象時点のデータ適用” として実行されるため、新規プロビジョニングがブロックされると復元も巻き添えで失敗します。
根本原因：リージョンの容量制限（キャパシティ制限）
Azure のマネージド データベースは、リージョンごとに確保された基盤リソース（計算・ストレージ・ネットワーク）上で提供されています。特定リージョンにおいて需要が急増したり、計画的なリソース切替や障害の影響で一部のコンピュート系 SKU が逼迫すると、プラットフォーム側で 新規プロビジョニングを一時停止 することがあります。これが ProvisioningDisabled の正体です。
- 影響範囲の特徴：すべてのサーバー作成が止まる場合もあれば、特定のサービス層（Burstable / General Purpose / Business Critical）や特定 vCore 帯のみ制限されるケースもあります。
- 既存サーバーへの影響：既存サーバーの稼働は継続しますが、スケールアップや HA 構成変更など「新しい基盤リソースの確保」を伴う操作は同様に制限される可能性があります。
- PITR が失敗する理由：PITR は「新しいサーバーに復元」＝新規作成と同義であるため、制限に引っかかります。
まず確認：誤診を避けるためのクイックチェック
同じエラーでも、実は別の条件ミスが原因ということがあります。無駄な往復を避けるため、以下の観点を最初に確認しましょう。
| 観点 | 確認ポイント | 補足/コマンド例 |
|---|---|---|
| 復元可能な時刻か | 保持期間内か／earliestRestoreDate 以降か | az mysql flexible-server show --name <src> -g <rg> --query "earliestRestoreDate" -o tsv |
| 同一リージョン指定 | 復元先リージョンが想定と一致しているか | ポータル/CLI のパラメータを再確認 |
| SKU/ティア | 制限対象のティア・vCore を選んでいないか | az mysql flexible-server list-skus -l <region>（提供 SKU の確認） |
| ネットワーク前提 | VNet 統合やプライベート DNS ゾーン設定の整合 | 復元後に再構成が必要な場合あり（後述） |
| RBAC/権限 | サブスクリプションでリソース作成権限があるか | ロール割り当てを確認（Owner/Contributor など） |
解決策（公式＋実務のコツ）：クォータ/容量の拡張申請
プラットフォーム都合の容量制限は、サポート経由のクォータ調整で解除（または例外許可）されるのが王道です。ポータルでの申請フローは次のとおりです。
| 手順 | 操作内容 |
|---|---|
| 1 | Azure ポータルで「サポート + トラブルシューティング」→ 新しいサポート要求 を開く |
| 2 | 検索ボックスに quota と入力し、カテゴリ その他 / サービスとサブスクリプションの制限 (クォータ) を選択 |
| 3 | Issue type: Service and subscription limits (quotas) Quota type: Azure Database for MySQL Flexible Server |
| 4 | 「追加の詳細」で リージョン（Location）、サービス層（Burstable / General Purpose / Business Critical）、必要 vCore 数 を記載 |
| 5 | 申請 → 数分で自動受付メール、通常は数時間〜1営業日で審査・拡張 |
| 6 | 承認後、同リージョンで再度 PITR を実行 |
申請時に記載すると通りやすい情報のテンプレート
- サブスクリプション ID／課金アカウント
- 対象リージョン（例：Japan East）
- サービス層（例：General Purpose）と vCore 数（例：8 vCores × 1 台）
- 必要となる理由（本番障害復旧／期限付きテスト等）と希望時期
- 短期的な暫定でも可か（「まず 4 vCores で作成し、後で 8 vCores に増強可」等）
- 想定 IOPS／接続数など、負荷の目安（任意）
ポイント：制限は SKU 単位であることも多く、「まず小さめ（または別ティア）で復元 → 後でスケールアップ」という妥協案が通る場合があります。
緊急時の回避策：業務を止めないための現実解
クォータ承認を待っていられない場合の選択肢を、実装のコツとともにまとめます。
別リージョンに一時復元（ジオリストア）
サーバー作成時に Geo 冗長バックアップ を有効化している環境では、別リージョンへ復元（ジオリストア）が可能です。復元後にアプリの接続先を切替え、落ち着いたら元リージョンへ再移行します。
| 手順の要点 | 実務のヒント |
|---|---|
| 復元先リージョンを選定 | レイテンシ・コスト・運用体制（監視/バックアップ連携）を考慮 |
| ネットワーク接続確保 | プライベート エンドポイント／DNS ゾーン連携を復元先で迅速に用意 |
| アプリ切替 | 接続文字列（ホスト名/ポート/SSL）を構成管理で即時に反映 |
| 後片付け | 元リージョンの容量復旧後に逆向き移行、課金最適化 |
注意：Geo 冗長を有効化していないサーバーは、ジオリストアを利用できません。今後に備えて設計段階で有効化を検討してください。
SKU/ティアを変えて一時復元
同リージョンでも、逼迫していない SKU/ティア を選べば復元できることがあります。例えば、大きめの vCore 帯が詰まっている場合は一旦小さめで復元→業務を再開→後日スケールアップという流れです。I/O が足りない場合はストレージ IOPS の上げ幅で緩和できるケースもあります。
読み取り専用レプリカ経由の一時運用
事前に別リージョンへレプリカを構成していれば、プライマリ障害時に アプリをレプリカへ誘導 することで業務継続できます。最終手段としてレプリカを昇格（手動）して独立運用に切替える選択肢もあります。
承認後に行う実作業：PITR の正しい手順
ポータルでの流れ
- ソース サーバーを開く → 復元 → ポイントインタイム復元 を選択
- 復元時刻（UTC）を指定し、新しいサーバー名 と コンピュート/ストレージ を設定
- ネットワーク設定（公開/プライベート、VNet/サブネット、プライベート DNS ゾーン）を確認
- 作成 → 完了後に接続疎通（TLS/証明書/ファイアウォール）をチェック
CLI 例（Azure CLI）
# 復元可能な最古の時刻を確認（UTC）
az mysql flexible-server show \
--name <source-server> \
--resource-group <rg> \
--query "earliestRestoreDate" -o tsv
# 指定時刻へポイントインタイム復元（同一リージョン）
az mysql flexible-server restore
--name
--resource-group
--source-server
--restore-time "2025-11-03T08:15:00Z"
# Geo 冗長バックアップ有効時に別リージョンへ復元する例（必要に応じて）
az mysql flexible-server restore
--name
--resource-group
--source-server
--restore-time "2025-11-03T08:15:00Z"
--location 復元後に必ず行う整備
| 項目 | 確認/対応内容 | 備考 |
|---|---|---|
| 接続方式 | プライベート/パブリック、必要なファイアウォール規則の設定 | 新サーバーで再構成が必要な場合あり |
| DNS/接続文字列 | アプリの接続先を新サーバー FQDN へ切替 | 構成管理で一括反映、ロールバック手順も定義 |
| TLS/証明書 | 必須バージョン、サーバー CA 更新の有無 | クライアント側信頼ストアを更新 |
| パラメータ | サーバー パラメータ（例：innodb、max_connections）差分の適用 | テンプレート化がおすすめ |
| バックアップ方針 | 保持期間、冗長性（ローカル/ゾーン/Geo）の見直し | 今後のジオリストア可否に直結 |
| 監視/アラート | メトリック・ログ・クエリ監視・異常検知ルール | 接続失敗率・CPU/IOPS・スロークエリなど |
「容量不足」でも状況を打開する 3 つのテクニック
- スケール段階戦略：まず vCore を抑えた SKU で復元し業務再開、夜間に段階的スケールアップ。性能不足は ストレージ IOPS/スループット強化 と SQL チューニングで一時吸収。
- ワークロード分割：読み取りが多いシステムなら、復元直後はリード系機能を 読み取り専用レプリカ へ逃がして負荷平準化。
- 一時的フェイルオーバー：別リージョン復元を 一次系 に昇格し、本番トラフィックを切替。元リージョンの容量回復後に再移行。
よくある落とし穴と対処
- UTC の取り違え：PITR の時間指定は UTC。アプリの障害発生時刻（JST 等）からの変換を誤ると、欲しいデータが入らない。
- ネットワーク継承の思い込み：復元サーバーに 同一の VNet/プライベートDNS 設定が自動で付くとは限らない。作成ウィザードで明示する。
- ユーザー/権限の差分：MySQL ユーザー/権限は復元時点の状態に戻る。直近の追加ユーザーが消えたように見えるのは仕様。
- バックアップ保持の過信：保持期間を短くしていたため、必要な時点がもう復元できない。定期的に保持期間と業務 RPO を擦り合わせる。
- スケール失敗の二次災害：容量制限下では復元後の スケールアップも失敗 し得る。最初の SKU 設計が重要。
- アプリ側タイムアウト：切替直後は接続プールの古いソケットでエラーが続く。ヘルスチェックとプール再生成を実装。
- 監査ログの取りこぼし：監査/診断設定が新サーバーに反映されず、監査空白期間が生じる。テンプレート適用を習慣化。
- コスト膨張：緊急回避で大きめ SKU を選びっぱなし。安定後はダウンサイジング計画を。
再発防止：キャパシティ制限に強い設計と運用
設計の原則
- Geo 冗長バックアップの活用：有効化しておけば、別リージョン復元の選択肢を確保できます。
- アプリのリージョン可搬性：接続文字列を構成で外出し、DNS CNAME や Feature Flag で瞬時に切替可能に。
- 読み取り分離アーキテクチャ：リードレプリカやキャッシュ層（App 内キャッシュ/分散キャッシュ）でピーク耐性を確保。
- IaC（Infrastructure as Code）：VNet/Private Endpoint/診断設定/警告ルールを Bicep/ARM/Terraform でテンプレート化。
運用と監視
- サブスクリプションの「使用量 + クォータ」監視：定期点検し、上限に近づいたら自動通知。
- Azure Service Health の活用：対象サービス/リージョンのサービス問題・計画メンテナンスにアラート。
- 定期的な DR ドリル：四半期ごとに「PITR 実演」「別リージョン復元」「アプリ切替」を台本化して検証。
- 容量サインの見える化：復元失敗・スケール失敗のイベントを Log Analytics に集約し、可視化/通知。
コマンド実用集（現場メモ）
# 提供 SKU の確認（参考：提供可否。実容量は別要因で制限されうる）
az mysql flexible-server list-skus -l <region> -o table
# 復元可能な最古の時刻（UTC）
az mysql flexible-server show
--name
--resource-group
--query "earliestRestoreDate" -o tsv
# ポイントインタイム復元（同一リージョン）
az mysql flexible-server restore
--name
--resource-group
--source-server
--restore-time "YYYY-MM-DDTHH:MM:SSZ"
# 復元後の基本疎通（例：SSL 必須）
mysql -h .mysql.database.azure.com -u @ -p
--ssl-mode=REQUIRED メリット・デメリット（今回の公式解決策）
| 項目 | 内容 |
|---|---|
| メリット | 既存リージョンに留まったまま復元でき、ネットワークやレイテンシの前提を崩さずに済む |
| デメリット | クォータ申請〜承認に時間がかかる場合があり、超短時間での復旧には不向き |
ケーススタディ：本番障害時の実運用シナリオ
以下は、平日昼間のプライマリ障害、同一リージョンで ProvisioningDisabled が発生した想定の標準台本です。
- アプリを リードレプリカ（同/別リージョン） に暫定誘導し、読み取り系を再開。
- 同時に クォータ拡張を即申請。申請時刻と事象の緊急度を明記。
- Geo 冗長バックアップが有効なら、別リージョンに PITR 復元 → 書き込み系も移行。
- 元リージョンの容量回復または拡張承認後、逆向き移行 を計画停止時間内に実施。
- 恒久対策として、Geo 冗長化・IaC・監視アラート を整備し、次回からは自動化比率を上げる。
FAQ
Q1：容量制限中でも既存サーバーのスケールは可能？
場合によっては不可です。新しい基盤リソース割り当てが必要なスケール操作は制限されることがあります。業務継続を優先するなら、まずは別リージョン復元や小さめ SKU での一時復元を検討してください。
Q2：いつまで制限が続くの？
プラットフォーム事情に依存します。クォータ申請で個別に例外許可が得られるケースが多く、最も早い解決策になりやすいです。
Q3：復元先サーバーはすべての設定がコピーされる？
データベース データと主要なサーバー設定は時点復元されますが、ネットワーク/接続関連（VNet、プライベート DNS、ファイアウォール）などは再構成が必要な場合があります。
Q4：別リージョン復元のコストは？
コンピュート/ストレージ/送受信データ量に応じた課金が発生します。緊急対応後はダウンサイジングや停止・削除で最適化しましょう。
結論
ProvisioningDisabled は、Azure 側のリージョン容量制限に起因する「新規プロビジョニング不可」状態であり、PITR が失敗するのは仕様です。最短の王道は サポートへのクォータ拡張申請。同時に、別リージョン復元（Geo 冗長バックアップ） や SKU 変更での一時復元 といった運用回避策を準備しておけば、ダウンタイムを最小化できます。さらに、クォータ監視・Service Health アラート・DR ドリル・IaC の整備で再発に強い体制を作ることが、クラウド時代のデータベース運用における最良の保険です。
付録：申請フォーム記入例（コピーして使えます）
【Issue type】Service and subscription limits (quotas)
【Quota type】Azure Database for MySQL Flexible Server
【Subscription】<サブスクリプション名/ID>
【Region】Japan East
【Tier / vCores】General Purpose / 8 vCores を 1 台（合計 8 vCores）
【Reason】本番障害復旧のため、PITR による新規サーバー作成が必要。
【When】可能な限り至急（本日中）
【Note】暫定的に 4 vCores での作成でも可、後日 8 vCores へ拡張予定
要点サマリ
- エラー
ProvisioningDisabledはリージョンの容量制限が原因。 - PITR は内部的に「新規インスタンス作成」＝制限の対象。
- 解決は クォータ拡張の申請。承認後に復元を再実行。
- 急ぎは 別リージョン復元 または SKU 変更で一時復元 が有効。
- クォータ監視・Service Health・DR ドリルで再発耐性を高める。
コメント