-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Security 2022-02-21
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
When new values are set for a given cluster server parameter, the change is typically only received by one node. Therefore, the update needs to be communicated to all other nodes in the cluster. For replica sets, it is easiest to accomplish this by persisting the cluster parameter values to a replicated document on disk. The usual replication machinery ensures that changes to the document eventually are mirrored on secondary nodes, and a new OpObserver can observe changes to the replication oplog to update in-memory values whenever an operation is applied on the cluster parameter document. Additionally, the durable storage is necessary to ensure cluster parameters can be persisted across server restarts and upgrades.
- Define the ClusterParameterOpObserver class, which should derive from the general OpObserver class. Make sure that this gets registered onto the global OpObserverRegistry during node startup.
- Implement overrides of the onInserts, onUpdate, aboutToDelete, onDelete, onDropDatabase, onDropCollection, postRenameCollection, onImportCollection, and _onReplicationRollback functions that monitor changes that will impact cluster server parameter documents on the config.settings collection.
- Implement a new function that instantiates all cluster server parameters on node startup based on values persisted on the config.clusterParameters collection. If the document does not exist, it will instantiate the cluster parameter to the default value.
- depends on
-
SERVER-59921 Create Feature flag for Mechanism for Specifying Cluster-Wide Configuration Options
-
- Closed
-