我想縮小我的MongoDB副本集的大小（集合的大小相同，但磁盤空間不斷增加）。根據MongoDB網站，我應該在主節點上運行mongod --repair以壓縮所有集合。問題將是網站的停機時間。所以，我有兩個選擇（我知道）：MongoDB複製集磁盤清理
以輔助節點關閉的副本設置，並在其上運行的mongod --repair並重新啓動回到副本集。我嘗試過這種方式，無法獲得「本地」收集過去的權限錯誤。
關閉輔助節點並刪除數據目錄中的所有文件。重新啓動mongo並讓它從主服務器恢復。這實際上對我有用，但我唯一擔心的是，如果您的期刊收藏已滿，並且由於它是封頂收藏，您將只收到日記中的數據，還是實際複製了所有主數據？
有沒有其他人遇到這種情況？當我試圖尋找這個時，我對缺乏信息感到驚訝。
將輔助節點關閉副本集並對其運行mongod --repair並重新啓動副本集。
這是一種常見的做法，通常稱爲「滾動修復」。您將副本從副本集中取出並進行修復，最後將主要副本作爲最後一步進行修復。只要您始終擁有大部分可用的副本集節點，此方法就可以最大限度地減少潛在的停機時間。
如果您經常刪除數據，您應該考慮在MongoDB 2.2中使用新的PowerOf2Sizes集合選項。這改變了分配方法來以兩個冪分配文檔空間（例如，500字節的文檔將被分配512字節），這允許從被刪除的文檔更有效地重用該空間（每次稍微花費幾個字節文件）。
我試過了，無法獲得'本地'集合的過去許可錯誤。
「本地」收集聲音上的權限錯誤，如文件系統權限（即基於您正在運行mongod的用戶）。您應該使用相同的用戶運行修復過程。
關閉輔助節點並刪除數據目錄中的所有文件。重新啓動mongo並讓它從主服務器恢復。這實際上對我有用，但我唯一擔心的是，如果您的期刊收藏已滿，並且由於它是封頂收藏，您將只收到日記中的數據，還是實際複製了所有主數據？
聽起來好像你正在將用於持久性和崩潰恢復的Journal與用於複製的Oplog相混淆。
如果您從主節點重新同步節點，則所有數據都將被複制。在此初始階段， 節點將處於RECOVERING狀態，並且不被視爲「健康」節點（即可用於查詢）。
一旦節點被抓住，它將變爲正常的SECONDARY狀態，此時oplog將用於進行同步。
一些進一步閱讀：
在你的問題，你是說蒙戈是消耗資源超過其正常貪婪的消費？ –