2025年9月25日: PostgreSQL 18 釋出!
支援的版本: 當前 (18) / 17 / 16 / 15 / 14 / 13
開發版本: devel
不支援的版本: 12 / 11 / 10

54.5. 邏輯流複製協議 #

本節描述邏輯複製協議,這是由 START_REPLICATION SLOT slot_name LOGICAL 複製命令啟動的訊息流。

邏輯流複製協議建立在物理流複製協議的原語之上。

PostgreSQL 邏輯解碼支援輸出外掛。pgoutput 是用於內建邏輯複製的標準外掛。

54.5.1. 邏輯流複製引數 #

使用 START_REPLICATION 命令,pgoutput 接受以下選項

proto_version

協議版本。目前支援版本 1234。需要有效的版本。

版本 2 僅支援伺服器版本 14 及更高版本,它允許流式傳輸大型進行中的事務。

版本 3 僅支援伺服器版本 15 及更高版本,它允許流式傳輸兩階段提交。

版本 4 僅支援伺服器版本 16 及更高版本,它允許並行應用大型進行中事務的流。

publication_names

要訂閱(接收更改)的釋出名稱的逗號分隔列表。單個釋出名稱被視為標準物件名稱,可以根據需要進行引用。至少需要一個釋出名稱。

binary

用於使用二進位制傳輸模式的布林選項。二進位制模式比文字模式更快,但稍微不太健壯。

messages

用於啟用傳送由 pg_logical_emit_message 寫入的訊息的布林選項。

streaming

啟用進行中事務流式傳輸的選項。有效值為 off(預設)、onparallelparallel 設定可啟用為某些訊息傳送額外資訊以供並行化使用。啟用 on 需要最低協議版本 2。對於 parallel 值,需要最低協議版本 4。

two_phase

啟用兩階段提交事務的布林選項。啟用它需要最低協議版本 3。

origin

透過其源傳送更改的選項。可能的值為 none,僅傳送沒有關聯源的更改;或 any,無論源如何都發送更改。這可用於避免複製節點之間出現迴圈(同一資料的無限複製)。

54.5.2. 邏輯複製協議訊息 #

各個協議訊息將在以下子節中討論。各個訊息在 第 54.9 節 中進行了描述。

所有頂層協議訊息都以一個訊息型別位元組開始。雖然在程式碼中表示為字元,但這是一個有符號位元組,沒有相關的編碼。

由於流複製協議提供了訊息長度,因此不需要頂層協議訊息在其頭部嵌入長度。

54.5.3. 邏輯複製協議訊息流 #

除了 START_REPLICATION 命令和重放進度訊息外,所有資訊都只從後端流向前端。

邏輯複製協議逐個傳送事務。這意味著一對 Begin 和 Commit 訊息之間的所有訊息都屬於同一個事務。同樣,一對 Begin Prepare 和 Prepare 訊息之間的所有訊息也屬於同一個事務。它還會在一對 Stream Start 和 Stream Stop 訊息之間傳送大型進行中事務的更改。此類事務的最後一個流包含 Stream Commit 或 Stream Abort 訊息。

每個傳送的事務都包含零個或多個 DML 訊息(Insert、Update、Delete)。在級聯設定的情況下,它還可以包含 Origin 訊息。Origin 訊息指示事務起源於不同的複製節點。由於在邏輯複製協議的範圍內,複製節點幾乎可以是任何東西,因此唯一的識別符號是 origin 名稱。下游負責根據需要(如果需要)處理此資訊。Origin 訊息始終在事務中的任何 DML 訊息之前傳送。

每個 DML 訊息都包含一個 relation OID,用於標識所操作的釋出者的關係。在給定 relation OID 的第一個 DML 訊息之前,將傳送一個 Relation 訊息,描述該關係的模式。之後,如果關係的定義自上次為此關係傳送 Relation 訊息以來發生了變化,將傳送一個新的 Relation 訊息。(協議假定客戶端能夠為所需數量的關係記住此元資料。)

Relation 訊息透過 OID 標識列型別。對於內建型別,假定客戶端可以在本地查詢該型別 OID,因此不需要額外資料。對於非內建型別的 OID,將在 Relation 訊息之前傳送一個 Type 訊息,以提供與該 OID關聯的型別名稱。因此,需要專門識別關係列型別的客戶端應該快取 Type 訊息的內容,並首先查閱該快取以檢視型別 OID 是否已在此定義。如果沒有,則在本地查詢型別 OID。

提交更正

如果您在文件中發現任何不正確、與您在使用特定功能時的體驗不符或需要進一步說明的內容,請使用 此表格 報告文件問題。