Mongodb集群节点故障恢复场景分析
2017-12-11 19:17
357 查看
一个适当配置的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对这些节点故障是怎么处理的。
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集群节点故障恢复场景分析
- Mongodb集群节点故障恢复场景分析
- Mongodb集群节点故障恢复场景分析
- Mongodb集群节点故障恢复场景分析
- PostgreSQL 三节点集群故障模拟及恢复
- MongoDB仲裁节点的理解以及memcached,zookeeper,redis,故障恢复方案思考.
- rac集群节点级联重启故障分析
- pgpool-II 2.10 故障节点动态恢复 基于pgpool-ii的集群配置(五)
- es故障节点恢复后加入集群导致删除索引重新出现
- vertica-三节点集群,一台机器故障,所有文件丢失。的恢复
- cdh集群节点系统文件损坏,重装系统恢复Hdfs数据
- etcd 集群搭建及常用场景分析
- CDH集群主节点宕机恢复
- 故障案例--mongodb3.0 mongorestore恢复数据库时hang住
- mongodb使用场景分析 以及一些mongodb参考链接
- 故障转移集群中删除节点
- MHA 故障库恢复到集群 python脚本
- Redis源码解析:28集群(四)手动故障转移、从节点迁移
- Redis源码解析:集群手动故障转移、从节点迁移详解
- MongoDB 分片集群故障RECOVERING 处理纪实