Details
-
Improvement
-
Resolution: Unresolved
-
Major - P3
-
None
-
None
-
Catalog and Routing
-
Sharding EMEA 2022-09-19, Sharding EMEA 2022-10-03, Sharding EMEA 2022-10-17, Sharding EMEA 2022-10-31, Sharding EMEA 2022-11-14, Sharding EMEA 2022-11-28, Sharding EMEA 2022-12-12, Sharding EMEA 2022-12-26, Sharding EMEA 2023-01-09
-
3
Description
After the ShardRegistry is made causally consistent in SERVER-46202, there should ideally no longer be any need for places to call the (non-causally consistent) getShardNoReload() method (and the other "NoReload" methods). We should clean up the call sites using these, and convert them to using the non-"NoReload" variants instead. This might require plumbing through opCtx (since getShard requires opCtx, but getShardNoReload doesn't), and also being careful to avoid any problems with getShard blocking (which getShardNoReload never does).
Attachments
Issue Links
- depends on
-
SERVER-72884 Remove usages of non causally consistent ShardRegistry::getShardForHostNoReload accessor
-
- Open
-
-
SERVER-67912 Reduce set of non-causally consistent API of the ShardRegistry
-
- Closed
-
-
SERVER-67914 Remove ShardRegistry::_getShardForRSNameNoReload
-
- Closed
-
- related to
-
SERVER-57280 ShardRegistry must be initialized before DDL coordinators contact any shard
-
- Closed
-
-
SERVER-46202 Implement ShardRegistry on top of ReadThroughCache to make it causally consistent
-
- Closed
-