MongoDB集群的冗余机制（Replication）

MongoDB集群的冗余机制（Replication）

 

优点：

1：Mongo是一个面向文档的JSON数据库，被设计为一个真正的对象数据库，而不是一个纯粹的键/值存储。

2：MongoDB适合用来描述一个具有个性化特征的实体对象正，快速无阻塞的数据数据并行写入功能以及丰富的查询功能是MongoDB的亮点，

对于实时分析、logging、全文搜索这样的场景是合适的选择。

3：Mongodb的内存映射文件机制以及schema-free的特点，让我们可以保持高速添加数据，不用担心数据库会出现堵塞。

4：MongoDB支持非常丰富的查询功能。几乎常用的SQL功能在它里面都有相应的方法来实现。而且支持索引，能够根据某一列进行WHERE条件快速筛选。

 

缺点：

1：占用空间过于虚高，原来1G的flatfile它需要4倍的磁盘空间存储。

2：mongodb的sharding到现在为止仍不太成熟。

 

MongoDB支持数据异步复制，增加数据的冗余，支持故障切换。

目前数据备份和后援支持结构有两种：

一种是主/从结构（Master/Slave Replication）:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

一种是备份组结构（Replica Set):

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Master/Slaves结构很容易理解，Hadoop也是采用这种方式的。

下面说明下Replica Set结构：

step 1:

这是一个Set,包括3个节点，其中有一个为主控节点（也就是图中的Member 2 PRIMARY）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

step 2:

如果主控节点崩溃了（也就是Member 2 挂了），这个时候会从Member1和Member2中选举出一个新的节点作为主控节点，

选举的策略是可以定制的，例如我可以定制当Member2挂了的时候，Member3就来作为主控节点，也可以根据别的策略筛选出一个节点

作为主控节点。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

step 3:

Member 3成为主控节点后，如果Member 2重新启动的话，那么就只能作为从属节点了。

 

step 4:

Member 2 恢复后，一个Set就稳定下来了。

 

Replica-Set 配置过程请查看：

http://datalife.javaeye.com/blog/805201

 

那么在什么情况下采用M/S结构？什么情况下采用Replica-Set结构？需要选择哪一种呢？

1：如果你使用的mongodb版本小于1.6的话（<v1.6）,选择M/S结构；

2：如果需要自动化故障切换和后备支援的话，使用Replica-Set（管理起来很方便）；

3：如果使用了--auth(出于安全的原因) 或者 --slavedelay的话，目前推荐使用M/S;

4：如果使用分片，Replica-Set是很适合使用的，特比是对于比较大的集群，效果更好；