维护目标（メンテナンス目標）
- クエリ性能の安定化と短縮（計画の最適化、ディスクI/Oの削減）
- テーブル・インデックスの肥大化抑制（不要タプルの回収、インデックス再構築）
- 統計情報の鮮度維持（ANALYZE による最新化）
- ストリーミングレプリケーションの整合性維持（遅延とロック影響の最小化）
前置条件（前提条件）
- 対象: PostgreSQL プライマリ/スタンバイ構成。作業はプライマリで実施し、スタンバイへのWAL適用で反映される。
- バージョン:
- 推奨: PostgreSQL 12 以上（REINDEX CONCURRENTLY が利用可能）
- 12 未満の場合: 非同期再作成（CREATE INDEX CONCURRENTLY → DROP INDEX CONCURRENTLY）で代替。制約（PRIMARY/UNIQUE）に紐づくインデックスはオンラインで安全に代替しにくいため計画停止が必要。
- 権限: 対象DBの所有者またはスーパーユーザ相当の権限
- 監視・安全:
- 直近のフルバックアップまたはPITR復旧点の有効性を確認済み
- 空きディスク容量: 再索引する最大インデックスサイズの約1.2〜2倍
- 監視: レプリケーション遅延、ロック待ち、ディスクI/O、CPU使用率の可視化
- メンテナンス時間帯: 低負荷帯を確保（長時間ロックが発生する可能性のある操作は停止時間を考慮）
- 影響範囲: VACUUM/ANALYZE/REINDEXはWAL出力量を増加させるため、スタンバイ遅延しやすい
操作步骤（操作手順）
- 準備・通知
- 操作説明:
- 作業ウィンドウと対象スキーマ/テーブル/インデックスを確定し、関係者へ通知
- ベースライン取得のための計測条件を定義（対象クエリ、指標、期間）
- 一時設定（推奨）：セッション単位で lock_timeout/statement_timeout を短めに設定
- 予期結果:
- 作業スコープとリスク共有が完了し、タイムアウトが適用される
例:
SET lock_timeout = '5s';
SET statement_timeout = '15min';
SET application_name = 'maint_reindex_vacuum';
- ベースライン採取
- 操作説明:
- バージョンとレプリケーション遅延確認（プライマリで実行）
- 大きい/スキャン頻度の低いインデックス、不要タプルが多いテーブルを抽出
- ディスク空き容量確認（OS側コマンドで実施）
- 予期結果:
- メンテ対象の候補リストが作成され、リソース状況が把握できる
例:
-- レプリケーション遅延概要
SELECT application_name, state, sync_state, replay_lag
FROM pg_stat_replication;
-- 大きいインデックスの上位
SELECT schemaname, relname AS table_name, indexrelname AS index_name,
pg_size_pretty(pg_relation_size(indexrelid)) AS index_size, idx_scan
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC
LIMIT 20;
-- デッドタプルが多いテーブル
SELECT schemaname, relname, n_live_tup, n_dead_tup
FROM pg_stat_all_tables
ORDER BY n_dead_tup DESC
LIMIT 20;
- 手動VACUUM（ANALYZEを含めて実施）
- 操作説明:
- オンライン維持を優先し、VACUUM (ANALYZE) を対象テーブルへ実施
- 複数テーブルは vacuumdb で並列化（-j）可能
- 進捗は pg_stat_progress_vacuum で確認
- 予期結果:
- 不要タプルが回収され、テーブル統計情報が更新される
例:
-- 個別実行
VACUUM (VERBOSE, ANALYZE) schema.table1;
VACUUM (VERBOSE, ANALYZE) schema.table2;
-- 複数テーブルを並列で（シェルから）
vacuumdb -d <DB名> -j 4 -z -t schema.table1 -t schema.table2
-- 進捗確認
SELECT relid::regclass AS table_name, phase, heap_blks_total, heap_blks_scanned, heap_blks_vacuumed
FROM pg_stat_progress_vacuum;
注意: オンライン運用中は VACUUM FULL は使用しない（全表再書き込みと長時間ロックが発生）。
- 統計情報の更新（必要に応じて追加ANALYZE）
- 操作説明:
- 列の分布が偏っているテーブルで計画が安定しない場合、ANALYZE を追加実行
- 予期結果:
例:
ANALYZE (VERBOSE) schema.table1;
- インデックス再構築（REINDEX）
- 操作説明:
- 候補インデックスへ REINDEX CONCURRENTLY を実施（PostgreSQL 12+）
- 1回に実施する本数を制限し、負荷とレプリケーション遅延を監視
- 失敗時に無効インデックスが残らないか確認（pg_index.indisvalid）
- 予期結果:
例（12+）:
-- 単一インデックス
REINDEX INDEX CONCURRENTLY schema.idx_target;
-- テーブル配下の全インデックス（必要に応じて）
REINDEX TABLE CONCURRENTLY schema.table1;
-- 実行後、無効インデックスの有無を確認
SELECT i.relname AS index_name, ix.indisvalid
FROM pg_index ix
JOIN pg_class i ON i.oid = ix.indexrelid
WHERE i.relname = 'idx_target';
代替（12未満、非制約インデックスのみ）:
-- 定義確認
SELECT pg_get_indexdef(indexrelid)
FROM pg_stat_user_indexes
WHERE indexrelname = 'idx_target';
-- 新規作成（新しい名前で）
CREATE INDEX CONCURRENTLY idx_target_new ON schema.table1 (col1, col2);
-- 旧インデックスを削除
DROP INDEX CONCURRENTLY schema.idx_target;
-- 新インデックス名をリネーム
ALTER INDEX schema.idx_target_new RENAME TO idx_target;
注意:
- 制約に紐づくインデックス（PRIMARY/UNIQUE）はオンライン手順が複雑なため、停止時間を確保するか、PostgreSQL のメジャーバージョン更新後に REINDEX CONCURRENTLY を使用
- REINDEX/CREATE INDEX はトランザクションブロック内で実行しない（BEGIN/COMMITで囲まない）
- スタンバイでは実行不可（読み取り専用）
- 再度のANALYZE（任意）
- 操作説明:
- 大規模な再索引後、対象テーブルに ANALYZE を再実施
- 予期結果:
- プランナが新しいインデックス状態を踏まえた最適計画を選択
例:
ANALYZE schema.table1;
- 終了処理・記録
- 操作説明:
- 一時的に変更したセッション設定を元に戻す
- 実施内容（対象、時刻、実行時間、サイズ変化、エラー）を記録
- 予期結果:
风险与应对（リスクと対応）
- 長時間ロック
- 対応: CONCURRENTLY を使用、lock_timeout 設定、対象を小分けに実行、低負荷時間に実施
- ディスク不足
- 対応: 事前に対象インデックスサイズを把握し、空き容量を確保（最大インデックスの1.2〜2倍）。不足時は対象を分割または順延
- レプリケーション遅延の増大
- 対応: 作業中に pg_stat_replication の遅延を監視、閾値超過で一時停止。必要に応じ vacuum_cost_limit を控えめに
- 自動VACUUM/他バッチとの競合
- 対応: スケジュール調整、対象テーブルの同時VACUUM回避。メンテ窓での大量更新を抑制
- REINDEX失敗・中断
- 対応: 実行後に pg_index.indisvalid を確認。無効インデックスが残存する場合は DROP INDEX を実施。再試行は負荷が落ち着いてから
- 誤対象の操作
- 対応: 実行前に対象一覧をレビュー、テスト環境で手順検証、ロールベースの最小権限で実施
验证方法（検証方法）
- 機能・整合性
- レプリケーション: pg_stat_replication の state/sync_state と遅延（replay_lag）が平常範囲
- インデックス有効性: indisvalid = true、重複/無効インデックスがない
- 効果（サイズ・統計）
- デッドタプル減少:
SELECT schemaname, relname, n_dead_tup
FROM pg_stat_all_tables
WHERE relname IN ('table1','table2')
ORDER BY n_dead_tup DESC;
- インデックスサイズ変化:
SELECT relname AS index_name, pg_size_pretty(pg_relation_size(oid)) AS size
FROM pg_class
WHERE relkind = 'i' AND relname IN ('idx_target')
ORDER BY pg_relation_size(oid) DESC;
- 性能（クエリ）
- 進捗・副作用
- VACUUM進捗/残タスク: pg_stat_progress_vacuum と autovacuum のログを確認
- エラーログ: REINDEX/ANALYZE のエラー・警告の有無
合否基準（例）:
- 対象クエリの中央値レイテンシが目標比で改善または維持
- 対象テーブルの n_dead_tup が大幅に減少
- 対象インデックスのサイズ縮小または idx_scan の増加傾向
- レプリケーション遅延が許容範囲内で収束
相关文档（関連ドキュメント）
注意:
- 本手順はオンライン維持を優先した基本手順。VACUUM FULL や制約付きインデックスの置換など、長時間ロックを伴う操作は停止時間を前提に個別計画を作成すること。
