[SERVER-3062] Read from the nearest slave Created: 09/May/11  Updated: 12/Jul/16  Resolved: 09/May/12

Status: Closed
Project: Core Server
Component/s: Internal Client, Sharding
Affects Version/s: None
Fix Version/s: 2.1.2

Type: Improvement Priority: Major - P3
Reporter: Kristina Chodorow (Inactive) Assignee: Ben Becker
Resolution: Done Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-3887 Mongos should use bucketed ping times... Closed
Related
Participants:

 Description   

as determined by ping time



 Comments   
Comment by Pierre Ynard [ 08/Jun/12 ]

Is the problem related to cursors? We have cases with very little constraints on data consistency so I'm a bit confused about what "out of order" means exactly

Comment by Eliot Horowitz (Inactive) [ 05/Jun/12 ]

Only when the client re-connects.
The problem with switching is then its possible to get out of order reads.

Comment by Pierre Ynard [ 05/Jun/12 ]

If I understand correctly, if no local replica is available then a non-local one is selected as a fallback, but if a local replica becomes available after that, the client will keep using the non-local, fallback replica that it already selected. Wouldn't it be better if the client automatically switched to the better slave? Is there a scope to the client's connections (besides the node going offline) where at some point the connection will be closed and the slave selection logic will be run again, choosing the better slave that time?

Comment by auto [ 09/May/12 ]

Author:

{u'login': u'', u'name': u'Ben Becker', u'email': u'ben.becker@10gen.com'}

Message: SERVER-3062: dbclient_rs should select a local replica set member by default.
Branch: master
https://github.com/mongodb/mongo/commit/1d335a6c1b59432af84f60a01b1ec6fed170b18c

Comment by Scott Hernandez (Inactive) [ 16/Nov/11 ]

We also need an option to read from closest replica, ind. of status (prim/sec).

Generated at Thu Feb 08 03:01:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.