[SERVER-31143] Ensure 3.4 binaries crash if they contain a UUID Created: 18/Sep/17 Updated: 29/Jan/18 Resolved: 29/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Louis Williams |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Storage 2017-10-23 |
| Participants: |
| Description |
|
In a replica set, after setFeatureCompatibilityVersion: 3.4 returns successfully, it is still possible for a minority of nodes to contain UUIDs. If a user then shuts down those nodes and downgrades their binaries to 3.4, the UUIDs will stick around and get stale while the data changes. |
| Comments |
| Comment by Louis Williams [ 29/Sep/17 ] |
|
Duplicates behavior of |
| Comment by Louis Williams [ 29/Sep/17 ] |
|
If a minority node has UUIDs, then it still has a targetVersion field set in the featureCompatibilityVersion document. This field is only removed once the upgrade is complete. As schwerin correctly pointed out, a 3.4 binary will not start in this case. |
| Comment by Andy Schwerin [ 28/Sep/17 ] |
|
Yes, I think that 3.4 won't start up when the targetVersion field is present, so I think this is a duplicate of the targetVersion work. |
| Comment by Eric Milkie [ 20/Sep/17 ] |
|
Will the new design for the values of admin.system.version help with this issue? |