[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: |
|
||||||||
| 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: |
| 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. |