一個(gè)適當(dāng)配置的Mongodb分片集群是沒有單點(diǎn)故障。
本文描述了分片集群中存在的幾種不同的潛在的節(jié)點(diǎn)故障場景，以及Mongodb對這些節(jié)點(diǎn)故障是怎么處理的。
1、Mongos節(jié)點(diǎn)宕機(jī)
一個(gè)Mongos進(jìn)程應(yīng)該運(yùn)行在每一個(gè)應(yīng)用程序服務(wù)器上，這個(gè)服務(wù)器應(yīng)該獨(dú)占這個(gè)Mongos進(jìn)程，并且通過它與分片集群來通訊。
Mongos進(jìn)程不是持久化的，相反，它們在啟動(dòng)的時(shí)候從Config Server上收集所有必須的配置信息。
這表明，任何一個(gè)應(yīng)用程序服務(wù)器節(jié)點(diǎn)故障，對作為一個(gè)整體的分片集群來講并沒有什么影響，所有別的應(yīng)用程序服務(wù)器將依然是繼續(xù)正常工作。
在這種情況下，恢復(fù)是一個(gè)相當(dāng)簡單的事情，我們只需要去啟動(dòng)一個(gè)新的應(yīng)用程序服務(wù)器和一個(gè)新的Mongos進(jìn)程即可。
2、分片中的某一個(gè)Mongod節(jié)點(diǎn)宕機(jī)
每一個(gè)分片由n個(gè)服務(wù)器構(gòu)成，這n個(gè)服務(wù)器被配置為一個(gè)復(fù)制集(replica set)。如果在復(fù)制集中的任何一個(gè)節(jié)點(diǎn)宕機(jī)，在這個(gè)分片上讀與寫操作任然是允許的。
更加重要的是，宕機(jī)服務(wù)器上的數(shù)據(jù)都不會(huì)丟失，因?yàn)閺?fù)制機(jī)制存在一個(gè)選項(xiàng)，那就是強(qiáng)制復(fù)制寫操作到分片的其它節(jié)點(diǎn)上再返回，這與在Dynamo上設(shè)置write=2類似。
在MongoDB v1.6以后版本中Replica sets才是可用的。
3、分片中的所有Mongod節(jié)點(diǎn)宕機(jī)
如果一個(gè)分片中的全部節(jié)點(diǎn)（replicas)都宕機(jī)了，在該分片內(nèi)的數(shù)據(jù)將不能被訪問。然而，操作任然是繼續(xù)進(jìn)行，只不過是由別的分片分擔(dān)?？次臋n就可以弄清楚為什么這樣。
如果分片被配置為一個(gè)復(fù)制集（Replicas set)，至少一個(gè)成員應(yīng)該在另外一個(gè)數(shù)據(jù)中心，那樣的話，整個(gè)分片都宕機(jī)幾乎是不可能的。為了有更大的冗余度，推薦這樣進(jìn)行配置。
4、一個(gè)Config Server宕機(jī)
一個(gè)產(chǎn)品級(jí)的分片集群需要有3個(gè)Config Server進(jìn)程，每一個(gè)進(jìn)程都在一臺(tái)獨(dú)立的機(jī)器上運(yùn)行。對于Config server中的集群元數(shù)據(jù)的寫操作使用一個(gè)兩階段提交，去確保是一個(gè)原子的并且是被復(fù)制的事務(wù)操作。
在任何一個(gè)配置服務(wù)器失效的時(shí)候，Mongodb集群的元數(shù)據(jù)都會(huì)變成為只讀了。集群系統(tǒng)繼續(xù)運(yùn)行，但是chunks在一個(gè)分片中將會(huì)成為不可以被拆分或者是不可以跨分片進(jìn)行遷移。對于大多數(shù)使用場景，這個(gè)不會(huì)導(dǎo)致問題，應(yīng)為改變Chunk元數(shù)據(jù)進(jìn)行的并不頻繁。
另外，使宕機(jī)的Config Server在一個(gè)合理的時(shí)間周期（一天）內(nèi)恢復(fù)是相當(dāng)重要的，這樣可以避免分片由于缺乏遷移而變得負(fù)載不均衡（相對而言，對于大多數(shù)產(chǎn)品場景，這種現(xiàn)象也不是很嚴(yán)重的事情）。