如果找到副本集要求有點混亂，我可能會丟失一些明顯的東西（比如在哪種情況下有選舉）。爲什麼一個mongodb副本集需要奇數個投票成員？
我明白，在正常的操作中，您需要法定人數，並進行投票，並獲得您需要的多數和奇數個機器。
但是，由於我們使用副本集進行故障轉移，如果主服務器死亡，則我們剩下偶數個投票成員，根據我有限的經驗延長選擇主服務器的時間。
另外根據文檔，增加一個投票成員不會開始選舉，似乎啓動（啓動）您的副本集與偶數個節點會更有意義？
因此，如果我們開始在副本集中使用4臺機器進行說明，並且一臺機器死機，那麼將有3臺機器重新選舉，即快速仲裁。我們增加一臺機器回到我們的正常操作狀態，不重選，我們回到正常的操作狀態。
有人可以闡明這一點嗎？
TL; DR：對於單主系統，即使是分區，也無法確定哪個剩餘部分仍佔多數，從而使兩個系統都處於關閉狀態。
設N是四個機羣集：
設M是三個機羣集：
=>相同的結果是成本的3/4。
現在，讓我們添加一個假設或兩個：
比方說，你有兩個數據中心，一個有兩個數據庫實例和後端服務器。如果到備份中心（有一個MongoDB實例）的連接失敗，您仍然在線。
現在，如果你在備份數據中心增加了第二個MongoDB實例，網絡分區會，儘管看似更高的冗餘，產量低可用性因爲我們會失去大部分的網絡分區的情況下，不能繼續運作。
=>減可用性較高的成本。但那還沒有回答這個問題。
比方說，你真的很擔心可用性：您在有兩個數據中心，與後端服務器進行了數據中心，任播IP地址，整個交易。現在，兩個DC之間的網絡已分區，但有些客戶端連接到DC A，而另一些客戶端則到達DC B.您現在如何確定哪個數據中心可以接受寫入？這是不可能的 - 這就是爲什麼奇數是必需。
你實際上並不需要選播IP地址，BGP或問題，成爲真正的任何花哨的東西，任何文字應用程序（比如一個工人，一個陳舊的要求，任何東西）將要求後合併不同的寫操作，這是一個完全不同的併發方案。
我不確定我是否理解你的例子有3臺和4臺機器。如果我們從4臺機器開始，如果兩個死亡（所以我們剩下2個），你說它是壞的。如果我們從3臺機器開始死亡（所以我們還剩下2臺），你說這很好。投票是否考慮了每個節點，即使那些不能參與投票的人也是如此？ – machunter
使用3臺機器時，如果一臺機器停機，系統仍然保持運行狀態，但不是2.有4臺機器，這是相同的，因爲2/4不是多數，所以它不能選擇一臺主機，所以沒有優勢額外的機器，但有額外的成本。然而，更有趣的問題是網絡分區，但同樣適用：如果網絡將計算機分成兩臺雙機設備，則會更糟糕，因爲即使所有機器運行，都無法接受寫入。 – mnemosyn
啊，你編輯了你的評論。是的，2/3是多數，2/4不是多數。更重要的是：想象一下網絡分區：所有節點都可以「參與投票」，但另一半不能看到。由於您無法區分節點故障與分區，因此您必須始終選擇所有投票成員的大多數，而不僅僅是那些可用的（貓咬尾） – mnemosyn