PostgreSQL 邏輯解碼概念

邏輯解碼是一種將對數(shù)據(jù)庫表的所有持久更改抽取到一種清晰、易于理解的格式 的處理，這種技術(shù)允許在不了解數(shù)據(jù)庫內(nèi)部狀態(tài)的詳細(xì)知識的前提下解釋該格式。

在PostgreSQL中，邏輯解碼通過解碼 預(yù)寫式日志的內(nèi)容來實現(xiàn)，預(yù)寫式日志描述了存儲 層面上的更改，而邏輯解碼則會把更改解碼成一種應(yīng)用相關(guān)的形式，例如一個元組 流或者 SQL 語句流。

在邏輯復(fù)制的環(huán)境下，一個槽表示一個更改流，這些更改可以在客戶機(jī)上以它們在原服務(wù)器上產(chǎn)生的順序被重播。每一個流從一個單一數(shù)據(jù)庫中流式傳送更改序列。

一個復(fù)制槽在一個PostgreSQL集簇的所 有數(shù)據(jù)庫之間具有一個唯一的標(biāo)識符。槽在使用它們的連接之間保持獨立并且 對于崩潰是安全的。

在常規(guī)操作中，一個邏輯槽只會把每次更改發(fā)出一次。 只有在檢查點時才會持久化每一個槽的當(dāng)前位置，因此如果發(fā)生崩潰，槽可能會回到一個較早的 LSN，這會導(dǎo)致服務(wù)器重啟時再次發(fā)送最近的更改。 邏輯解碼客戶端負(fù)責(zé)避免多次處理同一消息導(dǎo)致的副作用。 客戶端可能會希望在解碼時記錄它們看到的最新的 LSN，并且跳過任何從該 LSN 解碼得到的重復(fù)數(shù)據(jù)或者（使用復(fù)制協(xié)議時的）請求，而不是讓服務(wù)器來決定開始點。 復(fù)制進(jìn)度跟蹤特性就是為此服務(wù)的，請參考復(fù)制源頭。

對于同一個數(shù)據(jù)庫可能會存在多個獨立的槽。每一個槽有自己的狀態(tài)，允許不 同的消費者從該數(shù)據(jù)庫的更改流中的不同點開始接收更改。對于大多數(shù)應(yīng)用， 每一個消費者都將要求一個單獨的槽。

邏輯復(fù)制槽完全不知道接收者的狀態(tài)。甚至可能會有多個不同的接收者在不同 時間使用同一個槽，它們將只是從上一個接收者停止消費更改的地方開始得到 更改。但在任一給定時刻，只有一個接收者可以從一個槽中消費更改。

輸出插件將數(shù)據(jù)從預(yù)寫式日志的內(nèi)部表示轉(zhuǎn)換成復(fù)制槽的消費者所需的格式。

當(dāng)使用流復(fù)制接口創(chuàng)建一個新的復(fù)制槽時（見CREATE_REPLICATION_SLOT），一個快照將被導(dǎo)出（見 第 9.27.5 節(jié)），在它所顯示的 數(shù)據(jù)庫狀態(tài)之后所有的更改都將被包括在更改流中。通過使用 SET TRANSACTION SNAPSHOT讀取槽被創(chuàng)建時的數(shù)據(jù)庫狀態(tài)，這可以用來創(chuàng)建 一個新的復(fù)制。然后這個事務(wù)可以被用來及時轉(zhuǎn)儲那一點的數(shù)據(jù)庫狀態(tài)，它后來 可以被槽的內(nèi)容更新而不丟失任何更改。

并非總能夠創(chuàng)建快照。特別是在連接到熱備時，快照創(chuàng)建將會失敗。不要求快照導(dǎo)出的應(yīng)用可以用NOEXPORT_SNAPSHOT選項來抑制它。 option.