-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
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
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).
- depends on
-
SERVER-72884 Remove usages of non causally consistent ShardRegistry::getShardForHostNoReload accessor
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
- related to
-
SERVER-57280 ShardRegistry must be initialized before DDL coordinators contact any shard
-
- Closed
-
-
-
- Closed
-