[SERVER-39899] Enable the initial sync fuzzer in Evergreen Created: 01/Mar/19 Updated: 29/Oct/23 Resolved: 29/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.10 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Vlad Rachev (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | tig-evgconfig | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | STM 2019-04-08 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 40 | ||||||||
| Story Points: | 3 | ||||||||
| Description |
|
Create a new initial_sync_fuzzer.yml resmoke.py YAML suite file that causes mongod processes to use an effectively infinite number of initial sync attempts.
Define a new initial_sync_fuzzer_gen Evergreen task based on the existing rollback_fuzzer_gen Evergreen task.
Configure the new initial_sync_fuzzer_gen Evergreen task to run on all of the build variants the existing rollback_fuzzer_gen Evergreen task runs on with the exception of the "Enterprise RHEL 6.2 (inMemory)" and "Linux (ephemeralForTest)" build variants. Since the initial version of the initial sync fuzzer is meant to only be targeting the interaction between initial sync and prepared transactions, we can only run it against the WiredTiger storage engine.
|
| Comments |
| Comment by Githook User [ 29/Mar/19 ] | ||||||||||||
|
Author: {'name': 'vrachev', 'username': 'vrachev', 'email': 'vlad.rachev@mongodb.com'}Message: | ||||||||||||
| Comment by Vlad Rachev (Inactive) [ 28/Mar/19 ] | ||||||||||||
|
Thanks max.hirschhorn. I should've run the other initial sync tests before pushing. | ||||||||||||
| Comment by Max Hirschhorn [ 28/Mar/19 ] | ||||||||||||
|
vlad.rachev, I reverted the changes from 6b8b02e because they were causing the jstests/replsets/initial_sync_test_fixture_test.js test to fail. It looks like the restartNodeWithoutData() function needs to check whether TestData.logComponentVerbosity is defined before attempting to pass it as a server parameter to the server.
| ||||||||||||
| Comment by Githook User [ 28/Mar/19 ] | ||||||||||||
|
Author: {'email': 'max.hirschhorn@mongodb.com', 'name': 'Max Hirschhorn', 'username': 'visemet'}Message: Revert " This reverts commit 6b8b02e8d72c055c6f686a781e53cde9384461b3. | ||||||||||||
| Comment by Githook User [ 27/Mar/19 ] | ||||||||||||
|
Author: {'email': 'vlad.rachev@mongodb.com', 'name': 'vrachev', 'username': 'vrachev'}Message: | ||||||||||||
| Comment by Judah Schvimer [ 05/Mar/19 ] | ||||||||||||
|
I would just put replication.initialSync at level 4 since that should cover everything we have or will add. It's a very limited set of log messages, and if they're useful for anything this is what they should be useful for. | ||||||||||||
| Comment by Max Hirschhorn [ 04/Mar/19 ] | ||||||||||||
judah.schvimer, are the LOG(3) message in databases_cloner.cpp something you're likely interested in? initial_syncer.cpp logs information about timestamping at "replication.initialSync"=2 that was was curious if that'd be sufficient. | ||||||||||||
| Comment by Judah Schvimer [ 04/Mar/19 ] | ||||||||||||
|
Initial sync has it's own log component so logging just that at a very high level, and everything else at a much lower level definitely makes sense. | ||||||||||||
| Comment by Judah Schvimer [ 04/Mar/19 ] | ||||||||||||
|
I would start at either 0 or 2. I don't think 1 adds much for initial sync. If we wanted to log every op we apply or every document we insert we could see the least verbose way to do that. | ||||||||||||
| Comment by Max Hirschhorn [ 01/Mar/19 ] | ||||||||||||
|
judah.schvimer, do you have any recommendations for what logComponentVerbosity we set for the initial sync fuzzer? |