MongoDB | 2640546

Info

Putting --shardsvr on the command line of a MongoD that's not part of a cluster enables the sharding subsystem and puts it in a state ready for the shard to be joined to a cluster. In this state, because the user is still directly connected to the replica set, the sharding subsystem bypasses many checks, because the requests don't come from a MongoS (i.e., don't contain a shard version). However, there is a problematic line introduced under SERVER-49228 that forces an otherwise unversioned request to be treated as if it came from a MongoS and this causes the checks to not be bypassed. One of these checks requires an access to the shard id of the node, which will invariant in this state because it's not present. One of the ways to fix this would be to take part of the changes for SERVER-84754 and make the CSR initialize collections as UNSHARDED if the sharding state is not yet enabled. This approach should be safe to do, because once initialised, the sharding state cannot be rolled-back (or rather the node fasserts if it gets rolled back). Because of the previous condition, we have the following guarantee that any collections that existed prior to the RS joining the sharded cluster will continue as UNSHARDED until either someone shards them or until the node is restarted (in which case they will become UNKNOWN because ShardingState::enabled() == true).

Top User Comments

Steps to Reproduce