MongoDB 读写分离 - ITeye问答
《MongoDB管理与开发精要》11.5.2节，谈到读写分离，利用ReplicaSet主从机集群，写主要在高性能的PRIMARY，读则从一般的SECONDARY，用以分担PRIMARY的高强度读写压力。
但是在ReplicaSet里面，对PRIMARY的写就是对SECONDARY的写，因为OPLOG的同步，那么也就是说，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙，如果SECONDARY不及时写的话，导致跟不上OPLOG，会引起全库同步，结果会更糟糕。
从这点看，个人感觉这个"读写分离"概念应该是有问题的，如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的，那么再反过来说，SECONDARY不应该被视为性能低于PRIMARY的机器，对于一个RS，集群内的主机性能应该是相当的才对吧？
当然了，PRIMARY的写和SECONDARY的写还是有区别的，SECONDARY的写是不需要逻辑判断的，照搬照抄就可以，PRIMARY的写则需要对数据做校验、过滤等操作。
不知道我理解的对不对……
采纳的答案
引用《MongoDB管理与开发精要》11.5.2节，谈到读写分离，利用ReplicaSet主从机集群，写主要在高性能的PRIMARY，读则从一般的SECONDARY，用以分担PRIMARY的高强度读写压力。
读写分离：即查询 和 增删改 分离，好处是相互不阻塞，增大吞吐量，缺点是同步有延迟（同步一般是异步完成，数据不实时，比如每隔1秒从主同步一次数据到从）
&& 数据实时性高的需求不满足
但是在ReplicaSet里面，对PRIMARY的写就是对SECONDARY的写，因为OPLOG的同步，那么也就是说，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙，如果SECONDARY不及时写的话，导致跟不上OPLOG，会引起全库同步，结果会更糟糕。
是的，PRIMARY写繁忙，必定会导致SECONDARY的写繁忙：这个是定时异步同步的，造成从写频繁的可能行较小，除非网络慢； 不会全库同步，而是增量
引用从这点看，个人感觉这个"读写分离"概念应该是有问题的，如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的，那么再反过来说，SECONDARY不应该被视为性能低于PRIMARY的机器，对于一个RS，集群内的主机性能应该是相当的才对吧？
读写分离的核心是 查询 和 增删改 分离，好处是相互不阻塞，增大吞吐量，缺点是同步有延迟；
引用如此设计的目的，应该仅用于分担读压力，而对于写，其实集群内所有主机的压力都是相同的，至少是相当的
写的话，其实从比主要快，那是一个增量OPLog批处理；而且只有主节点保存OPLog，从不保存的；
Replica Sets 是有自动故障恢复功能的主从集群，，，Replica Sets 使用 n 个 Mongod 节点，构建具备自动容错转移(auto-failover)、自动恢复(auto-recovery) 的高可用方案。
引用当然了，PRIMARY的写和SECONDARY的写还是有区别的，SECONDARY的写是不需要逻辑判断的，照搬照抄就可以，PRIMARY的写则需要对数据做校验、过滤等操作。
这个没仔细研究过，不知道你说的对数据做校验、过滤什么意思； 都是对库操作，两者都是一致的，如关系型数据库 会进行约束检查的，不管主从，否则可能数据不一致。
Replica Sets 是有自动故障恢复功能的主从集群，Replica Sets 使用 n 个 Mongod 节点，构建具备自动容错转移(auto-failover)、自动恢复(auto-recovery) 的高可用方案。
已解决问题
未解决问题[MongoDB]&生产开发系列[四]&读写分离
MongoDB的读写分离
前些日子,考虑到业务有前后台之分(A人群用前台,B人群用后台)
且:A人群多以单条文档操作查询的形式存在,B人群则以统计以及批量操作形式居多
遂,决定按照业务进行MongoDB的读写分离;
主服务器提供读写服务(MongoDB复制集里面也只能主服务器提供读写服务,从服务器顶多提供读服务,当然主从服务器间的数据同步延迟可忽略不计)
从服务器提供读服务,需要slaveOk()选项,&MongoDB官方解释slaveOk:
db.getMongo().setSlaveOk()
This allows the current connection to allow read operations to run
on&&nodes.
注:这儿说这样设置是使得当前连接可以从从节点上执行读操作,而非是从服务器可以永久设置为可读
这儿当初选用Samus驱动而不选用官方驱动的悲催就体现了,Samus的查询只有Find()方法返回的Cursor对象才拥有Options(QueryOptions.SlaveOK)
只能将原有的FindOne()方法用Find()方法改装;
官方驱动是可以再连接字符串中设置是否需要slaveOk选项的.
说了这么多,具体读写分离的做法主要是在MongoHelper操作帮助类中新增ReadOnly方法,在其中加入Options(QueryOptions.SlaveOK)；
程序端调用时,初始化MongoHelper时传入主服务器IP和从服务器IP,前台使用不带有ReadOnly的方法,后台使用带有ReadOnly的方法,这样便实现了读写分离。
看来切换MongoDB的官方驱动只是个时间问题了。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。2945人阅读
MongoDB复制原理
mongodb各个节点常见的搭配方式为：一主一从、一主多从。
mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。
1：我们把mongodb文件夹放在D盘，同时在其他的服务器也安装mongoDB。
2：启动D盘上的mongodb,到对应的bin目录，输入命令：&mongod &--dbpath d:/mongodb,打开mongoDB.
3: 把该数据库指定为主数据库，命令：&mongodb --dbpath='XXX' --master，端口还是默认的27017.
4:&指定该数据库为从属数据库，命令：mongod
--dbpath=xxxx --port=8888 --slave --source=127.0.0.1:27017
5： 接下来，你会发现数据已经同步。
以上，个人笔记，仅供参考。 &
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：50988次
排名：千里之外
转载：22篇
(1)(2)(4)(1)(1)(2)(1)(1)(1)(1)(5)(4)(1)(1)(4)MongoDB是否有必要读写分离
看过京东对MongoDB运营的经验，对读写分离的分析是：
是不是可以使用Secondary或者SecondaryPreference实现读写分离来提高系统的承载能
1、Secondary节点的写压力跟Primary基本是相同的，所以，读操作在从库上并不会提高
查询速度。
2、由于是异步复制数据，所以读Secondary的数据可能是过时的。
3、在分片架构中使用读写分离的时候有可能会丢失数据或者读到重复数据。
读写分离真的收益不大吗
其实读写分离还是有意义的，关键是要解决同步数据延时问题，mongodb其实提供了相关的解决方案：
写操作的相关设置：
通过writeConcern指定REPLICA_ACKNOWLEDGED(4,2000)，也就是说4台节点全部写确认成功后才返回，设置了2秒的等待超时，可以根据复制集群数来指定节点数和等待超时时间
读操作的相关设置：
readPreference：SECONDARY_PREFERRED
也就是优先将读操作转发给mongodb从节点
感兴趣可以了解一下bboss会话共享框架，采用mongodb来存储会话数据，快速实现集群节点间会话共享和跨域跨应用会话共享，实现与具体容器无关，能够统计在线会话数，还能在统一监控中心管理应用会话（删除会话，查询会话数据等），无需使用session_sticky，参考资料：
--- 共有 3 条评论 ---
: 所有这个是一个矛盾的问题，要防止延迟读到脏数据，又要保证速度，这时通过设置超时间很有讲究了，同步复制策略也很关键
另外，因为从库也是不断从主机同步数据，其实从库的写压力也是很大
谢谢你精彩的回答， 不过我有一个问题，如果设置集群全部写确认成功后才返回，会影响接口API的返回响应时间。所以我们只采用确认主机写成功即返回}