[SERVER-39781] Blacklist out_to_existing.js from sharding_csrs_continuous_config_stepdown Created: 22/Feb/19  Updated: 29/Oct/23  Resolved: 18/Mar/19

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

Type: Bug Priority: Major - P3
Reporter: Ted Tuckman Assignee: Ted Tuckman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-40172 Unblacklist merge_to_existing from sh... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 24

 Description   

As exposed in our testing infrastructure, it seems like a config stepdown can cause a drop collection to be missed by both shards, leaving the cluster in a state where all shards agree the collection is sharded, but mongos knows it is not sharded.



 Comments   
Comment by Githook User [ 18/Mar/19 ]

Author:

{'name': 'Ted Tuckman', 'username': 'TedTuckman', 'email': 'ted.tuckman@mongodb.com'}

Message: SERVER-39781 Blacklist out_to_existing.js from continuous_config_stepdown
Branch: master
https://github.com/mongodb/mongo/commit/c90d961fbe008f81455ceaf53a4c8284eb76bbc5

Comment by Ted Tuckman [ 25/Feb/19 ]

For the test that fails a sharded collection is dropped and the test attempts to replace it with an unsharded collection

Comment by Kaloian Manassiev [ 22/Feb/19 ]

Is this drop of a sharded or unsharded collection? Because in the un-sharded case it should be retried and sent to the database primary and in the sharded case, we leave the collection and chunks entries for last, so retrying the operation even if it failed partway should still succeed.

In either case, retry should be able to clean-up any remaining state.

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