4.1起こりうる障害のパターン

本番データベースの障害対応は、まず何が起きたかを正確に切り分けるところから始まります。「サーバに接続できない」という一つの症状も、原因はプロセスのクラッシュ、OSのリソース枯渇（ディスク満杯・メモリ不足）、ネットワーク断、あるいは単なる過負荷による接続上限到達など様々です。Gold試験では、エラーメッセージ・プロセス状態・設定パラメータの3方向から障害の性質を特定し、適切な一次対応を選ぶ判断力が問われます。

4.1.1障害の特定：エラーメッセージ・プロセス・リソース

• エラーメッセージからの障害特定＝PostgreSQLのログ（log_destinationで設定した出力先）にはFATAL・PANIC・ERRORなど重大度が付く。PANICはサーバプロセス全体をクラッシュさせ自動再起動を引き起こす最重度で、could not write to file（ディスク書き込み失敗）やout of memory（メモリ枯渇）はOSリソース枯渇の典型的な兆候。
• サーバ停止・データ消失・OSリソース枯渇・プロセス状態分析＝psでPostgreSQLのpostmasterとバックエンドプロセスの生死を確認、df/duでディスク使用量、freeでメモリを確認するのが一次切り分けの定石。ディスクフルは特にWALの書き込み不能に直結し、最悪クラッシュに至るため最優先で除去すべき原因。

4.1.2タイムアウト系パラメータとクラッシュ後の挙動

• statement_timeout＝1つのSQL文の実行時間の上限（ミリ秒）。超過すると自動的にキャンセルされる。長時間クエリの暴走を防ぐ代表的な安全弁。
• lock_timeout＝ロック取得待ちの上限時間。ロック待ちがこれを超えるとエラーで中断（statement_timeoutより先に効くことが多い）。idle_in_transaction_session_timeout＝トランザクションを開始したままアイドル状態が続くセッションを自動的に切断するタイムアウト（長時間ロック保持による他セッションのブロックを防ぐ）。
• synchronous_commit＝コミット確定を待つ強度を制御するパラメータ（on/off等）。offにするとコミット応答は速いが、クラッシュ時に直近のコミット済みトランザクションが失われうる（同期レプリケーションの確実性にも関わる）。restart_after_crash＝バックエンドプロセスが異常終了（クラッシュ）した際にサーバ全体を自動的に再起動するかどうかを制御するパラメータ（既定on）。
• pg_ctl＝サーバプロセスを制御する標準コマンド（start/stop/restart/reload/status）。異常終了からの復旧ではpg_ctl startで再起動を試み、クラッシュリカバリ（WALの再生）が自動的に走ることを理解しておく。max_locks_per_transaction＝サーバ全体のロックテーブルのサイズを決める係数（トランザクション数×この値が目安上限）で、超過するとout of shared memoryエラーとなり大量のロックを要する操作（多数テーブルの一括操作等）が失敗しうる。