[SERVER-31137] Assert that the featureCompatibilityVersion server parameter is initialized from the featureCompatibilityVersion document during startup Created: 18/Sep/17 Updated: 30/Oct/23 Resolved: 19/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Maria van Keulen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Storage 2017-10-23 | ||||||||
| Participants: | |||||||||
| Description |
|
We should ensure the server parameter accurately reflects the stored FCV value before accepting connections. |
| Comments |
| Comment by Githook User [ 19/Oct/17 ] |
|
Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}Message: |
| Comment by Maria van Keulen [ 18/Oct/17 ] |
|
Ok, I will proceed with the ticket and exempt the replSet and shardsvr cases from the check. |
| Comment by Tess Avitabile (Inactive) [ 18/Oct/17 ] |
|
Yes, I think members of a replica set need to be able to connect before the in-memory FCV parameter is set. So exempting those configurations from the check makes sense. We can leave in in-memory FCV parameter uninitialized, so that the WT KV engine will not downgrade files if we shut down before the first election. |
| Comment by Geert Bosch [ 18/Oct/17 ] |
|
The question isn't so much whether we store the FCV document, but whether we know what to initialize the in-memory FCV parameter to. If for replset and/or shardserver it is OK to accept connection while we still default the FCV parameter to 3.4, we can exempt such configurations from the check. |
| Comment by Tess Avitabile (Inactive) [ 18/Oct/17 ] |
|
geert.bosch, maria.vankeulen pointed out that for nodes started with replset or shardsvr, we do not store the FCV document before accepting connections. She asked whether it makes sense to set the internal FCV parameter to 3.4 in those cases, so that we can assert that the internal FCV parameter is set at the end of startup. It looks like we only use kUnset when the WT KV engine is shutting down, to determine whether to downgrade files. So for replica sets, it sounds like the question is what the behavior of a new replica set should be if there is a shutdown before the first election. My instinct is that we should not downgrade files if there is a shutdown before the first election, since when we start back up again, we will set FCV=3.6 after the first election. But I may be incorrect, since I don't know what is involved in downgrading WT files. However, if that is the case, it sounds like we will have to leave the FCV parameter uninitialized until the first election. For shard servers, at the moment we do not write the FCV document until addShard is called. I'm guessing we should not leave the FCV parameter uninitialized for so long, and that we should downgrade WT files if there is a shutdown before addShard is called. Today at the upgrade/downgrade meeting we will discuss whether shard servers should set FCV=3.4 at startup (or at first election, for replica sets). Then we can reduce this to the replica set case. |