[SERVER-29431] initialsync.js does not verify that initial sync succeeds Created: 02/Jun/17 Updated: 30/Oct/23 Resolved: 23/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.9, 3.5.13 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | William Schultz (Inactive) |
| 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: |
v3.4
|
||||
| Sprint: | Repl 2017-07-31, Repl 2017-08-21, Repl 2017-09-11 | ||||
| Participants: | |||||
| Description |
|
initialsync.js creates a replica set with nodes of one version, then adds a node of a higher/lower version, and tests that initial sync succeeds on the new node. However, the test erroneously passes when initial sync does not succeed on the 3.4 branch:
|
| Comments |
| Comment by Ramon Fernandez Marina [ 24/Aug/17 ] |
|
Author: {'username': u'will62794', 'name': u'William Schultz', 'email': u'william.schultz@mongodb.com'}Message: (cherry picked from commit 45d595886839fb1ebf153f338c65011f1874be6d) |
| Comment by Ramon Fernandez Marina [ 24/Aug/17 ] |
|
Author: {'username': u'will62794', 'name': u'William Schultz', 'email': u'william.schultz@mongodb.com'}Message: |
| Comment by William Schultz (Inactive) [ 23/Aug/17 ] |
|
Improvements to the multiversion initial sync tests were committed in master. Those changes will fix the problems on the 3.4 branch once they are backported. (BACKPORT-1079). |
| Comment by William Schultz (Inactive) [ 22/Aug/17 ] |
|
On the 3.4 branch the multiVersion/initialsync.js test will run initial sync on a 3.2 node with a 3.4 sync source. The test will erroneously pass even if initial sync fails because we are only calling awaitReplication in the JS test as a way to check that initial sync completed. In version 3.2, we may complete the cloning phase and oplog application phase, and then move on to building indexes. We can see this point in one of the test logs. By this point of initial sync, we may have already set our optime to be up to date with the sync source, so checking the op time is not a correct way to determine initial sync success. We should be waiting until the node transitions into SECONDARY state. |