他のバージョンの文書 18 | 17 | 16 | 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

29.9. アーキテクチャ #

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

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

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

29.9.1. 初期スナップショット #

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

注記

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

注記

コピー中にテーブル同期ワーカーが失敗した場合、適用ワーカーが失敗を検出し、テーブル同期ワーカーを再生成して同期プロセスを続行します。 この動作により、一時的なエラーによってレプリケーションのセットアップが永続的に中断されることがなくなります。 wal_retrieve_retry_intervalも参照してください。