流復制協議中適當的備用狀態更新

Question

問題是關於流復制協議。 這非常簡單，專為物理復制而設計，能夠：

• 發送服務器狀態 > Primary keepalive message
• 接收副本狀態 > Standby status update
• 發送 WAL 數據 > XLogData

還有邏輯解碼，使用相同的 XLogData 幀發送插件從 WAL 解碼的數據，例如pglogical而不是原始 WAL。

Streaming Replication 希望我提交備用狀態更新，以釋放資源並刪除舊的 WAL，根據文檔

最后一個 WAL 字節的位置 + 1...

pglogical在 XLogData 幀中使用它自己的消息返回它自己的 LSN 位置，但這些是不可用的。

當數據寫入不同的數據庫時，邏輯解碼不起作用。 而slot position還需要更新，否則slot會丟失。 因此，唯一的方法是從Primary keepalive message發送 LSN 位置，根據文檔發送

服務器上 WAL 的當前端。

這令人困惑。 如果插槽在 position 100 而服務器已經在 200 上怎么辦？

所以，

在試驗和檢查 pg_recvlogical 的來源之后，了解到， Primary keepalive message並不意味着“服務器上 WAL 的當前結束”，但實際上從插槽 position 逐漸增加到當前（ pg_current_wal_lsn() ）服務器 LSN。 中間有 XLogData 幀（如果有的話）。 似乎，消息是按 LSN 順序接收的。

現在，問題：

Q1）它是否記錄在某處？

Q2）有意義嗎？ 我誤解了什么嗎？

Q3) 流消息總是按 LSN 排序嗎？

Q4) 可以從Primary keepalive message中提交位置嗎？

Answer 1

據此

writePtr 是 WAL 發送到的位置。 它本質上是
與 sentPtr 相同，但在某些情況下，我們需要先發送 keep alive
sentPtr 像跳過空交易時一樣更新。

然后寫在

pq_sendint64(&output_message, XLogRecPtrIsInvalid(writePtr) ? sentPtr : writePtr);

這意味着，服務器上 WAL 的當前端。 實際上是 WAL 被發送到的位置