一個配置恰當的mongodb 分片集羣不會有單點失效。
本章節描述了集羣服務器中可能出現的故障，及相應的對策。
1. 某個mongos路由進程故障每一個mongos會運行每一臺應用服務器上面，該應用服務器只能通過這個mongos進程和集羣進行通信。mongos進程不是固定不變的；相反，他們在啓動時從配置服務器那裏獲取必要的配置信息。
這意味着任何一臺應用服務器故障都不會影響到整個集羣，其他的應用服務器可以照常提供服務。恢復也是很簡單的，只需要重啓一個新的應用服務器和mongos進程。
2. 一個shard內的某個mongod服務器故障
每一個shard由包含了N個服務器的複製組組成，如果任何複製組內的任何一臺服務器故障了，該shard還是允許讀和寫操作的。更進一步，一臺服務器故障不會造成數據丟失，這是因爲複製組提供了一個選項在寫操作可以在返回前將數據強制將寫操作同步到備用節點。這個和Amazon's Dynamo上面設置w爲2是類似的。
3. 一個sahrd內的所有mongod服務器全部故障
如果一個shard的複製組裏面的服務器全部故障了，該shard上面的數據將不可訪問。此時，發生在其他shard的操作時可以繼續工作的。
如果將一個shard配置爲複製組，其中至少一個節點被放置在其他的數據中心，這樣整個shard出現故障的概率是很低的，在最大化冗餘中這也是推薦的配置。
4. 一個配置服務器故障
一個生產環境的配置服務器可能會有3臺配置服務器，每一個運行在一個獨立的機器上面。寫往配置服務器的操作使用了兩階段提交的機制保證原子性和shard集羣元數據的複製事務性。
任何一臺配置服務器發生故障，整個系統的元數據將變爲只讀。整個系統可以繼續提供服務，但是一個shard內的數據塊將不會被分裂或者遷移到其他shard。對於大部分的應用，這隻會帶來少量的問題，因爲數據塊的元數據很少發生變化。
這就是說，在一個合理的時間內將宕機的配置服務器重啓是很重要的，這樣shards纔不會由於缺少數據遷移而變的不能平衡（再說一遍，對於大部分生產場景，這可能不是一件很着急的事）。