論理レプリケーションとCDC・論理デコーディング

WAL から「行の変更」を取り出すという発想

WAL（先行書き込みログ）は本来、クラッシュリカバリのために「ページのどのバイトをどう書き換えたか」という物理操作を記録します。レプリカはこれを redo と同じ機構でそのまま再生すれば、プライマリと厳密に同一のバイト像になります。しかしこの物理表現は、版・OS・ページ形式の完全一致を要求し、テーブル単位の選択も異種DB連携もできません（物理 vs 論理の全体像）。

論理デコーディングは、この同じWALを起点に、まったく別の抽象へ翻訳する仕組みです。狙いは「ストレージの再現」ではなく「データの再現」、すなわち テーブル T の行が INSERT され、各列の値はこれ という行レベルの変更イベントをWALから取り出すことにあります。これができれば、レプリケーションだけでなく、変更を外部のあらゆるシステムへ波及させる**CDC（Change Data Capture）**の土台になります。

問題は、WALは論理的な意図をそのまま持っていない点です。記録されているのは物理操作であり、しかも複数トランザクションのレコードが時間順にインターリーブされています。論理デコーディングは、ここから元のトランザクション構造と列の意味を復元しなければなりません。

論理デコーディングの内部動作

論理デコーディングは、おおむね次の段階でWALを論理変更へ変換します。

中核は**リオーダーバッファ（reorder buffer）**です。WALを前から読むと、まだコミットしていない複数トランザクションの変更が混ざって流れてきます。これをそのまま出すと、ロールバックされる変更まで配ってしまいます。そこでデコーダはトランザクションID（XID）ごとに変更を一時バッファへ溜め、コミットレコードに到達した瞬間に、そのトランザクションの変更群をまとめてコミット順に出力します。アボートしたトランザクションのバッファは破棄されます。これにより、出力ストリームは「コミット済みの変更だけが、コミットされた順に並ぶ」ことが保証されます。

UPDATE と DELETE では、どの行が対象かを下流が特定できなければなりません。そのために**識別子（PostgreSQL では REPLICA IDENTITY）**の設定が効きます。既定では主キーを旧像として送りますが、FULL にすると全列の旧値を送れます。主キーが無く識別子も未設定のテーブルでは、UPDATE/DELETE をデコードできず失敗します。設計時に見落としやすい前提です。

レプリケーションスロット――位置と保持の管理

論理デコーディングを「止めても欠落しない」配送にしているのがレプリケーションスロットです。スロットは消費者ごとに作られる永続的な状態で、二つの役割を持ちます。

第一に、消費位置の永続化です。消費者が「ここまで受け取って永続化した」と通知すると、スロットはその位置（confirmed_flush LSN）を記録します。消費者が切断・再接続しても、スロットはこの位置を覚えているので、最後に確定した位置の直後からストリームを再開できます。これが再接続時の取りこぼし防止の根幹です。

第二に、**WALの保持（retention）**です。スロットは「まだ消費されていない最古の位置」を restart_lsn として保持し、データベースに対して「この位置より新しいWALは捨てるな」と要求します。論理デコードはコミット前から変更を読み始める必要があるため、restart_lsn はコミットされていないトランザクションの開始位置までさかのぼります。

出力プラグイン――デコード結果をどの形で出すか

リオーダーバッファが組み立てた論理変更を、実際に流す形式へ整形するのが出力プラグインです。デコーダ本体（変更の取り出しと順序付け）と、出力形式（バイト列への変換）を分離した設計であり、ここがCDCの拡張点になります。

プラグインは、デコーダから渡されるコールバック（トランザクション開始・各行の変更・コミット）に応じて、任意のフォーマットを生成します。代表例は次の通りです。

この分離があるおかげで、同じ論理デコード基盤の上に、PostgreSQL間レプリケーションも、JSONを食う外部パイプラインも、protobufで効率配送するCDC基盤も、プラグインを差し替えるだけで載せられます。MySQL には論理デコーダという同名の機構はありませんが、行ベースの binlog（ROW フォーマット）を読むことで等価な行レベル変更ストリームが得られ、CDC ツールはこれを抽象化して同じインターフェースで扱います。

CDC パイプラインへの応用

論理デコーディングと出力プラグインを組み合わせると、行レベルの変更ストリームを外部へ公開するCDCが成立します。狙いはレプリカ作成にとどまらず、検索インデックス・キャッシュ・データウェアハウス・ストリーム処理へ、データベースの全変更を順序付きで波及させることにあります。ログベースCDCは元からあるWALを読むだけなので、本番の書き込み経路にほぼ追加負荷をかけず、削除も含めて取りこぼしません。トリガベースやポーリング差分が抱える「アプリ負荷の増大」「削除の取りこぼし」を構造的に回避できます。

典型的なパイプラインは「初期スナップショット＋以後の変更ストリーム」で構成されます。

1. スナップショット取得開始時の LSN を記録（snapshot_lsn）
2. 既存データを一括コピー（初期ロード）
3. snapshot_lsn 以降の論理変更ストリームを購読
4. 各変更を主キー UPSERT で冪等に適用
5. confirmed_flush LSN を永続化し、スロットへ ack

整合性の保証は、本質的に二本柱です。第一に位置管理――各変更は単調増加する LSN（MySQL なら GTID）を持ち、消費者は「どこまで適用したか」をこれで永続化します。第二に冪等適用――ストリーミングはほぼ at-least-once（重複しうる）なので、再接続で同じ変更を二度受け取りえます。主キー UPSERT と適用済み位置の比較で、重複しても結果が変わらないようにします。さらに、トランザクション境界をまたいで適用しないことで、部分適用による中間状態の露出を防ぎます。リオーダーバッファがTx単位でまとめて出すのは、この境界尊重を下流で容易にするためでもあります。

まとめ

論理デコーディングは、クラッシュリカバリ用の物理ログであるWALを、行レベルの論理変更ストリームへ翻訳する仕組みです。WALレコードを再アセンブルし、システムカタログ（履歴スナップショット）で列の意味を与え、リオーダーバッファでトランザクション単位に集約してコミット順に出力します。これを「止めても欠落しない」配送にしているのがレプリケーションスロットで、消費位置の永続化とWAL保持という二役を担いますが、止まったスロットがWALを溜め込む運用リスクと裏表です。出力形式は出力プラグインで差し替えでき、同じ基盤の上に論理レプリケーションも外部CDCも載せられます。応用としてのCDCは、本番に無負荷で全変更を順序付きに公開し、整合性はLSN/GTIDの位置管理と冪等適用で担保します。トランザクションの境界を尊重したコミット順出力こそが、下流での正しい再構成を可能にする要です。