PostgreSQLには2種類のレプリケーションがあります。物理レプリケーション（バイナリログのバイト単位コピー）と論理レプリケーション（WALを論理的にデコードして流す）です。物理レプリケーションは「複製を作る」、論理レプリケーションは「変更イベントを取り出す」のが本質的な違いです。CDCの基礎となるのは論理レプリケーションです。
PostgreSQL 10（2017年）から組み込まれ、いまや本格的なCDC基盤として使われています。PublisherとSubscriberの設定だけでDBへのレプリケーションができ、Debeziumなどの外部CDCツールも内部的にはこれを使っています。仕組みと運用を整理します。
論理レプリケーションのアーキテクチャ
| 要素 | 役割 |
|---|---|
| Publication | 送信側で「どのテーブルを公開するか」を宣言 |
| Subscription | 受信側で「どのPublicationを購読するか」を宣言 |
| Replication Slot | WALを保持するための「予約席」 |
| Publisher | 送信側PostgreSQL |
| Subscriber | 受信側PostgreSQL（または外部ツール） |
基本セットアップ
-- 送信側（Publisher）
ALTER SYSTEM SET wal_level = 'logical';
-- 再起動が必要
CREATE PUBLICATION pub_orders FOR TABLE orders, customers;-- 受信側（Subscriber）
CREATE SUBSCRIPTION sub_orders
CONNECTION 'host=publisher dbname=shop user=replicator password=...'
PUBLICATION pub_orders;これだけでPublicationのテーブルがSubscriberに継続的にレプリケーションされます。初回は全データのコピー、以降はWAL経由の変更が反映されます。
Replication Slotsの仕組み
論理レプリケーションを支えるのが「Replication Slots」です。これは「Subscriberが読み終わるまでWALを保持する予約席」で、Subscriberがダウンしていても、Slotがある間はPublisher側でWALが保存され続けます。
これが二つの意味で重要です。Subscriberが復旧したときに取りこぼしなく続きから再開できます。しかし、Slotを放置すると無限にWALが溜まってディスクが満杯になります。「使われていないSlotはすぐ削除」が運用の鉄則です。
Debeziumから使う
Debeziumは「外部Subscriber」として、PostgreSQLの論理デコーディング機能を使います。論理レプリケーション機能（特に`pgoutput`プラグイン）の上に乗っているのがDebezium PostgreSQL Connectorです。
つまり「Debeziumを使う前提として、PostgreSQL側で論理レプリケーション設定が必要」ということです。Debeziumの基本はDebezium とはを参照してください。
マネージドPostgreSQLでの利用
| サービス | 論理レプリケーション |
|---|---|
| AWS RDS / Aurora | パラメータグループで`rds.logical_replication = 1`を設定 |
| Google Cloud SQL | `cloudsql.logical_decoding = on`フラグ |
| Azure DB for PostgreSQL | `wal_level = logical`をサーバーパラメータで |
| Supabase / Neon等 | 標準で有効化可能 |
主要クラウドで対応しています。ただし、SUPERUSER相当の権限が無いとSlot作成に制限がある場合があり、各クラウド独自の運用手順を確認します。
運用上のハマりどころ
- 使われないSlotでディスク満杯：もっとも多い事故。Slotが残ったままSubscriberが消えると、WAL保持が無限に伸びてディスクが満杯になり、DB全体が停止する。
- 大きなテーブルの初回同期：Subscription開始時、Publication対象のテーブル全体がコピーされる。本番DBへの初期負荷を読む。
- スキーマ変更の非対応：論理レプリケーションはDDL（ALTER TABLE等）を流さない。スキーマ変更は両側で個別に行う。
- シーケンスとプライマリキー：シーケンスはレプリされない。プライマリキー無いテーブルは制約がある。
向く・向かない場面
- 向く：PostgreSQL→PostgreSQLの論理レプリ、Debezium経由のCDC基盤、複数DBへの同時配信、特定テーブルのみのレプリケーション
- 向かない：DDLも含めた完全な複製（→物理レプリケーション）、PostgreSQL以外のDB、Slotsの運用ができない
まとめ
- 論理レプリケーションはPostgreSQL 10以降の組み込みCDC基盤。
- Publication/Subscriptionモデルでテーブル単位のレプリケーションが可能。
- Replication Slotsで再開可能性を担保、ただし放置するとディスク満杯リスク。
- DebeziumのPostgreSQL Connectorは内部的にこれを使う。
- 主要マネージドPostgreSQL（RDS/Cloud SQL/Azure）で有効化可能。
全体像はCDC実装ガイド、隣接はDebezium とは・Snowflake Streams CDC。論理レプリケーション運用の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. 物理レプリケーションとどう違う？
A. 物理レプリケーションは「DBファイルのバイト単位の複製」で、本番からの読み取り専用レプリカ（Hot Standby）に使われます。論理レプリケーションは「変更イベントの送信」で、テーブル単位の選択、異なるPostgreSQLバージョン間のレプリ、外部CDCへの中継、などができます。役割が異なるため、要件で使い分けます。
Q. Replication Slotがどれくらい溜まったら危険？
A. `pg_stat_replication_slots`や`pg_replication_slots`の`confirmed_flush_lsn`と現在のWAL位置を比較し、ラグを監視します。GBオーダーで溜まり始めたら警戒、TBオーダーで緊急対応です。Subscriberが復旧見込みがない場合は、`SELECT pg_drop_replication_slot(‘slot_name’);`で削除します。
Q. DDLをレプリケーションする方法は？
A. 標準の論理レプリケーションではDDLは流れません。PostgreSQL 16からDDLレプリケーションがプレビュー的に入っていますが、本格運用は別途検討が要ります。一般的には、両側でDDLを同期して実行する手順を運用に組み込みます。
Q. Subscriberとして外部ツール（Debezium・Fivetran等）を使うのは安全？
A. 安全に運用できます。これらのツールは論理デコーディングAPIを使ってWALを読むので、PostgreSQL本体への負荷は最小限です。ただしReplication Slotsの管理が外部ツール側に移るので、ツール側の障害や設定ミスで本番DBが影響を受けるリスクがあります。Slot監視とアラートを運用する前提で導入します。