如何僅使用兩台機器解決 MongoDB 中的複制？
我有兩台機器連接在一個環形網路中，每台機器在 HA 模式下執行 Wildfly，使用 JGroups ant MongoDB 在 HA 模式下使用副本集。機器 1 是主要機器，機器 2 是次要機器。
每當 Wildfly 1 下降時，Wildfly 2 會通過更改 ReplicaSet 的設置將 MongoDB 2 重新配置為主伺服器來提升。
我們知道 Replica Set 不能在兩台機器上單獨工作，但是我們有這個限制。
如果網路上發生分裂，Wildfly 1 繼續在 MongoDB 1 中寫入，Wildfly 2 也處於活動狀態，將 MongoDB 2 配置更改為主要配置，並開始對其進行寫入。
我們使用的是 MongoDB 3.6.5 版本。
問題：
- 重新建立網路並由 Wildfly 1 接管時，MongoDB 會發生什麼情況？
- MongoDB 2 將繼續作為主要但 Wildfly 2 將停止？
- MongoDB 1 將能夠與 MongoDB 2 合併嗎？
- 考慮到 MongoDB 通過合併來解決，如果 MongoDB 2 OPLOG 通過配置中指定的大小會發生什麼？他會回到起點（如汽車里程表）嗎？
我們知道 Replica Set 不能在兩台機器上單獨工作，但是我們有這個限制。
如果您的目標是具有自動故障轉移的高可用性，我肯定會尋求一種不涉及重新配置副本集或允許多個活動主節點的可能性的解決方案。
理想情況下，這確實需要第三台機器，因此您有一個平局投票，以允許 MongoDB 1 或 MongoDB 2 在兩者之間發生分區的情況下成為主要機器。第三台機器可以託管另一個輔助（推薦）或僅投票的仲裁器（不推薦用於 HA，因為它不能參與多數寫入確認）。
每當 Wildfly 1 下降時，Wildfly 2 會通過更改 ReplicaSet 的設置將 MongoDB 2 重新配置為主伺服器來提升。
如果 MongoDB 2 是輔助節點，則此方案僅在您強制重新配置時才有效（因為大多數投票副本集成員不可用）。
如文件中所述，強制重新配置是恢復副本集的最後手段，而不是您應該經常使用或自動化的過程：
Use this procedure only to recover from catastrophic interruptions. Do not use force every time you reconfigure. Also, do not use the force option in any automatic scripts and do not use force when there is still a primary.如果網路上發生分裂，Wildfly 1 繼續在 MongoDB 1 中寫入，Wildfly 2 也處於活動狀態，將 MongoDB 2 配置更改為主要配置，並開始對其進行寫入。
主節點只能在具有多數投票成員的分區中選舉或維持。只有兩個投票成員，網路分裂將導致目前的主要成員下台（因為它看不到大多數投票成員）並且沒有選舉產生主要成員。
重新建立網路並由 Wildfly 1 接管時，MongoDB 會發生什麼情況？
如果您強制 MongoDB 2 成為主要版本，它將具有一個具有顯著更高副本集配置版本的副本集配置。MongoDB 2 可能還有尚未復製到 MongoDB 1 的寫入，因此有兩個恢復階段：
- 如果 MongoDB 1 接受了任何未復製到 MongoDB 2 的寫入，MongoDB 1 將進入回滾模式以嘗試將寫入操作恢復到 oplog 中的公共點。如果在 MongoDB 2 上編寫了太多操作，或者 MongoDB 1 在其 oplog 中不再有共同點，則 MongoDB 1 將不得不重新同步。
- 假設兩個成員現在都有一致的 oplog 歷史記錄，MongoDB 1 將恢復同步（作為輔助）以嘗試趕上已在 MongoDB 2 上應用的寫入操作
如果這兩個階段都成功，MongoDB 1 應該有資格成為主要的。MongoDB 1 不會自動成為主節點，除非它的優先級高於 MongoDB 2。