MongoDB中文社区
什么场景下才适合用读写分离？是不是可以使用Secondary或者SecondaryPreference实现读写分离来提高系统的承载能
力？
1、Secondary节点的写压力跟Primary基本是相同的，所以，读操作在从库上并不会提高
查询速度。
2、由于是异步复制数据，所以读Secondary的数据可能是过时的。
3、在分片架构中使用读写分离的时候有可能会丢失数据或者读到重复数据。
读写分离唯一的作用是减少了主节点读的压力？
1、Secondary节点的写压力跟Primary基本是相同的，所以，读操作在从库上并不会提高
查询速度。
问题:
1、其实主备的写压力不是完全一致性,备库是批量应用oplog,主库有可能是单个操作来提交的,所以说写压力并不是完全等同.
即使在写压力等同的情况下,本次读写操作,读主要聚合计算,由于专门读节点来操作,存在大并发下消耗大量CPU,避免影响主库正常的读写操作.
2、例如在跨地区的副本集或者分片,此时读本地的从节点能够解决网络的延迟问题,从而提升读响应时间,从而提升查询速度。
3、如果主备的机器性能存在瓶颈,此时读确实不会提升查询速度。如果都不存在瓶颈的话,通常情况下读写分离不会提升查询速度。
2、由于是异步复制数据，所以读Secondary的数据可能是过时的。
回答:
确实存在的这样问题,如果要求实时很高,不建议读从库,直接主库。如果能接受可控的延迟,此时可以考虑。
可以在连接串配置最大延迟时间,最小允许配置是90s.
3、在分片架构中使用读写分离的时候有可能会丢失数据或者读到重复数据。
读写分离真的收益不大吗
问题:
对于重复数据这个是由于读从节点时默认读关注是available,读主库默认是local,所以调整默认读关注即可可以解决这个问题。
对于数据丢失–这个跟写关注设置有关系,即使不是访问备库,也可能存在如write concern设置1
至于读写分离收益问题需要具体问题具体分析,对于数据库强一致或者实时非常高的,此时读写分离会带来问题。
对于实时要求不高、分析统计类(过去时间点)、跨地区的集群、主库连接太多等情况下,读写分离还是有收益的
对于重复数据这个是由于读从节点时默认读关注是available,读主库默认是local,所以调整默认读关注即可可以解决这个问题
这个怎么理解
主要看你认为重复数据是什么？
对于重复数据这个是由于读从节点时默认读关注是available,读主库默认是local,所以调整默认读关注即可可以解决这个问题
这个怎么理解