[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:
Related
is related to SERVER-60679 Open a port on Mongos that accepts pr... Closed
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 (SERVER-60679) was backported to 5.0 and 5.2. So it's only applicable to 5.0/5.2/6.0+. MongoDb fails to start if we use it on 5.1. 

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 ]

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.

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:

  1. A setting that does not have affect the server suddenly has an effect because of a backport.
  2. A setParameter that is believed to have an effect, does not affect the server because it is misspelled or does not exist.

I believe this pattern would be fragile long term and do not want to enable support the ability to ignore setParameters at this time.

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