To define a cluster server parameter, we add it to the server_parameters section of an .idl file, with the set_at: cluster field. The generated source for the .idl file then calls MONGO_SERVER_PARAMETER_REGISTER, which makes the parameter usable and visible in commands such as getClusterParameter. Thus, whether a parameter is available depends on whether the .idl is linked into the MongoDB binaries or not.

Since we build multiple binaries (MongoD, MongoS), it is possible that a cluster server parameter is linked to only one of them, which is generally undesirable. For instance, in SERVER-93033 we found that some parameters were linked to only MongoD but not MongoS. This kind of problem is easy to miss since the only consequence is that the cluster parameter becomes unavailable in the user-facing MongoS router, but it is still available and usable within MongoD.

To avoid those problems reocurring in the future, we should add some mechanism that detects inconsistencies in what parameters are available. Some possibilities include:

• Test that a call to db.adminCommand( { getClusterParameter : '*' } ) returns the same parameters in both MongoD and MongoS.

• Test that the list of parameters in cluster_server_parameter_utils.js is exhaustive, i.e. add assertions to the tests in case a parameter is returned by MongoD or MongoS which is not listed in the test.