Mongodump 影響應用程序性能真的很糟糕
我們有一個相當大的 mongo 實例（150 GB），沒有分片，我們的定期備份（
mongodump）對應用程序性能有非常顯著的影響。更糟糕的是，由於應用大量使用 mongo，備份持續了 10 多個小時。我知道我們需要分片，並且我們計劃遷移到 ElasticSearch，所以我正在尋找一些短期解決方案。
我可以做些什麼來改善這一點，比如限制每秒查詢 mongodump 的數量或其他什麼？
我們在 32 核 190 GB RAM 伺服器上有一個獨立的 mongo，它與 nginx、rabbitmq 和一些小東西共享。我知道，這不是最乾淨的設置：）
所有轉儲的數據
mongodump都必須由 MongoDB 伺服器讀入記憶體。還值得注意的是mongodump備份數據和索引定義；與其他方法相比，恢復時間也可能顯著延長，因為mongorestore在載入數據後需要重新創建任何二級索引。如MongoDB 文件中所述，
mongodump對於備份和恢復小型部署很有用，但對於擷取大型系統的完整備份並不理想：當連接到 MongoDB 實例時，mongodump 會對 mongod 性能產生不利影響。如果您的數據大於系統記憶體，則查詢會將工作集推出記憶體，從而導致頁面錯誤。
如果您還希望在進行備份時保持部署可用，則獨立伺服器會限制您的備份選項。
以下是一些建議的方法，按推薦從高到低的順序排列：
方法一：使用雲備份服務
對於最簡單的短期解決方案，我會考慮使用像MongoDB Cloud Manager這樣的商業雲備份服務。MongoDB Cloud Manager 提供帶有計劃快照和保留策略的連續備份（有關更多資訊，請參閱備份準備）。雲服務還避免了您必須部署任何額外的伺服器/基礎設施，因此即使您計劃在未來這樣做，這也是一個有用的短期解決方案。
一般的方法是：
- 將您的獨立伺服器轉換為單節點副本集（即使用
replSet參數重新啟動並執行rs.initiate()）。- 註冊MongoDB 雲管理器。
- 下載並安裝 Cloud Manager 備份代理。
作為一個額外的好處，Cloud Manager 還包括一個監控代理，它可以從您的部署中擷取指標歷史記錄並允許您配置警報。
方法 #2：將您的部署轉換為副本集並從隱藏的輔助節點進行備份
這種方法需要配置一些額外的基礎設施，但可以減輕主伺服器備份的影響。通常，副本集至少配備三個成員以實現高可用性和自動故障轉移，但如果您的唯一目標是備份，則可以使用不太理想的兩台伺服器配置。
一般的方法是：
- 提供將用於備份的第二台伺服器
- 將您的獨立伺服器轉換為副本集。
- 將您的備份伺服器添加為優先級為 0（它永遠不會成為主伺服器）和 0 票的隱藏輔助伺服器。
- 使用一種受支持的備份方法在隱藏的輔助節點上進行備份。備份方法按推薦的一般順序列出：文件系統快照（如果您的配置支持）或文件複製（假設您停止
mongod）優於mongodump.- （理想情況下）如果您想要副本集配置的高可用性和故障轉移優勢，請添加另一個承載數據的輔助節點。
方法 #3：使用文件系統快照（如果可用且適當）
比目前影響較小的備份策略
mongodump是使用文件系統快照，假設您有一個支持快照的文件系統（並且您的所有數據和日誌文件都在一個卷上，因此您可以獲得一致的執行快照mongod）。文件系統快照的好處是不必將所有數據都讀入記憶體mongod，但是快照仍然會產生影響（尤其是在繁忙的系統上創建初始快照時）。連續快照更有效且影響更小，但仍然不是完整的備份解決方案，因為快照在您的伺服器本地（並且您目前只有一個獨立的）。注意事項
- 方法#1 和#2 都涉及啟用複制以促進備份。複製將在主伺服器上添加一些額外的本地 I/O，因為所有寫入操作都記錄在稱為oplog（操作日誌）的特殊上限集合中。
- 您已經提到將來可能需要分片，但在這樣做之前，我會將您的 MongoDB 工作負載與共享同一伺服器的其他程序隔離開來。如果您可以將備份策略更改為比 更有效的策略
mongodump，消除資源爭用，並擷取一些基線指標歷史記錄以供審查……您可能會發現分片還不是必需的。