-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
v5.1, v5.0, v4.4
-
Sharding 2021-11-29, Sharding 2021-12-13
-
56
-
1
Background
Mirrored Reads were introduced in 4.4. They "mirror" a read from the primary to the secondary as well. If the read that gets sent to the secondary has an older shard version than it expects, it will send a command to the primary to refresh.
Problem
The test calls refreshCatalogCacheForNs in order to make sure that the nodes are consistently refreshed. While this refreshes the primary, it does not refresh the secondary. This means that, due to mirrored reads, we could get spurious and unexpected refreshes on the primary.
There are a few possible solutions:
- Make the test not run with mirrored reads (not a good idea IMO)
- Make the test more resilient to background refreshes (even something as basic as retrying)
- Make the test refresh the secondaries alongside the primaries
- Update the refresh logic so that the secondary sends the shardVersion which made the secondary trigger a refresh. This way the primary can check whether or not it needs to refresh
- To automatically retry the operation using the auto retry logic. Specifically we could use withTxnAndAutoRetryOnMongos
- related to
-
SERVER-63493 update-shard-key tests failing due to transaction lock timeouts
- Closed