AWS 上的 MongoDB (EBS)：3 個副本與 2 個副本 + 仲裁器
我們有一個相當大的 Mongo DB 在 AWS 中執行。目前，我們正在使用具有 3 個實例的副本集執行。每個實例都有 5TB 的附加 EBS 儲存。每個實例每月超過 1000 美元。最重要的是，我們同時擁有 prod 和 staging 環境（即將推出第三個“dev”環境）。此外，當/如果我們遷移到分片環境時，這些成本將在未來爆炸式增長。
問題是，AWS 環境中 3 個副本的必要性有多大？
好吧好吧，我已經知道答案是“這取決於”。我正在尋找的是關於如何最好地權衡取捨的一些建議。例如…
- 考慮到每個 EBS 卷已經內置了三重冗餘，並且從備份中恢復相當簡單，我如何衡量 2 對 3 副本的附加容錯。
- 在考慮權衡時，除了冗餘之外還有其他考慮因素嗎？
- 有沒有人有隻執行 2 個副本 + 一個仲裁器的經驗（好或壞）？
- 考慮到每個 EBS 卷已經內置了三重冗餘，並且從備份中恢復相當簡單，我如何衡量 2 對 3 副本的附加容錯。
就 MongoDB 而言，在三節點副本集中只有兩個數據承載成員的關鍵考慮因素是，如果這些數據承載成員之一由於任何原因（計劃內維護或計劃外故障）不可用：
- 您不再有活動複製（只剩下一個數據承載成員）
- 您的部署不再承認高於
w:1（例如：w:majority或w:2）的寫入關注點此配置在單個成員發生故障時維護/選擇主節點方面具有高可用性，但如果您的數據承載成員之一不可用，仲裁器會損害數據冗餘。假設您有合理的時間從 EBS 備份中恢復（並且信任 EBS 冗餘），這對於您的案例來說可能是一個可以接受的折衷方案。
- 在考慮權衡時，除了冗餘之外還有其他考慮因素嗎？
如果您的程式碼使用高於預設值 ( ) 的 MongoDB寫入關注點
w:1，您將需要添加一個wtimeout值。如果您未指定該wtimeout選項並且無法達到寫入關注級別，則寫入操作將無限期阻塞。AWS 對冗餘基礎設施的保證通常只會擴展到跨多個可用區的故障，因此為了最大限度地提高可用性，您還應該將副本集成員部署到不同的可用區。
- 有沒有人有隻執行 2 個副本 + 一個 Arbiter 的經驗（好或壞）
我確實看到了使用者沒有考慮上述幾點的糟糕結果（特別是考慮到寫入問題和超時）。如果您在計劃（和測試）時考慮到這些警告，您應該能夠獲得良好的體驗。
最重要的是，我們同時擁有 prod 和 staging 環境（即將推出第三個“dev”環境）
擁有類似 prod 的暫存和開發環境肯定是有爭議的，但典型的成本節省是為開發部署較低規格的環境，並且故障轉移少於生產環境。對於暫存，您可能希望部署較低規格的環境，但具有類似的配置，以便您可以測試實際的故障轉移場景。如果您在暫存環境中進行性能或負載測試，則應為它們提供與生產環境相同的規範。