一次 max_standby_archive_delay 和 max_standby_streaming_delay 的值為 -1 是否會導致重負載時複製停止？

在 aws RDS 上的 postgresql 主從複製方案上的複制伺服器中，我收到以下錯誤：

SQLSTATE[40001]: Serialization failure: 7 ERROR:  canceling statement due to conflict with recovery

據我了解，原因是複制的發生類似於數據庫遷移。一系列查詢被寫入稱為 WAL 的東西，然後以 FIFO 序列執行。

另外，我了解到，一旦在執行 wal 時執行查詢，它可能會導致衝突，因為有時目前正在執行的查詢可能會導致獲取過時的數據。

因此，根據文件，存在允許首先執行目前查詢然後應用 wal 更改的延遲。這些是：

1. max_standby_archive_delay
2. max_standby_streaming_delay

但是在繁重的查詢（查詢執行時間> 30s）上將這些值設置為-1會導致副本長時間擁有陳舊數據嗎？

是的，就是這個想法。在複製衝突的情況下，PostgreSQL 只有兩個選項：

1. 取消查詢
2. 延遲複製更改的應用。

設置max_standby_streaming_delay為 -1 將無限期地延遲複製。

有一些方法可以減少複製衝突：

• 設置hot_standby_feedback = on為刪除由VACUUM. 您付出的代價是備用數據庫上長時間執行的查詢會使您的表膨脹。
• 在您的工作負載中不要有任何諸如DROP TABLE、TRUNCATE和ALTER TABLE類似的語句會導致ACCESS EXCLUSIVE鎖定。
• 在 PostgreSQL v12 中，您可以設置

ALTER TABLE atable SET (vacuum_truncate = off);

禁用 autovacuum 截斷（這也會導致短ACCESS EXCLUSIVE鎖）。在舊版本中，只有粗略且未記錄的解決方法可以設置old_snapshot_threshold為預設值以外的其他值。

這一切都很複雜，可能會產生不良影響，所以最好的建議是：如果您想要一個不會超過必要延遲的備用伺服器，但您還想在備用伺服器上執行長時間執行的查詢，您應該使用兩台備用伺服器, 一個用於這些相互衝突的目的中的每一個。

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