[SERVER-45181] Rollback via refetch should set initial data timestamp to max(minvalid, local oplog's top) on rollback success. Created: 16/Dec/19  Updated: 06/Dec/22  Resolved: 30/Dec/19

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

Type: Improvement Priority: Major - P3
Reporter: Suganthi Mani Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-38925 Rollback via refetch can cause _id du... Closed
Assigned Teams:
Replication
Participants:

 Description   

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.



 Comments   
Comment by Suganthi Mani [ 18/Dec/19 ]

william.schultz Your understanding is correct. Basically, we update the rolling back node's minvalid to sync source's top of oplog after refetching documents from sync source.
1) After refetching the documents from sync source and before rollback fix up writes - here
2) Another refetching of documents from sync source to update the collection metadata info - here.

Both the above the calls are made before setting our initialDataTimestamp. the optimization is to remove the redundant call here.

FYI, I noticed it while reading the code.

Comment by William Schultz (Inactive) [ 18/Dec/19 ]

Also, suganthi.mani, is there anything particular motivation for making this optimization, or was it just something you noticed when reading the code?

Comment by William Schultz (Inactive) [ 18/Dec/19 ]

suganthi.mani If I understand correctly you are saying that we have already fetched minValid from our sync source here, before setting our initialDataTimestamp and making another call to fetch the last operation from our sync source here. The RollbackSourceImpl::getLastOperation function is called inside checkRbidAndUpdateMinValid to set our minValid, so the optimization is to get rid of the latter, redundant call to getLastOperation and use the existing value of minValid.

Comment by Daniel Gottlieb (Inactive) [ 17/Dec/19 ]

Because local minvalid is none other than the rollback sync source oplog's top before the rollback start.

I believe this is what the previous logic did resulting in SERVER-38925. william.schultz left a very good write-up. suganthi.mani please take a look at that ticket to see if your intended change with this ticket would reintroduce that bug.

My interpretation was incorrect. suganthi.mani explained that the local/rolling back node's minvalid is updated to the sync source's top of oplog value after refetching documents. I believe this optimization is safe.

Generated at Thu Feb 08 05:08:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.