[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:
Depends
is depended on by SERVER-43198 Zombie writes from failing $merge sho... Backlog
is depended on by SERVER-43851 Work around zombie writes in $merge t... Closed
Related
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.

Background

In 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: SERVER-44252 Delete implicit collection creation loop through the config server in sharding
Branch: master
https://github.com/mongodb/mongo/commit/944e382e9b1cc6b873efaaa5aaf4c01a992f130f

Comment by Esha Maharishi (Inactive) [ 10/Dec/19 ]

jack.mulrow, Ok, I'm tempted to not try to work around SERVER-32198 and just pretend it doesn't exist - the Barcelona team is planning to fix SERVER-32198 for 4.4 anyway.

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 SERVER-44405, createIndexes will not check shard version when creating an index implicitly creates a collection. If we start allowing createIndexes to implicitly create an unsharded collection, we'll have to be careful to ensure that this can't lead to inconsistent indexes across shards if a stale router targets a stale shard (e.g. through the problem from SERVER-32198).

Comment by Charlie Swanson [ 08/Nov/19 ]

As mentioned in SERVER-43851, the query team would like to use the 'allowImplcitCollectionCreation' flag and uassert once it's no longer being used as a kick-back to the config server. When doing this work, please hold off on deleting those parts.

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

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