ご指摘ありがとうございます。以下に 完全なMarkdown形式のブログ記事 を修正版として提供いたします。
⸻
✅ 完成版：ブログ記事（Markdown形式）
【調査ログ公開】PostgreSQLサービスが停止していた！？原因の特定と復旧までの全手順
Djangoアプリを稼働させているサーバーで、ある日突然「データベースに接続できない」状態に。
調べたところ、PostgreSQLサービスの停止が原因でした。
この記事では、その原因をどのように突き止め、どのように復旧したかを全手順つきで公開します。
🔍 調査の流れと実行したコマンド
1. PostgreSQLサービスの基本ログ確認
```bash journalctl -u postgresql -n 50 --no-pager
• サービスの最新ログを確認
• 6月3日15:47に起動した記録のみあり、停止ログはなし
⸻
- 期間を指定したログ確認
journalctl -u postgresql --since 2025-06-01 --no-pager
• より広範囲のログを確認
• 起動ログのみで停止記録は見つからず
⸻
- PostgreSQLに関連する全ログの抽出
journalctl --since 2025-06-01 --grep postgresql --no-pager
• システム全体のログから「postgresql」関連を検索
• postgresql@14-mainでアサーション失敗が発生していたログを発見
⸻
- 特定クラスターのログを確認（14-main）
journalctl -u postgresql@14-main --since 2025-06-01 --no-pager
• 6月7日13:55と16:08にアサーション失敗の記録
⸻
- システム再起動の記録を確認
journalctl --since 2025-06-01 -g reboot --no-pager
• 6月3日15:17頃に再起動が発生していたことを特定
⸻
- 再起動後のPostgreSQL起動状況を確認
journalctl --since "2025-06-03 15:17:00" --until "2025-06-03 15:50:00" -g postgresql --no-pager
• PostgreSQL 16-main クラスターは正常に起動
• 14-mainは起動に失敗していた
⸻
- 現在のPostgreSQLクラスターの状態を確認
pg_lsclusters
• 16-mainクラスターのみが起動中で、14-mainは存在していないことを確認
⸻
🧠 調査結果のまとめ
項目 内容 発端 6月3日15:17のシステム再起動 稼働中のクラスター PostgreSQL 16-main 停止の影響を受けた部分 PostgreSQL 14-main（すでに存在しないが、ログで影響を確認） 現在の状態 16-mainのみが稼働中で、アプリも正常に接続している
⸻
🔁 推定される停止原因 • システムメンテナンスによる自動再起動 • 手動での再起動操作 • 不明な障害（ログには明確なトリガーなし）
⸻
💡 学びと対策ポイント • PostgreSQLのクラスター構成は定期的に見直すべき • pg_lsclusters で不要なクラスターが残っていないかチェック • systemdログの期間・キーワード検索が強力
⸻
✅ 現在の状態と結論
PostgreSQLサービスは現在 16-mainのみが正常に稼働中 であり、 Djangoアプリも無事復旧しています。
⸻
⚙️ 使用環境 • OS：Ubuntu 22.04 • DB：PostgreSQL 16 • Webアプリ：Django • WSGI：Gunicorn • Webサーバー：Nginx
⸻
✍️ まとめ
Djangoの接続エラーは、アプリの不具合よりも 環境やバックエンドのトラブルが原因であることが多い です。 本記事が、同様の障害に直面した方の助けになれば幸いです。
何か文章表現や図示などを追加したい場合も対応可能ですので、お気軽にどうぞ！