-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
ClusterScalability Apr14-Apr28
-
200
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Currently, the aggregation command run by the ReshardingOplogFetcher against the each donor shard specifies readPreference "nearest" to avoid overloading the donor's primary. The read also specifies maxStalenessSeconds to 90 to avoid reading from a secondary that is "too stale". The issue with this setup is that if during the critical section , the aggregate command ends up targeting a secondary with staleness greater than the critical section timeout window, then it would not be able to reach the "final" oplog entry and enter the "strict-consistency" in time.
- related to
-
SERVER-106341 Fix race condition in ReshardingOplogFetcherTest
-
- In Progress
-
-
SERVER-105842 Make ReshardingOplogFetcher fetch oplog entries from the primary when the recipient is approaching strict consistency to prepare for the critical section
-
- Closed
-
-
SERVER-105029 Avoid using failpoint in OnEnteringCriticalSectionAfterFetchingFinalOplogEntry unit test
-
- Open
-