是否可以在同時託管次要成員的機器上執行仲裁器？
我有兩台機器（這是一個限制）配置為 MongoDB 3.6.5 的副本集。
是否可以在同時託管次要成員的機器上執行仲裁器？
即使不建議這樣做，但如果可能的話，我如何在輔助伺服器上安裝仲裁器，以便在主伺服器出現故障並且輔助伺服器成為主伺服器時？
安裝後，如何配置副本集以供原始主節點返回並製作輔助節點的副本（不使用複制）？
是否可以在還託管次要成員的系統上執行仲裁器？
在同一主機上執行多個程序沒有技術限制，只要它們偵聽不同的埠號即可。例如，您可以啟動一個監聽埠 27018（而不是預設的 27017）的仲裁程序。但是，您確實需要考慮託管程序的操作影響。
即使不建議這樣做，但如果可能的話，我如何在輔助伺服器上安裝仲裁器，以便在主伺服器關閉時輔助伺服器成為主伺服器？
這是標準的副本集行為。假設您有一個首選的主節點（它將具有更高的
priority值），您的副本集配置將類似於：{ _id : "myreplset", members: [ { _id: 0, host: "machine1.example.net:27017", priority: 2 }, { _id: 1, host: "machine2.example.net:27017" }, { _id: 2, host: "machine2.example.net:27018" } ] }在您的副本集中有三個投票成員，選舉（或維護）主節點所需的嚴格多數是兩票。如果
machine1不可用，則成員machine2仍然可以選擇主節點。但是，由於
machine2擁有大多數投票成員，因此會產生一些操作後果：
- 如果
machine2不可用，machine1則無法在沒有手動干預強制重新配置副本集的情況下選舉或維持主節點。- 在網路分裂的情況下，
machine2將成為主要的。如果仲裁者（或另一個投票成員）在第三台機器上，這兩種情況都可以避免。
您可能需要考慮將仲裁器託管在 上
machine1，因此在網路分裂的情況下，主伺服器將保持打開狀態machine1（顛倒上述操作場景，以便故障轉移到machine2手動重新配置）。對於生產部署，我還建議使用第三個輔助節點（而不是仲裁器）。當您的 Primary-Secondary-Arbiter 部署關閉一個成員（因此有效地 Primary-Arbiter）時，不再有任何活動複製，您的部署將無法確認多數寫入。讓多個數據承載成員在同一台主機上競爭資源絕對不理想，但數據冗餘和多數寫入的可用性通常是更重要的因素。
安裝後，如何為原始主節點返回時配置副本集並製作輔助節點的副本？
假設您已
machine1按照上述範例為成員配置了更高的優先級，預期的結果是，當machine1再次可用時，它將自動從目前的主節點machine2（作為輔助節點）恢復同步。一旦成員machine1趕上並有資格成為主要成員，它將根據可用的更高優先級成員發起選舉（稱為優先接管選舉）。