[SERVER-74670] A new startup parameter to ignore unsupported parameters Created: 07/Mar/23 Updated: 26/Jun/23 Resolved: 26/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Xiang Gao | Assignee: | Mark Benvenuto |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Security
|
||||||||
| Sprint: | Security 2023-06-12, Security 2023-06-26 | ||||||||
| Participants: | |||||||||
| Description |
|
New server startup parameters can break older mongoDB versions. For example, loadBalancerPort ( Cloud backup/restore can run into this type of mongoDb startup failures due to incompatible parameters, especially with rapid release versions. For instance, to restore a mongoDB version 5.1 snapshot to a version 6.3 target cluster, as suggested by the server teams, we'd need to start mongoDB 5.1 on the snapshot and successively upgrade it 5.1->5.2->5.3->6.0->..->6.3. We currently use the startup parameters from the target cluster to start all the versions in the upgrade path. Using loadBalancerPort as an example, since it doesn't work with version 5.1, restore will fail. It'd be hard for backup team to keep track of versions and incompatible parameters. Therefore, we'd like to request a new startup parameter to let server ignore unsupported startup parameters. We can apply this new parameter to its supported versions only. |
| Comments |
| Comment by Mark Benvenuto [ 26/Jun/23 ] |
|
As discussed in previous comments, I do not think this such a feature to ignore unknown setParameters is a good idea and I am closing this ticket. |
| Comment by Mark Benvenuto [ 12/Jun/23 ] |
|
If the server adds a flag, then server is committed to supporting this for all customers even if the flag is hidden. Since the code is open source, its existence can be discovered by reading the code. Also, there has not been demand from other customers to support this. |
| Comment by Xiang Gao [ 09/Jun/23 ] |
How is this different we do it or server does it internally? This parameter can be private (not in public doc) |
| Comment by Mark Benvenuto [ 09/Jun/23 ] |
|
As stated before, MongoDB strives for backwards compatibility (particularly with API stability feature), but it has never guaranteed forwards compatibility. The API stability guarantees do not apply to setParameters though (https://github.com/mongodb/mongo/blob/a56b96b31585eb845b7dcbfbd52c9e52cef5d560/src/mongo/db/STABLE_API_README.md) You can get a list of setParameter that a given mongod instance supports by running the getParameter command (see https://www.mongodb.com/docs/upcoming/reference/command/getParameter/#retrieve-all-parameters). You can use this list to filter out setParmeters the server does not know about. At this time, we have no plans to add the ability to ignore unknown setParameters. I understand that you would like to run any MongoDB version with any set of setParameters you choose and MongoDB should just ignore the ones it does not know about. We have concerns you may set parameters on versions with unknown effects. This may cause problems over the long term as you cannot tell which setParameters have an affect on the server. Worse, as per your example:
I believe this pattern would be fragile long term and do not want to enable support the ability to ignore setParameters at this time. |