★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 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

55.5. 論理ストリーミングレプリケーションのプロトコル

この節では論理レプリケーションのプロトコルについて説明します。 このプロトコルはレプリケーションコマンドSTART_REPLICATION SLOT slot_name LOGICALで始まるメッセージフローです。

論理ストリーミングレプリケーションのプロトコルは、物理レプリケーションプロトコルの基本要素の上に構築されています。

55.5.1. 論理ストリーミングレプリケーションのパラメータ

論理レプリケーションのSTART_REPLICATIONコマンドは以下のパラメータを受け付けます。

proto_version

プロトコルバージョン。現在12、および3がサポートされています。

バージョン2は、サーババージョン14以降でのみサポートされており、大規模な進行中トランザクションのストリーミングが可能です。

バージョン3はサーババージョン15以降でのみサポートされており、2フェーズコミットのストリーミングが可能です。

publication_names

サブスクライブする(変更を受け取る)対象となるパブリケーション名をカンマで区切ったリストです。 個々のパブリケーション名は標準的なオブジェクト名と扱われ、必要に応じて引用符で括ることができます。

55.5.2. 論理レプリケーションのプロトコルのメッセージ

個々のプロトコルのメッセージについては以降の副節で説明します。 個々のメッセージについては55.9で説明されています。

トップレベルのプロトコルのメッセージはすべてメッセージタイプのバイトで始まります。 コード内では文字として表現されますが、これは文字符号化のないバイト(符号付き)です。

ストリーミングレプリケーションのプロトコルはメッセージ長を含むため、トップレベルのプロトコルのメッセージはそのヘッダに長さを埋め込む必要がありません。

55.5.3. 論理レプリケーションのプロトコルのメッセージフロー

START_REPLICATIONコマンドと再生進捗のメッセージを除き、すべての情報はバックエンド側からフロントエンド側にのみ流れます。

論理レプリケーションのプロトコルは、個々のトランザクションを一つずつ送信します。 これはつまり、BeginとCommitのメッセージの対の間にある全てのメッセージは同じトランザクションに属するということです。 同様に、Begin PrepareとPrepare messagesの間のすべてのメッセージが同じトランザクションに属しています。 また、ストリーム開始とストリーム終了メッセージの対の間の大きな継続中トランザクションの変更を送信します。 そのようなトランザクションの最後のストリームは、ストリームコミットあるいはストリームアボートメッセージを含んでいます。

送信されるすべてのトランザクションにはゼロ個以上のDMLメッセージ(Insert、Update、Delete)が含まれます。 カスケードの設定がされている場合は、Originメッセージを含めることができます。 Originメッセージはトランザクションの起点が別のレプリケーションノードであることを示します。 論理レプリケーションのプロトコルという観点では、レプリケーションノードはほぼ何でも良いため、唯一の識別子はOriginの名前です。 (必要なら)必要に応じてこれを処理するのは下流側の責任です。 Originメッセージは必ずトランザクション内のどのDMLよりも前に送信されます。

すべてのDMLメッセージには、パブリッシャーが処理していたリレーションOIDが含まれています。 指定されたリレーションOIDの最初DMLメッセージの前に、リレーションのスキーマを記述するリレーションメッセージが送られます。 最後に送信されたリレーションメッセージ以降にリレーションの定義が変更されていたら、続いて新しいリレーションメッセージが送信されます。 (必要なだけクライアントはこのメタデータを記憶できるとプロトコルは見なしています。)

リレーションメッセージはOIDによって列型を識別します。 組み込みの型では、クライアントはローカルに型OIDを検索できると見なされ、追加のデータは必要ありません。 組み込み以外の型OIDでは、OIDに紐づく型名を提供するために、リレーションメッセージの前に型メッセージが送られます。 したがって、リレーションの列の型を特に識別する必要のあるクライアントは、型メッセージの内容をキャッシュし、型OIDがキャッシュにあるかどうかまずキャッシュを調べるべきです。 もしなければ、ローカルでその型OIDを調べます。