Azure Database for PostgreSQL フレキシブル サーバーがポータルで「Starting（起動中）」のまま固まり、停止も再起動も効かない――そんなときは、設定ミスよりもプラットフォーム側の状態不整合が原因になっているケースがあります。本記事では実例をもとに、確認すべきポイントと、Developer プランでも復旧につなげるエスカレーション手順を整理します。
症状：ポータルが「Starting」から進まず、停止コマンドも効かない
このトラブルは、次のような形で現れます。
- Azure ポータルで PostgreSQL フレキシブル サーバーがずっと「Starting（起動中）」表示のまま
- 「停止」「起動」「再起動」を押しても状態が変化しない（操作を受け付けたように見えるだけ）
- Azure CLI から stop / start / restart を実行しても状態が変わらない
- アプリは接続できない、または接続が不安定
- Developer（開発者）プランのため、Azure サポート起票ができず Q&A に誘導される
まず理解しておきたいこと：表示（コントロール）と実態（DB稼働）はズレることがある
PostgreSQL フレキシブル サーバーの状態表示（Starting / Stopping / Running など）は、管理操作を司る仕組み（コントロール プレーン）と、実際の PostgreSQL エンジン稼働（データ プレーン）をまたいで更新されます。通常は数分〜十数分で整合しますが、まれに状態遷移が詰まって「表示だけ/実態だけ」がおかしくなることがあります。
| ポータル表示 | 実際に起こり得る状況 | 最初の確認 |
|---|---|---|
| Starting のまま | 起動処理中／起動済みだが表示が更新されない／内部状態が不整合 | 接続テスト（psql など）とメトリック更新の有無 |
| Stopping のまま | 停止処理中／停止済みだが表示が更新されない／内部状態が不整合 | 接続できるか、アクティビティ ログに停止操作が残っているか |
| Running だが接続不可 | ネットワーク/DNS/認証/証明書、または負荷で実質ダウン | アプリ側エラーとネットワーク設定（ファイアウォール/VNet/Private） |
今回のケース：内部的に「unhealthy」になり、バックエンド是正（mitigation）が必要だった
今回の相談では、Microsoft 側で調査した結果、該当の PostgreSQL フレキシブル サーバーは内部的に「不健全（unhealthy）」な状態になっており、通常の停止／起動操作では復旧できない状態でした。サポート チームがバックエンド側で是正措置（mitigation）を実施し、サーバーの状態を修復して「Starting」から正常稼働へ戻すことで解消しています。
結論として、同様の状況ではユーザー側の操作だけで解決できない可能性があり、Azure 側の復旧作業（調査・是正）が必要になることがあります。
最短で解決に近づくためのチェックリスト
「自分でできること」と「自分ではできないこと」を切り分けるために、次の順番で確認するのが効率的です。
| チェック | やること | 分かること | 次の判断 |
|---|---|---|---|
| 接続可否 | psql/アプリから接続テスト（SELECT 1;） | DBが実際に生きているか | 接続できるならメトリック/ログで不安定要因を探す |
| 直前の変更 | スケール/バージョン/ネットワーク変更などを洗い出す | きっかけの推定 | 変更直後ならその操作が詰まっている可能性を疑う |
| アクティビティ ログ | start/stop/restart や構成変更の履歴・結果を確認 | 失敗や保留、操作の相関情報 | 操作履歴が残るのに反映なしならエスカレーションを優先 |
| Resource Health / Service Health | リソースの健全性、リージョン障害の有無を確認 | プラットフォーム側影響の可能性 | 異常が出る場合は早めに問い合わせに切り替える |
| メトリック更新 | CPU/メモリ/接続数/IO が更新されているか確認 | 監視面から「固着」を見つける | 更新停止なら内部不整合や制御面の障害を疑う |
ユーザー側でできる切り分けの具体手順
接続テストで「データ プレーン」を確認する
ポータルの「Starting」は必ずしも「DB が完全に停止している」ことを意味しません。まずは実際に接続できるかを確認します。
- アプリの接続エラー（タイムアウト、認証失敗、TLS エラーなど）をそのまま控える
- 許可されたネットワーク（VNet/Private、またはパブリック許可）から psql 等で接続してみる
- 接続できた場合でも、クエリが安定して通るか（断続的に落ちないか）まで確認する
例（psql）：
psql "host=<server-name>.postgres.database.azure.com port=5432 dbname=<db> user=<user> sslmode=require"
アクティビティ ログを確認する（操作の証跡を残す）
「停止を押したのに止まらない」「再起動が反映されない」といった状況では、アクティビティ ログが重要な手がかりになります。ポータル上で確認できるほか、CLI でも抽出できます。
例（Azure CLI でアクティビティ ログを取得）：
# 直近の操作履歴を表示（例）
az monitor activity-log list --resource-group <rg> --max-events 50 --output table
ログに「start/stop/restart を実行した記録」は残るのに、状態が変わらない場合は、ユーザー操作では解決しないケース（内部状態の詰まり）を疑う材料になります。
メトリックで「異常な兆候」を掴む
表示が固着しているときほど、メトリックの動きが判断材料になります。例えば、次のような変化があれば「Starting 固着の裏で別の問題が進行している」可能性があります。
- 接続数が上限付近に張り付いている（接続枯渇）
- CPU が高止まりしている（重いクエリやバキューム遅延など）
- ストレージ/IO が逼迫している（IOPS不足、バースト枯渇など）
直前の変更を洗い出す：よく引き金になる操作
Starting 固着の直前に次のような操作があると、原因の当たりがつけやすくなります（エスカレーション時の説明にも有効です）。
- PostgreSQL のメジャー/マイナー バージョン更新
- コンピュート（vCore）スケールアップ/ダウン
- ストレージや IOPS の変更
- 高可用性（HA）構成やゾーン関連設定の変更
- ネットワーク設定変更（パブリック/プライベート、ファイアウォール、VNet 統合）
- メンテナンス ウィンドウ周辺のタイミング
ポータル/CLI で試せる操作（ただし限界もある）
「ユーザー側でできる操作」を試すこと自体は有効です。ただし、同じ操作を何度も繰り返すより、実行した時刻・結果・その後の状態を記録し、早めにエスカレーションへ切り替えられるようにしておくのがポイントです。
Azure CLI の start/stop/restart 例
# 状態確認
az postgres flexible-server show --resource-group <rg> --name <server> --query "state"
# 再起動
az postgres flexible-server restart --resource-group --name
# 停止
az postgres flexible-server stop --resource-group --name
# 起動
az postgres flexible-server start --resource-group --name 「反応しない」と判断してよいサイン
- ポータルと CLI の両方から操作しても、状態がまったく動かない
- アクティビティ ログに操作履歴は残るのに、成功/失敗が確定せず、状態反映もない
- Resource Health で異常や復旧処理の兆候が見える
- 接続不可が継続し、メトリックの更新も止まっている
この状態では、ユーザー側の追加操作で状況が好転する可能性は高くありません。証跡を揃えてエスカレーションに移るほうが現実的です。
エスカレーションが必要な理由：内部「unhealthy」は外から治せない
今回のケースのように内部状態が unhealthy になると、利用者の操作は「要求は出せても、バックエンドが状態遷移できない」状況になりがちです。これは権限不足や設定ミスではなく、サービス基盤側の修復（mitigation）が必要な障害クラスに入ります。
| 症状 | 考えられる状態 | 推奨アクション |
|---|---|---|
| Starting/Stopping が長時間固定、操作が効かない | 状態遷移の詰まり、内部的不健全、コントロール プレーン不整合 | 証跡を揃えて Microsoft 側へエスカレーション |
| 接続はできるが断続的に落ちる | 負荷・接続枯渇・メンテ影響・ネットワーク要因など | メトリック/ログで切り分け、改善できなければエスカレーション |
| 直前のスケール/更新の失敗が見える | 変更操作の失敗、ロールバック未完了 | 変更内容とログを添えて問い合わせ |
Developer プランでも復旧につなげる：Microsoft Q&A を一次窓口として使う
Developer プランでは、Azure ポータルから技術サポートを起票しようとしても、サポート プランの制約により Q&A へ誘導されることがあります。このとき重要なのは、Q&A を「一般掲示板」として捉えるのではなく、一次窓口として調査・復旧につなげる場として使うことです。
Q&A 投稿で押さえるポイント
- 接続文字列のパスワードなど機密は載せない
- 代わりに、リソース名、リソースグループ、リージョン、発生日時、試した操作、結果を具体的に書く
- アクティビティ ログの情報（操作の成功/失敗、相関 ID が出ていればそれ）を添える
- ポータルの状態が分かるスクリーンショットを添付する
そのまま使える質問テンプレート
【事象】
Azure Database for PostgreSQL Flexible Server が Azure ポータルで "Starting" のまま進まず、
停止/起動/再起動（ポータル・Azure CLI 両方）を実行しても状態が変わりません。
【環境】
* リージョン: <例: Japan East>
* サーバー名:
* リソースグループ:
* 発生開始日時:
【直前に行った変更】
* <例: vCore を 2→4 に変更>
* <例: バージョン更新>
* <変更なし>
【確認したこと / 試したこと】
* Activity Log: <該当操作の結果、相関 ID（あれば）>
* Resource Health:
* Azure CLI: stop/start/restart 実行 → 状態変化なし
* 接続可否: <接続不可 / 接続できるが不安定 など>
【相談】
ユーザー側で復旧できない状態（内部状態不整合/unhealthy の可能性）でしょうか。
バックエンドでの調査や是正（mitigation）が必要か確認いただけますか。 障害調査が早くなる「準備情報」
| 情報 | 例 | なぜ必要か |
|---|---|---|
| サーバー名 / リソースグループ / リージョン | my-pgflex / rg-app / Japan East | 対象特定とリージョン影響確認のため |
| 事象発生日時 | 2025-12-15 10:20 JST | 内部ログの検索範囲を絞るため |
| 直前の変更 | スケール、更新、設定変更 | 状態遷移が詰まったきっかけを推定するため |
| アクティビティ ログの結果 | Start/Stop の履歴、エラー | どの操作がどこで止まったか確認できる |
| 相関 ID（出る場合） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | Microsoft 側でトレースしやすくなる |
| アプリ側エラーログ | タイムアウト、接続拒否など | データ プレーン影響の有無を判断しやすい |
Azure ポータルからサポート リクエストを作れるケース
Developer プランでも、課金・サブスクリプション管理・請求に関する相談は、Azure ポータルからサポート リクエストを作成できる場合があります。一方で、技術的な障害の深掘りが必要なケースは、サポート プランにより窓口が制限されることがあります。
迷ったときは次の切り分けで判断を速くできます。
- 技術的にサービスが固まっている/復旧できない → Microsoft Q&A を入口にして調査依頼（今回のパターン）
- 課金、サブスクリプション、支払い方法、契約 → Azure ポータルのサポート リクエスト
業務を止めないための回避策：復旧待ちだけにしない
サーバーが Starting で固まり、復旧の見通しが立たない場合でも、アプリ側のダウンタイムを抑えるために「別サーバーへ切り替える」判断が必要になることがあります。PostgreSQL フレキシブル サーバーでは、バックアップからの復元（ポイント イン タイム リストア等）を使って、新しいサーバーを作り直して接続先を切り替える運用が現実的な回避策になります。
| 回避策 | 向いている状況 | 要点 | 注意点 |
|---|---|---|---|
| ポイント イン タイム リストアで別サーバー作成 | 本番影響が大きく、待てない | 直近の復元ポイントから新サーバーを作り、接続先を切り替える | 復元ポイント以降の更新は失う可能性。接続文字列や権限差分の調整が必要 |
| リード レプリカ（構成済みの場合）への暫定切替 | 読み取り主体で運用できる | 参照系をレプリカへ逃がし、原本復旧まで凌ぐ | 書き込みはできない/制約がある。構成済みであることが前提 |
| アプリ側でリトライ/サーキットブレーカー強化 | 短時間で戻る可能性がある | 瞬断耐性を上げ、ユーザー影響を軽減する | 根本解決ではない。長期化すると限界 |
ポイント イン タイム リストアで切り戻す流れ
復旧を待ちつつ、並行して「切り替えルート」を準備しておくと、状況が長引いたときに慌てずに済みます。
- 最後に正常だった時刻（または障害直前）を基準に復元ポイントを決める
- 新しい PostgreSQL フレキシブル サーバーを復元で作成する
- アプリの接続先（接続文字列、DNS、シークレット）を新サーバーに切り替える
- 最低限の動作確認（ログイン、主要クエリ、性能）を行う
- 旧サーバーは削除せず、原因調査やデータ差分確認のために一定期間保持する（要コスト判断）
再発防止：Starting/Stopping の固着を早期に検知する
同じ種類のインシデントで一番つらいのは、「気づいたときには長時間止まっていた」状態です。運用でできる対策は、固着を早く検知し、切り替え判断を速くすることです。
| 監視ポイント | おすすめの見方 | 狙い |
|---|---|---|
| サーバー状態（Running/Starting/Stopping） | 状態が一定時間以上変化しない場合に通知 | 固着の早期発見 |
| 接続失敗率（アプリ側） | エラー率・タイムアウト率をメトリック化 | データ プレーン障害の兆候検知 |
| CPU/メモリ/接続数 | 普段のベースラインからの逸脱を検知 | 過負荷・接続枯渇による不安定化の回避 |
| ストレージ/IO | 逼迫やスパイクを監視 | 性能劣化からの障害連鎖を防ぐ |
| 変更イベント（デプロイ） | スケール/設定変更を記録し、障害時に即参照 | 原因追跡の高速化 |
よくある質問
「Starting」のままでも接続できるのですが、放置してよいですか？
接続できる場合でも、表示の固着は「内部の状態が追従していない」サインであることがあります。直前にスケールや更新が走っているなら、しばらく様子を見る判断もありますが、接続エラーが増える・メトリックが不自然といった兆候があれば、早めにエスカレーションしておくほうが安全です。
強制停止や強制再起動のような手段はありますか？
利用者が任意に「強制」操作できる仕組みは基本的に用意されていません。サービスの安全性を担保するため、バックエンド側の制御が必要になることがあります。操作が効かない場合は、無理に連打するよりも、証跡（時刻・操作・結果）を揃えて問い合わせるほうが復旧に近づきます。
サーバーを削除して作り直すのはアリですか？
割り切った復旧策としては有効ですが、削除してしまうと原因調査やデータ差分確認が難しくなります。可能であれば、先にバックアップ/復元で新サーバーを用意して切り替え、旧サーバーは一定期間保持してから整理するほうが安全です。
再発を減らすために、運用で一番効く対策は何ですか？
「状態が固着したらすぐ気づける」監視と、「切り替えルート（復元で新サーバーを立てる）」の手順化が最も効きます。特に開発環境でも、本番に近い構成で運用するほど、障害時の判断が迷いにくくなります。
まとめ
- PostgreSQL フレキシブル サーバーが「Starting」から進まず、停止/起動操作も効かない場合、内部状態が不健全（unhealthy）になっている可能性があります。
- 今回のケースでは、ユーザー側では復旧できず、Microsoft 側のバックエンド是正（mitigation）で復旧しました。
- 接続テスト、アクティビティ ログ、Resource Health、メトリックで状況を整理し、試した操作と時刻を記録することが、復旧の近道です。
- Developer プランでも Microsoft Q&A を一次窓口として、調査・復旧へつなげられます。
- 長期化に備えて、バックアップから新サーバーへ切り替える回避策も準備しておくと、ダウンタイムを抑えられます。
コメント