[SERVER-6162] backport of targeted shard ranges instead of broadcast on all queries Created: 21/Jun/12  Updated: 11/Jul/16  Resolved: 26/Jun/12

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.7

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: Tad Marshall
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

We shouldn't ever send queries to shards where the collection does not exist - this can introduce version issues (since version 0 is "special") and cause problems when dropping shards (since the dropped shards are also targeted until refreshed).

Proposing backport of f93918db (partial or full) - we previously didn't backport b/c potentially a bit dangerous, but has not caused any problems in master for several months, so it's probably burned-in enough.



 Comments   
Comment by auto [ 27/Jun/12 ]

Author:

{u'date': u'2012-06-27T10:41:22-07:00', u'email': u'tad@10gen.com', u'name': u'Tad Marshall'}

Message: SERVER-6162 adapt sharding/no_empty_reset.js for v2.0

The test jstests/sharding/no_empty_reset.js was using some
functionality that wasn't present in the 2.0 shell. Add code
to find the shard name manually to adapt for this.
Branch: v2.0
https://github.com/mongodb/mongo/commit/dd36d37c09408cd0fac5c40b48c071afd7491b1e

Comment by Tad Marshall [ 26/Jun/12 ]

Backported to version 2.0.7.

Comment by auto [ 26/Jun/12 ]

Author:

{u'date': u'2012-06-25T11:10:00-07:00', u'name': u'gregs', u'email': u'greg@10gen.com'}

Message: SERVER-6162 backport of targeted shard ranges instead of broadcast on all queries

test and fix for zero-version being sent to unneeded shards during scatter/gather

Backport based on f93918db8ec15c9de7c884d0a560a185a8ef423d

Signed-off-by: Tad Marshall <tad@10gen.com>
Branch: v2.0
https://github.com/mongodb/mongo/commit/6c19d602f19c696f4231ed5d2da210c1f79c3296

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