mongodb備份結點數據目錄與主結點數據大小不一致

題外話，MongoDB歷史上出現過master/slave復制（其實現在也還存在）。嚴格地說，主備通常指的是那個東西。而我們現在用的基本上是復制集（replica set）。

再說你這種情況，其實是正常的。原理跟你的磁盤用久了會有碎片是一個道理。特別是你曾經大規(guī)模刪除過數據的情況下。簡單地解釋下，假設你的表中有doc1/doc2/doc3/doc4一共4個文檔，在磁盤上的存儲順序是：
doc1|doc2|doc3|doc4
現在你刪除了doc2，磁盤上的空間使用情況變成：
doc1|(空白)|doc3|doc4
系統(tǒng)是沒有辦法釋放這個空白空間的，除非你進行磁盤整理，把空白空間移到最后：
doc1|doc3|doc4|(空白)
然后系統(tǒng)才可以截斷文件尾部的空白，釋放掉這個空間?？梢钥闯鰜?，要把空白移動到文件尾是個相當費時費力的操作，最簡單的辦法是：把后面所有的文檔順序前移來填補doc2留下的空白（如上所示doc3/doc4被前移）。但是這樣涉及到大量的磁盤I/O，會對性能造成嚴重影響。當然不乏其他整理磁盤碎片的方法，但是無論哪一個，都會造成比較嚴重的I/O影響，因此一般我們是不會進行這樣的整理的。進行碎片整理的方式就是：compact命令。如前所述，因為它會對性能造成嚴重的影響，因此一般只會在維護時間進行這個操作。而就算你不進行這個操作，系統(tǒng)也知道哪些地方是空白的，在有新文檔進來的時候，會嘗試重新使用這些空白的部分從而最大化空間利用率。只是，無論再好的算法，空間重復利用一定不可能是100%的，因為新進來的文檔永遠沒有辦法正好跟之前被刪除的文檔一樣大，所以只能找一個比新文檔更大的空間來利用，這樣就會留下一個更小的、更難重復利用的碎片。
另外一種變通的方案是把節(jié)點內容刪除，重新進行一次同步。因為同步時相當于把所有文檔全部抓取一遍，并一個接一個重新寫到磁盤上，因此同步完成之后文檔在磁盤上是緊湊排列的，相當于進行了碎片整理。而且在這個過程中，受影響的是從節(jié)點，它在同步過程中并不對外提供服務，所以對線上的影響是最小的。但是注意，它同樣會對主節(jié)點造成影響，因為它要把主節(jié)點上的全部數據都讀一遍，主節(jié)點I/O升高是無法避免的。

最后回到你的問題，為什么從節(jié)點比主節(jié)點小，上面應該已經解釋清楚了。