1.2運用管理コマンド

Gold の出題範囲の中で最も重みが大きい副主題です。障害からの復旧手順（バックアップ・PITR）と、日々のクラスタの健全性を保つメンテナンス（VACUUM系）という、運用担当者が最も手を動かす領域が凝縮されています。ここでの理解の深さが、実際のインシデント対応の速さに直結します。

1.2.1非排他的バックアップとPITR

• 論理バックアップ＝pg_dump（単一データベースを SQL/カスタム形式で出力）・pg_dumpall（全データベース＋ロール定義などクラスタ全体を出力）。リストアは pg_restore（カスタム/ディレクトリ形式向け）や psql （プレーンSQL向け）。
• 物理バックアップ＝pg_basebackupでクラスタ全体のファイルをまるごと取得する。リモートからストリーミングで取得でき、-D（出力先）・-F（tar/plain）・-X（WALの同梱方法：stream/fetch）などのオプションを持つ。
• 非排他的低レベルバックアップ（Ver12-14で有効）＝pg_start_backup() でバックアップ開始を宣言（チェックポイント強制・バックアップラベル生成）→ファイルシステムレベルでファイルをコピー→pg_stop_backup() で終了を宣言し WAL アーカイブに必要な範囲を確定させる。排他的方式と異なり同時に複数のバックアップを実行でき、セッション切断時も自動終了する。
• PITR（Point-In-Time Recovery）＝ベースバックアップ＋その後のWAL（Write-Ahead Log）アーカイブを組み合わせ、任意の時点までロールフォワードして復元する仕組み。archive_command で WAL セグメントを退避先へコピーし、リカバリ時に recovery_target_time 等で復旧地点を指定する。

1.2.2VACUUM系コマンドとautovacuum

• VACUUM＝不要become（デッド）タプルの領域を再利用可能にする（通常版はテーブルロックを取らず同時実行可）。ANALYZE＝プランナ用の統計情報を更新する。vacuumdb＝これらをコマンドラインから呼び出すラッパー（-a 全DB・-z ANALYZE同時実行など）。
• CLUSTER＝指定インデックスの物理順序に合わせてテーブルを物理的に並べ替える（強い排他ロックが必要・実行中はテーブル使用不可）。REINDEX＝肥大化・破損したインデックスを再構築する。CHECKPOINT＝手動でチェックポイントを強制実行し、その時点までの変更をデータファイルへ確実に反映させる。
• autovacuum＝バックグラウンドで自動的に VACUUM/ANALYZE を実行するデーモン。しきい値は autovacuum_vacuum_threshold ＋ autovacuum_vacuum_scale_factor × 行数 の式で決まり、更新の多いテーブルほど頻繁に走る。テーブル単位に ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = 0.05) のようにチューニングできる。
• pgstattuple＝拡張機能。テーブル/インデックスの実際の肥大化率（デッドタプルの割合・空き領域率）を関数（pgstattuple('table')）で直接調べられる。統計の推測ではなく実測値を返す点が特徴。

1.2.3セッション制御と監視ロール

• pg_cancel_backend(pid)＝指定バックエンドの実行中クエリのみをキャンセルする（セッション自体は継続）。切断まで行うのは pg_terminate_backend(pid)（本節の範囲外・関連関数として対比）。
• pg_reload_conf()＝postgresql.conf を再起動せずに再読み込みするSQL関数（pg_ctl reload のSQL版）。max_connections など再起動が必要なパラメータには効かない点に注意。
• max_parallel_workers＝クラスタ全体で同時に使えるパラレルワーカーの総数上限（max_worker_processes の範囲内で設定）。pg_monitor＝多くの監視系ビュー・関数への閲覧権限をまとめて持つ組み込みロールで、GRANT pg_monitor TO monitoring_user のように付与し、スーパーユーザー権限を渡さずに監視ツールへ権限委譲できる。

本番障害からの復旧を想定した実務フローを追いましょう。深夜にディスク故障でクラスタが失われたとします。復旧の第一歩は、直近の物理バックアップ（pg_basebackup -D /backup/base -F tar -X stream で事前取得済みとします）を新しいストレージへ展開することです。次に、archive_command で退避してきた WAL アーカイブ一式を用意し、recovery.signal（または standby.signal）と postgresql.conf の restore_command・recovery_target_time を設定してサーバを起動すると、ベースバックアップ以降の WAL がロールフォワードされ、指定した時刻の直前まで復旧できます（PITR）。もし低レベルバックアップを自前のスクリプトで取得する運用なら、バックアップ開始時に SELECT pg_start_backup('nightly', false);（第2引数 false＝非排他的）を実行してからファイルシステムレベルで rsync 等によりデータディレクトリをコピーし、コピー完了後に SELECT pg_stop_backup(); を実行して WAL アーカイブに必要な範囲を確定させます。非排他的方式は複数の同時バックアップに対応し、セッションが切れても自動的に後始末される点が排他的方式より安全です。 復旧後の日常運用では、肥大化したテーブルを pgstattuple で実測してから対処します。SELECT * FROM pgstattuple('orders'); の dead_tuple_percent が高ければ、まず通常の VACUUM orders; を試し、それでも改善しない深刻な肥大化（インデックスの物理断片化を含む）なら、メンテナンス時間を確保した上で CLUSTER orders USING orders_pkey; や REINDEX INDEX orders_pkey; を検討します。CLUSTER は強い排他ロックを取るため業務時間内の実行は避けます。autovacuum の頻度が業務パターンに合わない（更新の多いテーブルで統計が古くなりがち）なら、テーブル単位で ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.02); のように感度を上げます。長時間実行される問題のあるクエリを止めたいが該当セッションの他の処理は継続させたいときは SELECT pg_cancel_backend(12345); を使い、設定変更後にサーバ全体を再起動せず反映したいときは SELECT pg_reload_conf(); を呼びます。監視ダッシュボード用のアカウントには GRANT pg_monitor TO dashboard_user; で必要十分な権限だけを与えます。

1.2.4この節のまとめ

• 論理バックアップ＝pg_dump/pg_dumpall／物理バックアップ＝pg_basebackup／非排他的低レベル＝pg_start_backup()→コピー→pg_stop_backup()（Ver12-14で有効）。PITRはベース＋WALアーカイブでロールフォワード
• VACUUM(同時実行可)／CLUSTER(強い排他ロック・物理並べ替え)／REINDEX／CHECKPOINT。autovacuumはテーブル単位でscale_factorをチューニング可。pgstattupleで実測肥大化を調査
• pg_cancel_backend()＝クエリのみ停止／pg_reload_conf()＝再起動なしで設定再読込。pg_monitorロールで監視権限を安全に委譲