なぜ「レプリケーションスロット」は、DBの守護神なのか
PostgreSQLを運用していて、一度は冷や汗をかいたことがあるはずです。そう、「レプリカの同期遅延がひどすぎて、プライマリ側で必要なWALファイルが削除されてしまった」という、あの悪夢のようなインシデントです。
かつては `wal_keep_segments`（現 `wal_keep_size`）というパラメータで、「とりあえずこれだけ残しておけば大丈夫だろう」と祈るような運用をしていた時期もありました。しかし、トラフィックが急増した瞬間にレプリカが息絶え、プライマリのWALが流れていく絶望感。
この問題を根本から解決するために生まれたのが、「レプリケーションスロット（Replication Slots）」です。今回は、この仕組みが内部でどう動き、我々に何をもたらしているのか、少し深掘りしてみましょう。
—
内部アーキテクチャ：WALとスロットの「約束」
レプリケーションスロットの本質は、プライマリに対する「データ保持の確約」です。
通常、PostgreSQLのプライマリは、チェックポイントを通過するたびに不要になったWALファイルを削除しようとします。しかし、レプリケーションスロットがアクティブな場合、プライマリ側は以下のプロセスを辿ります。
1. LSNのトラッキング: スロットは、各レプリカがどこまで読み込んだかを示す「LSN (Log Sequence Number)」を `pg_replication_slots` ビューで管理します。
2. 削除の抑止: `pg_wal` ディレクトリ内のファイル削除プロセスにおいて、スロットが保持している最小のLSN（`restart_lsn`）よりも古いWALは、たとえチェックポイントを超えても決して削除されません。
3. 同期の強制: これにより、レプリカが数時間オフラインになっても、再接続した瞬間に「まだ追いつける」という保証が手に入ります。
まさに、プライマリとレプリカの間に引かれた「絶対に切れない紐」のようなものです。
—
注意すべき「諸刃の剣」：ディスクフルへの道
熟練エンジニアの皆さんが重々承知している通り、この仕組みには最大の落とし穴があります。「スロットが保持し続けるWALファイルは、際限なく肥大化する」ということです。
もしレプリカが完全に死んでしまい、誰もそのスロットを消費しなくなったらどうなるか？プライマリのWAL領域は、ディスクが限界を迎えるまで膨れ上がり、最悪の場合、プライマリそのものがパニックに陥り停止します。
パフォーマンストラブルの勘所
もし「WAL領域が枯渇した」というアラートが鳴ったら、まず確認すべきは `pg_replication_slots` です。
SELECT slot_name, active, restart_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS replication_lag_size
FROM pg_replication_slots;
ここで `active = f` なのにWALが積まれているスロットを見つけたら、それが犯人です。迷わず手動で削除してください。自動化スクリプトを組む際は、この「死んだスロットの放置」がシステムダウンに直結することを肝に銘じる必要があります。
—
運用で一歩先に行くために
大規模な環境では、レプリケーションスロットの挙動を監視するだけでなく、`max_slot_wal_keep_size` を設定しておくことを強く推奨します。
PostgreSQL 13以降で導入されたこの設定は、「スロットがあっても、ここまでのサイズを超えたらWALをパージする」という安全装置です。これを設定しておけば、レプリカが壊れた際のプライマリの共倒れを防げます。
もちろん、これを設定するとレプリカの同期は切れますが、「レプリカの同期」と「プライマリの可用性」のどちらを取るべきか。その設計判断こそが、我々エンジニアの腕の見せ所ですよね。
—
まとめ：信頼を構築する仕組み
レプリケーションスロットは、単なる機能ではありません。それはデータベースの整合性を守るための、極めて高度な「状態管理」です。
- 健全な運用: 常にスロットの `restart_lsn` を監視し、放置されたスロットに目を光らせる。
- リスク管理: `max_slot_wal_keep_size` を活用して、システム全体の防御力を高める。
- 本質理解: WALは単なるログファイルではなく、レプリカとの対話の歴史であることを意識する。
技術の深淵を覗けば覗くほど、PostgreSQLのこうした「堅牢さへのこだわり」には感服させられます。皆さんも、スロットを単なる「便利な機能」として扱うのではなく、その裏にある複雑なステートマシンを想像しながら運用してみてください。
きっと、トラブルシューティングの景色が少し違って見えるはずです。
コメント