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

你可能感兴趣的:(MongoDB)