目次
- 目次
- ロジカルレプリケーションとは
- 仕組み
- Auroraにおけるロジカルレプリケーション
- ロジカルレプリケーションがレプリカで有効化できない理由の考察
- wal2json
- おまけ: CDCとWAL
- 参考
ロジカルレプリケーションとは
PostgreSQLの論理レプリケーション（Logical Replication）は、データベース内の特定のテーブルやデータを他のデータベースに選択的かつ柔軟に複製する機能です。PostgreSQL 10以降で公式にサポートされており、従来の物理レプリケーションと比較して、より細かい制御が可能です。
論理レプリケーションの大きな特徴として、まずテーブル単位でのレプリケーションが挙げられます。データベース全体を複製するのではなく、必要なテーブルだけを選択して複製できるため、柔軟なデータ同期が実現できます。また、異なるPostgreSQLバージョン間でもレプリケーションが可能であり、たとえばPostgreSQL 12からPostgreSQL 15へのデータ同期もスムーズに行えます。
さらに、データのフィルタリングや変換を行いながらレプリケーションできる点も特徴的です。これにより、特定の条件を満たすデータのみを複製するなど、複雑なシナリオへの対応が可能になります。一部の構成では双方向レプリケーション（bi-directional replication）にも対応しており、複数のデータベース間で相互にデータを同期させることができます。
加えて、レプリカ側でもトリガーや制約を活用できるため、データの整合性を保ちながら柔軟な運用が可能です。これらの特徴により、PostgreSQLの論理レプリケーションは多様な用途に対応する強力な機能となっています。
仕組み
PostgreSQLの論理レプリケーションは、パブリッシャー（Publisher）とサブスクライバー（Subscriber）のモデルで動作します。このモデルにより、データの送信元と受信先を明確に分けて管理でき、柔軟なレプリケーション設定が可能となります。
パブリッシャーはデータを送信する役割を担います。レプリケーションの対象となるテーブルを指定するために、CREATE PUBLICATIONコマンドを使用して設定を行います。これにより、特定のテーブルやデータを外部のデータベースに公開する準備が整います。
一方、サブスクライバーはデータを受信する側です。CREATE SUBSCRIPTIONコマンドを使用して、パブリッシャーから送信されるデータの受信設定を行います。サブスクライバーはパブリケーションに基づいてデータを取得し、自身のデータベースに適用します。
このような仕組みにより、PostgreSQLの論理レプリケーションは特定のデータを選択的に同期させることができ、異なるシステム間でも効率的なデータ連携を実現します。
ストリーミングレプリケーションとの比較
Auroraにおけるロジカルレプリケーション
Amazon Auroraのストリーミングレプリケーションは、従来のPostgreSQLやMySQLのレプリケーションとは異なる独自のアーキテクチャで設計されています。Auroraはデータベースの高可用性、パフォーマンス、スケーラビリティを実現するために、分散ストレージシステムと連携した効率的なレプリケーションメカニズムを採用しています。
Auroraにおけるストリーミングレプリケーションの仕組み
分離されたストレージとコンピュートのアーキテクチャ Auroraは、ストレージ層とコンピュート層を分離したアーキテクチャを採用しています。これにより、データはAuroraクラスタの分散ストレージに書き込まれ、すべての読み取り専用リーダーインスタンスが同じストレージから直接データを読み取ることが可能です。この構造により、従来のストリーミングレプリケーションで必要だった複雑なデータ転送のオーバーヘッドが削減されます。
Auroraストレージの分散設計
Auroraのストレージは、6つのコピーが3つの異なるアベイラビリティゾーン（AZ）に分散して保存されます。この分散ストレージにより、データの耐障害性と高可用性が確保されます。データは4/6のマジョリティ書き込みでコミットが完了し、読み取りも同様にマジョリティに基づいて行われます。
リーダーインスタンスの高速レプリケーション
Auroraでは、リーダーインスタンスがプライマリインスタンスのストレージ層に直接アクセスすることで、データの即時一貫性（eventual consistency）が保証されます。従来のPostgreSQLのようなWAL（Write-Ahead Logging）をファイルベースで転送する必要がなく、サブミリ秒単位のレプリケーション遅延が実現されています。
Aurora専用のログベースレプリケーション
Aurora PostgreSQLでは、PostgreSQLのWAL（Write-Ahead Log）に類似したAurora専用のログ構造が使用されますが、WALを直接ファイルとして扱うのではなく、ストレージレベルで管理されます。このため、レプリケーションの遅延が最小限に抑えられ、データの整合性が確保されます。
ロジカルレプリケーションがレプリカで有効化できない理由の考察
1. WALの生成と管理の制限
Auroraのリードレプリカは読み取り専用であるため、書き込み操作を行うことができず、それに伴いWAL（Write-Ahead Logging）の生成も行われません。ロジカルレプリケーションは、このWALを基にデータの変更をキャプチャする仕組みであるため、リードレプリカ上でロジカルレプリケーションが機能しないのは当然の結果と言えます。これはAurora特有の制約であり、標準的なPostgreSQL環境とは異なる動作を示します。
2. ストレージアーキテクチャの違い
AuroraはPostgreSQLとは異なる独自の分散ストレージアーキテクチャを採用しており、この設計はWALを利用した標準的なロジカルレプリケーションのフローと直接的な互換性がありません。Auroraのストレージ層は、データの変更を内部的に最適化された方法で複製・管理しており、このプロセスはPostgreSQLのロジカルレプリケーションの仕組みと競合する可能性があります。そのため、Auroraではロジカルレプリケーションの実装や運用において、標準的なPostgreSQLとは異なるアプローチが求められます。
wal2json
wal2json は、PostgreSQLのWrite-Ahead Logging (WAL) をJSON形式で出力するための出力プラグインです。主に、PostgreSQLの論理レプリケーション機能を活用して、データベース内の変更（INSERT、UPDATE、DELETEなど）をリアルタイムで外部システムに伝える際に使われます。
