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