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

http://blog.csdn.net/zhangzhaokun/article/details/6299527

一个适当配置的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在一个合理的时间周期（一天）内恢复是相当重要的，这样可以避免分片由于缺乏迁移而变得负载不均衡（相对而言，对于大多数产品场景，这种现象也不是很严重的事情）。