- 所有的从节点拥有与主节点一样的写入负载,读的加入会增加其负载;
- 对于分片的集合,在平衡器的关系下,数据的返回结果可能会缺失或者重复某部分数据;
- 相对而言,官方建议使用shard来分散读写请;
- 一致性的考虑,对一致性要求比较高的应用程序是不应该从备份节点读取数据,备份节点通常由于加载问题,网络等原因,而落后于主节点几毫秒,几秒,几分钟甚至更多。如果应用程序需要读取它自己的写操作(比如,先插入一个文档,再去查询它),那么不应该从备份节点去读取数据,除非针对写操作,使用Write Concern定义w数值,在复制到所有备份节点之后,再返回执行成功与否。总之,如果从一个落后的备份节点读取数据,就要牺牲一致性。如果希望写入操作返回之前被复制到所有的副本集成员,就要牺牲写入速度。
- 如果路由到的备份节点,其中一台挂了,那么其他节点将承担其相应的压力,需要注意此时在线节点的负载压力。
1.2 使用的场景
通常官方不推荐使用从节点实现读写分离,但可能存在以下场景需要使用读写分离:- 异地的分布式部署
- 故障切换,在紧急情况下向从节点读数据
1.3 延伸读写分离思考
该思考来源:https://github.com/smallnewer/bugs/issues/22 个人总结如下: 主从的写压力基本一样;- MongoDB从不会受到主写锁的影响,可通过mongotop 或者 mongostat查看写锁状态;
- MongoDB从会在主写锁后,在恢复oplog时,进行写锁;
- 从优先读,而且读太多会影响写;
- 从节点读的权限比写锁优先级高(注:主节点反之,应该是写贪婪的),建议当从节点的读太高从而影响了oplog的恢复时,改用分片方案。
二 读写分离部署
2.1 正常部署副本集
参考《006.MongoDB复制(副本集)》。2.2 开启Sencondary可读状态
1 [root@mongodb02 ~]# mongo --host 172.24.8.72 -u clusteradmin -p clusteradmin 2 my_rep:SECONDARY> db.getMongo().setSlaveOk() 3 [root@mongodb02 ~]# mongo --host 172.24.8.73 -u clusteradmin -p clusteradmin 4 my_rep:SECONDARY> db.getMongo().setSlaveOk() #分别连接两个Sencondary节点服务器,设置为可读状态
2.3 客户端设置读取方式
通过修改客户端读取方式实现从节点的读,具体方式包括:012.MongoDB读写分离
标签:插入 pos 恢复 ddl 分离 word layout mongo 备份