為什么要在主要-輔助-仲裁器MongoDB復制集中進行選舉，需要一個仲裁器？

Question

Mongo文檔列出了這種三人配置 ：主要，次要，仲裁者，作為副本集的最小體系結構。

為什么在那里需要仲裁員？ 如果主節點發生故障，則輔助節點將看不到心跳，因此需要成為主節點。 換句話說，為什么主配置+輔配置不夠？ 這個相關的問題似乎沒有解決這個問題，因為它討論了更多的節點。

Answer 1

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

如果突然，輔助服務器無法訪問主服務器，則可能是主服務器已關閉（在這種情況下，輔助服務器應成為主服務器），但也可能是隔離輔助服務器的網絡問題（此輔助服務器是在行動上）。

但是，如果您有仲裁者，而輔助仲裁者無法到達主要仲裁者，但它可以到達仲裁者，那么問題在於主要仲裁者，因此它必須成為新的主要仲裁者。 如果它不能到達主要節點，也不能到達仲裁者，則輔助節點會知道問題出在，他是被隔離的/損壞的-較差的輔助節點：（-，因此他不能成為主要節點

Answer 2

如果將仲裁員推到核心，那么它本質上就是用於投票的無數據保留成員。

正如我在鏈接的問題中所陳述的那樣，仲裁者的一種情況是： 為什么在MongoDB復制中需要一個“仲裁者”？ 打破CAP的問題，但這並不是其真正目的，因為您可以輕松地用數據保存節點替換該仲裁器，並具有相同的效果。

但是，仲裁員將有一些好處：

• 占地面積小
• 沒有數據
• 無需同步
• 可以立即投票
• 可以放置在網絡，應用程序服務器甚至其他輔助設備中的任何位置，以增強網絡的這一部分（這屬於分區）。

因此，即使在分區的一側（例如，您的網絡中沒有分區），仲裁器也非常有用。

現在說明基本設置。 不需要仲裁器，您可以將其分解為一個數據保存節點，但是3個數據保存節點不是最小的（這是保持自動故障轉移所需的最小值），實際上是2個數據保存節點和1個仲裁器最低。

現在回答：

換句話說，為什么主配置+輔配置不夠？

因為如果其中一個失敗，則僅剩下50％的投票（2-1 = 1），而50％的投票不足以使MongoDB能夠實際投票給成員（由配置的可投票成員總數判斷）您的rs.config ）。

同樣在這種情況下，MongoDB實際上不知道最后一個成員是否是最后一個成員。 它需要其他成員另行說明。

是的，這就是為什么您需要第三個人。