[SERVER-47364] Serialize config term in ReplSetConfig even if it is kUninitializedTerm Created: 06/Apr/20 Updated: 06/Dec/22 Resolved: 13/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.5.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently we do not append the config 'term' field to ReplSetConfig if the term is uninitialized (i.e. -1). We did this in 4.4 for compatibility issues with 4.2, in case a 4.4 binary node sent a config to a 4.2 node. This may not be necessary any longer, since versions >= 4.4 will always be able to parse a config object with a term. There might be issues with serializing uninitialized terms, however, if we expect multi-step downgrades e.g. from 4.6 -> 4.4 -> 4.2. If an uninitialized term was written down explicitly in 4.6, we might not remove it when we go from FCV 4.4 to FCV 4.2. If we do not support such a downgrade, scenario, though, then it might be safe to remove this extra logic. |
| Comments |
| Comment by Evin Roesle [ 23/Apr/20 ] |
|
There are no plans to support downgrades fromĀ 4.6->4.4->4.2 at this time. |