-
Type: Task
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
v8.0
-
CAR Team 2024-04-15
-
41
Before SERVER-80135, upon shard collection, the filtering information would be cleared on all non-db-primary participant shards and either installed correctly or cleared on the dbPrimary. In SERVER-80135, this behavior was changed so that the filtering information would be cleared on all participants (including the dbPrimary) and a best effort, asynchronous refresh would be done after the release of the critical section.
The motivation behind this was that when creating a collection on a shard outside the dbPrimary, it seemed like strange behavior to have the filtering information known on the dbPrimary but not on the shard owning data. The refresh was made asynchronous because it was best effort anyways.
However, we are seeing many test failures due to shards not knowing their filtering information after the shardCollection completes. Additionally, this new behavior could increase the latency of the first operation after the shard collection which would now have to wait for the refresh to finish rather than that cost being included in the shardCollection command.
In team discussions, it seemed as though the leaning was towards simply making the refresh on all shards synchronous so that the behavior is more consistent with prior versions. In this ticket, we should ensure that we have a consensus on this behavior and update the refresh if needed.
- is caused by
-
SERVER-80135 Allow ShardCollection to work correctly when an unsharded collection is not located on the DBPrimary
- Closed
- related to
-
SERVER-88998 Complete TODO listed in SERVER-88696
- Closed