一、读写分离
1、 先向主库中插入一条测试数据
2、 在从库进行查询等操作
当查询时报错了，说明是个从库且不能执行查询的操作
3、 让从库可以读，分担主库的压力
看来我们要是执行db.getMongo().setSlaveOk()， 我们就可查询从库了。
二、故障转移
复制集比传统的Master-Slave 有改进的地方就是他可以进行故障的自动转移，如果我们停掉
复制集中的一个成员，那么剩余成员会再自动选举出一个成员，做为主库。
例如:我们将28010 这个主库停掉，然后再看一下复制集的状态
1、杀掉28010 端口的MongoDB
2、 查看复制集状态
可以看到28010 这个端口的MongoDB 出现了异常，而系统自动选举了28012 这个端口为主，
所以这样的故障处理机制，能将系统的稳定性大大提高。
三、增减节点
MongoDB Replica Sets 不仅提供高可用性的解决方案，它也同时提供负载均衡的解决方案，
增减Replica Sets 节点在实际应用中非常普遍，例如当应用的读压力暴增时，3 台节点的环
境已不能满足需求，那么就需要增加一些节点将压力平均分配一下；当应用的压力小时，可
以减少一些节点来减少硬件资源的成本；总之这是一个长期且持续的工作。
1、增加节点
官方给我们提了2 个方案用于增加节点，一种是通过oplog 来增加节点，一种是通过数据库
快照(--fastsync)和oplog 来增加节点，下面将分别介绍。
a、通过oplog 增加节点
①、配置并启动新节点，启用28013这个端口给新的节点
②、添加此新节点到现有的Replica Sets
③、查看Replica Sets我们可以看到添加28013这个新节点的.
④、验证数据已经同步过来了
2、通过数据库快照(--fastsync)和oplog 增加节点
通过oplog 直接进行增加节点操作简单且无需人工干预过多，但oplog 是capped collection，
采用循环的方式进行日志处理，所以采用oplog 的方式进行增加节点，有可能导致数据的不
一致，因为日志中存储的信息有可能已经刷新过了。不过没关系，我们可以通过数据库快照
(--fastsync)和oplog 结合的方式来增加节点，这种方式的操作流程是，先取某一个复制集成
员的物理文件来做为初始化数据，然后剩余的部分用oplog 日志来追，最终达到数据一致性
①、取某一个复制集成员的物理文件来做为初始化数据
②、在取完物理文件后，在c1集中插入一条新文档，用于最后验证此更新也同步了
③、启用28014这个端口给新的节点
④、添加28014节点
rs1:PRIMARY> rs.add("127.0.0.1:28014")
⑤、验证数据已经同步过来了
3、减少节点
下面将刚刚添加的两个新节点28013 和28014 从复制集中去除掉，只需执行rs.remove 指令
就可以了，具体如下：
rs1:PRIMARY> rs.remove("127.0.0.1:28013")
rs1:PRIMARY> rs.remove("127.0.0.1:28014")
查看复制集状态，可以看到现在只有28010、28011、28012 这三个成员，原来的28013 和
28014 都成功去除了。
转载于:https://blog.51cto.com/janephp/1330577
