爲什麼仲裁者需要在主 - 次仲裁者MongoDB副本集中進行選舉？

Question

Mongo文檔列出了這個three-member configuration：主，次，仲裁者，作爲副本集的最小體系結構。

爲什麼在這裏需要仲裁者？如果主服務器出現故障，輔助服務器將看不到心跳，因此它需要成爲主服務器。換句話說，爲什麼主/輔配置不夠？這個related問題似乎沒有解決這個問題，因爲它討論了更多的節點。

Answer 1

假設您只有兩臺服務器，一臺主服務器和一臺輔助服務器。

如果突然次要服務器無法到達主服務器，可能是主服務器出現故障（在這種情況下，次服務器應該成爲主服務器），但它也可能成爲隔離次服務器的網絡問題（次服務器一個在契約中）。但是，如果你有一個仲裁器，並且仲裁不能到達主仲裁器，但它可以到達仲裁器，那麼這個問題與主仲裁器有關，因此它必須成爲新的主仲裁器。如果它不能到達主要的，也不是仲裁者，那麼次要人知道問題是他是孤立的/破碎的 - 次要的：（ - 所以他不能成爲主要的

Answer 2

如果你把仲裁者下到它核心它本質上是一個非數據保留成員用於投票

仲裁者的一個案例是我在鏈接的問題中說：Why do we need an 'arbiter' in MongoDB replication?打破CAP的問題，但這不是它的真正目的，因爲你可以很容易用數據保存節點替換該仲裁器並具有相同的效果。

但是，仲裁者會有幾個好處：

• 佔地面積小
• 沒有數據
• 無需同步
• 可以立即投票
• 可以從字面上隨時隨地把你的網絡，應用服務器，甚至另一個輔助，以提高你的網絡的一部分（這進入分區）。

因此仲裁者是非常有用的，即使在分區的一邊（即你的網絡沒有分區）。

現在來解釋基礎設置。仲裁器不是必需的，你可以將它分解爲一個數據保存節點，但是3個數據保存節點不是最小值（這是保持自動故障轉移所需的最小值），2個數據保存節點和1個仲裁器實際上是最小。

現在來回答：

換句話說，爲什麼不是主+副配置是否足夠呢？

因爲如果其中一個失敗，只剩下50％的選票（2-1 = 1），並且50％不會被歸類爲MongoDB實際投票的足夠多數（由您的rs.config中配置的可投票成員總數）。

同樣在這種情況下，MongoDB實際上並不知道最後一個成員是否是最後一個成員。它需要其他成員來告訴它。

所以是的，這就是爲什麼你需要第三個人。