【PostgreSQL】論理レプリケーションを自前で動かしてみた実録

実際に手を動かすのが一番。ということで、PostgreSQLの論理レプリケーションをローカル環境で構築してみました。パブリッシャー（出す側）とサブスクライバー（受ける側）のやり取りを、実際にコマンドを叩きながら追いかけます。

1. 設定の落とし穴：wal_levelの変更

【 現場の感触 】 最初のハードルは設定変更です。デフォルトでは論理レプリケーション用のログが出ないので、`postgresql.conf` を書き換えます。再起動が必要なので、本番環境なら「ちょっと待って」となるところですね。

# wal_level を logical にして再起動！
show wal_level;

[ 結果 ]
wal_level
-----------
logical ← これで準備完了。

2. パブリケーションの作成と権限の「儀式」

【 現場の感触 】 テーブルを作ってデータを放り込みます。ここで大事なのは「主キー（PK）」があること。論理レプリケーションでは「どの行を更新するか」を特定するためにPKが必須です。あとは接続用の専用ユーザーを作って、権限を付与します。この「運び屋」を作る作業がレプリケーションっぽさを感じさせます。

-- 全テーブルを対象にパブリケーション作成
CREATE PUBLICATION pub FOR ALL TABLES;

-- レプリケーション専用の「運び屋」ユーザーを作る
CREATE ROLE repluser LOGIN REPLICATION PASSWORD 'repluser';
GRANT pg_read_all_data TO repluser;

3. 同期開始！サブスクリプションの威力

【 現場の感触 】 サブスクライバー側で接続情報を指定してサブスクリプションを作成。実行した瞬間に、既存のデータが「バッ」と流れてくるのは見ていて気持ちいいものです。試しにデータを1行追加すると、即座に反映されるのが確認できました。まさにリアルタイム！

-- サブスクライバー側で実行（ここで同期が始まる）
CREATE SUBSCRIPTION sub CONNECTION 'host=... user=repluser...' PUBLICATION pub;

-- パブリッシャー側で insert
insert into sample_table values(3, 'ccc');

-- サブスクライバー側で確認
select * from sample_table; → ちゃんと 3 | ccc が反映されている！

4. 応用：同期を止めても「裏で溜まっている」

【 現場の感触 】 運用でよくある「一時停止（DISABLE）」も試しました。停止中にパブリッシャー側でガシガシ更新（'ddd'を追加）しても、サブスクライバー側は静かなまま。でも、再度「ENABLE」にした瞬間、溜まっていた更新が追い付いてくる。この確実性が論理レプリの頼もしいところです。

★ 検証のまとめ：
1. DISABLEにすると、サブスクライバー側はピタッと止まる。
2. パブリッシャー側の変更は破棄されず、裏（スロット）に保持される。
3. ENABLEに戻すと、未反映分が高速に流し込まれる。

実際にやってみると、コマンド一発で同期が制御できる手軽さと、内部でWALがしっかり管理されている安心感がよく分かりました。バージョン間のデータ移行や、特定のデータ集約には最高に便利そうです。