Loading...

XML

Word

Printable

JSON

Type: Bug
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 8.2.0-rc0
Affects Version/s: None
Component/s: None
Labels:
- auto-fix-version-interrupted
- resharding-success-rate-improvements

Assigned Teams:

Cluster Scalability
Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Sprint:
ClusterScalability Apr14-Apr28
Linked BF Score:
200
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
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

Assignee:: Cheahuychou Mao
Reporter:: Cheahuychou Mao
Participants:: Cheahuychou Mao, Githook User
Votes:: 0 Vote for this issue
Watchers:: 2 Start watching this issue

Created:: Apr 08 2025 06:13:15 PM UTC
Updated:: Jun 20 2025 07:52:56 PM UTC
Resolved:: May 12 2025 07:02:11 PM UTC

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates