MongoDB Server Parameters

On this page

Synopsis

Parameters
Authentication Parameters
General Parameters
Logging Parameters
Diagnostic Parameters
Replication and Consistency
Sharding Parameters
Health Manager Parameters
Storage Parameters
WiredTiger Parameters
Auditing Parameters
Transaction Parameters
Slot-Based Execution Parameters

Synopsis

MongoDB provides a number of configuration options that you can set using:

the setParameter command:
```
db.adminCommand( { setParameter: 1, <parameter>: <value>  } )
```
the setParameter configuration setting:
```
setParameter:
   <parameter1>: <value1>
   ...
```

the --setParameter command-line option for mongod and mongos:

mongod --setParameter <parameter>=<value>
mongos --setParameter <parameter>=<value>

For additional configuration options, see Configuration File Options, mongod and mongos.

Parameters

Authentication Parameters

authenticationMechanisms

Available for both mongod and mongos.

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

Value	Description
SCRAM-SHA-1	RFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function.
SCRAM-SHA-256	RFC 7677 standard Salted Challenge Response Authentication Mechanism using the SHA-256 hash function.
MONGODB-X509	MongoDB TLS/SSL certificate authentication.
GSSAPI (Kerberos)	External authentication using Kerberos. This mechanism is available only in MongoDB Enterprise.
PLAIN (LDAP SASL)	External authentication using LDAP. You can also use `PLAIN` for authenticating in-database users. `PLAIN` transmits passwords in plain text. This mechanism is available only in MongoDB Enterprise.

You can only set authenticationMechanisms during start-up.

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

mongod --setParameter authenticationMechanisms=PLAIN,SCRAM-SHA-256 --auth

awsSTSRetryCount

Changed in version 7.0: (Also starting in 6.0.7, 5.0.18, 4.4.22)

In previous versions, AWS IAM authentication retried only when the server returned an HTTP 500 error.

Available for both mongod and mongos.

Type: integer

Default: 2

For MongoDB deployments using AWS IAM credentials or AWS IAM environment variables.

Maximim number of AWS IAM authentication retries after a connection failure.

The following example sets awsSTSRetryCount to 15 retries:

mongod --setParameter awsSTSRetryCount=15

Alternatively, the following examples uses the setParameter command within mongosh:

db.adminCommand( { setParameter: 1, awsSTSRetryCount: 15 } )

clusterAuthMode

Available for both mongod and mongos.

Set the clusterAuthMode to either sendX509 or x509. Useful during rolling upgrade to use x509 for membership authentication to minimize downtime.

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

db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )

enableLocalhostAuthBypass

Available for both mongod and mongos.

Specify 0 or false to disable localhost authentication bypass. Enabled by default.

enableLocalhostAuthBypass is not available using setParameter database command. Use the setParameter option in the configuration file or the --setParameter option on the command line.

See Localhost Exception for more information.

KeysRotationIntervalSec

Default: 7776000 seconds (90 days)

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

You can only set KeysRotationIntervalSec during start-up, and cannot change this setting with the setParameter database command.

ldapForceMultiThreadMode

New in version 4.2.

Default: false

Enables the performance of concurrent LDAP operations.

Note

Only if you are certain that your instance of libldap is safe to use in this mode, enable this flag. You may experience crashes of the MongoDB process if the libldap version you are using is not thread safe.

You must use ldapForceMultiThreadMode to use LDAP connection pool. To enable LDAP connection pool, set ldapForceMultiThreadMode and ldapUseConnectionPool to true.

Tip

If you have any concerns regarding your MongoDB version, OS version or libldap version, please contact MongoDB Support.

ldapRetryCount

New in version 6.1.

Available for both mongod and mongos.

Type: integer

Default: 0

For MongoDB deployments using LDAP Authorization.

Number of operation retries by the server LDAP manager after a network error.

For example, the following sets ldapRetryCount to 3 seconds:

mongod --ldapRetryCount=3

Or, if using the setParameter command within mongosh:

db.adminCommand( { setParameter: 1, ldapRetryCount: 3 } )

ldapUserCacheInvalidationInterval

Changed in version 5.2.

Note

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:

If true, use ldapUserCacheRefreshInterval.
If false, use ldapUserCacheInvalidationInterval.

For use with MongoDB deployments using LDAP Authorization. Available for mongod instances only.

The interval (in seconds) that the mongod instance waits between external user cache flushes. After MongoDB flushes the external user cache, MongoDB reacquires authorization data from the LDAP server the next time an LDAP-authorized user issues an operation.

Increasing the value specified increases the amount of time MongoDB and the LDAP server can be out of sync, but reduces the load on the LDAP server. Conversely, decreasing the value specified decreases the time MongoDB and the LDAP server can be out of sync while increasing the load on the LDAP server.

Defaults to 30 seconds.

ldapUserCacheRefreshInterval

New in version 5.2.

Available for mongod only.

Type: integer

Default: 30 seconds

Note

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:

If true, use ldapUserCacheRefreshInterval.
If false, use ldapUserCacheInvalidationInterval.

For MongoDB deployments using LDAP Authorization.

The interval in seconds that mongod waits before refreshing the cached user information from the LDAP server.

The maximum interval is 86,400 seconds (24 hours).

For example, the following sets ldapUserCacheRefreshInterval to 4000 seconds:

mongod --setParameter ldapUserCacheRefreshInterval=4000

Or, if using the setParameter command within mongosh:

db.adminCommand( { setParameter: 1, ldapUserCacheRefreshInterval: 4000 } )

ldapUserCacheStalenessInterval

New in version 5.2.

Available for mongod only.

Type: integer

Default: 90 seconds

For MongoDB deployments using LDAP Authorization.

The interval in seconds that mongod retains the cached LDAP user information after the last cache refresh.

If more than ldapUserCacheStalenessInterval seconds elapse without a successful refresh of the user information from the LDAP server, then mongod:

Invalidates the cached LDAP user information.
Is unavailable for LDAP users. LDAP users are unable to authenticate until mongod contacts the LDAP server.

The maximum interval is 86,400 seconds (24 hours).

For example, the following sets ldapUserCacheStalenessInterval to 4000 seconds:

mongod --setParameter ldapUserCacheStalenessInterval=4000

Or, if using the setParameter command within mongosh:

db.adminCommand( { setParameter: 1, ldapUserCacheStalenessInterval: 4000 } )

ldapUseConnectionPool

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

MongoDB uses the following default values:

true on Windows.
true on Linux where MongoDB Enterprise binaries are linked against libldap_r.
false on Linux where MongoDB Enterprise binaries are linked against libldap.

You can only set ldapUseConnectionPool during start-up, and cannot change this setting with the setParameter database command.

ldapConnectionPoolUseLatencyForHostPriority

New in version 4.2.1.

Default: true

A boolean that determines whether the LDAP connection pool (see ldapUseConnectionPool) should use latency of the LDAP servers to determine the connection order (from lowest latency to highest).

You can only set ldapConnectionPoolUseLatencyForHostPriority during start-up, and cannot change this setting during runtime with the setParameter database command.

ldapConnectionPoolMinimumConnectionsPerHost

New in version 4.2.1.

Default: 1

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

You can only set ldapConnectionPoolMinimumConnectionsPerHost during start-up, and cannot change this setting during runtime with the setParameter database command.

ldapConnectionPoolMaximumConnectionsPerHost

New in version 4.2.1.

Changed starting in MongoDB versions 4.4.15, 5.0.9, and 6.0.0 Changed default value to 2147483647. In previous versions, the default is unset.

Default: 2147483647

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

You can only set ldapConnectionPoolMaximumConnectionsPerHost during start-up, and cannot change this setting during runtime with the setParameter database command.

ldapConnectionPoolMaximumConnectionsInProgressPerHost

New in version 4.2.1.

Changed starting in MongoDB versions 4.4.15, 5.0.9, and 6.0.0 Changed default value to 2. In previous versions, the default is unset.

Default: 2

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

You can only set ldapConnectionPoolMaximumConnectionsInProgressPerHost during start-up, and cannot change this setting with the setParameter database command.

ldapConnectionPoolHostRefreshIntervalMillis

New in version 4.2.1.

Default: 60000

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

You can only set ldapConnectionPoolHostRefreshIntervalMillis during start-up, and cannot change this setting with the setParameter database command.

ldapConnectionPoolIdleHostTimeoutSecs

New in version 4.2.1.

Default: 300

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

You can only set ldapConnectionPoolIdleHostTimeoutSecs during start-up, and cannot change this setting with the setParameter database command.

ldapShouldRefreshUserCacheEntries

New in version 5.2.

Available for mongod only.

Type: boolean

Default: true

For MongoDB deployments using LDAP Authorization.

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:

If true, use ldapUserCacheRefreshInterval.
If false, use ldapUserCacheInvalidationInterval.

You can only set ldapShouldRefreshUserCacheEntries during startup in the configuration file or with the --setParameter option on the command line. For example, the following disables ldapShouldRefreshUserCacheEntries:

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

maxValidateMemoryUsageMB

New in version 5.0: (Also available starting in 4.4.7.)

Default: 200

The maximum memory usage limit in megabytes for the validate command. If the limit is exceeded, validate returns as many results as possible and warns that not all corruption might be reported because of the limit.

You can set maxValidateMemoryUsageMB during startup, and can change this setting using the setParameter database command.

ocspEnabled

New in version 4.4: Available on Linux and macOS.

Default: true

The flag that enables or disables OCSP.

You can only set ocspEnabled during startup in the configuration file or with the --setParameter option on the command line. For example, the following disables OCSP:

mongod --setParameter ocspEnabled=false ...

Starting in MongoDB 6.0, if ocspEnabled is set to true during initial sync, all nodes must be able to reach the OCSP responder.

If a member fails in the STARTUP2 state, set tlsOCSPVerifyTimeoutSecs to a value that is less than 5.

Tip

Note

This parameter is only for use with TLS 1.2 or earlier. To specify cipher suites for use with TLS 1.3, use the opensslCipherSuiteConfig parameter.

You can only set opensslCipherConfig during start-up, and cannot change this setting using the setParameter database command.

For version 4.2 and greater, the use of TLS options is preferred over SSL options. The TLS options have the same functionality as the SSL options. For example, the following configures a mongod with a opensslCipherConfig cipher string of 'HIGH:!EXPORT:!aNULL@STRENGTH' in MongoDB 4.2:

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

opensslCipherSuiteConfig

New in version 5.0.

Available on Linux only

Specify the list of supported cipher suites OpenSSL should permit when using TLS 1.3 encryption.

For a list of cipher suites for use with TLS 1.3, see https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html. Multiple cipher suites can be provided as a colon-separated list.

Note

This parameter is only for use with TLS 1.3. To specify cipher strings for use with TLS 1.2 or earlier, use the opensslCipherConfig parameter.

You can only set opensslCipherSuiteConfig during start-up, and cannot change this setting using the setParameter database command. For example, the following configures a mongod with a opensslCipherSuiteConfig cipher suite of 'TLS_AES_256_GCM_SHA384' for use with TLS 1.3:

mongod --setParameter opensslCipherSuiteConfig='TLS_AES_256_GCM_SHA384' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem

opensslDiffieHellmanParameters

Available on Linux only

Specify the path to the PEM file that contains the OpenSSL Diffie-Hellman parameters when using TLS 1.2 or previous. Specifying the OpenSSL Diffie-Hellman parameters enables support for Ephemeral Diffie-Hellman (DHE) cipher suites during TLS/SSL encryption.

This parameter is not supported for use with TLS 1.3.

Ephemeral Diffie-Hellman (DHE) cipher suites (and Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) cipher suites) provide Forward Secrecy. Forward Secrecy cipher suites create an ephemeral session key that is protected by the server's private key but never transmitted. This ensures that even if a server's private key is compromised, you cannot decrypt past sessions with the compromised key.

Note

Starting in MongoDB 4.2, if opensslDiffieHellmanParameters is unset but ECDHE is enabled, MongoDB enables DHE using the ffdhe3072 Diffie-Hellman parameter, as defined in RFC-7919#appendix-A.2. The ffdhe3072 is a strong parameter (specifically, size is greater than 1024). Strong parameters are not supported with Java 6 and 7 unless extended support has been purchased from Oracle.

You can only set opensslDiffieHellmanParameters during startup, and cannot change this setting using the setParameter database command.

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

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 saslauthd instance to use for proxy authentication.

saslHostName

Available for both mongod and mongos.

saslHostName overrides MongoDB's default hostname detection for the purpose of configuring SASL and Kerberos authentication.

saslHostName does not affect the hostname of the mongod or mongos instance for any purpose beyond the configuration of SASL and Kerberos.

You can only set saslHostName during start-up, and cannot change this setting using the setParameter database command.

Note

saslHostName supports Kerberos authentication and is only included in MongoDB Enterprise. For more information, see the following:

saslServiceName

Available for both mongod and mongos.

Allows users to override the default Kerberos service name component of the Kerberos principal name, on a per-instance basis. If unspecified, the default value is mongodb.

MongoDB only permits setting saslServiceName at startup. The setParameter command can not change this setting.

saslServiceName is only available in MongoDB Enterprise.

Important

Ensure that your driver supports alternate service names.

scramIterationCount

Default: 10000

Available for both mongod and mongos.

Changes the number of hashing iterations used for all new SCRAM-SHA-1 passwords. More iterations increase the amount of time required for clients to authenticate to MongoDB, but makes passwords less susceptible to brute-force attempts. The default value is ideal for most common use cases and requirements.

If you modify this value, it does not change the iteration count for existing passwords. The scramIterationCount value must be 5000 or greater.

For example, the following sets the scramIterationCount to 12000.

mongod --setParameter scramIterationCount=12000

Or, if using the setParameter command within mongosh:

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

Tip

Note

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

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

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

tlsX509ExpirationWarningThresholdDays

New in version 4.4.

Default : 30

Available for both mongod and mongos.

Starting in MongoDB 4.4, mongod / mongos logs a warning on connection if the presented x.509 certificate expires within 30 days of the mongod/mongos system clock. Use the tlsX509ExpirationWarningThresholdDays parameter to control the certificate expiration warning threshold:

Increase the parameter value to trigger warnings farther ahead of the certificate expiration date.
Decrease the parameter value to trigger warnings closer to the certificate expiration date.
Set the parameter to 0 to disable the warning.

This parameter has a minimum value of 0.

You can only set tlsX509ExpirationWarningThresholdDays during mongod/mongos startup using either:

The setParameter configuration setting, or
The mongod --setParameter / mongos --setParameter command line option.

See x.509 Certificates Nearing Expiry Trigger Warnings for more information on x.509 expiration warnings in MongoDB 4.4.

For more information on x.509 certificate validity, see RFC 5280 4.1.2.5.

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 or mongos either by the --tlsClusterFile option or by the --tlsCertificateKeyFile option when --tlsClusterFile is not set. If the TLS certificate is set, by default, the instance sends the certificate when initiating intra-cluster communications with other mongod or mongos instances in the deployment. Set sslWithholdClientCertificate to 1 or true to direct the instance to withhold sending its TLS certificate during these communications. Use this option with --tlsAllowConnectionsWithoutCertificates (to allow inbound connections without certificates) on all members of the deployment. 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 whether the 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 maximum value of 86400 seconds (24 hours).

authFailedDelayMs

Default: 0

Available for both mongod and mongos.

Note

Enterprise Feature

Available in MongoDB Enterprise only.

The number of milliseconds to wait before informing clients that their authentication attempt has failed. This parameter may be in the range 0 to 5000, inclusive.

Setting this parameter makes brute-force login attacks on a database more time-consuming. However, clients waiting for a response from the MongoDB server still consume server resources, and this may adversely impact benign login attempts if the server is denying access to many other clients simultaneously.

allowRolesFromX509Certificates

Default: true

Available for both mongod and mongos.

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

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

General Parameters

allowDiskUseByDefault

Default: True

Available for mongod only.

Starting in MongoDB 6.0, pipeline stages that require more than 100 megabytes of memory to execute write temporary files to disk by default. In earlier verisons of MongoDB, you must pass { allowDiskUse: true } to individual find and aggregate commands to enable this behavior.

Individual find and aggregate commands may override the allowDiskUseByDefault parameter by either:

Using { allowDiskUse: true } to allow writing temporary files out to disk when allowDiskUseByDefault is set to false
Using { allowDiskUse: false } to prohibit writing temporary files out to disk when allowDiskUseByDefault is set to true

mongod --setParameter allowDiskUseByDefault=false

allowDiskUseByDefault only works on mongod not mongos. mongos never writes temporary files to disk. Use the setParameter command in a mongosh session that is connected to a running mongod to change the value of the parameter while the server is running:

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

connPoolMaxShardedConnsPerHost

Default: 200

Available for both mongod and mongos.

Sets the maximum size of the legacy connection pools for communication to the shards. The size of a pool does not prevent the creation of additional connections, but does prevent the connection pools from retaining connections above this limit.

Note

The parameter is separate from the connections in TaskExecutor pools. See ShardingTaskExecutorPoolMaxSize.

Increase the connPoolMaxShardedConnsPerHost value only if the number of connections in a connection pool has a high level of churn or if the total number of created connections increase.

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

mongos --setParameter connPoolMaxShardedConnsPerHost=250

connPoolMaxShardedInUseConnsPerHost

Available for both mongod and mongos.

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

By default, the parameter is unset.

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

mongos --setParameter connPoolMaxShardedInUseConnsPerHost=100

Tip

Note

The parameter is separate from the connections in TaskExecutor pools. See ShardingTaskExecutorPoolMaxSize.

Only adjust this setting if your driver does not pool connections and you're using authentication in the context of a sharded cluster.

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

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

Available for both mongod and mongos.

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

By default, the parameter is unset.

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

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

Important

MongoDB 4.4 removes the deprecated failIndexKeyTooLong parameter. Attempting to use this parameter with MongoDB 4.4 will result in an error.
MongoDB 4.2 deprecates the failIndexKeyTooLong parameter and removes the Index Key Length Limit for featureCompatibilityVersion (fCV) set to "4.2" or greater.

Setting failIndexKeyTooLong to false is a temporary workaround, not a permanent solution to the problem of oversized index keys. With failIndexKeyTooLong set to false, queries can return incomplete results if they use indexes that skip over documents whose indexed fields exceed the Index Key Length Limit.

failIndexKeyTooLong defaults to true.

Issue the following command to disable the index key length validation:

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

You can also set failIndexKeyTooLong at startup with the following option:

mongod --setParameter failIndexKeyTooLong=false

maxNumActiveUserIndexBuilds

Available for mongod only.

Type: integer

Default: 3

Sets the maximum number of concurrent index builds allowed on the primary. This is a global limit that applies across all collections.

Increasing the value of maxNumActiveUserIndexBuilds allows additional concurrent index builds at the cost of increased pressure on the WiredTiger cache.

System indexes are not limited to maxNumActiveUserIndexBuilds, however a system index build counts against the limit for user index builds.

After the server reaches maxNumActiveUserIndexBuilds, it blocks additional user index builds until the number of concurrent index builds drops below the maxNumActiveUserIndexBuilds limit. If an index build is blocked, the server logs this message:

Too many index builds running simultaneously, waiting until the
number of active index builds is below the threshold.

The following command sets a limit of 4 concurrent index builds:

db.adminCommand( { setParameter: 1, maxNumActiveUserIndexBuilds: 4 } )

Important

Do not run production mongod instances with ttlMonitorEnabled disabled, except under guidance from MongoDB support. Preventing TTL document removal can negatively impact MongoDB internal system operations that depend on TTL Indexes.

tcpFastOpenServer

New in version 4.4.

Available for both mongod and mongos.

Default: true

Enables support for accepting inbound TCP Fast Open (TFO) connections to the mongod/mongos from a client. TFO requires both the client and mongod/mongos host machine support and enable TFO:

Windows

The following Windows operating systems support TFO:

Microsoft Windows Server 2016 and later.
Microsoft Windows 10 Update 1607 and later.

macOS

macOS 10.11 (El Capitan) and later support TFO.

Linux

Linux operating systems running Linux Kernel 3.7 or later can support inbound TFO.

Set the value of /proc/sys/net/ipv4/tcp_fastopen to enable inbound TFO connections:

Set to 2 to enable only inbound TFO connections.
Set to 3 to enable inbound and outbound TFO connections.

This parameter has no effect if the host operating system does not support or is not configured to support TFO connections.

You can only set this parameter on startup, using either the setParameter configuration file setting or the --setParameter command line option.

See Support for TCP Fast Open for more information on MongoDB TFO support.

Tip

Note

$where will reuse existing JavaScript interpreter contexts, so changes to disableJavaScriptJIT may not take effect immediately for these operations.

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

mongod --setParameter disableJavaScriptJIT=false

indexMaxNumGeneratedKeysPerDocument

New in version 5.3.

Default: 100000

Limits the maximum number of keys generated for a document to prevent out of memory errors. It is possible to raise the limit, but if an operation requires more keys than the indexMaxNumGeneratedKeysPerDocument parameter specifies, the operation will fail.

maxIndexBuildMemoryUsageMegabytes

Default:

200 (For versions 4.2.3 and later)
500 (For versions 4.2.2 and earlier)

Limits the amount of memory that simultaneous index builds on one collection may consume for the duration of the builds. The specified amount of memory is shared between all indexes built using a single createIndexes command or its shell helper db.collection.createIndexes().

The memory consumed by an index build is separate from the WiredTiger cache memory (see cacheSizeGB).

Index builds may be initiated either by a user command such as createIndexes or by an administrative process such as an initial sync. Both are subject to the limit set by maxIndexBuildMemoryUsageMegabytes.

An initial sync populates only one collection at a time and has no risk of exceeding the memory limit. However, it is possible for a user to start index builds on multiple collections in multiple databases simultaneously and potentially consume an amount of memory greater than the limit set by maxIndexBuildMemoryUsageMegabytes.

Tip

To minimize the impact of building an index on replica sets and sharded clusters with replica set shards, use a rolling index build procedure as described on Rolling Index Builds on Replica Sets.

For feature compatibility version (fcv) "4.2" and later, the index build memory limit applies to all index builds.

reportOpWriteConcernCountersInServerStatus

Default: false

A boolean flag that determines whether the db.serverStatus() method and serverStatus command return opWriteConcernCounters information. [1]

You can only set reportOpWriteConcernCountersInServerStatus during startup in the config file or on the command line. For example:

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

[1]	Enabling `reportOpWriteConcernCountersInServerStatus` can have a negative performance impact; specifically, when running without TLS.

watchdogPeriodSeconds

Available for mongod only.

Type: integer

Default: -1 (disabled)

Determines how frequent the Storage Node Watchdog checks the status of the monitored filesystems:

The --dbpath directory
The journal directory inside the --dbpath directory
The directory of --logpath file
The directory of --auditPath file

Valid values for watchdogPeriodSeconds are:

-1 (the default), to disable/pause Storage Node Watchdog, or
An integer greater than or equal to 60.

Note

If a filesystem on a monitored directory becomes unresponsive, it can take a maximum of nearly twice the value of watchdogPeriodSeconds to terminate the mongod.
If any of its monitored directory is a symlink to other volumes, the Storage Node Watchdog does not monitor the symlink target. For example, if the mongod uses storage.directoryPerDB: true (or --directoryperdb) and symlinks a database directory to another volume, the Storage Node Watchdog does not follow the symlink to monitor the target.

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

mongod --setParameter watchdogPeriodSeconds=60

You can only enable the Storage Node Watchdog at startup. However, once enabled, you can pause the Storage Node Watchdog or change the watchdogPeriodSeconds during runtime.

Once enabled,

To pause the Storage Node Watchdog during runtime, set watchdogPeriodSeconds to -1.
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )
```
To resume or change the period during runtime, set watchdogPeriodSeconds to a number greater than or equal to 60.
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )
```

Note

It is an error to set watchdogPeriodSeconds at runtime if the Storage Node Watchdog was not enabled at startup time.

tcmallocReleaseRate

New in version 4.2.3.

Default: 1.0

Specifies the tcmalloc release rate (TCMALLOC_RELEASE_RATE). Per https://gperftools.github.io/gperftools/tcmalloc.html#runtime TCMALLOC_RELEASE_RATE is described as the "Rate at which we release unused memory to the system, via madvise(MADV_DONTNEED), on systems that support it. Zero means we never release memory back to the system. Increase this flag to return memory faster; decrease it to return memory slower. Reasonable rates are in the range [0,10]."

To modify the release rate during runtime, you can use the setParameter command; for example:

db.adminCommand( { setParameter: 1, tcmallocReleaseRate: 5.0 } )

You can also set tcmallocReleaseRate at startup time; for example:

mongod --setParameter "tcmallocReleaseRate=5.0"

fassertOnLockTimeoutForStepUpDown

New in version 5.3.

Default: 15 seconds

Available for both mongod and mongos.

Allows a server that receives a request to step up or step down, to terminate if it is unable to comply (for example due to faulty server disks) within the timeout. This enables a cluster to successfully elect a new primary node and thus continue to be available.

fassertOnLockTimeoutForStepUpDown defaults to 15 seconds. To disable nodes from fasserting, set fassertOnLockTimeoutForStepUpDown=0.

The following example disables nodes from fasserting:

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

Logging Parameters

logLevel

Available for both mongod and mongos.

Specify an integer between 0 and 5 signifying the verbosity of the logging, where 5 is the most verbose. [2]

The default logLevel is 0 (Informational).

The following example sets the logLevel to 2:

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

Tip

Warning

Using a large value, or disabling truncation with a value of 0, may adversely affect system performance and negatively impact database operations.

The following example sets the maximum log line size to 20 kilobytes:

mongod --setParameter maxLogSizeKB=20

quiet

Available for both mongod and mongos.

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

connection events;
the drop command, the dropIndexes command, the validate command; and
replication synchronization activities.

Consider the following example which sets the quiet parameter to 1:

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

Tip

Note

Enterprise Feature

Available in MongoDB Enterprise only.

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

Use redactClientLogData in conjunction with Encryption at Rest and TLS/SSL (Transport Encryption) to assist compliance with regulatory requirements.

To enable log redaction at startup, you can either:

Start mongod with the --redactClientLogData option:
```
mongod --redactClientLogData
```
Set the security.redactClientLogData option in the configuration file:
```
security:
   redactClientLogData: true
   ...
```

You can't use the --setParameter option to set redactClientLogData at startup.

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

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

Tip

Diagnostic Parameters

To facilitate analysis of the MongoDB server behavior by MongoDB engineers, MongoDB logs server statistics to diagnostic files at periodic intervals.

For mongod, the diagnostic data files are stored in the diagnostic.data directory under the mongod instance's --dbpath or storage.dbPath.

For mongos, the diagnostic data files, by default, are stored in a directory under the mongos instance's --logpath or systemLog.path directory. The diagnostic data directory is computed by truncating the logpath's file extension(s) and concatenating diagnostic.data to the remaining name.

For example, if mongos has --logpath /var/log/mongodb/mongos.log.201708015, then the diagnostic data directory is /var/log/mongodb/mongos.diagnostic.data/ directory. To specify a different diagnostic data directory for mongos, set the diagnosticDataCollectionDirectoryPath parameter.

The following parameters support diagnostic data capture (FTDC):

Note

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

diagnosticDataCollectionEnabled

Available for both mongod and mongos.

Type: boolean

Default: true

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

For example, the following disables the diagnostic collection:

mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionDirectoryPath

Type: String

Available for mongos only.

Warning

If Full Time Diagnostic Data Capture (FTDC) is disabled with diagnosticDataCollectionEnabled or if systemLog.destination is set to syslog, you must restart mongos after setting diagnosticDataCollectionDirectoryPath.

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

If unspecified, the diagnostic data directory is computed by truncating the mongos instance's --logpath or systemLog.path file extension(s) and concatenating diagnostic.data.

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

If the mongos cannot create the specified directory, the diagnostic data capture is disabled for that instance. mongos may not be able to create the specified directory if a file with the same name already exists in the path or if the process does not have permissions to create the directory.

diagnosticDataCollectionDirectorySizeMB

Available for both mongod and mongos.

Type: integer

Default: 200

Specifies the maximum size, in megabytes, of the diagnostic.data directory. If directory size exceeds this number, the oldest diagnostic files in the directory are automatically deleted based on the timestamp in the file name.

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

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

The minimum value for diagnosticDataCollectionDirectorySizeMB is 10 megabytes. diagnosticDataCollectionDirectorySizeMB must be greater than maximum diagnostic file size diagnosticDataCollectionFileSizeMB.

diagnosticDataCollectionFileSizeMB

Available for both mongod and mongos.

Type: integer

Default: 10

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

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

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

The minimum value for diagnosticDataCollectionFileSizeMB is 1 megabyte.

diagnosticDataCollectionPeriodMillis

Available for both mongod and mongos.

Type: integer

Default: 1000

Specifies the interval, in milliseconds, at which to collect diagnostic data.

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

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

The minimum value for diagnosticDataCollectionPeriodMillis is 100 milliseconds.

Replication and Consistency

disableSplitHorizonIPCheck

New in version 5.0.0.

Available for both mongod and mongos.

Type: boolean

Default: false

To configure cluster nodes for split horizon DNS, use host names instead of IP addresses.

Starting in MongoDB v5.0, replSetInitiate and replSetReconfig reject configurations that use IP addresses instead of hostnames.

Use disableSplitHorizonIPCheck to modify nodes that cannot be updated to use host names. The parameter only applies to the configuration commands.

mongod and mongos do not rely on disableSplitHorizonIPCheck for validation at startup. Legacy mongod and mongos instances that use IP addresses instead of host names will start after an upgrade.

Instances that are configured with IP addresses log a warning to use host names instead of IP addresses.

To allow configuration changes using IP addresses, set disableSplitHorizonIPCheck=true using the command line:

/usr/local/bin/mongod  --setParameter disableSplitHorizonIPCheck=true -f /etc/mongod.conf

To allow configuration changes using IP addresses, set disableSplitHorizonIPCheck=true using the node's configuration file:

setParameter:
   disableSplitHorizonIPCheck: true

If you attempt to update disableSplitHorizonIPCheck at runtime, db.adminCommand() returns an error:

db.adminCommand( { setParameter: 1, "disableSplitHorizonIPCheck": true } )
MongoServerError: not allowed to change [disableSplitHorizonIPCheck] at runtime

enableOverrideClusterChainingSetting

New in version 5.0.2.

Available for both mongod and mongos.

Type: boolean

Default: false

If enableOverrideClusterChainingSetting is true, replica set secondary members can replicate data from other secondary members even if settings.chainingAllowed is false.

You can only set enableOverrideClusterChainingSetting at startup and cannot change this setting with the setParameter command.

For example, to set the enableOverrideClusterChainingSetting for a mongod instance to true:

mongod --setParameter enableOverrideClusterChainingSetting=true

logicalSessionRefreshMillis

Available for both mongod and mongos.

Type: integer

Default: 300000 (5 minutes)

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

You can only set logicalSessionRefreshMillis at startup and cannot change this setting with the setParameter command.

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

mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes

Available for both mongod and mongos.

Type: integer

Default: 30

Warning

For testing purposes only

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

The time in minutes that a session remains active after its most recent use. Sessions that have not received a new read/write operation from the client or been refreshed with refreshSessions within this threshold are cleared from the cache. State associated with an expired session may be cleaned up by the server at any time.

This parameter applies only to the instance on which it is set. To set this parameter on replica sets and sharded clusters, you must specify the same value on every member; otherwise, sessions will not function properly.

You can only set localLogicalSessionTimeoutMinutes at startup and cannot change this setting with the setParameter command.

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

mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs

Available for both mongod and mongos.

Type: integer

Default: 31536000 (1 year)

The maximum amount by which the current cluster time can be advanced; specifically, maxAcceptableLogicalClockDriftSecs is the maximum difference between the new value of the cluster time and the current cluster time. Cluster time is a logical time used for ordering of operations.

You cannot advance the cluster time to a new value if the new cluster time differs from the current cluster time by more than maxAcceptableLogicalClockDriftSecs.

You can only set maxAcceptableLogicalClockDriftSecs at startup and cannot change this setting with the setParameter command.

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

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions

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 maxSessions for a mongod instance to 1000:

mongod --setParameter maxSessions=1000

oplogBatchDelayMillis

New in version 6.0.

Available for both mongod and mongos.

Type: integer

Default: 0

The number of milliseconds to delay applying batches of oplog operations on secondary nodes. By default, oplogBatchDelayMillis is 0, meaning oplog batches are applied with no delay. When there is no delay, MongoDB may apply frequent, small oplog batches to secondaries.

Increasing oplogBatchDelayMillis causes MongoDB to apply oplog batches less frequently on secondaries, with each batch containing larger amounts of data. This reduces IOPS on secondaries, but adds latency for writes with write concern "majority".

You can only set oplogBatchDelayMillis at startup. You cannot set oplogBatchDelayMillis during runtime.

For example, run the following command to set the oplogBatchDelayMillis for a mongod instance to 20 milliseconds:

mongod --setParameter oplogBatchDelayMillis=20

storeFindAndModifyImagesInSideCollection

New in version 5.1.

Available for both mongod and mongos.

Type: boolean

Default: true

Determines whether the temporary documents required for retryable findAndModify commands are stored in the side collection (config.image_collection).

If storeFindAndModifyImagesInSideCollection is:

true, the temporary documents are stored in the side collection.
false, the temporary documents are stored in the replica set oplog.

Keep storeFindAndModifyImagesInSideCollection set to true if you:

Have a large retryable findAndModify workload.
Require more temporary document space for retryable findAndModify commands than is available in the replica set oplog.

Note

Secondaries may experience increased CPU usage when storeFindAndModifyImagesInSideCollection is true.

For example, to set storeFindAndModifyImagesInSideCollection to false during startup:

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

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

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

TransactionRecordMinimumLifetimeMinutes

Available for mongod only.

Type: integer

Default: 30

The minimum lifetime a transaction record exists in the transactions collection before the record becomes eligible for cleanup.

You can only set TransactionRecordMinimumLifetimeMinutes at startup and cannot change this setting with the setParameter command.

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

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

Note

For flow control to engage, the replica set/sharded cluster must have: featureCompatibilityVersion (fCV) of 4.2 and read concern majority enabled. That is, enabled flow control has no effect if fCV is not 4.2 or if read concern majority is disabled.

flowControlTargetLagSeconds

New in version 4.2.

Type: integer

Default: 10

The target maximum majority committed lag when running with flow control. When flow control is enabled, the mechanism attempts to keep the majority committed lag under the specified seconds. The parameter has no effect if flow control is disabled.

The specified value must be greater than 0.

In general, the default settings should suffice; however, if modifying from the default value, decreasing, rather than increasing, 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 control mechanism detects the majority commit point has not moved.

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

initialSyncTransientErrorRetryPeriodSeconds

New in version 4.4.

Type: integer

Default: 86400

The amount of time in seconds a secondary performing initial sync attempts to resume the process if interrupted by a transient network error. The default value is equivalent to 24 hours.

initialSyncSourceReadPreference

New in version 4.4.

Type: String

Available for mongod only.

The preferred source for performing initial sync. Specify one of the following read preference modes:

primary
primaryPreferred (Default for voting replica set members)
secondary
secondaryPreferred
nearest (Default for newly added or non-voting replica set members)

If the replica set has disabled chaining, the default initialSyncSourceReadPreference read preference mode is primary.

You cannot specify a tag set or maxStalenessSeconds to initialSyncSourceReadPreference.

If the mongod cannot find a sync source based on the specified read preference, it logs an error and restarts the initial sync process. The mongod exits with an error if it cannot complete the initial sync process after 10 attempts. For more information on sync source selection, see Initial Sync Source Selection.

initialSyncSourceReadPreference takes precedence over the replica set's settings.chainingAllowed setting when selecting an initial sync source. After a replica set member successfully completes initial sync, it defers to the value of chainingAllowed when selecting a replication sync source.

You can only set this parameter on startup, using either the setParameter configuration file setting or the --setParameter command line option.

initialSyncMethod

New in version 5.2.

Available for mongod only.

Type: String

Default: logical

Available only in MongoDB Enterprise.

Method used for initial sync.

Set to logical to use logical initial sync. Set to fileCopyBased to use file copy based initial sync.

This parameter only affects the sync method for the member on which it is specified. Setting this parameter on a single replica set member does not affect the sync method of any other replica set members.

You can only set this parameter on startup, using either the setParameter configuration file setting or the --setParameter command line option.

maxNumSyncSourceChangesPerHour

New in version 5.0.

Type: integer

Default: 3

Sync sources are evaluated each time a sync source is updated and each time a node fetches a batch of oplog entries. If there are more than maxNumSyncSourceChangesPerHour source changes in an hour, the node temporarily stops re-evaluating that sync source. If this parameter is set with a high value, the node may make unnecessary source changes.

This parameter will not prevent a node from starting to sync from another node if it doesn't have a sync source. The node will re-evaluate if a sync source becomes invalid. Similarly, if the primary changes and chaining is disabled, the node will update to sync from the new primary.

oplogFetcherUsesExhaust

New in version 4.4.

Available for mongod only.

Type: boolean

Default: true

Enables or disables streaming replication. Set the value to true to enable streaming replication.

Set the value to false to disable streaming replication. If disabled, secondaries fetch batches of oplog entries by issuing a request to their sync from source and waiting for a response. This requires a network roundtrip for each batch of oplog entries.

You can only set this parameter on startup, using either the setParameter configuration file setting or the --setParameter command line option.

oplogInitialFindMaxSeconds

Type: integer

Default: 60

Available for mongod only.

Maximum time in seconds for a member of a replica set to wait for the find command to finish during data synchronization.

replWriterThreadCount

Type: integer

Default: 16

Available for mongod only.

Maximum number of threads to use to apply replicated operations in parallel. Values can range from 1 to 256 inclusive. However, the maximum number of threads used is capped at twice the number of available cores.

You can only set replWriterThreadCount at startup and cannot change this setting with the setParameter command.

Tip

Sharding Parameters

Note

Starting in version 4.2, MongoDB removes the parameter AsyncRequestsSenderUseBaton and always enables the performance enhancement controlled by the parameter.

balancerMigrationsThrottlingMs

New in version 7.0: (Also available starting in 6.3.1, 6.0.6, 5.0.18)

Type: integer

Default: 1000

Available for mongod only.

Specifies the minimum amount of time between two consecutive balancing rounds. This allows you to throttle the balancing rate. This parameter only takes effect on config server nodes.

This example sets balancerMigrationsThrottlingMs to 2000 milliseconds at startup:

mongod --setParameter balancerMigrationsThrottlingMs=2000

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

db.adminCommand( { setParameter: 1, balancerMigrationsThrottlingMs: 2000 } )

chunkDefragmentationThrottlingMS

New in version 5.3.

Type: integer

Default: 0

Available for both mongod and mongos.

Specifies the minimum time period (in milliseconds) between consecutive split and merge commands run by the balancer when the chunks in a sharded collection are defragmented. chunkDefragmentationThrottlingMS limits the rate of split and merge commands.

The following example sets chunkDefragmentationThrottlingMS to 10 milliseconds:

mongod --setParameter chunkDefragmentationThrottlingMS=10

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

db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )

chunkMigrationConcurrency

Available starting in MongoDB 6.3 (and 5.0.15).

Type: integer

Default: 1

Available for mongod only.

Specifies an integer that sets the number of threads on the source shard and the receiving shard for chunk migration. Chunk migrations use the number of threads that you set on the receiving shard for both the source and receiving shard.

Increasing the concurrency improves chunk migration performance, but also increases the workload and disk IOPS usage on the source shard and the receiving shard.

Maximum value is 500.

You should typically use half the total number of CPU cores as threads. For example, if the total is 16 cores, set chunkMigrationConcurrency to 8 threads (or fewer).

If chunkMigrationConcurrency is greater than 1, the _secondaryThrottle configuration setting is ignored. The _secondaryThrottle setting determines when the chunk migration proceeds with the next document in the chunk. For details, see Range Migration and Replication.

The following example sets chunkMigrationConcurrency to 5:

mongod --setParameter chunkMigrationConcurrency=5

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

db.adminCommand( { setParameter: 1, chunkMigrationConcurrency: 5 } )

disableResumableRangeDeleter

New in version 4.4.

Type: boolean

Default: false

Available for mongod only.

If set on a shard's primary, specifies if range deletion is paused on the shard. If set to true, cleanup of ranges containing orphaned documents is paused. The shard can continue to donate chunks to other shards, but the donated documents will not be removed from this shard until you set this parameter to false. This shard can continue to receive chunks from other shards as long as it does not have a pending range deletion task in the config.rangeDeletions collection that overlaps with the incoming chunk's range.

When disableResumableRangeDeleter is true, chunk migrations fail if orphaned documents exist on the recipient shard's primary in the same range as the incoming chunks.

The parameter has no effect on the mongod if it is not the shard's primary.

Important

If you set disableResumableRangeDeleter parameter to true, ensure that you apply it consistently for all members in the shard's replica set. In the event of a failover, this setting's value on the new primary dictates the behavior of the range deleter.

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

mongod --setParameter disableResumableRangeDeleter=false

enableShardedIndexConsistencyCheck

New in version 4.4: (Also available starting in 4.2.6.)

Type: boolean

Default: true

Available for mongod only.

If set on the config server's primary, enables or disables the index consistency check for sharded collections. The parameter has no effect on the mongod if it is not the config server's primary.

The following example sets enableShardedIndexConsistencyCheck to false for a config server primary:

mongod --setParameter enableShardedIndexConsistencyCheck=false

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

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

Tip

Note

Under certain workloads, opportunistic reads may trigger the opening of unnecessary connections from mongos to mongod and reduce overall performance. This parameter should not be enabled unless your application has a specific need for the feature.

For example, to set opportunisticSecondaryTargeting during startup:

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

New in version 4.4: (Also available starting in 4.2.6.)

Type: integer

Default: 600000

Available for mongod only.

If set on the config server's primary, the interval, in milliseconds, at which the config server's primary checks the index consistency of sharded collections. The parameter has no effect on the mongod if it is not the config server's primary.

You can only set the parameter during startup, and cannot change this setting using the setParameter database command.

For example, the following sets the interval at 300000 milliseconds (5 minutes) at startup:

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

Warning

If metadataRefreshInTransactionMaxWaitBehindCritSecMS is too low, mongos could use all of its retry attempts and return an error.

You can set metadataRefreshInTransactionMaxWaitBehindCritSecMS at startup and during runtime.

For example, to set metadataRefreshInTransactionMaxWaitBehindCritSecMS to 400 milliseconds:

db.adminCommand( { setParameter: 1, metadataRefreshInTransactionMaxWaitBehindCritSecMS: 400 } )

readHedgingMode

New in version 4.4.

Type: string

Default: on

Available for mongos only.

Specifies whether mongos supports hedged reads for those read operations whose read preference have enabled the hedged read option.

Available values are:

Value	Description
`on`	The `mongos` instance supports hedged reads for read operations whose read preference have enabled the hedged read option.
`off`	The `mongos` instance does not support hedged reads. That is, hedged reads are unavailable, even for read operations whose read preference have enabled the hedged read option.

For example, to turn off hedged read support for a mongos instance, you can issue the following during startup:

mongos --setParameter readHedgingMode=off

Or if using the setParameter command in a mongosh session that is connected to a running mongos:

db.adminCommand( { setParameter: 1, readHedgingMode: "off" } )

Tip

Note

In MongoDB 4.4, the warmMinConnectionsInShardingTaskExecutorPoolOnStartup parameter is enabled by default for the mongos.

The following example sets ShardingTaskExecutorPoolMinSize to 2 during startup:

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

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

mongos can have up to n TaskExecutor connection pools, where n is the number of cores. See taskExecutorPoolSize.

Tip

Note

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

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

The following sets the orphanCleanupDelaySecs to 20 minutes:

mongod --setParameter orphanCleanupDelaySecs=1200

This may also be set using the setParameter command:

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

rangeDeleterBatchDelayMS

Available for mongod only.

Type: Non-negative integer

Default: 20

The amount of time in milliseconds to wait before the next batch of deletion during the cleanup stage of range migration (or the cleanupOrphaned command).

The _secondaryThrottle replication delay occurs after each batch deletion.

The following sets the rangeDeleterBatchDelayMS to 200 milliseconds:

mongod --setParameter rangeDeleterBatchDelayMS=200

The parameter may also be set using the setParameter command:

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

rangeDeleterBatchSize

Available for mongod only.

Type: Non-negative integer

Default: 2147483647 starting in MongoDB 5.1.2, 5.0.6, and 4.4.12 (128 in earlier MongoDB versions)

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

A value of 0 indicates that the system chooses the default value.

The following example sets rangeDeleterBatchSize to 32 documents:

mongod --setParameter rangeDeleterBatchSize=32

The parameter may also be set using the setParameter command:

db.adminCommand( { setParameter: 1, rangeDeleterBatchSize: 32 } )

skipShardingConfigurationChecks

Available for mongod only.

Type: boolean

Default: false

When true, allows for starting a shard member or config server member as a standalone for maintenance operations. This parameter is mutually exclusive with the --configsvr or --shardsvr options.

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

mongod --setParameter skipShardingConfigurationChecks=true

Important

Once maintenance has completed, remove the skipShardingConfigurationChecks parameter when restarting the mongod.

findChunksOnConfigTimeoutMS

New in version 5.0.

Available for both mongod and mongos.

Type: Non-negative integer

Default: 900000

The timeout in milliseconds for find operations on chunks.

If there is a large number of chunks in the cluster and chunk loading fails with the error ExceededTimeLimit, increase the parameter value:

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

Health Manager Parameters

activeFaultDurationSecs

Type: Document

Available for mongos only.

The amount of time to wait from a Health Managers Overview failure until the mongos is removed from the cluster, in seconds.

When a failure is detected and a Health Manager is configured as critical, the server waits for the specified interval before removing the mongos from the cluster.

For example, to set the duration from failure to crash to five minutes, issue the following at startup:

mongos --setParameter activeFaultDurationSecs=300

Or if using the setParameter command in a mongosh session that is connected to a running mongos:

db.adminCommand(
  {
      setParameter: 1,
      activeFaultDurationSecs: 300
  }
)

Parameters set with setParameter do not persist across restarts. See the setParameter page for details.

To make this setting persistent, set activeFaultDurationSecs in your mongos config file using the setParameter option as in the following example:

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

Type: Array of documents

Available for mongos only.

Use this parameter to set intensity levels for Health Managers.

healthMonitoringIntensities accepts an array of documents, values. Each document in values takes two fields:

type, the Health Manager facet
intensity, the intensity level

Health Managers

Facet	What the Health Observer Checks
`configServer`	Cluster health issues related to connectivity to the config server.
`dns`	Cluster health issues related to DNS availability and functionality.
`ldap`	Cluster health issues related to LDAP availability and functionality.

Intensity Levels

Intensity Level	Description
`critical`	The Health Manager on this facet is enabled and has the ability to move the failing mongos out of the cluster if an error occurs. The Health Manager waits the amount of time specified by `activeFaultDurationSecs` before stopping and moving the mongos out of the cluster automatically.
`non-critical`	The Health Manager on this facet is enabled and logs errors, but the mongos remains in the cluster if errors are encountered.
`off`	The Health Manager on this facet is disabled. The mongos does not perform any health checks on this facet. This is the default intensity level.

For example, to set the dns Health Manager facet to the critical intensity level, issue the following at startup:

mongos --setParameter 'healthMonitoringIntensities={ values:[ { type:"dns", intensity: "critical"} ] }'

Or if using the setParameter command in a mongosh session that is connected to a running mongos:

db.adminCommand(
  {
      setParameter: 1,
      healthMonitoringIntensities: { values: [ { type: "dns", intensity: "critical" } ] } } )
  }
)

Parameters set with setParameter do not persist across restarts. See the setParameter page for details.

To make this setting persistent, set healthMonitoringIntensities in your mongos config file using the setParameter option as in the following example:

setParameter:
   healthMonitoringIntensities: "{ values:[ { type:\"dns\", intensity: \"critical\"} ] }"

healthMonitoringIntervals

Type: Array of documents

Available for mongos only.

How often this Health Manager will run, in milliseconds.

healthMonitoringIntervals accepts an array of documents, values. Each document in values takes two fields:

type, the Health Manager facet
interval, the time interval it runs at, in milliseconds

Health Managers

Facet	What the Health Observer Checks
`configServer`	Cluster health issues related to connectivity to the config server.
`dns`	Cluster health issues related to DNS availability and functionality.
`ldap`	Cluster health issues related to LDAP availability and functionality.

For example, to set the ldap Health Manager facet to the run health checks every 30 seconds, issue the following at startup:

mongos --setParameter 'healthMonitoringIntervals={ values:[ { type:"ldap", interval: "30000"} ] }'

Or if using the setParameter command in a mongosh session that is connected to a running mongos:

db.adminCommand(
  {
      setParameter: 1,
      healthMonitoringIntervals: { values: [ { type: "ldap", interval: "30000" } ] } } )
  }
)

Parameters set with setParameter do not persist across restarts. See the setParameter page for details.

To make this setting persistent, set healthMonitoringIntervals in your mongos config file using the setParameter option as in the following example:

setParameter:
   healthMonitoringIntervals: "{ values: [{type: \"ldap\", interval: 200}] }"

progressMonitor

Type: Document

Available for mongos only.

Progress Monitor runs tests to ensure that Health Manager checks do not become stuck or unresponsive. Progress Monitor runs these tests in intervals specified by interval. If a health check begins but does not complete within the timeout given by deadline, Progress Monitor stops the mongos and removes it from the cluster.

`progressMonitor` Fields

Field	Description	Units
`interval`	How often to ensure Health Managers are not stuck or unresponsive.	Milliseconds
`deadline`	Timeout before automatically failing the mongos if a Health Manager check is not making progress.	Seconds

To set the interval to 1000 milliseconds and the deadline to 300 seconds, issue the following at startup:

mongos --setParameter 'progressMonitor={"interval": 1000, "deadline": 300}'

Or if using the setParameter command in a mongosh session that is connected to a running mongos:

db.adminCommand(
  {
      setParameter: 1,
      progressMonitor: { interval: 1000, deadline: 300 } )
  }
)

Parameters set with setParameter do not persist across restarts. See the setParameter page for details.

To make this setting persistent, set progressMonitor in your mongos config file using the setParameter option as in the following example:

setParameter:
   progressMonitor: "{ interval: 1000, deadline: 300 }"

Storage Parameters

honorSystemUmask

Available for mongod only.

Default: false

If honorSystemUmask is set to true, new files created by MongoDB have permissions in accordance with the user's umask settings. You cannot set processUmask if honorSystemUmask is set to true.

If honorSystemUmask is set to false, new files created by MongoDB have permissions set to 600, which gives read and write permissions only to the owner. New directories have permissions set to 700. You can use processUmask to override the default permissions for groups and other users on all new files created by MongoDB.

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

mongod --setParameter honorSystemUmask=true

Note

honorSystemUmask is not available on Windows systems.

journalCommitInterval

Available for mongod only.

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

Consider the following example which sets the journalCommitInterval to 200 ms:

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

Tip

Note

Increasing the value of minSnapshotHistoryWindowInSeconds increases disk usage. For more information, see Snapshot History Retention.

To modify this value for a MongoDB Atlas cluster, you must contact Atlas Support.

processUmask

New in version 4.4.

Available for mongod only.

Overrides the default permissions used for groups and other users when honorSystemUmask is set to false. By default, when honorSystemUmask is set to false, new files created by MongoDB have permissions set to 600. Use the processUmask parameter to override this default with a custom umask value. The file owner inherits permissions from the system umask.

You cannot set this parameter if honorSystemUmask is set to true. You can only set this parameter during start-up and cannot change this setting using the setParameter database command.

Consider the following example, which sets the permissions for groups and other users to read/write only and retains the system umask settings for the owner:

mongod --setParameter processUmask=011

Note

processUmask is not available on Windows systems.

syncdelay

Available for mongod only.

Specify the interval in seconds between fsync operations where mongod flushes its working memory to disk. By default, mongod flushes memory to disk every 60 seconds. In almost every situation you should not set this value and use the default setting.

Consider the following example which sets the syncdelay to 60 seconds:

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

Tip

WiredTiger Parameters

wiredTigerMaxCacheOverflowSizeGB

Note

Deprecated in MongoDB 4.4

MongoDB deprecates the wiredTigerMaxCacheOverflowSizeGB parameter. The parameter has no effect starting in MongoDB 4.4.

Default: 0 (No specified maximum)

Available for mongod only.

Specify the maximum size (in GB) for the "lookaside (or cache overflow) table" file WiredTigerLAS.wt for MongoDB 4.2.1-4.2.x. The file no longer exists starting in version 4.4.

The parameter can accept the following values:

Value	Description
`0`	The default value. If set to `0`, the file size is unbounded.
number >= 0.1	The maximum size (in GB). If the `WiredTigerLAS.wt` file exceeds this size, `mongod` exits with a fatal assertion. You can clear the `WiredTigerLAS.wt` file and restart `mongod`.

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

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

To set the maximum size during start up, use the storage.wiredTiger.engineConfig.maxCacheOverflowFileSizeGB instead.

New in version 4.2.1.

wiredTigerConcurrentReadTransactions

Available for mongod only.

Available for the WiredTiger storage engine only.

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

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

Tip

Warning

Avoid modifying the wiredTigerEngineRuntimeConfig unless under the direction from MongoDB engineers as this setting has major implication across both WiredTiger and MongoDB.

Consider the following operation prototype:

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

See the WiredTiger documentation for all available WiredTiger configuration options.

Auditing Parameters

auditAuthorizationSuccess

Type: boolean

Default: false

Note

Available only in MongoDB Enterprise and MongoDB Atlas.

Available for both mongod and mongos.

Enables the auditing of authorization successes for the authCheck action.

When auditAuthorizationSuccess is false, the audit system only logs the authorization failures for authCheck.

To enable the audit of authorization successes, issue the following command:

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

Enabling auditAuthorizationSuccess degrades performance more than logging only the authorization failures.

If runtime audit configuration is enabled, the auditAuthorizationSuccess parameter should not appear in the mongod or mongos configuration file. The server will fail to start if the parameter is present.

Tip

Note

Using the default value of 300 seconds, non-config nodes may lag up to 5 minutes behind a setAuditConfig command.

auditEncryptionHeaderMetadataFile

New in version 6.0.

Type: string

Note

Available only in MongoDB Enterprise. MongoDB Enterprise and Atlas have different configuration requirements.

Available for both mongod and mongos.

Path and file name for logging metadata audit headers for audit log encryption. A header is placed at the top of each audit log file and contains metadata for decrypting the audit log. The headers are also stored in the audit log.

You can only set auditEncryptionHeaderMetadataFile during startup in the configuration file or with the --setParameter option on the command line. For example, the following sets the path and file for auditEncryptionHeaderMetadataFile:

mongod --setParameter auditEncryptionHeaderMetadataFile=/auditFiles/auditHeadersMetadataFile.log

auditEncryptKeyWithKMIPGet

New in version 6.0.

Type: boolean

Default: false

Note

Available only in MongoDB Enterprise. MongoDB Enterprise and Atlas have different configuration requirements.

Available for both mongod and mongos.

Enables audit log encryption for Key Management Interoperability Protocol (KMIP) servers that only support KMIP protocol version 1.0 or 1.1.

You can only set auditEncryptKeyWithKMIPGet during startup in the configuration file or with the --setParameter option on the command line. For example, the following sets auditEncryptKeyWithKMIPGet to true:

mongod --setParameter auditEncryptKeyWithKMIPGet=true

Transaction Parameters

coordinateCommitReturnImmediatelyAfterPersistingDecision

New in version 5.0.

Updated in version 6.1

Type: boolean

Default: false

Available for mongod only.

Behavior When `false`

The shard transaction coordinator waits for all members to acknowledge the decision to either commit or cancel a multi-document transaction before returning the result to the client.

Behavior When `true`

The shard transaction coordinator returns a multi-document transaction commit decision to the client as soon as the decision is made durable with the requested transaction write concern.

If the client requested a write concern that is less than "majority", the commit may roll back after the decision is returned to the client.

Transactions may not have "read your writes" consistency. That is, a read operation may not reflect the results of a write operation that preceded it. This can happen in the following cases:

A transaction has to write to multiple shards.
The read and the earlier write take place in different sessions.

Causal consistency only guarantees the causal relationship of reads and writes that occurr within the same session.

Example

The following example sets coordinateCommitReturnImmediatelyAfterPersistingDecision to true:

mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

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

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

internalSessionsReapThreshold

New in version 6.0.

Available for both mongod and mongos.

Default: 1000

Session limit for internal session metadata deletion. The metadata:

Contains session transaction information for user operations.
Is stored in the config.transactions collection.

When the number of internal sessions is greater than internalSessionsReapThreshold, the metadata is deleted.

If you set internalSessionsReapThreshold to 0, the internal session metadata is only deleted when the user session ends.

The following example sets internalSessionsReapThreshold to 500 sessions:

db.adminCommand( { setParameter: 1, internalSessionsReapThreshold: 500 } )

You can also set internalSessionsReapThreshold at startup. For example:

mongod --setParameter internalSessionsReapThreshold=500

transactionLifetimeLimitSeconds

Available for mongod only.

Default: 60

Specifies the lifetime of multi-document transactions. Transactions that exceed this limit are considered expired and will be aborted by a periodic cleanup process. The cleanup process runs every transactionLifetimeLimitSeconds/2 seconds or at least once every 60 seconds.

The cleanup process helps relieve storage cache pressure.

The minimum value for transactionLifetimeLimitSeconds is 1 second.

The following sets the transactionLifetimeLimitSeconds to 30 seconds:

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

You can also set parameter transactionLifetimeLimitSeconds at startup time.

mongod --setParameter "transactionLifetimeLimitSeconds=30"

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

Starting in MongoDB 5.0, if you change the transactionLifetimeLimitSeconds parameter, you must also change transactionLifetimeLimitSeconds to the same value on all config server replica set members. Keeping this value consistent:

Ensures the routing table history is retained for at least as long as the transaction lifetime limit on the shard replica set members.
Reduces the transaction retry frequency and therefore improves performance.

transactionTooLargeForCacheThreshold

New in version 6.2.

Available for mongod only.

Type: decimal

Default: 0.75

The threshold value for retrying transactions that fail due to cache pressure. The value is a percentage of the dirty cache size. The default value, 0.75, means 75% of the dirty cache.

The dirty cache is limited to 20% of the total cache size. When transactionTooLargeForCacheThreshold is set to 0.75, the server only retries transactions that use less than 15% (0.75 * 20%) of the total storage engine cache.

The limit only applies to retries. Large transactions can use more than transactionTooLargeForCacheThreshold percent of the dirty cache. However, if a large transaction is rolled back due to cache pressure, the server issues a TransactionTooLargeForCache error and does not retry the transaction.

To disable this behavior, set transactionTooLargeForCacheThreshold to 1.0.

For more information on WiredTiger storage, see: storage.wiredTiger Options.

maxTransactionLockRequestTimeoutMillis

Available for mongod only.

Type: integer

Default: 5

The maximum amount of time in milliseconds that multi-document transactions should wait to acquire locks required by the operations in the transaction.

If the transaction cannot acquire the locks after waiting maxTransactionLockRequestTimeoutMillis, the transaction aborts.

By default, multi-document transactions wait 5 milliseconds. That is, if the transaction cannot acquire the locks within 5 milliseconds, the transaction aborts. If an operation provides a greater timeout in a lock request, maxTransactionLockRequestTimeoutMillis overrides the operation-specific timeout.

You can set maxTransactionLockRequestTimeoutMillis to:

0 such that if the transaction cannot acquire the required locks immediately, the transaction aborts.
A number greater than 0 to wait the specified time to acquire the required locks. This can help obviate transaction aborts on momentary concurrent lock acquisitions, like fast-running metadata operations. However, this could possibly delay the abort of deadlocked transaction operations.
-1 to use the operation specific timeout.

The following sets the maxTransactionLockRequestTimeoutMillis to 20 milliseconds:

db.adminCommand( { setParameter: 1, maxTransactionLockRequestTimeoutMillis: 20 } )

You can also set this parameter during start-up:

mongod --setParameter maxTransactionLockRequestTimeoutMillis=20

shouldMultiDocTxnCreateCollectionAndIndexes

Removed in 5.0

Type: boolean

Default: true

A flag that enables or disables the creation of a collection or an index inside transactions. Set the parameter to:

true to enable. (Default)
false to disable.

You can set the parameter during startup or runtime.

Important

When setting the parameter for a sharded cluster, set the parameter on all shards.

To set the parameter at startup, specify the parameter in the configuration file or with the --setParameter option on the command line. For example:

mongod --setParameter shouldMultiDocTxnCreateCollectionAndIndexes=false

To modify during runtime, you can use the setParameter command; for example:

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

Slot-Based Execution Parameters

planCacheSize

New in version 6.3.

Type: string

Default: 5%

Available for mongod only.

Note

Although the planCacheSize parameter existed in prior versions of MongoDB, it had no effect on the plan cache until version 6.3.

Sets the size of the plan cache only for the slot-based query execution engine.

You can set the planCacheSize value to either:

A percentage of the system's total physical memory to allocate for the plan cache. For example, "8.5%".
The exact amount of data to allocate for the plan cache in either MB or GB. For example, "100MB" or "1GB".

Increasing the plan cache size adds more cached query shapes for the query planner. This can improve query performance, but increases memory usage.

The following startup command sets planCacheSize to 80 megabytes:

mongod --setParameter planCacheSize="80MB"

You can also use the setParameter command within the MongoDB Shell:

db.adminCommand( { setParameter: 1, planCacheSize: "80MB" } )

Back

install_compass

MongoDB Wire Protocol

Matching Policy	Description
`"automatic"` (Default)	Starting in 5.0 (and 4.4.5 and 4.2.13), `"automatic"` is the new default value. When set for a `mongos`, the instance follows the behavior specified for the `"matchPrimaryNode"` option. When set for a `mongod`, the instance follows the behavior specified for the `"disabled"` option. Note If the `ShardingTaskExecutorPoolReplicaSetMatching` is set to `"automatic"`, the `replicaSetMatchingStrategy` still describes the actual policy being used, not `"automatic"`. To find the value of the `ShardingTaskExecutorPoolReplicaSetMatching`, use `getParameter` which returns the value of the server parameter.
`"matchPrimaryNode"`	When set for a `mongos`, the minimum size limit of the instance's connection pool to each secondary of a replica set in the sharded cluster (specifically, shard replica set and config servers) is equal to the size of its connection pool to that replica set's primary. When set for a `mongod`, the minimum size limit of the instance's connection pool to each secondary of another replica set in the sharded cluster (specifically, shard replica set and config servers) is equal to the size of its connection pool to that replica set's primary. Warning If multiple shard servers in your topology can experience a rapid influx of cross-shard operations, do not set this option on your `mongod` instances. In case of a primary stepdown, `matchPrimaryNode` ensures that any secondary that becomes the primary can handle the current level of primary reads and writes.
`"matchBusiestNode"`	When set for a `mongos`, the instance's minimum size limit of the connection pool to each member of a replica set in the sharded cluster (specifically, shard replica set and config servers) is equal to the largest among the active connection counts to the primary and each secondary member of that replica set. When set for a `mongod`, the instance's minimum size limit of the connection pool to each member of another replica set in the sharded cluster (specifically, shard replica set and config servers) is equal to the largest among the active connection counts to the primary and each secondary member of that replica set. With `"matchBusiestNode"`, `mongos` maintains enough connections to each secondary to handle the current level of primary and secondary reads and writes. The number of connections to maintain in the pool decreases as the number of active connections decreases.
`"disabled"`	When set for a `mongos`, the instance's minimum number of connections in the instance's connection pool to each node of a replica set in the sharded clusterv (specifically, shard replica set and config servers) is equal to the `ShardingTaskExecutorPoolMinSize`. When set for a `mongod`, the instance's minimum number of connections in the instance's connection pool to each node of another replica set in the sharded cluster (specifically, shard replica set and config servers) is equal to the `ShardingTaskExecutorPoolMinSize`.

MongoDB Server Parameters.leafygreen-ui-m0pgrr{-webkit-align-self:center;-ms-flex-item-align:center;align-self:center;padding:0 10px;visibility:hidden;}.leafygreen-ui-a30zj9{color:#889397;vertical-align:middle;margin-top:-2px;}.css-fmznk8{margin-top:-85px;position:absolute;padding-bottom:2px;}

Synopsis

Parameters

Authentication Parameters

Note

Tip

Note

Note

Tip

See also:

Tip

See also:

Note

Note

Note

Note

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

Note

Important

Tip

See also:

Tip

See also:

Tip

See also:

Tip

See also:

Tip

See also:

Tip

See also:

Note

Note

Enterprise Feature

General Parameters

Note

Tip

See also:

Tip

See also:

Note

Tip

See also:

Tip

See also:

Important

Important

Tip

See also:

Tip

See also:

Tip

See also:

Note

Tip

Note

Note

Logging Parameters

Tip

See also:

Warning

Tip

See also:

Note

Enterprise Feature

Tip

See also:

Tip

See also:

Diagnostic Parameters

Note

Warning

Replication and Consistency

Warning

For testing purposes only

Note

Tip

See also:

Note

Tip

MongoDB Server Parameters

`progressMonitor` Fields

Behavior When `false`

Behavior When `true`