Currently when a read is performed against a view backed by an unsharded collection, the following takes place:
1) mongos sends the read to the primary shard for the given database
2) The primary shard determines that namespace is a view, and returns the view definition and underlying namespace to mongos
3) mongos rewrites the read on the view to be an aggregate command against the underlying collection, with the view definition incorporated into the aggregation pipeline
4) mongos executes the aggregate command
When the view is backed by an unsharded collection we would ideally perform the rewrite on the primary shard and execute locally rather than return the view definition to mongos for rewrite/execution. This was previously not possible, as the primary shard could incorrectly report that a sharded collection was unsharded. With the completion of SERVER-32198 however we can now definitively know whether a collection's sharding state is sharded, unsharded or unknown. In the case where we know it is unsharded, we can execute the view on the read remotely, without mongos kick-back.
- causes
-
SERVER-89348 [v5.0] ReplicaSet started with --shardsvr but not added to a cluster doesn't consider all collections as unsharded
- Closed
- is related to
-
SERVER-32198 Missing collection metadata on the shard implies both UNSHARDED and "metadata not loaded yet"
- Closed
-
SERVER-42282 Consider replacing CommandOnShardedViewNotSupportedOnMongod mechanism with rewrite / routing from shard
- Backlog
- related to
-
SERVER-55454 Relax OperationShardingState::initializeClientRoutingVersion _shardVersionsChecked invariant
- Closed