一個配置恰當的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才不會由於缺少資料移轉而變的不能平衡(再說一遍,對於大部分生產情境,這可能不是一件很著急的事)。