[SERVER-29427] Remove internalValidateFeaturesAsMaster flag Created: 02/Jun/17 Updated: 06/Dec/22 Resolved: 16/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
The server parameter internalValidateFeaturesAsMaster=false is set on backup nodes to allow them to accept usages of new features through the command path, regardless of featureCompatibilityVersion. This is needed because backup nodes perform an initial sync through the command path, and it is a valid state to have new features in the database even with a downgraded featureCompatibilityVersion. For example, it's a valid state to have featureCompatibilityVersion=3.2 and decimal data on a 3.4 mongod, so backup must be able to initial sync this state. If no features require this server parameter in 3.6, we should remove support for it. |
| Comments |
| Comment by Eric Milkie [ 16/Jun/17 ] |
|
We can reopen this in the future if we want to do this after 3.6.. |
| Comment by David Storch [ 16/Jun/17 ] |
|
My current recommendation is that we close this ticket as Won't Fix. Although we may not use internalValidateFeaturesAsMaster for the 3.4/3.6 upgrade, it probably makes sense to leave this mechanism in place. It would be necessary if we were to, say, add another BSON type. |
| Comment by David Storch [ 15/Jun/17 ] |
|
Have we been able to conclude that there are no new features in 3.6 which will require this flag in order for the backup/restore service to work? CC steve.briskin. |