只有兩台機器的副本集有意義嗎？
很多 MongoDB 教程在談到副本集時，都給出了兩台機器的範例：一台最初初始化為主要機器，另一台最初創建為輔助機器。
據我了解：
- 如果主成員意外死亡，輔助成員無論如何都不會選擇新的主成員，因為它不會擁有多數（在兩台機器的副本集中有兩個）。
- 如果主成員不可用，則無法從數據庫中讀取數據，即使使用
read_preference=ReadPreference.SECONDARY.- 重新創建主成員無論如何都不起作用：它不能添加到現有的副本集中，因為它缺少主成員；它也不能
rs.initiate();，因為它將創建具有不同 ID 的不同副本集。因此，在現實生活中是否存在複製集中只有兩個成員有意義的情況？或者這種情況只是理論上的，並且在實踐中期望在每個副本集中看到至少三個成員？
如果主成員意外死亡，輔助成員無論如何都不會選擇新的主成員，因為它不會擁有多數（在兩台機器的副本集中有兩個）。
這是對的。為了選舉（和維持）初選，需要有大多數投票成員。
如果主成員不可用，即使使用 read_preference=ReadPreference.SECONDARY，也無法從數據庫中讀取數據。
這是不正確的。如果沒有主節點，您將無法寫入副本集，但仍然可以使用非主節點讀取首選項（例如
secondary、primaryPreferred、secondaryPreferred或）進行讀取nearest。預設讀取首選項是primary，它提供強一致性（相對於從輔助讀取時的最終一致性）。如果可用，primaryPreferred讀取首選項從主數據庫讀取，否則從輔助數據庫讀取。重新創建主成員無論如何都不起作用：它不能添加到現有的副本集中，因為它缺少主成員；它不能 rs.initiate(); 或者，因為它將創建具有不同 ID 的不同副本集。
如果您失去了雙節點副本集中的成員之一，您可以強制將倖存的成員重新配置為單節點副本集，然後添加新成員。您只需要
rs.initiate()在副本集的生命週期中執行一次。因此，在現實生活中是否存在複製集中只有兩個成員有意義的情況？或者這種情況只是理論上的，並且在實踐中期望在每個副本集中看到至少三個成員？
通常，大多數副本集部署都有足夠的成員來允許自動故障轉移（即最少三個成員）。如果高可用性不是問題（或者您更喜歡手動干預），則不允許使用兩個成員的副本集。但是，允許故障轉移的更典型選項是向您的副本集添加第三個僅投票成員（又名仲裁者） 。
仲裁者是一個輕量級的僅投票成員，如果您的兩個數據承載成員之一在三成員配置中不可用，它將提供多數所需的額外投票。仲裁器有助於提高可用性，但它是對第三個數據承載成員的妥協。當帶有仲裁器的三成員副本集處於降級狀態（即您的數據承載成員之一不可用）時，您仍將擁有一個主副本，但不再具有數據冗餘或複制。仲裁器還將阻止您的應用程序依賴
majority寫入關注點來確保將數據送出給大多數副本集成員。我個人的建議是至少為生產副本集部署三個數據承載成員，但是可以考慮使用更少的數據承載成員進行開發或非關鍵部署。