MongoDB集群节点故障恢复场景分析

一个适当配置的Mongodb分片集群是没有单点故障。本文描述了分片集群中存在的几种不同的潜在的节点故障场景，以及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在一个合理的时间周期（一天）内恢复是相当重要的，这样可以避免分片由于缺乏迁移而变得负载不均衡（相对而言，对于大多数产品场景，这种现象也不是很严重的事情）。