[SERVER-41931] Remove forceRollbackViaRefetch flag Created: 26/Jun/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: 4.0.10, 4.2.0-rc2
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32588 Create flag to use rollback via refetch Closed
is related to SERVER-40954 Error message for UnrecoverableRollba... Closed
Assigned Teams:
Replication
Participants:

 Description   

If the forceRollbackViaRefetch parameter is set to true, we will hit an invariant when trying to do a rollback. The intended behavior is for us to use the rollbackViaRefetch algorithm no matter what, even if the storage engine supports the recover-to-timestamp functionality.



 Comments   
Comment by Alyson Cabral (Inactive) [ 26/Jun/19 ]

Ok, yeah, let's get rid of it.

Comment by Judah Schvimer [ 26/Jun/19 ]

We introduced it because we were afraid that recover to a timestamp could have a bad bug and we wanted an easy way for users to fall back on the old algorithm if they were having a problem with the new rollback algorithm. Apparently they never actually could due to this invariant.

Comment by Alyson Cabral (Inactive) [ 26/Jun/19 ]

Why did we introduce the flag? Why would users have used it in the past?

Comment by Judah Schvimer [ 26/Jun/19 ]

I think on 4.2, we do not want to try to support this parameter. We have no testing of how it will interact with prepare (it will likely invariant). On 4.0 it was supposed to work and I don't see why it shouldn't work minus the invariant we're hitting.

alyson.cabral, do we care about this flag, or should we just remove it since we barely test it, and clearly no one is using it?

Comment by William Schultz (Inactive) [ 26/Jun/19 ]

This is a bug on both 4.0 and 4.2. At first glance it appears we have at least one test on 4.2 that utilizes the forceRollbackViaRefetch parameter, but in that test the rollback actually fails hereĀ before we ever hit the problematicĀ invariant. On 4.0, a grep for "forceRollbackViaRefetch" turns up matches only in bgsync.cpp, bgsync.h, and rs_rollback.h, so we don't have any test coverage of the parameter there.

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