為什麼 Postgres 複製 write_lag 以秒為單位

我在pg_receivewal本地執行，沒有壓縮，它將段與 db 文件儲存在同一個驅動器上。這是複制統計資訊：

imbolc=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 12920                   
usesysid         | 10                           
usename          | postgres                
application_name | pg_receivewal                
client_addr      |               
client_hostname  |                
client_port      | -1             
backend_start    | 2019-08-25 13:18:00.504531+07
backend_xmin     |               
state            | streaming                    
sent_lsn         | C/80009218              
write_lsn        | C/80009218                   
flush_lsn        |                         
replay_lsn       |                              
write_lag        | 00:00:09.838314         
flush_lag        | 00:00:40.028949              
replay_lag       | 00:00:40.028949
sync_priority    | 0              
sync_state       | async

如果我設置synchronous_commit = off，write_lag仍然很重要，超過 2.5 秒。

所以我的問題是：

• 為什麼write_lag這麼高？
• 這是否意味著如果數據庫崩潰，最後 10 秒的事務可能會失去？
• 有沒有辦法改進它？

這是否意味著如果數據庫崩潰，最後 10 秒的事務可能會失去？

如果數據庫發生“軟”崩潰，例如電源故障，它將在啟動時進行自動恢復，並使用它在 pg_wal 或 pg_xlog 目錄中找到的日誌文件恢復所有事務（除了可能失去到 synchronous_commit = off 的事務） . pg_receivewal 與這種情況無關。

如果數據庫發生“硬”崩潰，例如儲存介質永久失去並且您必須從備份中恢復，那麼您將失去超過 10 秒的事務。由於 pg_receivewal 將文件儲存到與 db 文件相同的位置，因此它們將一起失去。在與數據庫相同的機器上執行 pg_receivewal 並將文件儲存到同一個驅動器是沒有意義的練習，僅適用於測試目的。

除了那個問題，你誤解了這個領域的用途。它不是衡量有風險的數據，而是“與衡量最近寫入事務的同步送出和事務可見性延遲的目標一致”。

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