我被要求對後端使用 postgresql 的應用程序進行逆向工程。我可以看到正在進行一些數據庫複製……根據我的閱讀，我認為它被稱為流複製。主伺服器上的設置如下所示：

wal_level = hot_standby
max_wal_senders = 5
wal_keep_segments = 32

我的問題是：什麼會影響在主伺服器上創建新記錄與它何時顯示/被複製到從伺服器之間的延遲？

通過閱讀手冊，（http://www.postgresql.org/docs/current/static/hot-standby.html）我看到它使用的模型是“最終一致性”……該頁面上的第 4 段指出：

備用伺服器上的數據需要一些時間才能從主伺服器到達，因此在主伺服器和備用伺服器之間會有可測量的延遲。因此，在主數據庫和備用數據庫上幾乎同時執行相同的查詢可能會返回不同的結果。我們說備用數據庫上的數據最終與主數據庫一致。

但是是否有任何模式/方法來猜測需要多長時間？還是真的只是隨意的？

如果您能指出我正確的方向，我將不勝感激。謝謝。

我的問題是：什麼會影響在主伺服器上創建新記錄與它何時顯示/被複製到從伺服器之間的延遲？

真正重要的是什麼

複製延遲取決於幾件事。

歸檔命令僅在已完成的 WAL 段上呼叫。因此，如果您的伺服器只產生很少的 WAL 流量（或者在它這樣做的時候有鬆弛期），那麼在事務完成和它在存檔儲存中的安全記錄之間可能會有很長的延遲。要限制**未歸檔數據的陳舊時間，您可以設置archive_timeout強制伺服器至少經常切換到新的 WAL 段文件。請注意，由於強制切換而提前歸檔的歸檔文件的長度仍與完全完整的文件相同。**因此，設置一個非常短的 archive_timeout 是不明智的——它會使你的存檔儲存膨脹。archive_timeout一分鐘左右的設置通常是合理的。

wal_level

首先，為了有意義地使用流複製，必須將 WAL 設置為hot_standby（現在replica在 9.6+ 中呼叫）。如果需要，邏輯解碼對於理解 WAL 日誌很有用。例如，使用邏輯解碼，您可以使用這些外掛：

• test_decoding – 預設外掛
• wal2json – 顯示 JSON 格式的變化
• decoder_raw – 重構應用了更改的查詢

有關更多資訊，請參閱此文章

提到的其他事情

我認為這些東西並不重要，

• wal_keep_segments這儲存了您保留的過去日誌文件的數量。如果超過此限制，您將失去同步。如果您傳輸速度足夠快並且沒有連接中斷，我不確定它有多重要。您現在可以使用複制槽以更好的方式執行此操作。
• max_wal_sendersWAL 運輸要麼有效，要麼無效。您在導出 wal 日誌以啟用複制的伺服器上設置此設置，但它與max_connections.

我可以建議一種對我有效的粗略方法。

• 創建一個 python 腳本，在幾毫秒後輪詢特定表，並在行數更改時列印時間戳。
• 保持這個腳本在 master 和 slave 上執行。因此，當您在主數據庫上插入一條記錄時，您將獲得該記錄在每個數據庫上可用時的時間戳。
• 然後，您可以比較時間戳並獲得延遲。（假設主從時鐘均為 UTC）

我想延遲將取決於事務中傳輸的數據量以及連接兩台機器的網路速度。

引用自：https://dba.stackexchange.com/questions/93221