[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: |
|
||||||||
| 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. 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. 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 ] |
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. |