他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

31.7. アーキテクチャ

論理レプリケーションは、パブリッシャー側のデータベース上のデータのスナップショットをコピーすることから始まります。 それが完了したあとは、パブリッシャーにおける変更は、発生した時にリアルタイムでサブスクライバーに送られます。 サブスクライバーはパブリッシャーでコミットが発生した順にデータを適用します。 そのため、どの単一のサブスクリプションにおいても、パブリケーションに対するトランザクションの一貫性が保証されます。

論理レプリケーションは物理ストリーミングレプリケーション(27.2.5参照)と似たアーキテクチャで構成されています。 WAL送信プロセスと適用プロセスで実装されています。 WAL送信プロセスはWALのロジカルデコーディング(第49章に記載)を開始し、標準のロジカルデコーディングプラグイン(pgoutput)をロードします。 このプラグインは、WALから読み込んだ更新を論理レプリケーションプロトコル(55.5参照)に変換します。 そして、パブリケーションの指定にしたがってフィルタします。 データは次に、ストリーミングレプリケーションプロトコルを使って継続的に適用ワーカーに転送されます。 適用ワーカーは、データをローカルテーブルにマップし、更新を受信すると正しいトランザクション順に個々の更新を適用します。

サブスクライバーデータベース上の適用プロセスは、常にsession_replication_rolereplicaに設定して実行されます。 これは、デフォルトでは、トリガーとルールはサブスクライバー上では起動されないことを意味します。 ユーザーは、必要に応じて、 ALTER TABLEコマンド、ENABLE TRIGGERおよびENABLE RULE句を使用して、テーブルのトリガーおよびルールを有効にすることを選択できます。

今のところ、論理レプリケーション適用プロセスは行トリガーだけを起動し、文トリガーは起動しません。 ただし、初期テーブル同期はCOPYコマンドのように実装されているので、INSERTの行と文トリガーの両方を起動します。

31.7.1. 初期スナップショット

既存のサブスクライブされたテーブル中の初期データのスナップショットが取得され、特殊な適用プロセスの並列インスタンスにコピーされます。 このプロセスは自身のレプリケーションスロットを作成し、既存のデータをコピーします。 コピーが終わるとすぐにテーブル内容が他のバックエンドから見えるようになります。 既存のデータのコピーが終わると、ワーカーは同期モードに入ります。 このモードでは、初期データのコピー中に起こった更新を標準の論理レプリケーションを使ってストリーミングすることにより、テーブルが主適用プロセスと同期状態になることを保証します。 この同期フェーズの間、パブリッシャーで発生したのと同じ順序で変更が適用され、コミットされます。 ひとたび同期が完了すれば、テーブルのレプリケーションの制御は主適用プロセスに戻され、レプリケーションは通常通り継続されます。

注記

パブリケーションのパブリッシュパラメータは、レプリケーションされるDML操作にのみ影響します。 初期データ同期では、既存のテーブルデータをコピーするときにこのパラメータは考慮されません。