我對 mongodb 還很陌生，我在這裡解決了一些 devops 問題。

我們在 AWS 上部署了一個 b2b SaaS 產品，客戶之間沒有網路效應，一些客戶擁有比其他客戶大得多的數據庫。他們目前正在一台中央 mongodb 伺服器上執行，我們遇到了嚴重的嘈雜鄰居問題，我們需要隔離擁有大量聯繫人集合的客戶端。

我的問題是：對於我們在aws中為個別大客戶提供他們自己的隔離vpc的設置，最低合理的mongodb伺服器是多少？這是否需要是 mongo 文件中指示的 3 個伺服器副本集，還是可以合理地將一個 ec2 實例用作小型數據庫的生產 mongo 伺服器？

您可以在單個 MongoDB 實例上執行生產環境。在非常特殊的情況下。在我們清理了一些關於副本集的事情之後，讓我們看看這些情況是什麼。

在副本集上

與流行的看法相反，副本集只有一個主要目的：確保數據庫的可用性。讓我們假設您只有一個實例。每一次維護工作，每一次伺服器崩潰，每一次管理錯誤都會導致停機。停機時間不僅會影響您的 SLA（已經夠糟糕了），而且很可能會導致 DBA 在派對之夜後的早上 06:00 起床，現在他試圖讓自己的咖啡因水平足夠高能夠恢復半醉狀態的數據庫。

此外：不可避免地，您將失去備份和恢復服務之間的所有數據。首先，很明顯，您將失去上次備份和伺服器變得不可用之間的所有數據。然後，您將失去在停機期間生成的所有數據。

現在讓我們假設您有一個包含兩個數據承載節點和仲裁器的副本集。稍微好一些。您的主節點發生故障，另一個數據承載節點被選中，並且由於自動故障轉移（大多數驅動程序提供）您的服務繼續執行，沒有停機時間和數據失去。但: 你失去了冗餘。因此，為了降低風險，一個 DBA 再次下床，他現在必須將仲裁器提升為數據承載節點，等待數據同步，同時希望同步速度快於您的更改速度數據（更準確地說：您希望您的複制 oplog 視窗大於同步數據所需的時間）。如果沒有，數據同步將失敗，您必須關閉應用程序才能讓同步成功。您通過此設置獲得的好處是您可以選擇何時關閉應用程序以恢復冗餘。

旁注：如果您的數據更改率超過複製 oplog 視窗，您應該分片。始終確保您的複制 oplog 視窗足夠大。

現在讓我們假設您有三個數據承載節點，如建議的那樣。即使一台伺服器發生故障（或更新等），您仍然有冗餘。一個節點在夜間發生故障？睡個好覺！

那麼我什麼時候可以擁有單台伺服器的生產環境呢？

考慮到上述情況，當且僅當您

• 沒有 SLA 和/或您的客戶可以忍受延長的停機時間
• 您的 DBA 隨時待命以恢復服務
• 您和/或您的客戶可以忍受在上次備份和恢復服務之間失去數據的情況。

在我所知道的大多數嚴肅的商業應用程序中，對這些條件中的一個或多個的答案是“否”。

我可以擁有一個具有兩個數據承載節點和一個仲裁器的生產環境嗎？

是的，假設您可以忍受失去一個數據承載節點將導致冗餘的事實。在這種情況下，您很可能必須重新同步您的數據，這需要您密切監視您的複制 oplog 視窗並確保重新同步所需的時間適合它。

鑑於仲裁器實例和數據承載節點之間的價格差異，您是在具有兩個數據承載節點和一個仲裁器的設置之間進行選擇，還是在具有三個數據承載節點的建議設置之間進行選擇，這是一個風險管理問題。

結論

可以合理地使用一個 ec2 實例作為小型數據庫的生產 mongo 伺服器嗎？

說白了：不是恕我直言。這將是近乎疏忽，增加了可以用相對較少的錢來減輕的風險，並且很可能比至少擁有一個具有兩個數據承載節點和一個仲裁器的副本集更昂貴。如果你考慮到一切。

這是否需要是 mongo 文件中指示的 3 個伺服器副本集？

除非你真的、真的、真的知道你在做什麼：是的。

引用自：https://serverfault.com/questions/877097