跨雲和本地部署 MongoDB
我們計劃將 MongoDB 實施為一個延伸集群，其中包括 DC 1 中的 Primary Secondary，DC 2 中的 Secondary Secondary，雲中的 Arbiter（DC 3），其中 DC 1 和 DC 2 是本地伺服器，DC 3 在雲中
我的問題是：
1）我們是否需要在 AWS 中保留與我們的本地伺服器相同的作業系統，或者我們也可以保留 Amazon Linux？在我們的例子中，它是本地伺服器中的 RHEL 7.2
2）如果否，如果我們在副本節點之間使用不同的作業系統，是否會對性能產生影響？
- 如果是，我們是否需要像在本地伺服器中那樣頻繁地進行更新檔升級？
4）如果寫關注為多數，故障轉移如何在這里工作？
5）如果有的話，這種方法的其他權衡是什麼？
- 我們是否需要在 AWS 中保留與我們的本地伺服器相同的作業系統，或者我們也可以保留 Amazon Linux？在我們的例子中，它是本地伺服器中的 RHEL 7.2
對於副本集的所有成員，沒有嚴格的要求具有相同的 O/S，但一般來說，具有一致的 O/S 是一個好主意，這樣您就可以在副本集成員之間進行類似的配置和性能調整。
但是，由於您的 DC3（雲）實例似乎是仲裁者（僅參與投票），因此任何 O/S 差異都應該與性能無關。
- 如果否，如果我們在副本節點之間使用不同的作業系統，是否會對性能產生影響？
Amazon Linux 從 RHEL 演變而來，因此不是完全不同的作業系統（例如，Linux 與 Windows）。但是，Linux 發行版之間可能存在不同的配置或調整。我不希望 Linux 發行版之間的性能有顯著差異，但這是您必須使用自己的案例和工作負載測試的東西。
- 如果是，我們是否需要像在本地伺服器中那樣頻繁地進行更新檔升級？
這取決於您自己的安全策略，但我希望更新檔升級同樣適用於本地和雲伺服器。
- 如果寫關注為 Majority ，故障轉移如何在這里工作？
假設您在 DC1 和 DC2 中擁有相同數量的實例，仲裁器可用於確保在任一 DC 無法訪問時可以選擇主節點。仲裁器無法確認寫入（因為它是僅投票節點），因此如果您有主次仲裁器 (PSA) 配置，如果您的數據承載節點之一不可用，您將無法確認多數寫入。
我強烈建議使用 PSS（即沒有仲裁器）來支持一致的故障轉移，包括選舉和多數寫入問題。
- 如果有的話，這種方法的其他權衡是什麼？
如上所述，仲裁器無法確認寫入，因此如果您想支持具有多數寫入問題的容錯，則不建議這樣做。將 PSA 配置降級為 PsA（一個輔助節點宕機）後，您具有寫入可用性（因為仍然可以維護主節點），但不再具有復製或數據冗餘（因為只有一個數據承載節點寫入數據）。