CouchDB複製如何與失敗/恢復的服務器一起運行？

Question

考慮以下情形：位於

3 EC2實例：

• US-WEST
• 愛爾蘭
• 東京

每個實例是專用的CouchDB服務器。每個CouchDB服務器都設置爲與其他服務器（雙向）連續複製。

現在假設愛爾蘭服務器由於某些AWS停機而下線。美國西部和東京CouchDB服務器將重試X次，然後最終無法通過該服務器進行復制（這是否正確？）

假設6小時過去，AWS將該區域重新聯機並且該服務器返回起來 - 我認爲美國西部和東京將忽略愛爾蘭服務器，直到愛爾蘭的CouchDB服務器重新啓動雙向同步與他們兩個，一拉：

愛爾蘭CouchDB的_replicator僞設置

• replicate [source = local主機，目標= US-西]
• 複製[源=我們走向，目標=本地主機]
• 複製[源=本地主機，目標=東京]
• 複製[源=東京，目標=本地主機]

問題1：我對Couch的複製失敗/恢復的理解是否正確？

Q2：如果網絡故障在一小時後修復（特別是：服務器沒有重新啓動，迫使DB在啓動時重新啓動自身），那麼相應的CouchDB實例如何對此做出反應？我想我們西方和東京會忘記愛爾蘭，但愛爾蘭突然開始與這兩臺服務器再次交談，重新初始化雙向連續複製？

我特別感興趣的是EC2環境中的故障​​恢復，所以如果有一個特定的細節我錯過了，請告訴我。

謝謝！

Answer 1

在1.1之前，複製任務不是持久的，即使是連續的。如果發生斷線，重試的嘗試有限，但最終會停止。當連接恢復時，您將需要再次啓動複製。由於複製是冪等的（兩次啓動相同的複製任務與啓動一次相同），您可以添加一個cronjob以便每分鐘啓動一次（或任何時間間隔似乎都是理智的）。如果任務已經運行，則嘗試返回成功（但不會啓動另一個複製）。

在1.1中，您可以通過在特殊_replicator數據庫中創建文檔來創建持久複製任務。 CouchDB 將重試此操作，如果它崩潰或連接中斷。注意：1.1.0最終放棄，在下一個版本（1.1.1）中，我們允許無限重試。由於CouchDB是從頭開始設計的，以支持多主複製，所以聽到它很好地處理連接中斷時，您不會感到驚訝。中斷期間發生的變化很快找到並複製。