[SERVER-59957] Add NamespaceString::isPerShardNamespace method Created: 14/Sep/21  Updated: 26/Oct/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Bernard Gorman Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: PM-2144-Milestone-0, oldshardingemea
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-59839 ShardServerProcessInterface::getColle... Closed
Assigned Teams:
Catalog and Routing
Sprint: Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27, Sharding EMEA 2022-01-10, Sharding EMEA 2022-01-24, Sharding EMEA 2022-02-07, Sharding EMEA 2022-02-21
Participants:

 Description   

When attempting to perform an internal read, we typically use our pipeline-building API to create a pipeline and attach a cursor source here, which can be either a local cursor (when running on a replica set) or a cursor which we establish via a sharded network request (when running on a shard). However, there are certain cases where the namespace we are attempting to read from is shard-local - that is, the collection exists independently on each shard - and attempting to attach a cursor source ends up incorrectly issuing a request to the remote primary shard instead, because the sharding infrastructure reports the collection as being unsharded. This has lead us to create an increasing list of exceptions for different internal namespaces as each such use-case is encountered, and in other cases to use NamespaceString::isNamespaceAlwaysUnsharded as an imperfect approximation of a check for shard-local collections.

We should add a new helper method NamespaceString::isPerShardNamespace or isShardLocalNamespace so that we can easily determine whether a given namespace is expected to exist independently on each shard, or whether we must issue a remote request to access it.


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