Details
-
Task
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
Replication
-
Fully Compatible
Description
In 3.6, we kept around the old 3.4 rollback algorithm, which can be optionally used by setting the rollbackMethod server parameter to rollbackViaRefetchNoUUID We did not make any improvements to this algorithm and so don't expect it to be any better or worse than 3.4 To maintain some basic coverage for it, however, we can create a replica sets test suite that runs with this old rollback algorithm, and create a sub-directory in jstests/replsets with tests whitelisted to run on this test suite. To make this simple, we can just copy any existing rollback tests that will be superseded by new 3.6 rollback tests into this directory and run those on the old algorithm. These should be the tests that exercise specific operations and operation sequences. We can leave tests that exercise general rollback machinery to be run on both the new and old rollback algorithm. For example double_rollback.js.
The tests to be run only on the old algorithm can be likely be as follows:
rollback.js
rollback2.js
rollback3.js
rollback_cmd_unrollbackable.js
rollback_collMod_fatal.js
rollback_collMod_PowerOf2Sizes.js
rollback_index.js
We will have 3.6 tests that supersede these rollback tests, so it is fine to let them run only on the old algorithm. As part of this ticket we can also get rid of the Rollback 3.4 evergreen variant. It doesn't seem necessary, and it is running a lot of test suites unrelated to rollback, which seems wasteful.