【4】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）:
http://dl.iteye.com/upload/attachment/344536/b703c8b8-0c8c-3356-abbb-a233d5c95473.png
一种是备份组结构（Replica Set):
http://dl.iteye.com/upload/attachment/344546/9d33f469-695f-37cb-8d7b-ee4808057933.png
Master/Slaves结构很容易理解，Hadoop也是采用这种方式的。
下面说明下Replica Set结构：
step 1:
这是一个Set,包括3个节点，其中有一个为主控节点（也就是图中的Member 2 PRIMARY）
http://dl.iteye.com/upload/attachment/344548/9447dbae-ccc1-3f46-97c8-58dd6ebdd0e8.png
step 2:
如果主控节点崩溃了（也就是Member 2 挂了），这个时候会从Member1和Member2中选举出一个新的节点作为主控节点，
选举的策略是可以定制的，例如我可以定制当Member2挂了的时候，Member3就来作为主控节点，也可以根据别的策略筛选出一个节点
作为主控节点。
http://dl.iteye.com/upload/attachment/344550/2680fad4-a067-3f25-b516-c78d24beca66.png
step 3:
Member 3成为主控节点后，如果Member 2重新启动的话，那么就只能作为从属节点了。
http://dl.iteye.com/upload/attachment/344552/d99f1556-37d6-36a7-bff6-8546039e3306.png
step 4:
Member 2 恢复后，一个Set就稳定下来了。
http://dl.iteye.com/upload/attachment/344554/bf0c6ccc-e904-35fd-9724-f23e121d44aa.png
Replica-Set 配置过程请查看：
http://datalife.iteye.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是很适合使用的，特比是对于比较大的集群，效果更好；
MongoDB如何安装（Linux下）？
请查看：
http://datalife.iteye.com/admin/blogs/802336
单机安装MongoDB集群？
请查看：
http://datalife.iteye.com/admin/blogs/804223
MongoDB查询语句和MySQL有何差异？
请查看：
http://datalife.iteye.com/admin/blogs/804762
[欢迎转载，最好注明出处]
页:
[1]