Azure Database for PostgreSQL Flexible Server でメジャーバージョンアップ後に状態が「起動中(Starting)」のまま変わらず、停止・起動もできない――。本記事では実際の事例をもとに原因の考え方、確認ポイント、ユーザー側でできることとサポート依頼のコツ、再発防止策をまとめます。
症状としてよく見えるサイン
Azure Database for PostgreSQL Flexible Server の状態が長時間「起動中(Starting)」のまま変わらないとき、実際には Azure 側（コントロールプレーン）の操作が詰まっている ケースが多く、ユーザーがポータルや CLI から行う「停止」「起動」「再起動」「スケール」などの操作が一斉にブロックされます。画面上の表示だけでなく、次のようなサインが揃ったら「操作ロック」状態を疑ってください。
| 場所 | よくある表示・エラー | 読み取れること |
|---|---|---|
| Azure ポータル | 状態が「起動中 (Starting)」から何時間も変わらない | バックエンド処理が完了せず、状態遷移が戻っていない可能性 |
| Azure CLI | Stop/Start/Restart が「別の操作を処理中のため実行できない」等で失敗 | リソースに対して排他的な操作が継続中（または残骸が残っている） |
| アクティビティログ | アップグレード開始以降、読み取り系（例: Get PostgreSQL server list）が高頻度で大量に記録 | 原因というより「状態を見に行くアクセス」が継続しているサイン。書き込み系の操作失敗がないかも併せて確認 |
今回の事例で起きていたこと
事例の流れは次の通りです。
- Azure Database for PostgreSQL Flexible Server でメジャーバージョンアップを実行。
- 数時間経っても完了しないため、アップグレードをキャンセル。
- その後、サーバーを「停止 → 起動」しようとしたが、ポータルの状態が「起動中(Starting)」から変わらない。
- CLI で停止しようとしても「別の操作を処理中のため Stop を実行できない」といったエラーで停止できない。
- アクティビティログには、アップグレード開始以降「Get PostgreSQL server list」のログが 2 分おきに大量に出続ける。
結論から言うと、このケースは ユーザー側から進行中の操作を強制キャンセルできる類のものではなく、Microsoft 側（サポート/PG チーム）がバックエンドから緩和策（mitigation）を適用して復旧しました。
原因の考え方：失敗したメジャーバージョンアップが「操作中」を解除できない
Azure Database for PostgreSQL Flexible Server のメジャーバージョンアップは、表面上は「アップグレード」ボタンひとつでも、内部では複数のバックエンド処理が段階的に走ります。ここで一部の処理が失敗すると、Azure 側の状態管理が「操作中」のまま戻れず、ポータルでは「起動中(Starting)」に張り付いたように見えることがあります。
この「操作中」状態は厄介で、リソースに対する排他ロックのように振る舞います。そのためユーザーが Stop/Start を実行しても、Azure 側は「まだ別の操作が走っている（走っていた扱いになっている）」としてブロックし、結果として何もできなくなります。
また、アクティビティログに大量に出ていた「Get PostgreSQL server list」は、典型的には 一覧表示や監視が状態を取りに行っている読み取り系の操作です。これ自体がサーバーを壊しているわけではなく、「状態を確認し続けている」ことがログとして残りやすい、という性質があります。重要なのは、同じ時刻帯に Upgrade/Update/Restart/Stop/Start などの書き込み系操作が失敗していないか、どの操作が最後に成功/失敗したかです。
まず切り分ける：コントロールプレーンの問題か、データプレーンの問題か
「起動中(Starting)」が長引くと焦りますが、落ち着いて 2 つの観点 で状況を切り分けると、次の行動が決めやすくなります。
| 観点 | 確認方法の例 | わかること | 次にやること |
|---|---|---|---|
| データプレーン（DB に接続できるか） | psql で接続、アプリのヘルスチェック、接続先 FQDN の疎通 | 実際に PostgreSQL が動いているか／停止しているか | 接続できるなら、退避や代替案（復元・切替）の準備 |
| コントロールプレーン（Azure の状態・操作が正常か） | ポータルの状態遷移、アクティビティログ、CLI の Stop/Start の成否 | Azure 側の操作が詰まっているか | 操作が一切通らないなら、早期にサポートへエスカレーション |
今回の事例は、Stop/Start がブロックされている時点で コントロールプレーン側の詰まりが濃厚でした。ここを見誤って操作を繰り返すと、ログだけが増え、復旧判断が遅れることがあります。
ユーザー側でやりがちな NG 行動
- 停止→起動→再起動→スケールを短時間で何度も繰り返す（操作キューが増えて余計に詰まることがある）
- 同じ操作をポータルと CLI の両方から同時に投げる（競合しやすい）
- 原因が不明なまま、パラメータ変更やネットワーク設定変更を重ねる（切り分けが難しくなる）
- 「起動中」だからといって、すぐに削除して作り直す（復旧できたはずのデータに戻れなくなるリスク）
ユーザー側でできる現実的な確認と対処
この種の問題は「自力で直す」よりも、早く正しい情報を集めて、必要ならサポートに渡すことが最短ルートです。以下は、作業の優先度が高い順のチェックリストです。
アクティビティログで「最後に何が起きたか」を時系列で把握する
ポータルのアクティビティログで、該当サーバーのリソースに絞り込み、アップグレード開始時刻以降の書き込み系操作（Upgrade/Update/Restart/Stop/Start）がどうなっているかを確認します。特に次を押さえると、サポート側が状況を追いやすくなります。
- 最後に「成功」している操作の種類と時刻
- 最初に「失敗」している操作の種類と時刻
- 失敗イベントに含まれるエラーコード／メッセージ
- 同時刻に発生している関連操作（ネットワーク、バックアップ、メンテナンス等）
CLI から確認する場合は、アクティビティログを取得して失敗イベントを抽出すると把握しやすいです。
az monitor activity-log list \
--resource-id <PostgreSQL Flexible Server のリソースID> \
--status Failed \
--max-events 50 -o table実際に DB に接続できるか（データプレーン）を確認する
ポータルが「起動中」でも、稀にデータプレーンが動いていることがあります。アプリケーションの接続テストや psql の疎通を試し、いまデータにアクセスできるかを確認してください。
- 接続できる：緊急避難として pg_dump での論理バックアップや、別環境への退避を検討
- 接続できない：復旧は Azure 側の操作解除が必要な可能性が高い
Azure 側の「健康状態」も同時に確認する
操作詰まりは個別要因だけでなく、リージョン/基盤側の影響が絡むこともあります。ポータル上で次の場所も確認し、異常があればその情報もサポートへ添えると判断が速くなります。
| 確認先 | 見るポイント | 補足 |
|---|---|---|
| Resource health（リソース正常性） | 当該サーバーの「利用可能性」「プラットフォームイベント」 | Azure 側イベントが出ていれば有力な手掛かり |
| Service Health（サービス正常性） | リージョンの障害/インシデント情報 | 同リージョンで広域影響がないか確認 |
| メトリクス | CPU、メモリ、I/O、接続数、ストレージ | 「実は動いている/完全停止している」の判断材料 |
復旧までのビジネス継続策を用意する（可能なら）
本番影響が大きい場合、サポート対応を待つ間に「復旧したらすぐ切り替えられる代替案」を準備しておくと、ダウンタイムを最小化できます。代表的な選択肢は次の通りです。
| 選択肢 | メリット | 注意点 | 向いている状況 |
|---|---|---|---|
| ポイントインタイムリストア（別サーバーに復元） | 既存バックアップを使って別個体を立てられる | 復元時刻以降のデータは失われる可能性。接続先変更が必要 | とにかくサービスを再開したい |
| アプリ側でリトライ/フェイルオーバー設定を一時調整 | 短時間の不安定さを吸収できることがある | 根本解決ではない。負荷が増えると逆効果になることも | 復旧までの一時しのぎをしたい |
| 接続できるうちに論理バックアップ（pg_dump） | 最悪の事態でもデータを手元に残せる | DB サイズ次第で時間がかかる。性能影響に注意 | データ保全を最優先したい |
ポイントインタイムリストアを CLI で行う場合のイメージです（実際の引数は環境に合わせてください）。
az postgres flexible-server restore \
--resource-group <RG> \
--name <新しいサーバー名> \
--source-server <元サーバー名またはリソースID> \
--restore-time "YYYY-MM-DDTHH:MM:SSZ"このケースの決定打：Microsoft サポートによるバックエンド緩和策（mitigation）
今回の事例は、メジャーバージョンアップが内部的に失敗したことにより、サーバーがバックエンド側で「操作中」の状態から正常に戻れず、ポータル上では「起動中(Starting)」に張り付いていました。この状態ではユーザー操作がブロックされるため、ポータル/CLI だけでの解消は困難です。
実際には Microsoft 側（サポート/PG チーム）がバックエンドから緩和策（mitigation）を適用し、詰まっていた状態を解除したことで、サーバーが正常なオンライン状態に復旧しました。
同様の症状が出た場合、一定時間待っても状態が変わらず、Stop/Start も受け付けないなら、早めにサポート チケットを開くことが現実的な解決策になります。
サポートへ渡すと解決が早い情報
| 項目 | 具体例 | なぜ必要か |
|---|---|---|
| サーバー名・リソース ID | /subscriptions/…/resourceGroups/…/providers/Microsoft.DBforPostgreSQL/flexibleServers/… | バックエンド側で対象を特定するため |
| リージョン | Japan East など | 該当クラスタ/基盤の確認に必要 |
| 実行した操作の内容 | メジャーバージョンアップ開始とキャンセル（例: 13→15） | どのワークフローが詰まったか判断できる |
| 状態が固まった時刻 | 「起動中」になった時刻、キャンセル時刻 | ログの当たりを付けやすい |
| 表示されるエラー | CLI のエラー全文、ポータルの失敗詳細 | 原因となる内部エラーの手掛かりになる |
| アクティビティログの該当イベント | Failed のイベント（JSON/スクリーンショットでも可） | 再現と切り分けが早い |
サポート依頼文のテンプレート
チケットを切るときは、状況が一目で伝わるように「事実」と「困っていること」を分けて書くとスムーズです。以下はそのまま流用できるテンプレートです。
現象:
Azure Database for PostgreSQL Flexible Server が「起動中(Starting)」のまま長時間変化しません。
Stop/Start などの操作も「別の操作を処理中のため実行できない」旨のエラーで失敗します。
直前に行った操作:
メジャーバージョンアップを開始しましたが、数時間経っても完了せずキャンセルしました。
確認したこと:
* アクティビティログで Upgrade 開始以降、関連する Failed イベントを確認
* CLI でも Stop/Start がブロックされることを確認
* （可能なら）DB への接続可否も確認
お願い:
バックエンド側で詰まっている操作/状態を解除し、サーバー状態の復旧（オンライン化）をご支援ください。
情報:
* サーバー名:
* リソースID:
* リージョン:
* アップグレード開始時刻:
* キャンセル時刻:
* 状態が固まった時刻:
* 代表的なエラー:
* 影響範囲（本番/検証、SLA影響の有無）:メジャーバージョンアップ前に押さえたい予防策
「起動中(Starting)で固まる」事象はレアケースですが、起きたときの影響が大きいため、事前準備の差が復旧時間に直結します。特に本番環境では、次のポイントをルール化しておくと安心です。
バックアップ戦略を「切り戻し」まで含めて設計する
- 論理バックアップ（pg_dump）を取得し、別環境でリストア手順まで確認する
- ポイントインタイムリストアの保持期間（バックアップ保持）を見直し、必要な期間を確保する
- 「最悪この時刻まで戻せば復旧できる」という 復元目標時刻（RPO） を決める
検証サーバーでリハーサルして「時間」と「互換性」を把握する
本番と同じ拡張機能、同等のデータ量、同じパラメータ構成で検証し、以下を確認します。
- アップグレードにかかるおおよその時間（データ量・拡張・I/O により大きく変動）
- アプリの互換性（SQL 文、ドライバ、ORM の挙動、拡張機能）
- パフォーマンスの変化（インデックス、プランナー、VACUUM 関連の差分）
メンテナンス計画を「長引く前提」で組む
- 余裕のあるメンテナンスウィンドウを確保する
- アップグレード中の監視（接続数、ストレージ、CPU、I/O）を事前に用意する
- 不測の事態に備え、切り戻し案（PITR で新サーバー復元→接続先切替）を文書化する
当日の運用チェックリスト
| タイミング | チェック項目 | ポイント |
|---|---|---|
| 開始前 | バックアップ取得、復元手順の確認 | 「戻せる」状態を先に作る |
| 開始前 | アプリの書き込み停止/メンテ表示 | 不整合や再試行嵐を避ける |
| 実行中 | アクティビティログとメトリクス監視 | 異常の早期発見 |
| 長引く場合 | むやみに操作を重ねない | 操作キューを増やさない |
| 固まった場合 | サポートへ必要情報を添えて連絡 | バックエンド解除が必要なケースがある |
よくある質問
「Get PostgreSQL server list」が大量に出るのは異常ですか？
読み取り系の操作ログが増えること自体は珍しくありません。ポータルの一覧表示や監視が状態を取りに行くと、アクティビティログに記録されることがあります。重要なのは、その前後で アップグレードや更新などの書き込み系操作が失敗していないか、失敗が連鎖していないかです。
キャンセルしたのに元に戻らないのはなぜ？
「キャンセル」はフロント側の要求を取り下げただけで、バックエンド側では既に始まった処理の整合性を取る必要があります。そこで失敗すると、状態だけが残ってしまうことがあります。この場合、ユーザー側から完全にクリーンアップする手段が用意されていないことが多く、サポート対応が必要になります。
Cloud Shell や CLI で「進行中の操作をキャンセル」できませんか？
このタイプの詰まりは、ユーザーが ARM 操作を止めれば解決するものではなく、バックエンド内部のワークフローが「操作中」を解放できない状態になっていることがあります。そのため、Cloud Shell や CLI からの Stop/Start がブロックされている場合は、ユーザー側での強制解除が難しく、サポートによる内部対応が現実的になります。
サポートに連絡する目安は？
操作がブロックされ、状態が長時間変わらない場合は、待つほど状況が好転するとは限りません。特に本番影響がある場合は、アクティビティログで状況を確認したうえで、早めにサポートへエスカレーションしてください。
まとめ
Azure Database for PostgreSQL Flexible Server が「起動中(Starting)」のまま進まない問題は、メジャーバージョンアップ失敗などを契機に、Azure 側のバックエンド処理が「操作中」から戻れなくなることで発生することがあります。この状態では Stop/Start がブロックされ、ユーザー単独での解消が難しいケースがあります。
まずはアクティビティログで最後に走った操作と失敗イベントを把握し、むやみに状態変更を繰り返さないこと。そして、必要な情報（リソースID、時刻、エラー、操作履歴）を揃えて Azure サポートに依頼し、バックエンド緩和策（mitigation）を適用してもらうのが、復旧への近道です。加えて、バックアップとリハーサル、切り戻し案を用意しておくことで、万一の際の影響を最小化できます。
コメント