-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Replication
Currently here, rollback via refetch sets the initial data timestamp to max(rollback sync source oplog's top, local oplog's top). As a result, we do 2 unnecessary things
1) We perform a network call to sync source to get the oplog's top.
2) We delay the stable check point. Because, for a stable check point to happen, we need stable ts to be >= initial data timestamp. So, if many operations happened on sync source after rollback start, then the local min valid will be lesser than sync source oplog's top.
Instead, we should set the initial data timestamp to max(local minvalid, local oplog's top). Because the rolling back node's minvalid gets updated to the sync source's top of oplog value after refetching the documents from sync source.
Note: This is just an optimization ticket.
- related to
-
SERVER-38925 Rollback via refetch can cause _id duplication when enableMajorityReadConcern:false
- Closed