[SERVER-33878] Update OplogFetcher to go into SyncSource selection on CappedPositionLost error Created: 14/Mar/18  Updated: 05/Dec/22  Resolved: 24/Jul/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-28068 Do not go into rollback due to fallin... Closed
Related
related to SERVER-28068 Do not go into rollback due to fallin... Closed
is related to SERVER-71156 Fatal Assertion 40507 UnrecoverableRo... Closed
Assigned Teams:
Replication
Participants:
Case:
Linked BF Score: 0

 Description   

If we get it during secondary oplog fetching due to falling off the back of our sync source’s oplog, and retry the query (current behavior), we are guaranteed to go into rollback and fassert in rollback via refetch, or just fail to find a common point (which means reading the entire sync source oplog) in rollback to a stable timestamp. If we simply went back to sync source selection, we could skip all that and maybe find a better sync source that works, or log the “too stale” error like we expect.



 Comments   
Comment by Judah Schvimer [ 24/Jul/20 ]

I checked with samy.lanka and we think this was fixed by SERVER-28068. I will close this as a duplicate.

Generated at Thu Feb 08 04:34:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.