[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:
Gantt Dependency
has to be done after SERVER-30242 Add a method to determine if fCV has ... Closed
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: SERVER-31137 Assert the in-memory fCV is initialized on startup
Branch: master
https://github.com/mongodb/mongo/commit/d8f0d6292967c7f9bdba8890f58acee3a97c247d

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.

Generated at Thu Feb 08 04:26:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.