[SERVER-44252] Delete implicit collection creation loop through the config server in sharding Created: 25/Oct/19 Updated: 29/Oct/23 Resolved: 09/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Mihai Andrei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2019-11-04, Sharding 2019-11-18, Sharding 2019-12-02, Sharding 2019-12-16, Sharding 2019-12-30, Sharding 2020-01-13 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
PM-1168 will allow implicitly creating collections inside transactions, which would fail in sharding today because of this uassert in DatabaseImpl::createCollection. (Hitting the uassert would abort the transaction on the shard.) Since the implicit collection creation loop through the config server is not currently used for adding new collections immediately into the sharding catalog, we will just delete this loop and revisit implicit collection creation as part of other catalog work in the future. BackgroundIn sharding, shards never implicitly create collections on themselves. Instead, if they receive a request that would implicitly create a collection, they throw here. The exception is caught in the service entry point on the shard, and a handler that sends _configsvrCreateCollection to the config server is invoked. The _configsvrCreateCollection command then creates the collection on the primary shard. |
| Comments |
| Comment by Githook User [ 09/Jan/20 ] |
|
Author: {'name': 'Mihai Andrei', 'email': 'mihai.andrei@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 10/Dec/19 ] |
|
jack.mulrow, Ok, I'm tempted to not try to work around I think the result will be that the stale mongos that attached shardVersion UNSHARDED and a database version will either have targeted the correct primary shard or will get a StaleDbVersion error and retry against the correct primary shard. |
| Comment by Jack Mulrow [ 10/Dec/19 ] |
|
Yeah it still checks databaseVersion here. |
| Comment by Esha Maharishi (Inactive) [ 09/Dec/19 ] |
|
jack.mulrow, will createIndexes still check databaseVersion in that case? (It should currently, see the test case for createIndexes in database_versioning_all_commands.js.) |
| Comment by Jack Mulrow [ 09/Dec/19 ] |
|
Note that as of |
| Comment by Charlie Swanson [ 08/Nov/19 ] |
|
As mentioned in |
| Comment by Esha Maharishi (Inactive) [ 28/Oct/19 ] |
|
Marked as related to PM-1361, since if we remove the CannotImplicitlyCreateCollection uassert, the current implementation of createIndexes on mongos (to broadcast to all shards) would cause the collection to get implicitly created on shards that do not own chunks for the collection, probably with the wrong UUID. CC jack.mulrow |