[SERVER-37390] RollbackTestFixture doesn't need to wait for a new primary if it didn't shut down the current primary Created: 28/Sep/18 Updated: 29/Oct/23 Resolved: 03/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.3, 4.3.3, 4.0.20 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Suganthi Mani |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.2, v4.0
|
||||||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2018-10-22, Repl 2018-11-05, Repl 2019-09-23, Repl 2019-11-18, Execution Team 2019-12-16, Repl 2019-12-02, Repl 2019-12-16, Execution Team 2020-01-13, Execution Team 2019-12-30 | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 33 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
The rollback fuzzer suites utilize the RollbackTestFixture to run randomized rollback testing. Some of the suites (e.g. rollback_fuzzer_clean_shutdowns) will shut down nodes at random times. After we shutdown a node, we wait until there is a stable primary so that we can continue doing writes in the test. The way we check this can be racy, though, if we get a current primary that then steps down, and we get that same node as a secondary. Instead of asserting that the primary and secondary are not equal, I think it would be simpler to just check if we shut down the original primary. If so, then we need to wait for a new primary. Otherwise, we shouldn't need to wait, since the original primary should be stable, since it is supported by an arbiter. |
| Comments |
| Comment by Githook User [ 03/Aug/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}Message: (cherry picked from commit 02ce213b40c56096c9c57e093778b0889c335bb9) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 15/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}Message: (cherry picked from commit 02ce213b40c56096c9c57e093778b0889c335bb9) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by William Schultz (Inactive) [ 07/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It looks like we already have a failpoint that is used to speed up tests that are slowed down by that awaitData timeout. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by William Schultz (Inactive) [ 06/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
judah.schvimer A previous investigation turned up this remaining timeout that depends on the election timeout. I did not do a thorough look at it but that was my hypothesis for why rollback tests ran slower when using a 24 hour election timeout. Here are the runtimes of some rollback tests before and after the changes made by suganthi.mani.
Those are all tests with "rollback" in their name, so it may include some that don't use RollbackTest fixture. Here is a general sense of the timing distribution before and after the changes, limited to tests between 0 and 100 seconds in duration. Before (mean=40.05 seconds)
After (mean=84.52 seconds)
Our thought was to introduce a failpoint to reduce that timeout for the RollbackTest fixture. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Judah Schvimer [ 06/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
william.schultz, how does the high election timeout slow down the test fixture? The timeout is 24 hours, and the test doesn't take 24 hours, so I would expect us to not rely on that timeout ever. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by William Schultz (Inactive) [ 06/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
suganthi.mani Can we file a ticket for improving the speed of RollbackTest fixture (see comment above) now that these changes are pushed? Per our latest in person discussion, my understanding was that the high election timeout slows down the test fixture somewhat significantly. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 03/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by William Schultz (Inactive) [ 15/Nov/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
suganthi.mani In relation to our discussion about using a high election timeout in RollbackTest to prevent any unwanted topology changes, I noticed when running a sample rollback test that this timeout can cause a test to run much slower if we use an extremely high election timeout i.e. 24 hours. It added around 50 seconds of execution time to the "jstests/replsets/rollback_rename_collection_on_sync_source.js" test. That awaitData timeout may be something we could make configurable for tests that use a high election timeout. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Suganthi Mani [ 14/Nov/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note to myself-> This needs to backported to 4.2 + 4.0. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by William Schultz (Inactive) [ 03/Sep/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
As of now, I don't think this will be included in the Faster Local Testing (FLT) project. This ticket was originally filed to address a correctness concern mentioned in the linked BF. It was not about improving performance of the test fixture. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ratika Gandhi [ 29/Aug/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
william.schultz, Adding you here to please check if this is in scope for Faster Local Testing. |