AWS 上的 MongoDB 災難準備
我正在尋找有關 AWS 託管環境中 MongoDB 災難恢復的最佳實踐建議。
此時我們的設置是相當標準的，3 個伺服器的副本集（1 個主伺服器、1 個輔助伺服器和 1 個仲裁器），主伺服器和輔助伺服器上的 mongo 卷是 EBS 支持的。所有這些都在一個區域中，分佈在多個可用區中。最終我們將需要跨越區域，但這是另一天的討論。
我在 Mongo 文件中看到的備份建議談到了 EBS 快照（很容易實現自動化）。然而，如果災難發生，他們不會讓我們回到失敗的時候。
- 我是否需要記錄 oplogs 並在失敗後將它們結合使用來恢復？
- 我是否應該在副本集中啟動另一個實例，專門用於備份和快照，而不是拍攝主要和次要的快照？如果是這樣，我們又回到了 oplog 問題，不是嗎？
- 我是否應該對每個副本捲進行快照並完全依賴副本集來涵蓋從故障到最後一個快照之間的時間？
我正在尋找可用的最強大的策略。高達秒級的數據保護和故障後系統恢復速度優先於價格。我們可以稍後優化價格。
提前感謝所有建議…
首先，如果您拍攝快照，它將包含 oplog - oplog 只是存在於本地數據庫中的封頂集合。快照將返回到某個時間點，並且假設您啟用了日記功能（預設情況下已啟用），您無需為快照執行任何特殊操作即可用作備份。
唯一的絕對要求是 EBS 快照必須足夠新，才能落入您的oplog視窗內——即快照備份 oplog 中記錄的最後（最近）操作也必須仍在目前主節點的 oplog 中，以便它們能找到一個共同點。如果是這種情況，它將像這樣工作：
- 您從 EBS 快照備份還原輔助節點
mongod開始、查找（並應用）任何相關的日誌文件- 接下來，從連接到主，並在兩個oplog中找到一個公共點
- 主節點的任何後續操作都將應用於RECOVERING輔助節點
- 一旦輔助節點充分趕上，它就會進入 SECONDARY 狀態並且備份完成
如果快照不夠新，那麼它可以被丟棄——在 oplog 中沒有共同點，輔助節點無論如何都必須從頭開始重新同步。
要回答您的具體問題：
我是否需要記錄 oplogs 並在失敗後將它們結合使用來恢復？
如上所述，如果您進行快照，則您已經在備份 oplog
我是否應該在副本集中啟動另一個實例，專門用於備份和快照，而不是拍攝主要和次要的快照？如果是這樣，我們又回到了 oplog 問題，不是嗎？
除了我上面提到的公共點/視窗之外，沒有任何 oplog 問題。有些人確實為此選擇了輔助節點（通常是隱藏的）以避免增加正常節點的負載。注意：即使是隱藏的成員也有投票權，因此如果您出於備份目的添加了一個，您可以從配置中刪除仲裁器，您仍然會有 3 個投票成員。
我是否應該對每個副本捲進行快照並完全依賴副本集來涵蓋從故障到最後一個快照之間的時間？
副本集的每個成員都應該是相同的 - 數據是相同的，任何輔助節點都可以成為主節點等 - 這些不是從節點，每個副本集成員都包含完整的 oplog 和所有數據。
因此，拍攝多個快照（假設您信任該過程）將是多餘的（當然您可能想要這種冗餘）。是的，副本集功能的全部目的是確保您不需要採取特殊措施以這種方式使用輔助節點（當然，請記住上面的警告）。