[SERVER-31563] Reevaluate not_allowed_on_sharded_collection_cmd.js testing Created: 13/Oct/17 Updated: 30/Oct/23 Resolved: 10/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.9, 4.0.4, 4.1.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Randolph Tan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||||||
| Sprint: | Sharding 2018-09-24 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 34 | ||||||||||||||||
| Description |
|
to whether include testing with "stale mongos". movePrimary can currently cause multiple mongos to be out of sync until they refresh their ShardRegistry. So the test could be trying to test a behavior that is known to be undefined. Our docs already has the proper warning:
|
| Comments |
| Comment by Githook User [ 05/Oct/18 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: (cherry picked from commit b226e55c4ca7b8c1275d51f6a1300cfed2ec7d24) |
| Comment by Githook User [ 27/Sep/18 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: (cherry picked from commit b226e55c4ca7b8c1275d51f6a1300cfed2ec7d24) |
| Comment by Githook User [ 10/Sep/18 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: |
| Comment by Randolph Tan [ 10/Sep/18 ] |
|
Update: the test can still fail because convertToCapped needs the collection to exists. So, if the staleMongos created the collection on the wrong shard, covertToCapped would error out. |
| Comment by Randolph Tan [ 10/Sep/18 ] |
|
The test should work properly now since |
| Comment by Blake Oler [ 02/Mar/18 ] |
|
When looking at BF-8195 with esha.maharishi, we found that the ensureMovePrimary command always runs against the first mongos (st.s0). In this test, that happens to be the "freshMongos" instead of the "staleMongos." The "staleMongos" won't know that the primary has been changed. In the case that shard0 remains the primary, the test will run correctly. In the case that the primary is changed from shard0 to shard1, the "staleMongos" will continue to run commands against the old primary shard, causing failures. A quick solution would be to switch the places of "freshMongos" and "staleMongos." If this is done, the "staleMongos" will run the movePrimary command, and therefore know the new primary. |