MongoDB延遲成員複製機制

我們正在考慮在我們的 MongoDB 副本集中實現一個延遲成員，以保護我們免受基於人為錯誤的數據損壞，例如有人不小心刪除了一些數據。

延遲成員實際上如何延遲複製，我認為有兩種可能性：

1. 延遲成員使用過濾器觀察主節點的 oplogts < now - delay
2. 延遲成員實時觀察主節點的 oplog，將 oplog 儲存在本地，並將每個操作重播為ts >= now - delay

這對我們至關重要的原因是我們正在考慮相對較大的複制延遲（24 小時）。在正常操作中，我們的 oplog 維護了大約 5 天的數據，所以無論是上面的 (1) 還是 (2) 用於複製，我們都可以。但是，在某些時候，我們的寫入工作量非常高，在這種情況下，我們的 oplog 有時只會包含 < 1hr 的數據。在這種情況下，上面的（1）對我們不起作用。

實施是根據您的第一個建議：延遲輔助應用基於延遲來自源 oplog 的操作。您的擔憂也是有效的：如果源 oplog 週期不足以覆蓋輔助延遲，則延遲的輔助將變得陳舊並需要重新同步。

延遲的輔助將幫助您處理一些數據恢復方案（例如，尚未應用的收集丟棄），但對於更全面的恢復選項，我會考慮持續備份解決方案，例如 MongoDB Cloud Manager（或 MongoDB Ops Manager ，這是本地等價物）。Cloud Manager Backup 提供帶有可查詢快照的連續備份，允許您預覽和恢復數據子集。預設情況下，每 6 小時拍攝一次基本快照，並具有可自定義的快照間隔和保留策略。

引用自：https://dba.stackexchange.com/questions/211484