[JAVA-458] with slaveOk, query distribution to slave is not even Created: 26/Oct/11 Updated: 18/Jun/12 Resolved: 05/Apr/12 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Antoine Girbal | Assignee: | Jeffrey Yemin |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
For a 3 node replset, looks like 1 slave is hit 80% and the other one 20%. |
| Comments |
| Comment by Jeffrey Yemin [ 18/Jun/12 ] |
|
Closing for 2.8.0 release. |
| Comment by auto [ 17/May/12 ] |
|
Author: {u'login': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}Message: |
| Comment by Jonathan Hodges [ 07/Apr/12 ] |
|
Hi, We are using version 2.7.3 of the Java driver with version 2.7.3 of a 5 node replica set. We have noticed this issue where under load only the master and one of the slave nodes receive the bulk of the traffic. It seemed to be higher than the 80% mentioned above, but we didn't drill down to determine the actual distribution percentage. We will definitely grab 2.8.0 when it is released, but until then we were curious if you might be able to suggest a suitable workaround. Is it possible to create two instances of the Java driver, one configured for the writes and map/reduce and the other for the reads? For the read instance would it be possible to only use a subset of the 5 node replica set to connect to that doesn't include the master, maybe just 3 of the nodes that weren't getting leveraged? Thanks in advance, Jonathan Hodges |
| Comment by Jeffrey Yemin [ 05/Apr/12 ] |
|
The expected behavior was that all slave-ok queries would be evenly load-balance across all secondaries within 15 ms (overridable using com.mongodb.slaveAcceptableLatencyMS system property) of the fastest secondary. This is now what actually happens. As before, the ping times for each member of the replica are still measureed in a background thread (named "ReplicaSetStatus:Updater"). This thread (one for each instance on Mongo created) loops through each member of the replica set, calling the "isMaster" command on each, and measures the latency of the call for each member. It then sleeps for 5000 ms before doing it again (configurable with the "com.mongodb.updaterIntervalMS" system property. In addition, if no primary was found, instead of sleeping for 5000 ms, it only sleeps for 10 ms before trying again, so that the client finds the new primary fairly fast but without spamming it too hard. This interval is configurable with the "com.mongodb.updaterIntervalNoMasterMS" system property. One other behavioral change: All readers and writers block until at least one pass through the replica set in the updater thread has completed. |
| Comment by auto [ 05/Apr/12 ] |
|
Author: {u'login': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}Message: Merge branch 'master' into |