-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Replication
-
(copied to CRM)
-
0
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.
- duplicates
-
SERVER-28068 Do not go into rollback due to falling off the back of your sync source's oplog
- Closed
- is related to
-
SERVER-71156 Fatal Assertion 40507 UnrecoverableRollbackError and Mongo Crash with 4.0.27 WT
- Closed
- related to
-
SERVER-28068 Do not go into rollback due to falling off the back of your sync source's oplog
- Closed