Mongodb叢集節點故障恢複情境分析

一個適當配置的Mongodb分區叢集是沒有單點故障。
本文描述了分區叢集中存在的幾種不同的潛在的節點故障情境，以及Mongodb對這些節點故障是怎麼處理的。
1、Mongos節點宕機
一個Mongos進程應該運行在每一個應用程式伺服器上，這個伺服器應該獨佔這個Mongos進程，並且通過它與分區叢集來通訊。
Mongos進程不是持久化的，相反，它們在啟動的時候從Config Server上收集所有必須的配置資訊。
這表明，任何一個應用程式伺服器節點故障，對作為一個整體的分區叢集來講並沒有什麼影響，所有別的應用程式伺服器將依然是繼續正常工作。
在這種情況下，恢複是一個相當簡單的事情，我們只需要去啟動一個新的應用程式伺服器和一個新的Mongos進程即可。
2、分區中的某一個Mongod節點宕機
每一個分區由n個伺服器構成，這n個伺服器被配置為一個複製集(replica set)。如果在複製集中的任何一個節點宕機，在這個分區上讀與寫操作任然是允許的。
更加重要的是，宕機伺服器上的資料都不會丟失，因為複製機制存在一個選項，那就是強制複製寫操作到分區的其它節點上再返回，這與在Dynamo上設定write=2類似。
在MongoDB v1.6以後版本中Replica sets才是可用的。
3、分區中的所有Mongod節點宕機
如果一個分區中的全部節點（replicas)都宕機了，在該分區內的資料將不能被訪問。然而，操作任然是繼續進行，只不過是由別的分區分擔。看文檔就可以弄清楚為什麼這樣。
如果分區被配置為一個複製集（Replicas set)，至少一個成員應該在另外一個資料中心，那樣的話，整個分區都宕機幾乎是不可能的。為了有更大的冗餘度，推薦這樣進行配置。
4、一個Config Server宕機
一個產品級的分區叢集需要有3個Config Server進程，每一個進程都在一台獨立的機器上運行。對於Config server中的叢集中繼資料的寫操作使用一個兩階段交易認可，去確保是一個原子的並且是被複製的事務操作。
在任何一個設定管理員失效的時候，Mongodb叢集的中繼資料都會變成為唯讀了。叢集系統繼續運行，但是chunks在一個分區中將會成為不可以被拆分或者是不可以跨分區進行遷移。對於大多數使用情境，這個不會導致問題，應為改變Chunk中繼資料進行的並不頻繁。
另外，使宕機的Config Server在一個合理的時間周期（一天）內恢複是相當重要的，這樣可以避免分區由於缺乏遷移而變得負載不均衡（相對而言，對於大多數產品情境，這種現象也不是很嚴重的事情）。