PostgreSQL Replication之第四章 設定非同步複製（7）

標籤：

4.7 衝突管理

在PostgreSQL中，流複製資料僅在一個方向流動。XLOG由master提供給幾個slave,這些slave消耗交易記錄並為您提供一個較好的資料備份。您可能想知道這怎麼會導致衝突，這會發生衝突。

考慮一下情形：如您所知，資料複製有很小的延遲。因此，XLOG在由master產生之後結束於slave。這微小的延遲會引起如所示的情景：

我們假設一個slave開始讀取一個表。它是一個長讀操作。與此同時，master收到一個請求，實際地刪除那個表。這有一點問題，因為slave仍然需要這個資料來執行它的SELECT語句。另一方面，所有來自master的請求任何情況下必須被服從。這是一個經典的衝突。

 [如果發生衝突，PostgreSQL將發出一下錯誤資訊：由於恢複衝突終止串連。]

有兩種選擇來解決這個問題：

1. slave終止有問題的操作之前，不要重放衝突的交易記錄

2.殺死slave上的查詢來解決那個問題。

第一選擇在回放進程回放期間可能會導致嚴重的延遲，尤其是當slave執行相當長的操作。第二個選擇可能經常殺死slave上的查詢。資料庫執行個體不能通過自己知道對您的應用程式什麼是最好的。所以您必須要在延遲重放和殺死查詢之間找到一個適當的平衡。

為了找到這個微妙的平衡，PostgreSQL在postgresql.conf中提供了兩個參數：

max_standby_archive_delay = 30s

# max delay before canceling queries

# when reading WAL from archive;

# -1 allows indefinite delay

max_standby_streaming_delay = 30s

# max delay before canceling queries

# when reading streaming WAL;

# -1 allows indefinite delay

當有衝突操作的時候，max_standby_archive_delay 參數會告訴系統，終止XLOG重放需要多長時間。在預設設定中, 如果找到一個衝突，slave將延遲XLOG重放長達30s 。如果slave 正在從檔案重放交易記錄，這個設定是有效。

如果XLOG正在通過流進入slave，max_standby_streaming_delay 會告訴slave ，終止XLOG重放需要多長時間。如果時間已經到期，並且衝突仍然存在，PostgreSQL 將取消那個語句，因為一個恢複問題引起slave系統上的問題，恢複XLOG恢複來追趕。

在前面的例子中，我們已經表明，如果一個表被刪除，衝突可能會出現。這是一個明顯的情境；然而，迄今為止，它還不是最常見的一個。它更可能是一行通過VACUUM或HOT-UPDATE來刪除，導致slave上的衝突。

衝突一段時間冒出來一次很煩人，並引發您的應用產生不良行為。換句話說，如果可能的話，衝突應該避免。我們已經看到了重放日誌是如何延遲的。這些並不是PostgreSQL提供的唯一機制。還有兩個我們可以使用的設定。

兩個設定中的第一個同時也是較早的設定是vacuum_defer_cleanup_age。它在事務中被測量並告訴PostgreSQL什麼時候刪除一行資料。通常如果沒有更多的事務可以看到資料，一行資料通過VACUUM被刪除。vacuum_defer_cleanup_age告訴VACUUM不立即清除一行資料，但是在資料被清除之前會等待一些事務。

延遲清理將保持一行資料的時間比需要的時間稍長。這有助於slave完成那些依靠舊資料行的查詢。尤其是如果您的slave提供處理一些分析工作的服務，這將有助於確保沒有查詢白白的殺死。

還有一個控制衝突的方法是利用hot_standby_feedback。這個想法是slave向master報告事務ID，這也可以反過來，使用此資訊來延遲VACUUM。這是避免slave上的清理衝突的最簡單的方法之一。

[請記住，延遲清理會導致增加空間佔用及一些副作用，在任何情況下都必須牢記。其效果和在master上運行長事務一樣。]

PostgreSQL Replication之第四章 設定非同步複製（7）