RT,
聽人說過：
20M的情況下插入1百萬的數據進行分片,會丟數據
63M的情況下插入6千萬條的數據進行分片也有丟數據的情況
不同的mongodb版本也有差異
大夥對這個值有經驗嗎？
高洛峰2017-05-02 09:20:15
「丟數據」和chunksize是兩個不相關的東西，並沒有直接的邏輯聯繫，不知道什麼人會把這兩個東西扯到一起說給你聽。由於我也不知道具體指的什麼樣的特定場景出現丟數據，所以就我所知道的情況，給出一些可能會對你有用的答案。
看起來你關注的是丟資料的問題而根本不是chunksize，再者通常情況下chunksize保留預設值就沒有什麼問題，所以chunksize的問題我就略過了。
就「丟數據」做一些說明。對於任何一個資料庫，無理由的丟資料都是不可容忍的。所以出現了丟數據的情況，要嘛是
出現了不可抗拒的因素，例如斷電，硬體損壞，網路故障等
配置原因
軟體出現嚴重bug。
對於1反正你也無能為力了，這點應該透過ReplicaSet的複製功能來盡可能減少影響。
第2點，如果你沒有開journal(預設已開啟），遇到斷電或程式crash的情況，可能會遺失30ms內的資料。如果資料非常重要無法容忍30ms的遺失，請開啟j參數：
mongodb://ip:port/db?replicaSet=rs&j=1
（以上參數也可能透過程式碼按單次要求的粒度來指定，請查閱你使用的驅動文件）
這個參數確保資料寫入時阻塞到journal寫到磁碟上為止。
但是你以為資料落盤就算安全了嗎？記住這是分散式環境，單一機器的資料安全並不能代表叢集。所以在萬一的情況下，journal雖然落盤，但是還沒來得及複製到replica的其他結點上，然後primary正当掉了，就会有其他结点通过选举成为新的primary，這時候就會發生一個有意思的情況叫做rollback，有興趣可以閱讀一下。當然通常複製的速度是非常快的，發生rollback的情況非常稀有。好吧你可能還是覺得不夠安全，那還有一個w參數可以使用:
mongodb://ip:port/db?replicaSet=rs&j=1&w=1
w參數可以確保寫入作業被阻塞直到資料落到多個結點上（w=1/2/3...n）。
那這樣就安全了嗎？ sorry，特別倒楣的情況下（真應該去買彩票），你把資料複製到了多於一個結點上，萬一這組結點同時失效了怎麼辦？所以有了w=majority（大多數）。當叢集失去大多數結點的時候會變成唯讀狀態，所以不會有新資料寫入，也就不會有rollback。當一切恢復之後，你的資料還在。
以上是一些會出現資料遺失的情況，可以想像w和j的配置在資料安全性得到保障的同時，一定會很大程度影響寫入效率。這其實應該是你根據你對資料遺失的容忍程度自己客製的策略，不算是bug。
另外想到一點，在社區常常遇到有人喜歡做這種事情：
kill -9 mongod要我說簡直太殘暴了，幹嘛一上來就用大砲打蚊子。這種情況下出現資料遺失只能說活該。實際上，
kill mongod是安全的，但是-9就是你的不對了。
至於第3點，mongodb在開發過程中確實出現導致資料遺失的bug，3.0.8-3.0.10是重災區，避開這幾個版本。話說回來，哪個軟體開發過程不出現點問題呢？ 3.0.10發現問題的當天就出了3.0.11，修復速度已經快得可以了。
好了，說了這麼多，也不知道對題主有沒有用。還是提醒一下，盡可能把問題描述清楚，不然只能像我這樣猜測你到底在什麼樣的場景下遇到了什麼樣的問題，最可能出現的情況就是那句老話：
Garbage in, garbage out