MongoDB Server Parameters

Synopsis

MongoDB provides a number of configuration options that you can setusing:

  1. db.adminCommand( { setParameter: 1, <parameter>: <value>  } )
  1. setParameter:
  2.    <parameter1>: <value1>
  3.    ...
  • the —setParameter command-line option for mongodand mongos:
  1. mongod --setParameter <parameter>=<value>
  2. mongos --setParameter <parameter>=<value>

For additional configuration options, seeConfiguration File Options, mongod andmongos.

Parameters

Authentication Parameters

  • authenticationMechanisms

Changed in version 4.0: Remove support for the deprecated MONGODB-CR authentication mechanism.

Available for both mongod and mongos.

Specifies the list of authentication mechanisms the server accepts. Setthis to one or more of the following values. If you specify multiplevalues, use a comma-separated list and no spaces. For descriptionsof the authentication mechanisms, see Authentication.

ValueDescriptionSCRAM-SHA-1RFC 5802 standardSalted Challenge Response Authentication Mechanism using the SHA-1hash function.SCRAM-SHA-256RFC 7677 standardSalted Challenge Response Authentication Mechanism using the SHA-256hash function.

Requires featureCompatibilityVersion set to 4.0.

New in version 4.0.

MONGODB-X509MongoDB TLS/SSL certificate authentication.GSSAPI (Kerberos)External authentication using Kerberos. This mechanism isavailable only in MongoDB Enterprise.PLAIN (LDAP SASL)External authentication using LDAP. You can also use PLAINfor authenticating in-database users. PLAIN transmitspasswords in plain text. This mechanism is available only inMongoDB Enterprise.

You can only set authenticationMechanisms duringstart-up.

For example, to specify both PLAIN and SCRAM-SHA-256 as theauthentication mechanisms, use the following command:

  1. mongod --setParameter authenticationMechanisms=PLAIN,SCRAM-SHA-256 --auth
  • clusterAuthMode

New in version 2.6.

Available for both mongod and mongos.

Set the clusterAuthMode to either sendX509 orx509. Useful during rolling upgrade to use x509 formembership authenticationto minimize downtime.

For more information about TLS/SSL and MongoDB, seeConfigure mongod and mongos for TLS/SSL andTLS/SSL Configuration for Clients .

  1. db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )
  • enableLocalhostAuthBypass
  • Available for both mongod and mongos.

Specify 0 or false to disable localhost authenticationbypass. Enabled by default.

enableLocalhostAuthBypass is not available usingsetParameter database command. Use thesetParameter option in the configuration file or the—setParameter option on thecommand line.

See Localhost Exception for more information.

  • KeysRotationIntervalSec

New in version 3.6.

Default: 7776000 seconds (90 days)

Specifies the number of seconds for which an HMAC signing keyis valid before rotating to the next one. This parameter is intendedprimarily to facilitate authentication testing.

You can only set KeysRotationIntervalSec duringstart-up, and cannot change this setting with thesetParameter database command.

  • ldapUserCacheInvalidationInterval
  • For use with MongoDB deployments usingLDAP Authorization. Available for mongodinstances only.

The interval (in seconds) that the mongod instancewaits between external user cache flushes. After MongoDB flushes theexternal user cache, MongoDBreacquires authorization data from the LDAP server thenext time an LDAP-authorized user issues an operation.

Increasing the value specified increases the amount of timeMongoDB and the LDAP server can be out of sync, but reduces the load onthe LDAP server. Conversely, decreasing the value specifieddecreases the time MongoDB and the LDAP server can be out of sync whileincreasing the load on the LDAP server.

Defaults to 30 seconds.

  • ldapUseConnectionPool

New in version 4.0.9.

Specifies whether MongoDB should use connection pooling whenconnecting to the LDAP server for authentication/authorization.

Starting in version 4.2, MongoDB uses the following default values:

  • true on Windows.

  • true on Linux where MongoDB Enterprise binaries are linked againstlibldap_r.

  • false on Linux where MongoDB Enterprise binaries are linked againstlibldap.

Tip

To allow concurrent authentication commands for LDAP users, youmay wish to link to libldap_r. For assistance, contactsupport.

In earlier versions (versions 4.0.9+), the default value isfalse.

You can only set ldapUseConnectionPool duringstart-up, and cannot change this setting with thesetParameter database command.

  • ldapConnectionPoolUseLatencyForHostPriority
  • New in version 4.2.1 and 4.0.13

Default: true

A boolean that determines whether the LDAP connection pool (seeldapUseConnectionPool) should use latency of the LDAPservers to determine the connection order (from lowest latency tohighest).

You can only setldapConnectionPoolUseLatencyForHostPriority duringstart-up, and cannot change this setting during runtime with thesetParameter database command.

  • ldapConnectionPoolMinimumConnectionsPerHost
  • New in version 4.2.1 and 4.0.13

Default: 1

The minimum number of connections to keep open to each LDAP server.

You can only setldapConnectionPoolMinimumConnectionsPerHost duringstart-up, and cannot change this setting during runtime with thesetParameter database command.

  • ldapConnectionPoolMaximumConnectionsPerHost
  • New in version 4.2.1 and 4.0.13

The maximum number of connections to keep open to each LDAP server.

You can only setldapConnectionPoolMaximumConnectionsPerHost duringstart-up, and cannot change this setting during runtime with thesetParameter database command.

  • ldapConnectionPoolMaximumConnectionsInProgressPerHost
  • New in version 4.2.1 and 4.0.13

The maximum number of in-progress connect operations to each LDAP server.

You can only setldapConnectionPoolMaximumConnectionsInProgressPerHostduring start-up, and cannot change this setting with thesetParameter database command.

  • ldapConnectionPoolHostRefreshIntervalMillis
  • New in version 4.2.1 and 4.0.13

Default: 60000

The number of milliseconds in-between health checks of the pooledLDAP connections.

You can only setldapConnectionPoolHostRefreshIntervalMillis duringstart-up, and cannot change this setting with thesetParameter database command.

  • ldapConnectionPoolIdleHostTimeoutSecs
  • New in version 4.2.1 and 4.0.13

Default: 300

The maximum number of seconds that the pooled connections to an LDAPserver can remain idle before being closed.

You can only setldapConnectionPoolIdleHostTimeoutSecs duringstart-up, and cannot change this setting with thesetParameter database command.

  • opensslCipherConfig

New in version 3.6.

Changed in version 4.0: With the use of native TLS/SSL libraries, the parameteropensslCipherConfig is supported for Linux/BSD andno longer supported in Windows and macOS. See MongoDB 4.0TLS/SSL.

Specify the cipher string for OpenSSL when using TLS/SSL encryption.For a list of cipher strings, seehttps://www.openssl.org/docs/man1.0.2/apps/ciphers.html#CIPHER-STRINGS

You can only set opensslCipherConfig during start-up, andcannot change this setting using the setParameterdatabase command.

For version 4.2 and greater, the use of TLS options is preferredover SSL options. The TLS options have the same functionality asthe SSL options.

  1. mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem

For versions 4.0 and earlier:

  1. mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --sslMode requireSSL --sslPEMKeyFile Certs/server.pem
  • opensslDiffieHellmanParameters

New in version 3.6.

Available on Linux only

Specify the path to the PEM file that contains the OpenSSLDiffie-Hellman parameters. Specifying the OpenSSL Diffie-Hellmanparameters enables support for Ephemeral Diffie-Hellman (DHE) cipher suites duringTLS/SSL encryption.

Ephemeral Diffie-Hellman (DHE) cipher suites (and Ephemeral EllipticCurve Diffie-Hellman (ECDHE) cipher suites) provideForward Secrecy. Forward Secrecy cipher suitescreate an ephemeral session key that is protected by the server’sprivate key but never transmitted. This ensures that even if aserver’s private key is compromised, you cannot decrypt pastsessions with the compromised key.

Note

Starting in MongoDB 4.2, ifopensslDiffieHellmanParameters is unset butECDHE is enabled, MongoDB enables DHE usingffdhe3072 Diffie-Hellman parameter, as defined inRFC 7919#appendix-A.2. The ffdhe3072 is a strong parameter(i.e. size is greater than 1024). Strong parameters are notsupported with Java 6 and 7 unless extended support has beenpurchased from Oracle.

You can only set opensslDiffieHellmanParameters duringstartup, and cannot change this setting using thesetParameter database command.

If for performance reasons, you need to disable support for DHEcipher suites, use the opensslCipherConfig parameter:

  1. mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL:!DHE:!kDHE@STRENGTH' ...
  • saslauthdPath

Note

Available only in MongoDB Enterprise (except MongoDB Enterprise for Windows).

Available for both mongod and mongos.

Specify the path to the Unix Domain Socket of the saslauthdinstance to use for proxy authentication.

saslHostName overrides MongoDB’s default hostnamedetection for the purpose of configuring SASL and Kerberosauthentication.

saslHostName does not affect the hostname of themongod or mongos instance for any purposebeyond the configuration of SASL and Kerberos.

You can only set saslHostName during start-up, andcannot change this setting using the setParameterdatabase command.

Note

saslHostName supports Kerberos authentication and isonly included in MongoDB Enterprise. For Linux systems, seeConfigure MongoDB with Kerberos Authentication on Linuxfor more information.

Allows users to override the default Kerberosservice name component of the Kerberosprincipal name, on a per-instance basis. If unspecified, thedefault value is mongodb.

MongoDB only permits setting saslServiceName atstartup. The setParameter command can not changethis setting.

saslServiceName is only available in MongoDBEnterprise.

Important

Ensure that your driver supports alternate service names.

  • scramIterationCount

New in version 3.0.0.

Default: 10000

Available for both mongod and mongos.

Changes the number of hashing iterations used for all newSCRAM-SHA-1 passwords. More iterations increase the amount oftime required for clients to authenticate to MongoDB, but makespasswords less susceptible to brute-force attempts. The defaultvalue is ideal for most common use cases and requirements.

If you modify this value, it does not change the iteration count forexisting passwords. The scramIterationCount value mustbe 5000 or greater.

For example, the following sets the scramIterationCountto 12000.

  1. mongod --setParameter scramIterationCount=12000

Or, if using the setParameter command within themongo shell:

  1. db.adminCommand( { setParameter: 1, scramIterationCount: 12000 } )

See also

  • scramSHA256IterationCount

New in version 4.0.

Default: 15000

Available for both mongod and mongos.

Changes the number of hashing iterations used for all newSCRAM-SHA-256 passwords. More iterations increase the amount oftime required for clients to authenticate to MongoDB, but makespasswords less susceptible to brute-force attempts. The defaultvalue is ideal for most common use cases and requirements.

If you modify this value, it does not change iteration count forexisting passwords. The scramSHA256IterationCount valuemust be 5000 or greater.

For example, the following sets the scramSHA256IterationCountto 20000.

  1. mongod --setParameter scramSHA256IterationCount=20000

Or, if using the setParameter command within themongo shell:

  1. db.adminCommand( { setParameter: 1, scramSHA256IterationCount: 20000 } )

See also

  • sslMode

New in version 2.6.

Available for both mongod and mongos.

Set the net.ssl.mode to either preferSSL orrequireSSL. Useful during rolling upgrade to TLS/SSL to minimize downtime.

For more information about TLS/SSL and MongoDB, seeConfigure mongod and mongos for TLS/SSL andTLS/SSL Configuration for Clients .

  1. db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } )

See also

tlsMode

  • tlsMode

New in version 4.2.

Available for both mongod and mongos.

Set to either:

  1. db.adminCommand( { setParameter: 1, tlsMode: "preferTLS" } )

For more information about TLS/SSL and MongoDB, seeConfigure mongod and mongos for TLS/SSL andTLS/SSL Configuration for Clients .

See also

sslMode

  • tlsWithholdClientCertificate
  • Default: false

New in version 4.2.

Available for both mongod and mongos.

A TLS certificate is set for a mongod ormongos either by the—tlsClusterFile option or by the—tlsCertificateKeyFile option when—tlsClusterFile is not set. If the TLScertificate is set, by default, the instance sends the certificate wheninitiating intra-cluster communications with othermongod or mongos instances inthe deployment. Set tlsWithholdClientCertificate to 1 or true todirect the instance to withhold sending its TLS certificate during thesecommunications. Use this option with—tlsAllowConnectionsWithoutCertificates(to allow inbound connections without certificates) on all members of thedeployment. tlsWithholdClientCertificate is mutually exclusive with—clusterAuthMode x509.

  • tlsX509ClusterAuthDNOverride

New in version 4.2.

Available for both mongod and mongos.

An alternative Distinguished Name (DN) that the instance can alsouse to identify members of the deployment.

For a MongoDB deployment that uses x.509 certificates forclusterAuthMode, deployment members identifyeach other using x.509 certificates (net.tls.clusterFile, if specified, andnet.tls.certificateKeyFile) during intra-clustercommunications. For members of the same deployment, the DN fromtheir certificates must have the same Organization attributes(O’s), the Organizational Unit attributes (OU’s), and theDomain Components (DC’s).

If tlsX509ClusterAuthDNOverride is set for a member,the member can also use the override value when comparing the DNcomponents (O’s, OU’s, and DC’s) of the presentedcertificates. That is the member checks the presented certificatesagainst itsnet.tls.clusterFile/net.tls.certificateKeyFile.If the DN does not match, the member checks the presentedcertifcate against the tlsX509ClusterAuthDNOverridevalue.

Note

If set, you must set this parameter on all members of thedeployment.

You can use this parameter for a rolling update of certificates tonew certificates that contain a new DN value. SeeRolling Update of x.509 Cluster Certificates that Contain New DN.

For more information about membership certificate requirements, seeMember Certificate Requirements for details.

  • sslWithholdClientCertificate
  • Default: false

Deprecated since version 4.2: Use tlsWithholdClientCertificate instead.

Available for both mongod and mongos.

A TLS certificate is set for a mongod ormongos either by the—tlsClusterFile option or by the—tlsCertificateKeyFile option when—tlsClusterFile is not set. If the TLScertificate is set, by default, the instance sends the certificate wheninitiating intra-cluster communications with othermongod or mongos instances inthe deployment. Set sslWithholdClientCertificate to 1 or true todirect the instance to withhold sending its TLS certificate during thesecommunications. Use this option with—tlsAllowConnectionsWithoutCertificates(to allow inbound connections without certificates) on all members of thedeployment. sslWithholdClientCertificate is mutually exclusive with—clusterAuthMode x509.

  • userCacheInvalidationIntervalSecs
  • Default: 30

Available for mongos only.

On a mongos instance, specifies the interval (in seconds)at which the mongos instance checks to determine whetherthe in-memory cache of user objects has stale data, and if so,clears the cache. If there are no changes to user objects,mongos will not clear the cache.

This parameter has a minimum value of 1 second and a maximumvalue of 86400 seconds (24 hours).

Changed in version 3.0: Default value has changed to 30 seconds, and the minimumvalue allowed has changed to 1 second. mongosonly clears the user cache if there are changes.

  • authFailedDelayMs
  • Default: 0

Available for both mongod and mongos.

New in version 3.4.

Enterprise Feature

Available in MongoDB Enterprise only.

The number of milliseconds to wait before informing clients that theirauthentication attempt has failed. This parameter may be in the range0 to 5000, inclusive.

Setting this parameter makes brute-force login attacks on a databasemore time-consuming. However, clients waiting for a response from theMongoDB server still consume server resources, and this may adverselyimpact benign login attempts if the server is denying access to manyother clients simultaneously.

  • allowRolesFromX509Certificates
  • Default: true

Available for both mongod and mongos.

Available starting in MongoDB 4.0.11 (and 3.6.14 and 3.4.22)

A boolean flag that allows or disallows the retrieval ofauthorization roles from client x.509 certificates.

You can only set allowRolesFromX509Certificates duringstartup in the config file or on the command line.

General Parameters

  • connPoolMaxShardedConnsPerHost

New in version 2.6.

Default: 200

Available for both mongod and mongos.

Sets the maximum size of the legacy connection pools for communication to theshards. The size of a pool does not prevent the creation ofadditional connections, but does prevent the connection pools fromretaining connections above this limit.

Note

The parameter is separate from the connections in TaskExecutorpools. See ShardingTaskExecutorPoolMaxSize.

Increase the connPoolMaxShardedConnsPerHost valueonly if the number of connections in a connection pool has ahigh level of churn or if the total number of created connectionsincrease.

You can only set connPoolMaxShardedConnsPerHost duringstartup in the config file or on the command line. For example:

  1. mongos --setParameter connPoolMaxShardedConnsPerHost=250
  • connPoolMaxShardedInUseConnsPerHost

New in version 3.6.3.

Available for both mongod and mongos.

Sets the maximum number of in-use connections at any given time forthe legacy sharded cluster connection pools.

By default, the parameter is unset.

You can only set connPoolMaxShardedConnsPerHost duringstartup in the config file or on the command line. For example:

  1. mongos --setParameter connPoolMaxShardedInUseConnsPerHost=100

See also

connPoolMaxShardedConnsPerHost

  • shardedConnPoolIdleTimeoutMinutes

New in version 3.6.3.

Available for both mongod and mongos.

Sets the time limit that a connection in the legacy sharded clusterconnection pool can remain idle before being closed.

By default, the parameter is unset.

You can only set shardedConnPoolIdleTimeoutMinutes duringstartup in the config file or on the command line. For example:

  1. mongos --setParameter shardedConnPoolIdleTimeoutMinutes=10

See also

connPoolMaxShardedConnsPerHost

  • connPoolMaxConnsPerHost

New in version 2.6.

Default: 200

Available for both mongod and mongos.

Sets the maximum size of the legacy connection pools for outgoing connectionsto other mongod instances in the global connection pool. The sizeof a pool does not prevent the creation of additional connections,but does prevent a connection pool from retaining connections inexcess of the value of connPoolMaxConnsPerHost.

Note

The parameter is separate from the connections in TaskExecutorpools. See ShardingTaskExecutorPoolMaxSize.

Only adjust this setting if your driver does not poolconnections and you’re using authentication in thecontext of a sharded cluster.

You can only set connPoolMaxConnsPerHost during startupin the config file or on the command line. For example:

  1. mongod --setParameter connPoolMaxConnsPerHost=250
  • connPoolMaxInUseConnsPerHost

New in version 3.6.3.

Available for both mongod and mongos.

Sets the maximum number of in-use connections at any given time forfor outgoing connections to other mongod instances inthe legacy global connection pool.

By default, the parameter is unset.

You can only set connPoolMaxInUseConnsPerHost duringstartup in the config file or on the command line. For example:

  1. mongod --setParameter connPoolMaxInUseConnsPerHost=100

See also

connPoolMaxConnsPerHost

  • globalConnPoolIdleTimeoutMinutes

New in version 3.6.3.

Available for both mongod and mongos.

Sets the time limit that connection in the legacy global connectionpool can remain idle before being closed.

By default, the parameter is unset.

You can only set globalConnPoolIdleTimeoutMinutesduring startup in the config file or on the command line. Forexample:

  1. mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

See also

connPoolMaxShardedConnsPerHost

  • cursorTimeoutMillis

New in version 3.0.2.

Default: 600000 (i.e. 10 minutes)

Available for both mongod and mongos.

Sets the expiration threshold in milliseconds for idle cursorsbefore MongoDB removes them; i.e. MongoDB removes cursors that havebeen idle for the specified cursorTimeoutMillis.

For example, the following sets the cursorTimeoutMillisto 300000 milliseconds (i.e. 5 minutes).

  1. mongod --setParameter cursorTimeoutMillis=300000

Or, if using the setParameter command within themongo shell:

  1. db.adminCommand( { setParameter: 1, cursorTimeoutMillis: 300000 } )

Setting cursorTimeoutMillis to less than or equalto 0 results in all cursors being immediately eligible for timeout.Generally, the timeout value should be greater than the average amount oftime for a query to return results. Use tools like the cursor.explain()cursor modifier to analyze the average query time and select an appropriatetimeout period.

  • failIndexKeyTooLong
  • Available for mongod only.

Changed in version 4.2:

For MongoDB 2.6 through MongoDB versions withfeatureCompatibilityVersion (fCV) set to "4.0" or earlier,Index Key Length Limit applies. If youattempt to insert or update a document whose index field exceedsthe Index Key Length Limit, the operationwill fail and return an error to the client.

To avoid this issue, consider using hashed indexes or indexing a computed value. If you have anexisting data set and want to disable this behavior so you canupgrade and then gradually resolve these indexing issues, you canuse failIndexKeyTooLong to disable this behavior.

Important

Setting failIndexKeyTooLong to false isa temporary workaround, not a permanent solution to theproblem of oversized index keys. WithfailIndexKeyTooLong set to false, queries canreturn incomplete results if they use indexes that skip overdocuments whose indexed fields exceed theIndex Key Length Limit.

failIndexKeyTooLong defaults to true.

Issue the following command to disable the index key lengthvalidation:

  1. db.adminCommand( { setParameter: 1, failIndexKeyTooLong: false } )

You can also set failIndexKeyTooLong atstartup time with the following option:

  1. mongod --setParameter failIndexKeyTooLong=false
  • notablescan
  • Available for mongod only.

Specify whether all queries must use indexes. If 1, MongoDBwill not execute queries that require a collection scan and will return anerror.

Consider the following example which sets notablescan to 1or true:

  1. db.adminCommand( { setParameter: 1, notablescan: 1 } )

Setting notablescan to 1 can be useful for testingapplication queries, for example, to identify queries that scan anentire collection and cannot use an index.

To detect unindexed queries without notablescan, consider readingthe Evaluate Performance of Current Operations andOptimize Query Performancesections and using the logLevel parameter,mongostat and profiling.

Don’t run production mongod instances withnotablescan because preventing collection scans can potentiallyaffect queries in all databases, including administrative queries.

  • ttlMonitorEnabled
  • Available for mongod only.

To support TTL Indexes, mongodinstances have a background thread that is responsible for deletingdocuments from collections with TTL indexes.

To disable this worker thread for a mongod, setttlMonitorEnabled to false, as in the followingoperations:

  1. db.adminCommand( { setParameter: 1, ttlMonitorEnabled: false } )

Alternately, you may disable the thread at startup time by starting themongod instance with the following option:

  1. mongod --setParameter ttlMonitorEnabled=false
  • disableJavaScriptJIT

Changed in version 4.0: The JavaScript engine’s JIT compiler is now disabled by default.

Available for mongod only.

The MongoDB JavaScript engine uses SpiderMonkey, which implementsJust-in-Time (JIT) compilation for improved performance when running scripts.

To enable the JIT, set disableJavaScriptJIT to false, as inthe following example:

  1. db.adminCommand( { setParameter: 1, disableJavaScriptJIT: false } )

Note

$where will reuse existing JavaScript interpretercontexts, so changes to disableJavaScriptJIT may nottake effect immediately for these operations.

Alternately, you may enable the JIT at startup time by starting themongod instance with the following option:

  1. mongod --setParameter disableJavaScriptJIT=false
  • maxIndexBuildMemoryUsageMegabytes

New in version 3.4.

Default: 500

Limits the amount of memory that simultaneous indexbuilds on one collection may consume for the duration of thebuilds. The specified amount of memory is shared between allindexes built using a singlecreateIndexes command or its shell helperdb.collection.createIndexes().

The memory consumed by an index build is separate from theWiredTiger cache memory (seecacheSizeGB).

Index builds may be initiated either by a user commandsuch as Create Indexor by an administrative process such as aninitial sync.Both are subject to the limit set bymaxIndexBuildMemoryUsageMegabytes.

An initial sync operation populatesonly one collection at a time and has no risk of exceeding the memorylimit. However, it is possible for a user to start indexbuilds on multiple collections in multiple databases simultaneouslyand potentially consume an amount of memory greater than the limitset in maxIndexBuildMemoryUsageMegabytes.

Tip

To minimize the impact of building an index on replica sets andsharded clusters with replica set shards, use a rolling index buildprocedure as described onBuild Indexes on Replica Sets.

Changed in version 4.2.

  • reportOpWriteConcernCountersInServerStatus

New in version 4.0.6.

Default: false

A boolean flag that determines whether thedb.serverStatus() method and serverStatuscommand return opWriteConcernCounters information. [1]

You can only setreportOpWriteConcernCountersInServerStatus duringstartup in the config file or on the command line. For example:

  1. mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

[1]Enabling reportOpWriteConcernCountersInServerStatuscan have a negative performance impact; specificaly, when runningwithout TLS.

  • watchdogPeriodSeconds
  • Available for mongod only.

Type: integer

Default: -1 (disabled)

Note

  • Starting in MongoDB 4.2, the Storage Node Watchdog is available in both the Community andMongoDB Enterprise editions.
  • In earlier versions (3.2.16+, 3.4.7+, 3.6.0+, 4.0.0+), theStorage Node Watchdog is onlyavailable in MongoDB Enterprise edition.

Determines how frequent the Storage Node Watchdog checks the status of the monitoredfilesystems:

Note

  • If a filesystem on a monitored directory becomes unresponsive,it can take a maximum of nearly twice the value ofwatchdogPeriodSeconds to terminate themongod.
  • If any of its monitored directory is a symlink to othervolumes, the Storage Node Watchdog does not monitor the symlinktarget. For example, if the mongod usesstorage.directoryPerDB: true (or —directoryperdb) and symlinks a database directory toanother volume, the Storage Node Watchdog does not follow thesymlink to monitor the target.

To enable Storage Node Watchdog,watchdogPeriodSeconds must be set during startup.

  1. mongod --setParameter watchdogPeriodSeconds=60

You can only enable the Storage Node Watchdog at startup. However, once enabled, you canpause the Storage Node Watchdog orchange the watchdogPeriodSeconds during runtime.

Once enabled,

  1. db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )
  • To resume or change the period during runtime, setwatchdogPeriodSeconds to a number greater than orequal to 60.
  1. db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )

Note

It is an error to set watchdogPeriodSeconds at runtime if theStorage Node Watchdog was not enabled atstartup time.

Logging Parameters

Specify an integer between 0 and 5 signifying the verbosityof the logging, where 5 is themost verbose. [2]

The default logLevel is 0 (Informational).

The following example sets the logLevel to 2:

  1. db.adminCommand( { setParameter: 1, logLevel: 2 } )

See also

[2]Starting in version 4.2, MongoDB includes the Debug verbosity level(1-5) in the log messages. For example,if the verbosity level is 2, MongoDB logs D2. In previousversions, MongoDB log messages only specified D for Debug level.

  • logComponentVerbosity

New in version 3.0.0.

Available for both mongod and mongos.

Sets the verbosity levels of various components for log messages. The verbosity level determines theamount of Informational and Debugmessages MongoDB outputs. [3]

The verbosity level can range from 0 to 5:

  • 0 is the MongoDB’s default log verbosity level, to includeInformational messages.
  • 1 to 5 increases the verbosity level to includeDebug messages.For a component, you can also specify -1 to inherit the parent’sverbosity level.

To specify the verbosity level, use a document similar to thefollowing:

  1. {
  2.   verbosity: <int>,
  3.   <component1>: { verbosity: <int> },
  4.   <component2>: {
  5.      verbosity: <int>,
  6.      <component3>: { verbosity: <int> }
  7.   },
  8.   ...
  9. }

For the components, you can specify just the <component>: <int>in the document, unless you are setting both the parent verbositylevel and that of the child component(s) as well:

  1. {
  2.   verbosity: <int>,
  3.   <component1>: <int> ,
  4.   <component2>: {
  5.      verbosity: <int>,
  6.      <component3>: <int>
  7.   }
  8.   ...
  9. }

The top-level verbosity field corresponds tosystemLog.verbosity which sets the default level for allcomponents. The default value of systemLog.verbosity is0.

The components correspond to the following settings:

  1. db.adminCommand( {
  2.    setParameter: 1,
  3.    logComponentVerbosity: {
  4.       verbosity: 1,
  5.       query: { verbosity: 2 },
  6.       storage: {
  7.          verbosity: 2,
  8.          journal: {
  9.             verbosity: 1
  10.          }
  11.       }
  12.    }
  13. } )

You can also set parameter logComponentVerbosity atstartup time, passing the verbosity level document as a string.

  1. mongod --setParameter "logComponentVerbosity={command: 3}"

The mongo shell also provides the db.setLogLevel()to set the log level for a single component. For various ways to setthe log verbosity level, see Configure Log Verbosity Levels.

[3]Starting in version 4.2, MongoDB includes the Debug verbosity level(1-5) in the log messages. For example,if the verbosity level is 2, MongoDB logs D2. In previousversions, MongoDB log messages only specified D for Debug level.

  • maxLogSizeKB

New in version 3.4.

Available for both mongod and mongos.

Type: integer

Default: 10

Specifies the maximum size, in kilobytes, for a log line. Lines exceedingthis limit print only the beginning and end of the line, excising the middleportion.

For example, the following sets the maximum size to 20 kilobytes:

  1. mongod --setParameter maxLogSizeKB=20

Warning

Using a large value for maxLogSizeKB may adversely affectsystem performance and negatively impact database operations.

Sets quiet logging mode. If1, mongod will go into a quiet loggingmode which will not log the following events/activities:

  • connection events;
  • the drop command, thedropIndexes command, thediagLogging command, thevalidate command, and theclean command; and
  • replication synchronization activities.Consider the following example which sets thequiet to 1:
  1. db.adminCommand( { setParameter: 1, quiet: 1 } )

See also

quiet

  • redactClientLogData

New in version 3.4.

Available for both mongod and mongos.

Type: boolean

Enterprise Feature

Available in MongoDB Enterprise only.

Configure the mongod or mongos toredact any message accompanying a given log event before logging.This prevents the program from writing potentially sensitive datastored on the database to the diagnostic log. Metadata such as erroror operation codes, line numbers, and source file names are stillvisible in the logs.

Use redactClientLogData in conjunction withEncryption at Rest andTLS/SSL (Transport Encryption) to assist compliance withregulatory requirements.

To enable log redaction on a running mongod ormongos, use the following command:

  1. db.adminCommand( { setParameter: 1, redactClientLogData : true } )

See also

security.redactClientLogData

Configures mongod to log full source code stack tracesfor every database and socket C++ exception, for use with debugging.If true, mongod will log full stack traces.

Consider the following example which sets thetraceExceptions to true:

  1. db.adminCommand( { setParameter: 1, traceExceptions: true } )

See also

systemLog.traceAllExceptions

  • suppressNoTLSPeerCertificateWarning

New in version 4.0.1.

Available for both mongod and mongos.

Type: boolean

Default: false

By default, a mongod or mongos withTLS/SSL enabled andnet.ssl.allowConnectionsWithoutCertificates : truelets clients connect without providing a certificate forvalidation while logging an warning. SetsuppressNoTLSPeerCertificateWarning to 1 or true tosuppress those warnings.

The following operation sets suppressNoTLSPeerCertificateWarningto true:

  1. db.adminCommand( { setParameter: 1, suppressNoTLSPeerCertificateWarning: true} )

Diagnostic Parameters

To facilitate analysis of the MongoDB server behavior by MongoDBengineers, MongoDB logs server statistics to diagnostic files atperiodic intervals.

For mongod, the diagnostic data files are stored in thediagnostic.data directory under the mongod instance’s—dbpath or storage.dbPath.

For mongos, the diagnostic data files, by default, arestored in a directory under the mongos instance’s—logpath or systemLog.path directory. The diagnosticdata directory is computed by truncating the logpath’s fileextension(s) and concatenating diagnostic.data to the remainingname.

For example, if mongos has —logpath/var/log/mongos.log.201708015, then the diagnostic data directory is/var/log/mongos.diagnostic.data/ directory. To specify a differentdiagnostic data directory for mongos, set thediagnosticDataCollectionDirectoryPath parameter.

The following parameters support diagnostic data capture (FTDC):

Note

The default values for the diagnostic data capture interval and themaximum sizes are chosen to provide useful data to MongoDB engineerswith minimal impact on performance and storage size. Typically, thesevalues will only need modifications as requested by MongoDB engineersfor specific diagnostic purposes.

  • diagnosticDataCollectionEnabled

New in version 3.2.

Changed in version 3.4.14: Available for both mongod and mongos.

Type: boolean

Default: true

Determines whether to enable the collecting and logging of data fordiagnostic purposes. Diagnostic logging is enabled by default.

For example, the following disables the diagnostic collection:

  1. mongod --setParameter diagnosticDataCollectionEnabled=false
  • diagnosticDataCollectionDirectoryPath

New in version 3.4.14.

Type: String

Available for mongos only.

Specify the directory for the diagnostic directory formongos. If the directory does not exist,mongos creates the directory.

If unspecified, the diagnostic data directory is computed bytruncating the mongos instance’s —logpath orsystemLog.path file extension(s) and concatenatingdiagnostic.data.

For example, if mongos has —logpath/var/log/mongos.log.201708015, then the diagnostic data directory is/var/log/mongos.diagnostic.data/.

Important

If mongos cannot create the specified directory, e.g.a file exists with the same name in the path or the process doesnot have permissions to create the directory, the diagnostic datacapture will be disabled for that instance.

  • diagnosticDataCollectionDirectorySizeMB

New in version 3.2.

Changed in version 3.4: Increased default size to 200 megabytes.

Changed in version 3.4.14: Available for both mongod and mongos.

Type: integer

Default: 200

Specifies the maximum size, in megabytes, of the diagnostic.datadirectory. If directory size exceeds this number, the oldestdiagnostic files in the directory are automatically deleted based onthe timestamp in the file name.

For example, the following sets the maximum size of the directory to250 megabytes:

  1. mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

The minimum value fordiagnosticDataCollectionDirectorySizeMB is 10megabytes. diagnosticDataCollectionDirectorySizeMB mustbe greater than maximum diagnostic file sizediagnosticDataCollectionFileSizeMB.

  • diagnosticDataCollectionFileSizeMB

New in version 3.2.

Changed in version 3.4.14: Available for both mongod and mongos.

Type: integer

Default: 10

Specifies the maximum size, in megabytes, of each diagnosticfile. If the file exceeds the maximumfile size, MongoDB creates a new file.

For example, the following sets the maximum size of each diagnosticfile to 20 megabytes:

  1. mongod --setParameter diagnosticDataCollectionFileSizeMB=20

The minimum value fordiagnosticDataCollectionFileSizeMB is 1 megabyte.

  • diagnosticDataCollectionPeriodMillis

New in version 3.2.

Changed in version 3.4.14: Available for both mongod and mongos.

Type: integer

Default: 1000

Specifies the interval, in milliseconds, at which to collectdiagnostic data.

For example, the following sets the interval to5000 milliseconds or 5 seconds:

  1. mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

The minimum value fordiagnosticDataCollectionPeriodMillis is 100milliseconds.

Logical Session Parameters

  • logicalSessionRefreshMillis

Availability

New in version 4.0.4 (and version 3.6.9).

Available for both mongod and mongos.

Type: integer

Default: 300000 (i.e. 5 minutes)

The interval (in milliseconds) at which the cache refreshes its logicalsession records against the main session store.

You can only set logicalSessionRefreshMillis atstartup and cannot change this setting with thesetParameter command.

For example, to set the logicalSessionRefreshMillisfor a mongod instance to 10 minutes:

  1. mongod --setParameter logicalSessionRefreshMillis=600000
  • localLogicalSessionTimeoutMinutes

New in version 3.6.

Available for both mongod and mongos.

Type: integer

Default: 30

For testing purposes only

This parameter is intended for testing purposes only and not forproduction use.

The time in minutes that a session remains activeafter its most recent use. Sessions that have not received a newread/write operation from the client or been refreshed withrefreshSessions within this threshold are cleared from thecache. State associated with an expired session may be cleaned up by theserver at any time.

This parameter applies only to the instance on which it is set. Toset this parameter on replica sets and sharded clusters, you mustspecify the same value on every member; otherwise, sessions willnot function properly.

You can only set localLogicalSessionTimeoutMinutes atstartup and cannot change this setting with thesetParameter command.

For example, to set the localLogicalSessionTimeoutMinutesfor a test mongod instance to 20 minutes:

  1. mongod --setParameter localLogicalSessionTimeoutMinutes=20
  • maxAcceptableLogicalClockDriftSecs

New in version 3.6.

Available for both mongod and mongos.

Type: integer

Default: 31536000 (1 year)

The maximum amount by which the current cluster time can be advanced;i.e., maxAcceptableLogicalClockDriftSecs is the maximumdifference between the new value of the cluster time and the currentcluster time. Cluster time is a logical time used for ordering ofoperations.

You cannot advance the cluster time to a new value if the newcluster time differs from the current cluster time by more thanmaxAcceptableLogicalClockDriftSecs,

You can only set maxAcceptableLogicalClockDriftSecs atstartup and cannot change this setting with thesetParameter command.

For example, to set the maxAcceptableLogicalClockDriftSecsfor a mongod instance to 15 minutes:

  1. mongod --setParameter maxAcceptableLogicalClockDriftSecs=900
  • maxSessions

New in version 4.0.1.

Available for both mongod and mongos.

Type: integer

Default: 1000000

The maximum number of sessions that can be cached.

You can only set maxSessions during start-up.

For example, to set the maxSessionsfor a mongod instance to 1000:

  1. mongod --setParameter maxSessions=1000
  • TransactionRecordMinimumLifetimeMinutes

New in version 3.6.

Available for mongod only.

Type: integer

Default: 30

The minimum lifetime a transaction record exists in thetransactions collection before the record becomeseligible for cleanup.

You can only set TransactionRecordMinimumLifetimeMinutes atstartup and cannot change this setting with thesetParameter command.

For example, to set the TransactionRecordMinimumLifetimeMinutesfor a mongod instance to 20 minutes:

  1. mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

See also

localLogicalSessionTimeoutMinutes

Replication Parameters

  • enableFlowControl

New in version 4.2.

Type: boolean

Default: true

Enables or disables the mechanism that controls the rate at which theprimary applies its writes with the goal of keeping the secondary members’majority committed lag under aconfigurable maximum value.

Note

For flow control to engage, the replica set/sharded cluster musthave: featureCompatibilityVersion (FCV) of4.2 and read concern majority enabled. That is, enabled flowcontrol has no effect if FCV is not 4.2 or if read concernmajority is disabled.

  • flowControlTargetLagSeconds

New in version 4.2.

Type: integer

Default: 10

The target maximum majority committed lag when runningwith flow control. When flow control is enabled, the mechanismattempts to keep the majority committed lag underthe specified seconds. The parameter has no effect if flow controlis disabled.

The specified value must be greater than 0.

In general, the default settings should suffice; however, ifmodifying from the default value, decreasing, rather thanincreasing, the value may prove to be more useful.

  • flowControlWarnThresholdSeconds

New in version 4.2.

Type: integer

Default: 10

The amount of time to wait to log a warning once the flow controlmechanism detects the majority commit point has not moved.

The specified value must be greater than or equal to 0, with 0 todisable warnings.

  • oplogInitialFindMaxSeconds

New in version 3.6.

Type: integer

Default: 60

Available for mongod only.

Maximum time in seconds for a member of a replica set to waitfor the find command to finish duringdata synchronization.

  • replWriterThreadCount

New in version 3.2.

Type: integer

Default: 16

Available for mongod only.

Number of threads to use to apply replicated operations in parallel.Values can range from 1 to 256 inclusive. You can only setreplWriterThreadCount at startup and cannot change thissetting with the setParameter command.

  • rollbackTimeLimitSecs
  • Type: 64-bit integer

Default: 86400 (1 day)

Maximum age of data that can be rolled back. Negative values forthis parameter are not valid.

Starting in MongoDB 4.2+ and 4.0.13+, if the time between the endof the to-be-rolledback instance’s oplog and the first operationafter the common point (the last point where the source node and theto-be-rolledback node had the same data) exceeds this value, therollback will fail.

In MongoDB 4.0.0-4.0.12, if the time between the end of the to-be-rolledbackinstance’s oplog and the common point (the last point where thesource node and the to-be-rolledback node had the same data) exceedsthis value, the rollback will fail.

To effectively have an unlimited rollback period, set the value to2147483647 which is the maximum value allowed and equivalent toroughly 68 years.

New in version 4.0.

  • waitForSecondaryBeforeNoopWriteMS

New in version 3.6.

Available for mongod only.

Type: integer

Default: 10

The length of time (in milliseconds) that a secondary must wait ifthe afterClusterTime is greater than the last applied time fromthe oplog. After the waitForSecondaryBeforeNoopWriteMS passes,if the afterClusterTime is still greater than the last appliedtime, the secondary makes a no-op write to advance the last appliedtime.

The following example sets thewaitForSecondaryBeforeNoopWriteMS to 20 milliseconds:

  1. mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

During runtime, you can also set the parameter with thesetParameter command:

  1. db.adminCommand( { setParameter: 1, waitForSecondaryBeforeNoopWriteMS: 20 } )
  • createRollbackDataFiles
  • Available for mongod only.

Type: boolean

Default: true

New in version 4.0.

Flag that determines whether MongoDB creates rollback files that contains documents affected during arollback.

By default, createRollbackDataFiles is true andMongoDB creates the rollback files.

The following example sets createRollbackDataFilesto false so that the rollback files are not created:

  1. mongod --setParameter createRollbackDataFiles=false

During runtime, you can also set the parameter with thesetParameter command:

  1. db.adminCommand( { setParameter: 1, createRollbackDataFiles: false } )

For more information, see Collect Rollback Data.

  • enableElectionHandoff

New in version 4.0.2.

Type: boolean

Default: true

A flag that can reduce the downtime after the primary steps downfrom either the rs.stepDown() method or thereplSetStepDown command. Specifically, if true, when aprimary steps down after rs.stepDown() (or thereplSetStepDown command without the force: true),it nominates an eligible secondary to call an election immediately.If false, after the step down, secondaries can wait up tosettings.electionTimeoutMillis before calling an election.

An eligible secondary must be caught up with the stepped downprimary and have priority greater than 0. Ifmultiple secondary members meet this criteria, the stepped downprimary selects the eligible secondary with the highestpriority. If the more than one eligiblesecondary members have the same priority, thestepped down primary selects the secondary with the lowest_id. The stepped down primary does not waitfor the effects of the handoff.

The parameter has no impact if the primary steps down for reasonsother than rs.stepDown() (or thereplSetStepDown command without the force: true).

  • replBatchLimitBytes
  • Default: 104857600 (100MB)

Sets the maximum oplog application batch size in bytes.

Values can range from 16777216 (16MB) to 104857600 (100MB) inclusive.

The following example sets replBatchLimitBytesto 64 MB so that the rollback files are not created:

  1. mongod --setParameter replBatchLimitBytes=67108864

During runtime, you can also set the parameter with thesetParameter command:

  1. db.adminCommand( { setParameter: 1, replBatchLimitBytes: 64 * 1024 * 1024 } )

New in version 4.0.10.

Sharding Parameters

Note

Starting in version 4.2, MongoDB removes the parameterAsyncRequestsSenderUseBaton and always enables the performanceenhancement controlled by the parameter.

  • replMonitorMaxFailedChecks
  • Available in MongoDB 3.2 only

Type: integer

Default: 30

The number of times the mongod or mongosinstance tries to reach the replica sets in the sharded cluster(e.g. shard replica sets, config server replica set) to monitor thereplica set status and topology.

When the number of consecutive unsuccessful attempts exceeds thisparameter value, the mongod or mongos instancedenotes the monitored replica set as unavailable. If the monitoredreplica set is the config server replica set:

  • timeOutMonitoringReplicaSets
  • Available in MongoDB 3.2.10 and later 3.2-series only

Type: integer

Default: false

The flag that determines whether the mongod ormongos instance should stop its attempt to reach themonitored replica set after unsuccessfully tryingreplMonitorMaxFailedChecks number of times.

If the monitored replica set is the config server replica set andtimeOutMonitoringReplicaSets is set to true, youmust restart mongod or mongos if themongod or mongos instance cannot reach any ofthe config servers for the specified number of times. See thev3.2 troubleshooting guidefor more details.

  • ShardingTaskExecutorPoolHostTimeoutMS
  • Type: integer

Default: 300000 (i.e. 5 minutes)

Available for mongos only.

Maximum time that mongos goes without communication to ahost before mongos drops all connections to the host.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

If set, ShardingTaskExecutorPoolHostTimeoutMS should begreater than the sum ofShardingTaskExecutorPoolRefreshRequirementMS andShardingTaskExecutorPoolRefreshTimeoutMS. Otherwise,mongos adjusts the value ofShardingTaskExecutorPoolHostTimeoutMS to be greater than thesum.

  1. mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000
  • ShardingTaskExecutorPoolMaxConnecting

New in version 3.6.

Type: integer

Default: 2

Available for mongos only.

Maximum number of simultaneous initiating connections (includingpending connections in setup/refresh state) each TaskExecutorconnection pool can have to a mongod instance. You canset this parameter to control the rate at which mongosadds connections to a mongod instance.

If set, ShardingTaskExecutorPoolMaxConnecting should beless than or equal to ShardingTaskExecutorPoolMaxSize.If it is greater, mongos ignores theShardingTaskExecutorPoolMaxConnecting value.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

  1. mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20
  • ShardingTaskExecutorPoolMaxSize
  • Type: integer

Default: 264 - 1

Available for mongos only.

Maximum number of outbound connections each TaskExecutor connectionpool can open to any given mongod instance. The maximumpossible connections to any given host across all TaskExecutor poolsis:

  1. ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

  1. mongos --setParameter ShardingTaskExecutorPoolMaxSize=4

mongos can have up to n TaskExecutor connectionpools, where n is the number of cores. SeetaskExecutorPoolSize.

See also

ShardingTaskExecutorPoolMinSize

  • ShardingTaskExecutorPoolMinSize
  • Type: integer

Default: 1

Available for mongos only.

Minimum number of outbound connections each TaskExecutor connectionpool can open to any given mongod instance.

ShardingTaskExecutorPoolMinSize connections are created thefirst time a connection to a new host is requested from the pool.While the pool is idle, the pool maintains this number ofconnections until ShardingTaskExecutorPoolHostTimeoutMSmilliseconds pass without any application using that pool.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

  1. mongos --setParameter ShardingTaskExecutorPoolMinSize=2

mongos can have up to n TaskExecutor connectionpools, where n is the number of cores. SeetaskExecutorPoolSize.

See also

ShardingTaskExecutorPoolMaxSize

  • ShardingTaskExecutorPoolRefreshRequirementMS
  • Type: integer

Default: 60000 (1 minute)

Available for mongos only.

Maximum time the mongos waits before attempting toheartbeat a resting connection in the pool.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

If set, ShardingTaskExecutorPoolRefreshRequirementMS should begreater than ShardingTaskExecutorPoolRefreshTimeoutMS.Otherwise, mongos adjusts the value ofShardingTaskExecutorPoolRefreshTimeoutMS to be less thanShardingTaskExecutorPoolRefreshRequirementMS.

  1. mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000
  • ShardingTaskExecutorPoolRefreshTimeoutMS
  • Type: integer

Default: 20000 (20 seconds)

Available for mongos only.

Maximum time the mongos waits for a heartbeat beforetiming out the heartbeat.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

If set, ShardingTaskExecutorPoolRefreshTimeoutMS should beless than ShardingTaskExecutorPoolRefreshRequirementMS.Otherwise, mongos adjusts the value ofShardingTaskExecutorPoolRefreshTimeoutMS to be less thanShardingTaskExecutorPoolRefreshRequirementMS.

  1. mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000
  • ShardingTaskExecutorPoolReplicaSetMatching

New in version 4.2.

Type: string

Default: “matchPrimaryNode”

Available for mongos only.

The policy that determines the minimum size limit of themongos instance’s connection pools to the shardedcluster’s replica set secondaries.

Available values are:

Matching PolicyDescription"matchPrimaryNode" (Default)For each replica set in the sharded cluster (i.e. shardreplica set and config servers), the minimum size limit ofthe mongos instance’s connection pool to eachsecondary of that replica set is equal to the size of itsconnection pool to the primary.

In case of primary stepdown, matchPrimaryNode ensuresthat any secondary that becomes the primary can handle thecurrent level of primary reads and writes."matchBusiestNode"For each replica set in the sharded cluster (i.e. shardreplica set and config servers), the minimum size limit ofthe mongos instance’s connection pool to eachmember of that replica set is equal to the largest amongthe active connections counts to the primary and eachsecondary members.

With "matchBusiestNode", mongos maintainsenough connections to each secondary to handle the currentlevel of primary and secondary reads and writes. The numberof connections to maintain in the pool decreases as thenumber of active connections decreases."disabled"For each replica set in the sharded cluster (i.e. shardreplica set and config servers), the minimum number ofconnections in the mongos instance’sconnection pool to each secondary is equal to theShardingTaskExecutorPoolMinSize.

The following example sets theShardingTaskExecutorPoolReplicaSetMatching to"matchBusiestNode" during startup:

  1. mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="matchBusiestNode"

During runtime, you can also set the parameter with thesetParameter command:

  1. db.adminCommand( { setParameter: 1,  ShardingTaskExecutorPoolReplicaSetMatching: "matchBusiestNode" } )
  • taskExecutorPoolSize

Changed in version 4.0.

Type: integer

Default: 1

Available for mongos only.

The number of Task Executor connection pools to use for a givenmongos.

If the parameter value is 0 or less, the number of Task Executorconnection pools is the number of cores with the followingexceptions:

  • If the number of cores is less than 4, the number of Task Executorconnection pools is 4.

  • If the number of cores is greater than 64, the number of TaskExecutor connection pools is 64.Starting in MongoDB 4.0, the default value oftaskExecutorPoolSize is 1:

  • In MongoDB 4.0 deployment, you can settaskExecutorPoolSize to 0 and, on Linux, setAsyncRequestsSenderUseBaton tofalse for the previous behavior.

  • In MongoDB 4.2+ deployment, MongoDB removes theAsyncRequestsSenderUseBaton parameter and always enables theperformance enhancement controlled by the parameter.You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.
  1. mongos --setParameter taskExecutorPoolSize=6

See also

  • migrateCloneInsertionBatchDelayMS

New in version 4.0.5: The parameter is also available starting in 3.4.18 and 3.6.10

Available for mongod only.

Type: Non-negative integer

Default: 0

Time in milliseconds to wait between batches of insertions duringcloning step of the migration process. This wait is in addition tothe secondaryThrottle.

The default value of 0 indicates no additional wait.

The following sets the migrateCloneInsertionBatchDelayMS to 200milliseconds:

  1. mongod --setParameter migrateCloneInsertionBatchDelayMS=200

The parameter may also be set using the setParametercommand:

  1. db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchDelayMS: 200 } )
  • migrateCloneInsertionBatchSize

New in version 4.0.5: The parameter is also available starting in 3.4.18 and 3.6.10

Available for mongod only.

Type: Non-negative integer

Default: 0

The maximum number of documents to insert in a single batch duringthe cloning step of the migration process.

The default value of 0 indicates no maximum number of documentsper batch. However, in practice, this results in batches thatcontain up to 16 MB of documents.

The following sets the migrateCloneInsertionBatchSize to 100documents:

  1. mongod --setParameter migrateCloneInsertionBatchSize=100

The parameter may also be set using the setParametercommand:

  1. db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchSize: 100 } )
  • orphanCleanupDelaySecs

New in version 3.6.

Default: 900 (15 minutes)

Available for mongod only.

Minimum delay before a migrated chunk is deleted from the sourceshard.

Before deleting the chunk during chunk migration, MongoDB waits fororphanCleanupDelaySecs or for in-progress queries involvingthe chunk to complete on the shard primary, whichever is longer.

However, because the shard primary has no knowledge of in-progress queriesrun on the shard secondaries, queries that use the chunk but are run onsecondaries may see documents disappear if these queries take longer thanthe time to complete the shard primary queries and theorphanCleanupDelaySecs.

Note

This behavior only affects in-progress queries that start before thechunk migration. Queries that start after the chunk migration startswill not use the migrating chunk.

If a shard has storage constraints, consider reducing this valuetemporarily. If running queries that exceed 15 minutes on shardsecondaries, consider increasing this value.

The following sets the orphanCleanupDelaySecs to 20 minutes:

  1. mongod --setParameter orphanCleanupDelaySecs=1200

This may also be set using the setParameter command:

  1. db.adminCommand( { setParameter: 1, orphanCleanupDelaySecs: 1200 } )
  • rangeDeleterBatchDelayMS

New in version 4.0.1: The parameter is also available starting in 3.4.17 and 3.6.7.

Available for mongod only.

Type: Non-negative integer

Default: 20

The amount of time in milliseconds to wait before the next batch ofdeletion during the cleanup stage of chunk migration (or the cleanupOrphanedcommand).

In MongoDB 3.4, consider whether _secondaryThrottle is set before modifying therangeDeleterBatchDelayMS. In MongoDB 3.4, the_secondaryThrottle replication delay occurs after each document deletioninstead of after the batch deletion.

In MongoDB 3.6+, the _secondaryThrottle replication delay occurs after each batch deletion.

The following sets the rangeDeleterBatchDelayMS to 200milliseconds:

  1. mongod --setParameter rangeDeleterBatchDelayMS=200

The parameter may also be set using the setParametercommand:

  1. db.adminCommand( { setParameter: 1, rangeDeleterBatchDelayMS: 200 } )
  • rangeDeleterBatchSize

New in version 4.0.5: The parameter is also available starting in 3.4.19 and 3.6.10

Available for mongod only.

Type: Non-negative integer

Default: 0

The maximum number of documents in each batch to delete during thecleanup stage of chunk migration(or the cleanupOrphaned command).

The default value of 0 indicates that the system chooses anappropriate value, generally 128 documents.

The following sets the rangeDeleterBatchSize to 100documents:

  1. mongod --setParameter rangeDeleterBatchSize=100

The parameter may also be set using the setParametercommand:

  1. db.adminCommand( { setParameter: 1, rangeDeleterBatchSize: 100 } )
  • skipShardingConfigurationChecks

New in version 3.6.3.

Available for mongod only.

Type: boolean

Default: false

When true, allows for starting a shard member or config servermember as a standalone for maintenance operations. This parameter ismutually exclusive with the —configsvr or —shardsvr options.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

  1. mongod --setParameter skipShardingConfigurationChecks=true

Important

Once maintenance has completed, remove theskipShardingConfigurationChecks parameter whenrestarting the mongod.

The parameter is also available for MongoDB versions:

  • MongoDB 3.2.19+
  • MongoDB 3.4.11+

Storage Parameters

  • journalCommitInterval
  • Available for mongod only.

Specify an integer between 1 and 500 signifying the numberof milliseconds (ms) between journal commits.

Consider the following example which sets thejournalCommitInterval to 200 ms:

  1. db.adminCommand( { setParameter: 1, journalCommitInterval: 200 } )

See also

storage.journal.commitIntervalMs

  • syncdelay
  • Available for mongod only.

Specify the interval in seconds between fsync operationswhere mongod flushes its working memory to disk. Bydefault, mongod flushes memory to disk every 60seconds. In almost every situation you should not set this valueand use the default setting.

Consider the following example which sets the syncdelay to60 seconds:

  1. db.adminCommand( { setParameter: 1, syncdelay: 60 } )

See also

syncPeriodSecs andjournalCommitInterval.

  • honorSystemUmask

New in version 3.6.

Default: false

If honorSystemUmask is set to true, new filescreated by MongoDB have permissions in accordance with theuser’s umask settings.

If honorSystemUmask is set to false, new filescreated by MongoDB have permissions set to 600, which givesread and write permissions only to the owner. New directories havepermissions set to 700.

You can only set this parameter during start-up and cannot changethis setting using the setParameter database command.

  1. mongod --setParameter honorSystemUmask=true

Note

honorSystemUmask is not available on Windows systems.

WiredTiger Parameters

  • wiredTigerMaxCacheOverflowSizeGB
  • Available starting in MongoDB 4.2.1 (and 4.0.12)

Default: 0 (No specified maximum)

Available for mongod only.

Specify the maximum size (in GB) for the “lookaside (or cacheoverflow) table” file WiredTigerLAS.wt.

The parameter can accept the following values:

ValueDescription0The default value. If set to 0, the file size isunbounded.number >= 0.1The maximum size (in GB). If the WiredTigerLAS.wtfile exceeds this size, mongod exits with afatal assertion. You can clear the WiredTigerLAS.wtfile and restart mongod.

You can only set this parameter during runtime using thesetParameter database command:

  1. db.adminCommand( { setParameter: 1, wiredTigerMaxCacheOverflowSizeGB: 100 } )

To set the maximum size during start up, use thestorage.wiredTiger.engineConfig.maxCacheOverflowFileSizeGBinstead.

  • wiredTigerConcurrentReadTransactions

New in version 3.0.0.

Available for mongod only.

Available for the WiredTiger storage engine only.

Specify the maximum number of concurrent read transactions allowedinto the WiredTiger storage engine.

  1. db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: <num> } )

See also

wiredTiger.concurrentTransactions

  • wiredTigerConcurrentWriteTransactions

New in version 3.0.0.

Available for mongod only.

Available for the WiredTiger storage engine only.

Specify the maximum number of concurrent write transactions allowedinto the WiredTiger storage engine.

  1. db.adminCommand( { setParameter: 1, wiredTigerConcurrentWriteTransactions: <num> } )

See also

wiredTiger.concurrentTransactions

  • wiredTigerEngineRuntimeConfig

New in version 3.0.0.

Available for mongod only.

Specify wiredTiger storage engine configuration options for arunning mongod instance. You can only set thisparameter using the setParameter command and _not_using the command line or configuration file option.

Warning

Avoid modifying the wiredTigerEngineRuntimeConfigunless under the direction from MongoDB engineers as this setting hasmajor implication across both WiredTiger and MongoDB.

Consider the following operation prototype:

  1. db.adminCommand({
  2.    "setParameter": 1,
  3.    "wiredTigerEngineRuntimeConfig": "<option>=<setting>,<option>=<setting>"
  4. })

See the WiredTiger documentation for all available WiredTigerconfiguration options.

Auditing Parameters

  • auditAuthorizationSuccess

New in version 2.6.5.

Default: false

Note

Available only in MongoDB Enterpriseand MongoDB Atlas.

Available for both mongod and mongos.

Enables the auditing of authorizationsuccesses for the authCheckaction.

When auditAuthorizationSuccess is false, theaudit system only logs the authorizationfailures for authCheck.

To enable the audit of authorization successes, issue the followingcommand:

  1. db.adminCommand( { setParameter: 1, auditAuthorizationSuccess: true } )

Enabling auditAuthorizationSuccess degrades performancemore than logging only the authorization failures.

See also

getParameter

Transaction Parameters

  • transactionLifetimeLimitSeconds

New in version 4.0.

Available for mongod only.

Default: 60

Specifies the lifetime of multi-document transactions. Transactions that exceeds this limit areconsidered expired and will be aborted by a periodic cleanupprocess. The cleanup process runs everytransactionLifetimeLimitSeconds/2 seconds or at leastonce per every 60 seconds.

The cleanup process helps relieve storage cache pressure.

The minimum value for transactionLifetimeLimitSeconds is 1second.

The following sets thetransactionLifetimeLimitSeconds to 30seconds:

  1. db.adminCommand( { setParameter: 1, transactionLifetimeLimitSeconds: 30 } )

You can also set parameter transactionLifetimeLimitSeconds atstartup time.

  1. mongod --setParameter "transactionLifetimeLimitSeconds=30"

To set the parameter for a sharded cluster, the parameter must bemodified for all shard replica set members.

  • maxTransactionLockRequestTimeoutMillis

New in version 4.0.

Available for mongod only.

Type: integer

Default: 5

The maximum amount of time in milliseconds that multi-documenttransactions should wait to acquire locksrequired by the operations in the transaction.

If the transaction cannot acquire the locks after waitingmaxTransactionLockRequestTimeoutMillis, the transactionaborts.

By default, multi-document transactionswait 5 milliseconds. That is, if the transaction cannot acquirethe locks within 5 milliseconds, the transaction aborts. If anoperation provides a greater timeout in a lock request,maxTransactionLockRequestTimeoutMillis overrides theoperation-specific timeout.

You can set maxTransactionLockRequestTimeoutMillis to:

  • 0 such that if the transaction cannot acquire the requiredlocks immediately, the transaction aborts.
  • A number greater than 0 to wait the specified time to acquirethe required locks. This can help obviate transaction aborts onmomentary concurrent lock acquisitions, like fast-running metadataoperations. However, this could possibly delay the abort ofdeadlocked transaction operations.
  • -1 to use the operation specific timeout.The following sets themaxTransactionLockRequestTimeoutMillis to 20milliseconds:
  1. db.adminCommand( { setParameter: 1, maxTransactionLockRequestTimeoutMillis: 20 } )

You can also set this parameter during start-up:

  1. mongod --setParameter maxTransactionLockRequestTimeoutMillis=20