[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:
Backports
Depends
Duplicate
duplicates SERVER-33770 send dbVersion on convertToCapped Closed
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:

If you use the movePrimary command to move un-sharded collections, you must either restart all mongos instances, or use the flushRouterConfig command on all mongos instances before reading or writing any data to any unsharded collections that were moved. This action ensures that the mongos is aware of the new shard for these collections.



 Comments   
Comment by Githook User [ 05/Oct/18 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-31563 Remove sections of not_allowed_on_sharded_collection_cmd.js with known bugs

(cherry picked from commit b226e55c4ca7b8c1275d51f6a1300cfed2ec7d24)
(cherry picked from commit f1c9541eed03d725e14720c6c9c6a54d84f44e66)
Branch: v4.0
https://github.com/mongodb/mongo/commit/60ffd6066c60558c786a0949da12696ab045cbd6

Comment by Githook User [ 27/Sep/18 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-31563 Remove sections of not_allowed_on_sharded_collection_cmd.js with known bugs

(cherry picked from commit b226e55c4ca7b8c1275d51f6a1300cfed2ec7d24)
Branch: v3.6
https://github.com/mongodb/mongo/commit/f1c9541eed03d725e14720c6c9c6a54d84f44e66

Comment by Githook User [ 10/Sep/18 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-31563 Remove sections of not_allowed_on_sharded_collection_cmd.js with known bugs
Branch: master
https://github.com/mongodb/mongo/commit/b226e55c4ca7b8c1275d51f6a1300cfed2ec7d24

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 SERVER-33770 started attaching DatabaseVersion to convertToCapped.

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.

Generated at Thu Feb 08 04:27:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.