Mongodb架構和具有兩個數據中心的故障轉移

Question

我試圖弄清楚是否有一種方法可以無縫地對mongo副本集進行故障轉移，而大多數mongodb節點都位於主數據中心中。 我當前的限制是2個數據中心，第三個數據中心是不可能的。 我的問題是，如果數據中心1發生故障，那么在沒有人工干預的情況下，數據中心2中的輔助節點將不會升級為主節點。

數據中心1（主）：Mongo節點（主）Mongo節點（仲裁器）

數據中心2（中學）：Mongo Node（中學）

我看過mongodb白皮書，但它們指出，如果dc1丟失，則需要手動干預才能在dc2主數據庫中創建mongodb實例。

我的問題是，是否存在一種架構或配置，該架構或配置將使其有可能丟失數據中心1，並且仍然具有在無需手動干預/重新配置的情況下啟用寫操作的數據中心2接管能力。 在不采用3數據中心體系結構的情況下是否可以做到這一點。 是否可以使每個站點上的兩個3個成員副本集保持同步，並可能對連接的應用程序進行網絡級別的故障轉移？

謝謝。

Answer 1

如果對我來說有2個數據中心，最簡單的解決方案是僅覆蓋Primary中的失敗。 好消息是，如果Slave已死-您只需要等待即可。

如果無法訪問Primary，則需要回調將Slave強制為Primary的過程。 如果您不花更多時間創建網關來緩沖查詢並等待來自交換機的回調，則此開關將導致應用程序停機。 這樣，隨着超時的增加，您將只會變得緩慢。

在主服務器再次上線之后，您需要重新連接到它（因為您的從節點不可靠）-這將再次導致停機-您需要另一個過程來檢查主數據庫是否處於活動狀態（來自數據中心2）以及是否是觸發事件並繼續進行回調。

可以強制將Slave設置為Primary的手動干預可以包裝到腳本中。

對我而言，最好的解決方案是使用第三個數據中心，仲裁器將保留在那里。 跳過這一點並將應用程序邏輯放在那的努力是不值得的。 Mongo中的自動故障轉移非常有效且可靠。 如果您使用應用程序邏輯通過2個數據中心來實現這一目標，則可能會遇到很多問題。我寧願接受他們的建議。

Answer 2

首先，您已經注意到，您不能僅使用兩個節點進行自動故障轉移。 其次，當您認為“第三”數據中心時，金錢並不是真正的問題。 您可能會問為什么或“怎么做”？ 如您所知，您需要仲裁人。 仲裁器確實不需要資源，任何小型Linux機器都可以。 小型VPS機器不需要花費那么多。 在這里您可以找到機器1 x 2.40 GHz，512 MB，20 GB ，每月僅需1.24€。 從這里您將獲得每月1.99歐元的更強大的機器。

實際上，這兩個地方都可以使用這些“微型”機器運行相當大的mongodb。