Docs Home → Develop Applications → MongoDB Manual
MongoDB Server Parameters![](/docs/v5.3/assets/link.svg)
On this page
Synopsis![](/docs/v5.3/assets/link.svg)
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 formongod
andmongos
:mongod --setParameter <parameter>=<value> mongos --setParameter <parameter>=<value>
For additional configuration options, see
Configuration File Options, mongod
and
mongos
.
Parameters![](/docs/v5.3/assets/link.svg)
Authentication Parameters![](/docs/v5.3/assets/link.svg)
authenticationMechanisms
Changed in version 4.0: Remove support for the deprecated
MONGODB-CR
authentication mechanism.Available for both
mongod
andmongos
.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.
ValueDescriptionRFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function.RFC 7677 standard Salted Challenge Response Authentication Mechanism using the SHA-256 hash function.
Requires featureCompatibilityVersion set to
4.0
.New in version 4.0.
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 usePLAIN
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
andSCRAM-SHA-256
as the authentication mechanisms, use the following command:mongod --setParameter authenticationMechanisms=PLAIN,SCRAM-SHA-256 --auth
clusterAuthMode
Available for both
mongod
andmongos
.Set the
clusterAuthMode
to eithersendX509
orx509
. Useful during rolling upgrade to use x509 for membership authentication to minimize downtime.For more information about TLS/SSL and MongoDB, see Configure
mongod
andmongos
for TLS/SSL and TLS/SSL Configuration for Clients .db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )
enableLocalhostAuthBypass
Available for both
mongod
andmongos
.Specify
0
orfalse
to disable localhost authentication bypass. Enabled by default.enableLocalhostAuthBypass
is not available usingsetParameter
database command. Use thesetParameter
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 thesetParameter
database command.
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
to4000
seconds:mongod --setParameter ldapUserCacheRefreshInterval=4000 Or, if using the
setParameter
command withinmongosh
: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, thenmongod
: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
to4000
seconds:mongod --setParameter ldapUserCacheStalenessInterval=4000 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, ldapUserCacheStalenessInterval: 4000 } )
ldapUseConnectionPool
New in version 4.0.9.
Specifies whether MongoDB should use connection pooling when connecting 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 against
libldap_r
.false on Linux where MongoDB Enterprise binaries are linked against
libldap
.
In earlier versions (versions 4.0.9+), the default value is
false
.You can only set
ldapUseConnectionPool
during start-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 (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 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 set
ldapConnectionPoolMinimumConnectionsPerHost
during start-up, and cannot change this setting during runtime with thesetParameter
database command.
ldapConnectionPoolMaximumConnectionsPerHost
New in version 4.2.1 and 4.0.13
Changed starting in MongoDB versions 4.4.15 and 5.0.9 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 thesetParameter
database command.
ldapConnectionPoolMaximumConnectionsInProgressPerHost
New in version 4.2.1 and 4.0.13
Changed starting in MongoDB versions 4.4.15 and 5.0.9 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 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 pooled LDAP connections.
You can only set
ldapConnectionPoolHostRefreshIntervalMillis
during start-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 LDAP server can remain idle before being closed.
You can only set
ldapConnectionPoolIdleHostTimeoutSecs
during start-up, and cannot change this setting with thesetParameter
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 theconfiguration file
or with the--setParameter
option on the command line. For example, the following disablesldapShouldRefreshUserCacheEntries
:mongod --setParameter ldapShouldRefreshUserCacheEntries=false
maxValidateMemoryUsageMB
New in version 5.0.
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 thesetParameter
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 theconfiguration file
or with the--setParameter
option on the command line. For example, the following disables OCSP:mongod --setParameter ocspEnabled=false ...
ocspValidationRefreshPeriodSecs
New in version 4.4: Available on Linux.
The number of seconds to wait before refreshing the stapled OCSP status response. Specify a number greater than or equal to 1.
You can only set
ocspValidationRefreshPeriodSecs
during startup in theconfiguration file
or with the--setParameter
option on the command line. For example, the following sets the parameter to 3600 seconds:mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ... Starting in MongoDB 5.0, the
rotateCertificates
command anddb.rotateCertificates()
method will also refresh any stapled OCSP responses.
opensslCipherConfig
Available on Linux only
Changed in version 4.0: With the use of native TLS/SSL libraries, the parameter
opensslCipherConfig
is supported for Linux/BSD and no longer supported in Windows and macOS. See MongoDB 4.0 TLS/SSL.Specify the cipher string for OpenSSL when using TLS/SSL encryption. For a list of cipher strings, see https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Multiple cipher strings can be provided as a colon-separated list.
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 thesetParameter
database command.For version 4.2 and greater, the use of
TLS
options is preferred overSSL
options. The TLS options have the same functionality as theSSL
options. For example, the following configures amongod
with aopensslCipherConfig
cipher string of'HIGH:!EXPORT:!aNULL@STRENGTH'
in MongoDB 4.2:mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem For versions 4.0 and earlier:
mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --sslMode requireSSL --sslPEMKeyFile 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 thesetParameter
database command. For example, the following configures amongod
with aopensslCipherSuiteConfig
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 theffdhe3072
Diffie-Hellman parameter, as defined in RFC-7919#appendix-A.2. Theffdhe3072
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 thesetParameter
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
andmongos
.Specify the path to the Unix Domain Socket of the
saslauthd
instance to use for proxy authentication.
saslHostName
Available for both
mongod
andmongos
.saslHostName
overrides MongoDB's default hostname detection for the purpose of configuring SASL and Kerberos authentication.saslHostName
does not affect the hostname of themongod
ormongos
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 thesetParameter
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
andmongos
.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. ThesetParameter
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
andmongos
.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 be5000
or greater.For example, the following sets the
scramIterationCount
to12000
.mongod --setParameter scramIterationCount=12000 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, scramIterationCount: 12000 } )
scramSHA256IterationCount
New in version 4.0.
Default:
15000
Available for both
mongod
andmongos
.Changes the number of hashing iterations used for all new
SCRAM-SHA-256
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 iteration count for existing passwords. The
scramSHA256IterationCount
value must be5000
or greater.For example, the following sets the
scramSHA256IterationCount
to20000
.mongod --setParameter scramSHA256IterationCount=20000 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, scramSHA256IterationCount: 20000 } )
sslMode
Available for both
mongod
andmongos
.Set the
net.ssl.mode
to eitherpreferSSL
orrequireSSL
. Useful during rolling upgrade to TLS/SSL to minimize downtime.For more information about TLS/SSL and MongoDB, see Configure
mongod
andmongos
for TLS/SSL and TLS/SSL Configuration for Clients .db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } ) Tip
See also:
tlsMode
New in version 4.2.
Available for both
mongod
andmongos
.Set to either:
preferTLS
requireTLS
The
tlsMode
parameter is useful during rolling upgrade to TLS/SSL to minimize downtime.db.adminCommand( { setParameter: 1, tlsMode: "preferTLS" } ) For more information about TLS/SSL and MongoDB, see Configure
mongod
andmongos
for TLS/SSL and TLS/SSL Configuration for Clients .Tip
See also:
tlsOCSPStaplingTimeoutSecs
New in version 4.4: Available for Linux.
The maximum number of seconds the
mongod
/mongos
instance should wait to receive the OCSP status response for its certificates.Specify an integer greater than or equal to (
>=
) 1. If unset,tlsOCSPStaplingTimeoutSecs
uses thetlsOCSPVerifyTimeoutSecs
value.You can only set
tlsOCSPStaplingTimeoutSecs
during startup in theconfiguration file
or with the--setParameter
option on the command line. For example, the following sets thetlsOCSPStaplingTimeoutSecs
to 20 seconds:mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...
tlsOCSPVerifyTimeoutSecs
New in version 4.4: Available for Linux and Windows.
Default: 5
The maximum number of seconds that the
mongod
/mongos
should wait for the OCSP response when verifying client certificates.Specify an integer greater than or equal to (
>=
) 1.You can only set
tlsOCSPVerifyTimeoutSecs
during startup in theconfiguration file
or with the--setParameter
option on the command line. For example, the following sets thetlsOCSPVerifyTimeoutSecs
to 20 seconds:mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...
tlsWithholdClientCertificate
Default: false
New in version 4.2.
Available for both
mongod
andmongos
.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 TLS certificate is set, by default, the instance sends the certificate when initiating intra-cluster communications with othermongod
ormongos
instances in the deployment. SettlsWithholdClientCertificate
to1
ortrue
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.tlsWithholdClientCertificate
is mutually exclusive with--clusterAuthMode x509
.
tlsX509ClusterAuthDNOverride
New in version 4.2.
Available for both
mongod
andmongos
.An alternative Distinguished Name (DN) that the instance can also use to identify members of the deployment.
For a MongoDB deployment that uses x.509 certificates for
clusterAuthMode
, deployment members identify each other using x.509 certificates (net.tls.clusterFile
, if specified, andnet.tls.certificateKeyFile
) during intra-cluster communications. For members of the same deployment, theDN
from their certificates must have the same Organization attributes (O
's), the Organizational Unit attributes (OU
's), and the Domain Components (DC
's).If
tlsX509ClusterAuthDNOverride
is set for a member, the member can also use the override value when comparing theDN
components (O
's,OU
's, andDC
's) of the presented certificates. That is the member checks the presented certificates against itsnet.tls.clusterFile
/net.tls.certificateKeyFile
. If the DN does not match, the member checks the presented certificate against thetlsX509ClusterAuthDNOverride
value.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
andmongos
.Starting in MongoDB 4.4,
mongod
/mongos
logs a warning on connection if the presented x.509 certificate expires within30
days of themongod/mongos
system clock. Use thetlsX509ExpirationWarningThresholdDays
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
duringmongod/mongos
startup using either:The
setParameter
configuration setting, orThe
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
andmongos
.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 TLS certificate is set, by default, the instance sends the certificate when initiating intra-cluster communications with othermongod
ormongos
instances in the deployment. SetsslWithholdClientCertificate
to1
ortrue
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 themongos
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 of86400
seconds (24 hours).
authFailedDelayMs
Default: 0
Available for both
mongod
andmongos
.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
to5000
, 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
andmongos
.Available starting in MongoDB 4.0.11 (and 3.6.14 and 3.4.22)
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![](/docs/v5.3/assets/link.svg)
connPoolMaxShardedConnsPerHost
Default: 200
Available for both
mongod
andmongos
.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
andmongos
.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
See also:
shardedConnPoolIdleTimeoutMinutes
Available for both
mongod
andmongos
.Sets the time limit that a connection in the legacy sharded cluster connection pool can remain idle before being closed.
By default, the parameter is unset.
You can only set
shardedConnPoolIdleTimeoutMinutes
during startup in the config file or on the command line. For example:mongos --setParameter shardedConnPoolIdleTimeoutMinutes=10 Tip
See also:
connPoolMaxConnsPerHost
Default: 200
Available for both
mongod
andmongos
.Sets the maximum size of the legacy connection pools for outgoing connections to other
mongod
instances in the global connection pool. The size of a pool does not prevent the creation of additional connections, but does prevent a connection pool from retaining connections in excess of the value ofconnPoolMaxConnsPerHost
.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
andmongos
.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
See also:
globalConnPoolIdleTimeoutMinutes
Available for both
mongod
andmongos
.Sets the time limit that connection in the legacy global connection pool can remain idle before being closed.
By default, the parameter is unset.
You can only set
globalConnPoolIdleTimeoutMinutes
during startup in the config file or on the command line. For example:mongos --setParameter globalConnPoolIdleTimeoutMinutes=10 Tip
See also:
cursorTimeoutMillis
Default: 600000 (10 minutes)
Available for both
mongod
andmongos
.Sets the expiration threshold in milliseconds for idle cursors before MongoDB removes them; specifically, MongoDB removes cursors that have been idle for the specified
cursorTimeoutMillis
.For example, the following sets the
cursorTimeoutMillis
to300000
milliseconds (5 minutes).mongod --setParameter cursorTimeoutMillis=300000 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, cursorTimeoutMillis: 300000 } ) Setting
cursorTimeoutMillis
to less than or equal to0
results in all cursors being immediately eligible for timeout. Generally, the timeout value should be greater than the average amount of time for a query to return results. Use tools like thecursor.explain()
cursor modifier to analyze the average query time and select an appropriate timeout period.
failIndexKeyTooLong
Removed in 4.4
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.
For MongoDB 2.6 through MongoDB versions with featureCompatibilityVersion (fCV) set to
"4.0"
or earlier, Index Key Length Limit applies. If you attempt to insert or update a document whose index field exceeds the Index Key Length Limit, the operation will fail and return an error to the client.To avoid this issue, consider using hashed indexes or indexing a computed value. If you have an existing data set and want to disable this behavior so you can upgrade and then gradually resolve these indexing issues, you can use
failIndexKeyTooLong
to disable this behavior.Setting
failIndexKeyTooLong
tofalse
is a temporary workaround, not a permanent solution to the problem of oversized index keys. WithfailIndexKeyTooLong
set tofalse
, queries can return incomplete results if they use indexes that skip over documents whose indexed fields exceed the Index Key Length Limit.failIndexKeyTooLong
defaults totrue
.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
notablescan
Available for
mongod
only.Specify whether all queries must use indexes. If
1
, MongoDB will not execute queries that require a collection scan and will return an error.Consider the following example which sets
notablescan
to1
or true:db.adminCommand( { setParameter: 1, notablescan: 1 } ) Setting
notablescan
to1
can be useful for testing application queries, for example, to identify queries that scan an entire collection and cannot use an index.To detect unindexed queries without
notablescan
, consider reading the Evaluate Performance of Current Operations and Optimize Query Performance sections and using thelogLevel
parameter,mongostat
and profiling.Don't run production
mongod
instances withnotablescan
because preventing collection scans can potentially affect queries in all databases, including administrative queries.
ttlMonitorEnabled
Available for
mongod
only.Default:
true
To support TTL Indexes,
mongod
instances have a background thread that is responsible for deleting documents from collections with TTL indexes.To disable this worker thread for a
mongod
, setttlMonitorEnabled
tofalse
, as in the following operations:db.adminCommand( { setParameter: 1, ttlMonitorEnabled: false } ) Alternately, you may disable the thread at startup time by starting the
mongod
instance with the following option:mongod --setParameter ttlMonitorEnabled=false Important
Do not run production
mongod
instances withttlMonitorEnabled
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
andmongos
.Default:
true
Enables support for accepting inbound TCP Fast Open (TFO) connections to the
mongod/mongos
from a client. TFO requires both the client andmongod/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
See also:
tcpFastOpenClient
New in version 4.4.
Available for both
mongod
andmongos
.Default:
true
Linux Operating System Only
Enables support for outbound TCP Fast Open (TFO) connections from the
mongod/mongos
to a client. TFO requires both the client and themongod/mongos
host machine support and enable TFO.Linux operating systems running Linux Kernel 4.11 or later can support outbound TFO.
Set the value of
/proc/sys/net/ipv4/tcp_fastopen
to enable outbound TFO connections:1
to enable only outbound TFO connections.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
See also:
tcpFastOpenQueueSize
New in version 4.4.
Available for both
mongod
andmongos
.Default:
1024
As part of establishing a TCP Fast Open (TFO) connection, the client submits a valid TFO cookie to the
mongod/mongos
before completion of the standard TCP 3-way handshake. Themongod/mongos
keeps a queue of all such pending TFO connections.The
tcpFastOpenQueueSize
parameter sets the size of the queue of pending TFO connections. While the queue is full, themongod/mongos
falls back to the normal three-way handshake for incoming client requests and ignores the presence of TFO cookies. Once the queue size falls back below the limit, themongod/mongos
begins accepting new TFO cookies.Increasing the default queue size may improve the effect of TFO on network performance. However, large queue sizes also increase the risk of server resource exhaustion due to excessive incoming TFO requests.
Decreasing the default queue size may reduce the risk of resource server resource exhaustion due to excessive incoming TFO requests. However, small queue sizes may also reduce the effect of TFO on network performance.
The minimum queue size is
0
. A queue of0
effectively disables TFO.
This parameter has no effect on host operating systems that do not support or are not configured for TFO connections. See Support for TCP Fast Open for more information on MongoDB TFO support.
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 implements Just-in-Time (JIT) compilation for improved performance when running scripts.
To enable the JIT, set
disableJavaScriptJIT
tofalse
, as in the following example:db.adminCommand( { setParameter: 1, disableJavaScriptJIT: false } ) Note
$where
will reuse existing JavaScript interpreter contexts, so changes todisableJavaScriptJIT
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 helperdb.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 Create Index or by an administrative process such as an initial sync. Both are subject to the limit set by
maxIndexBuildMemoryUsageMegabytes
.An initial sync operation 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 in
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.
Changed in version 4.2.
For feature compatibility version (fcv)
"4.2"
, the index build memory limit applies to all index builds.For feature compatibility version (fcv)
"4.0"
, the index build memory limit only applies to foreground index builds.
reportOpWriteConcernCountersInServerStatus
New in version 4.0.6.
Default: false
A boolean flag that determines whether the
db.serverStatus()
method andserverStatus
command returnopWriteConcernCounters
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)
Note
Starting in MongoDB 4.2, the Storage Node Watchdog is available in both the Community and MongoDB Enterprise editions.
In earlier versions (3.2.16+, 3.4.7+, 3.6.0+, 4.0.0+), the Storage Node Watchdog is only available in MongoDB Enterprise edition.
Determines how frequent the Storage Node Watchdog checks the status of the monitored filesystems:
The
--dbpath
directoryThe
journal
directory inside the--dbpath
directory ifjournaling
is enabledThe directory of
--logpath
fileThe directory of
--auditPath
file
Valid values for
watchdogPeriodSeconds
are:-1
(the default), to disable/pause Storage Node Watchdog, orAn 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 themongod
.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
usesstorage.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: Also available in 3.6.17+ and 4.0.14+
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
andmongos
.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, setfassertOnLockTimeoutForStepUpDown=0
.The following example disables nodes from fasserting:
mongod --setParameter fassertOnLockTimeoutForStepUpDown=0
Logging Parameters![](/docs/v5.3/assets/link.svg)
logLevel
Available for both
mongod
andmongos
.Specify an integer between
0
and5
signifying the verbosity of the logging, where5
is the most verbose. [2]The default
logLevel
is0
(Informational).The following example sets the
logLevel
to2
:db.adminCommand( { setParameter: 1, logLevel: 2 } ) Tip
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 previous versions, MongoDB log messages only specifiedD
for Debug level.
logComponentVerbosity
Available for both
mongod
andmongos
.Sets the verbosity levels of various components for log messages. The verbosity level determines the amount of Informational and Debug messages MongoDB outputs. [3]
The verbosity level can range from
0
to5
:0
is the MongoDB's default log verbosity level, to include Informational messages.1
to5
increases the verbosity level to include Debug messages.
For a component, you can also specify
-1
to inherit the parent's verbosity level.To specify the verbosity level, use a document similar to the following:
{ verbosity: <int>, <component1>: { verbosity: <int> }, <component2>: { verbosity: <int>, <component3>: { verbosity: <int> } }, ... } For the components, you can specify just the
<component>: <int>
in the document, unless you are setting both the parent verbosity level and that of the child component(s) as well:{ verbosity: <int>, <component1>: <int> , <component2>: { verbosity: <int>, <component3>: <int> } ... } The top-level
verbosity
field corresponds tosystemLog.verbosity
which sets the default level for all components. The default value ofsystemLog.verbosity
is0
.The components correspond to the following settings:
Unless explicitly set, the component has the verbosity level of its parent. For example,
storage
is the parent ofstorage.journal
. That is, if you specify astorage
verbosity level, this level also applies to:storage.journal
components unless you specify the verbosity level forstorage.journal
.storage.recovery
components unless you specify the verbosity level forstorage.recovery
.
For example, the following sets the
default verbosity level
to1
, thequery
to2
, thestorage
to2
, and thestorage.journal
to1
.db.adminCommand( { setParameter: 1, logComponentVerbosity: { verbosity: 1, query: { verbosity: 2 }, storage: { verbosity: 2, journal: { verbosity: 1 } } } } ) You can also set parameter
logComponentVerbosity
at startup time, passing the verbosity level document as a string.mongod --setParameter "logComponentVerbosity={command: 3}" mongosh
also provides thedb.setLogLevel()
to set the log level for a single component. For various ways to set the 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 previous versions, MongoDB log messages only specifiedD
for Debug level.
maxLogSizeKB
Available for both
mongod
andmongos
.Type: non-negative integer
Default: 10
Specifies the maximum size, in kilobytes, for an individual attribute field in a log entry; attributes exceeding this limit are truncated.
Truncated attribute fields print field content up to the
maxLogSizeKB
limit and excise field content past that limit, retaining valid JSON formatting. Log entries that contain truncated attributes append atruncated
object to the end of the log entry.See log message truncation for more information.
A value of
0
disables truncation entirely. Negative values for this parameter are not valid.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
andmongos
.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, thedropIndexes
command, thediagLogging
command, thevalidate
command; andreplication synchronization activities.
Consider the following example which sets the
quiet
parameter to1
:db.adminCommand( { setParameter: 1, quiet: 1 } ) Tip
See also:
redactClientLogData
Available for both
mongod
andmongos
.Type: boolean
Note
Enterprise Feature
Available in MongoDB Enterprise only.
Configure the
mongod
ormongos
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 on a running
mongod
ormongos
, use the following command:db.adminCommand( { setParameter: 1, redactClientLogData : true } ) Tip
See also:
traceExceptions
Available for both
mongod
andmongos
.Configures
mongod
to log full source code stack traces for every database and socket C++ exception, for use with debugging. Iftrue
,mongod
will log full stack traces.Consider the following example which sets the
traceExceptions
totrue
:db.adminCommand( { setParameter: 1, traceExceptions: true } ) Tip
See also:
suppressNoTLSPeerCertificateWarning
New in version 4.0.1.
Available for both
mongod
andmongos
.Type: boolean
Default: false
By default, a
mongod
ormongos
with TLS/SSL enabled andnet.ssl.allowConnectionsWithoutCertificates
:true
lets clients connect without providing a certificate for validation while logging an warning. SetsuppressNoTLSPeerCertificateWarning
to1
ortrue
to suppress those warnings.The following operation sets
suppressNoTLSPeerCertificateWarning
totrue
:db.adminCommand( { setParameter: 1, suppressNoTLSPeerCertificateWarning: true} )
Diagnostic Parameters![](/docs/v5.3/assets/link.svg)
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
andmongos
.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.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
orsystemLog.path
file extension(s) and concatenatingdiagnostic.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/
.Important
If the
mongos
cannot create the specified directory, the diagnostic data capture is disabled for that instance. This is often caused by:a file with the same name already exists in the path, or
the process does not have permissions to create the directory.
diagnosticDataCollectionDirectorySizeMB
Increased default size to 200 megabytes.
Available for both
mongod
andmongos
.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
is10
megabytes.diagnosticDataCollectionDirectorySizeMB
must be greater than maximum diagnostic file sizediagnosticDataCollectionFileSizeMB
.
diagnosticDataCollectionFileSizeMB
Available for both
mongod
andmongos
.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
is1
megabyte.
diagnosticDataCollectionPeriodMillis
Available for both
mongod
andmongos
.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
is100
milliseconds.
Replication and Consistency![](/docs/v5.3/assets/link.svg)
disableSplitHorizonIPCheck
New in version 5.0.0.
Available for both
mongod
andmongos
.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
andmongos
.Type: boolean
Default: false
If
enableOverrideClusterChainingSetting
istrue
, replica set secondary members can replicate data from other secondary members even ifsettings.chainingAllowed
isfalse
.You can only set
enableOverrideClusterChainingSetting
at startup and cannot change this setting with thesetParameter
command.For example, to set the
enableOverrideClusterChainingSetting
for amongod
instance totrue
:mongod --setParameter enableOverrideClusterChainingSetting=true
logicalSessionRefreshMillis
Note
Availability
New in version 4.0.4 (and version 3.6.9).
Available for both
mongod
andmongos
.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 thesetParameter
command.For example, to set the
logicalSessionRefreshMillis
for amongod
instance to 10 minutes:mongod --setParameter logicalSessionRefreshMillis=600000
localLogicalSessionTimeoutMinutes
Available for both
mongod
andmongos
.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 thesetParameter
command.For example, to set the
localLogicalSessionTimeoutMinutes
for a testmongod
instance to 20 minutes:mongod --setParameter localLogicalSessionTimeoutMinutes=20
maxAcceptableLogicalClockDriftSecs
Available for both
mongod
andmongos
.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 thesetParameter
command.For example, to set the
maxAcceptableLogicalClockDriftSecs
for amongod
instance to 15 minutes:mongod --setParameter maxAcceptableLogicalClockDriftSecs=900
maxSessions
New in version 4.0.1.
Available for both
mongod
andmongos
.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 amongod
instance to 1000:mongod --setParameter maxSessions=1000
storeFindAndModifyImagesInSideCollection
New in version 5.1.
Available for both
mongod
andmongos
.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 totrue
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
istrue
.For example, to set
storeFindAndModifyImagesInSideCollection
tofalse
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 thesetParameter
command.For example, to set the
TransactionRecordMinimumLifetimeMinutes
for amongod
instance to 20 minutes:mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20 Tip
See also:
enableFlowControl
New in version 4.2.
Type: boolean
Default: true
Enables or disables the mechanism that controls the rate at which the primary applies its writes with the goal of keeping the secondary members'
majority committed
lag under a configurable maximum value.Note
For flow control to engage, the replica set/sharded cluster must have: featureCompatibilityVersion (FCV) of
4.2
and read concernmajority enabled
. That is, enabled flow control has no effect if FCV is not4.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 themajority 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:
primaryPreferred
(Default for voting replica set members)nearest
(Default for newly added or non-voting replica set members)
If the replica set has disabled
chaining
, the defaultinitialSyncSourceReadPreference
read preference mode isprimary
.You cannot specify a tag set or
maxStalenessSeconds
toinitialSyncSourceReadPreference
.If the
mongod
cannot find a sync source based on the specified read preference, it logs an error and restarts the initial sync process. Themongod
exits with an error if it cannot complete the initial sync process after10
attempts. For more information on sync source selection, see Initial Sync Source Selection.initialSyncSourceReadPreference
takes precedence over the replica set'ssettings.chainingAllowed
setting when selecting an initial sync source. After a replica set member successfully completes initial sync, it defers to the value ofchainingAllowed
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
Method used for initial sync.
Set to
logical
to use logical initial sync. Set tofileCopyBased
to use file copy based initial sync.You can only set this parameter on startup, using either the
setParameter
configuration file setting or the--setParameter
command line option.Note
Available only in MongoDB Enterprise.
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. You can only set
replWriterThreadCount
at startup and cannot change this setting with thesetParameter
command.Tip
See also:
replWriterMinThreadCount
New in version 5.0.
Type: integer
Default: 0
Available for
mongod
only.Minimum number of threads to use to apply replicated operations in parallel. Values can range from 0 to 256 inclusive. You can only set
replWriterMinThreadCount
at startup and cannot change this setting with thesetParameter
command.Parallel application of replication operations uses up to
replWriterThreadCount
threads. IfreplWriterMinThreadCount
is configured with a value less thanreplWriterThreadCount
, the thread pool will timeout idle threads until the total count of threads in the thread pool is equal toreplWriterMinThreadCount
.replWriterMinThreadCount
must be configured with a value that is less than or equal toreplWriterThreadCount
.
rollbackTimeLimitSecs
Type: 64-bit integer
Default: 86400 (1 day)
Maximum age of data that can be rolled back. Negative values for this parameter are not valid.
Starting in MongoDB 4.2+ and 4.0.13+, if the time between the end of the to-be-rolledback instance's oplog and the first operation after the common point (the last point where the source node and the to-be-rolledback node had the same data) exceeds this value, the rollback will fail.
In MongoDB 4.0.0-4.0.12, if the time between the end of the to-be-rolledback instance's oplog and the common point (the last point where the source node and the to-be-rolledback node had the same data) exceeds this value, the rollback will fail.
To effectively have an unlimited rollback period, set the value to
2147483647
which is the maximum value allowed and equivalent to roughly 68 years.New in version 4.0.
waitForSecondaryBeforeNoopWriteMS
Available for
mongod
only.Type: integer
Default: 10
The length of time (in milliseconds) that a secondary must wait if the
afterClusterTime
is greater than the last applied time from the oplog. After thewaitForSecondaryBeforeNoopWriteMS
passes, if theafterClusterTime
is still greater than the last applied time, the secondary makes a no-op write to advance the last applied time.The following example sets the
waitForSecondaryBeforeNoopWriteMS
to 20 milliseconds:mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20 During runtime, you can also set the parameter with the
setParameter
command: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 a rollback.
By default,
createRollbackDataFiles
istrue
and MongoDB creates the rollback files.The following example sets
createRollbackDataFiles
to false so that the rollback files are not created:mongod --setParameter createRollbackDataFiles=false During runtime, you can also set the parameter with the
setParameter
command: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 down from either the
rs.stepDown()
method or thereplSetStepDown
command.If the flag is true, when a primary steps down after
rs.stepDown()
(or thereplSetStepDown
command without theforce: true
), the primary nominates an eligible secondary to call an election immediately.If the flag is false, after the step down, secondaries can wait up to
settings.electionTimeoutMillis
before calling an election.An eligible secondary must be caught up with the stepped down primary and have
priority
greater than 0. If multiple secondary members meet this criteria, the stepped down primary selects the eligible secondary with the highestpriority
. If the more than one eligible secondary members have the samepriority
, the stepped down primary selects the secondary with the lowest_id
. The stepped down primary does not wait for the effects of the handoff.The parameter has no impact if the primary steps down for reasons other than
rs.stepDown()
(or thereplSetStepDown
command without theforce: 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
replBatchLimitBytes
to 64 MB so that the rollback files are not created:mongod --setParameter replBatchLimitBytes=67108864 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, replBatchLimitBytes: 64 * 1024 * 1024 } ) New in version 4.0.10.
mirrorReads
Available for
mongod
only.New in version 4.4
Type: Document
Default:
{ samplingRate: 0.01, maxTimeMS: 1000 }
Specifies the settings for mirrored reads for the
mongod
instance. The settings only take effect when the member is a primary.The parameter
mirrorReads
takes a JSON document with the following fields:FieldDescriptionsamplingRate
The sampling rate used to mirror a subset of operations that support mirroring to a subset of electable (specifically,
priority greater than 0
) secondaries. That is, the primary mirrors reads to each electable secondary at the specified sampling rate.Valid values are:
0.0
Turns off mirroring.1.0
The primary mirrors all operations that supports mirroring to each electable secondary.Number between0.0
and1.0
(exclusive)The primary randomly samples each electable secondary at the specified rate to be sent mirrored reads.For example, given a replica set with a primary and two electable secondaries and a sampling rate of
0.10
, the primary mirrors reads to each electable secondary at the sampling rate of 10 percent such that one read may be mirrored to one secondary and not to the other or to both or to neither. That is, if the primary receives100
operations that can be mirrored, the sampling rate of0.10
may result in8
reads being mirrored to one secondary and13
reads to the other or10
to each, etc.The default value is
0.01
.maxTimeMS
The maximum time in milliseconds for the mirrored reads. The default value is
1000
.The
maxTimeMS
for the mirrored reads is separate from themaxTimeMS
of the original read being mirrored.You can set
mirrorReads
during startup in theconfiguration file
or with the--setParameter
option on the command line. If specifying from the configuration file or on the command line, enclose themirrorReads
document in quotes.For example, the following sets the mirror reads sampling rate to
0.10
from the command line:mongod --setParameter mirrorReads='{ samplingRate: 0.10 }' Or, to specify in a configuration file:
setParameter: mirrorReads: '{samplingRate: 0.10}' Or if using the
setParameter
command in amongosh
session that is connected to a runningmongod
, do not enclose the document in quotes:db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )
allowMultipleArbiters
Available for
mongod
only.New in version 5.3.
Type: boolean
Default: false
Specifies whether the replica set allows the use of multiple arbiters.
The use of multiple arbiters is not recommended:
Multiple arbiters prevent the reliable use of the majority write concern. MongoDB counts arbiters in calculating a membership majority, but arbiters do not store data. With the inclusion of multiple arbiters, it's possible for a majority write operation to return success before the write replicates to a majority of data bearing nodes.
Multiple arbiters allow replica sets to accept writes even when the replica set doesn't have sufficient secondaries for data replication.
For more information, see Concerns with Multiple Arbiters.
The parameter can only be set during startup:
mongod --setParameter allowMultipleArbiters=true
Sharding Parameters![](/docs/v5.3/assets/link.svg)
Note
Starting in version 4.2, MongoDB removes the parameter
AsyncRequestsSenderUseBaton
and always enables the performance
enhancement controlled by the parameter.
chunkDefragmentationThrottlingMS
New in version 5.3.
Type: integer
Default: 0
Available for both
mongod
andmongos
.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
to10
milliseconds:mongod --setParameter chunkDefragmentationThrottlingMS=10 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )
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 chunk`ranges containing :term:`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 tofalse
. This shard can continue to receive chunks from other shards as long as it does not have a pending range deletion task in theconfig.rangeDeletions
collection that overlaps with the incoming chunk's range.When
disableResumableRangeDeleter
istrue
, 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 totrue
, 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 (and 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
tofalse
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
See also:
shardedIndexConsistencyCheckIntervalMS
parametershardedIndexConsistency
metrics returned by theserverStatus
command.
shardedIndexConsistencyCheckIntervalMS
New in version 4.4 (and 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
See also:
enableShardedIndexConsistencyCheck
parametershardedIndexConsistency
metrics returned by theserverStatus
commandq
enableFinerGrainedCatalogCacheRefresh
New in version 4.4.
Type: boolean
Default: true
Available for both
mongod
andmongos
.This parameter allows the catalog cache to be refreshed only if the shard needs to be refreshed. If disabled, any stale chunk will cause the entire chunk distribution for a collection to be considered stale and force all routers who contact the shard to refresh their shard catalog cache.
You can only set this parameter during start-up and cannot change this setting using the
setParameter
database command.mongod --setParameter enableFinerGrainedCatalogCacheRefresh=true mongos --setParameter enableFinerGrainedCatalogCacheRefresh=true Tip
See also:
maxTimeMSForHedgedReads
New in version 4.4.
Type: integer
Default: 150
Available for
mongos
only.Specifies the maximum time limit (in milliseconds) for the hedged read. That is, the additional read sent to hedge the read operation uses the
maxTimeMS
value ofmaxTimeMSForHedgedReads
while the read operation that is being hedged uses themaxTimeMS
value specified for the operation.For example, to set the limit to 200 milliseconds, you can issue the following during startup:
mongos --setParameter maxTimeMSForHedgedReads=200 Or if using the
setParameter
command in amongosh
session that is connected to a runningmongos
:db.adminCommand( { setParameter: 1, maxTimeMSForHedgedReads: 200 } ) Tip
See also:
maxCatchUpPercentageBeforeBlockingWrites
New in version 5.0: (Also available starting in 4.4.7, 4.2.15, 4.0.26)
Type: integer
Default: 10
Available for
mongod
only.For
moveChunk
operations, specifies the maximum percentage of untrasferred data allowed by the migration protocol (expressed in percentage of the total chunk size) to transition from thecatchup
phase to thecommit
phase.Setting a higher catchup percentage can decrease the amount of time it takes for the migration to complete at the cost of increased latency during concurrent
upsert
anddelete
operations.For example, to set the maximum percentage to 20, you can issue the followingduring startup:
mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20 You cannot change
maxCatchUpPercentageBeforeBlockingWrites
during runtime.Tip
See also:
metadataRefreshInTransactionMaxWaitBehindCritSecMS
New in version 5.2: (Also available starting in 5.1.0, 5.0.4)
Type: integer
Default: 500
Available for
mongod
only.Limits the time a shard waits for a critical section within a transaction.
When a query accesses a shard, a chunk migration or DDL operation may already hold the critical section for the collection. If the query finds the critical section is taken, the shard waits until the critical section has been released. When the shard returns control to
mongos
,mongos
retries the query. However, if a multi-shard transaction interacts with an operation that takes the critical section on multiple shards, the interaction can result in a distributed deadlock.metadataRefreshInTransactionMaxWaitBehindCritSecMS
limits the maximum time a shard waits within a transaction for the critical section to be released.To reduce the maximum wait time for the critical section within a transaction, lower the the value of
metadataRefreshInTransactionMaxWaitBehindCritSecMS
.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:
ValueDescriptionon
Themongos
instance supports hedged reads for read operations whose read preference have enabled the hedged read option.off
Themongos
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 amongosh
session that is connected to a runningmongos
:db.adminCommand( { setParameter: 1, readHedgingMode: "off" } ) Tip
See also:
shutdownTimeoutMillisForSignaledShutdown
New in version 5.0.
Type: integer
Default: 15000
Available for
mongod
only.Specifies the time (in milliseconds) to wait for any ongoing database operations to complete before initiating a shutdown of
mongod
in response to aSIGTERM
signal.For example, to set the time to 250 milliseconds, you can issue the following during startup:
mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250 Or if using the
setParameter
command in amongosh
session that is connected to a runningmongod
:db.adminCommand( { setParameter: 1, shutdownTimeoutMillisForSignaledShutdown: 250 } )
mongosShutdownTimeoutMillisForSignaledShutdown
New in version 5.0.
Type: integer
Default: 15000
Available for
mongos
only.Specifies the time (in milliseconds) to wait for any ongoing database operations to complete before initiating a shutdown of
mongos
in response to aSIGTERM
signal.For example, to set the time to 250 milliseconds, you can issue the following during startup:
mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250 Or if using the
setParameter
command in amongosh
session that is connected to a runningmongos
:db.adminCommand( { setParameter: 1, mongosShutdownTimeoutMillisForSignaledShutdown: 250 } )
replMonitorMaxFailedChecks
Available in MongoDB 3.2 only
Type: integer
Default: 30
The number of times the
mongod
ormongos
instance tries to reach the replica sets in the sharded cluster (for example, shard replica sets, config server replica set) to monitor the replica set status and topology.When the number of consecutive unsuccessful attempts exceeds this parameter value, the
mongod
ormongos
instance denotes the monitored replica set as unavailable. If the monitored replica set is the config server replica set:For MongoDB 3.2.0-3.2.9, the monitoring
mongod
ormongos
instance will become unusable and needs to be restarted. See the v3.2 troubleshooting guide for more details.For MongoDB 3.2.10 and later 3.2-series, see also
timeOutMonitoringReplicaSets
.
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 the monitored replica set after unsuccessfully tryingreplMonitorMaxFailedChecks
number of times.If the monitored replica set is the config server replica set and
timeOutMonitoringReplicaSets
is set totrue
, you must restartmongod
ormongos
if themongod
ormongos
instance cannot reach any of the config servers for the specified number of times. See the v3.2 troubleshooting guide for more details.
ShardingTaskExecutorPoolHostTimeoutMS
Type: integer
Default: 300000 (5 minutes)
Available for both
mongod
andmongos
.Maximum time that
mongos
goes without communication to a host beforemongos
drops all connections to the host.If set,
ShardingTaskExecutorPoolHostTimeoutMS
should be greater than the sum ofShardingTaskExecutorPoolRefreshRequirementMS
andShardingTaskExecutorPoolRefreshTimeoutMS
. Otherwise,mongos
adjusts the value ofShardingTaskExecutorPoolHostTimeoutMS
to be greater than the sum.The following example sets
ShardingTaskExecutorPoolHostTimeoutMS
to120000
during startup:mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolHostTimeoutMS: 120000 } )
ShardingTaskExecutorPoolMaxConnecting
Type: integer
Default: 2
Available for both
mongod
andmongos
.Maximum number of simultaneous initiating connections (including pending connections in setup/refresh state) each TaskExecutor connection pool can have to a
mongod
instance. You can set this parameter to control the rate at whichmongos
adds connections to amongod
instance.If set,
ShardingTaskExecutorPoolMaxConnecting
should be less than or equal toShardingTaskExecutorPoolMaxSize
. If it is greater,mongos
ignores theShardingTaskExecutorPoolMaxConnecting
value.The following example sets
ShardingTaskExecutorPoolMaxConnecting
to20
during startup:mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMaxConnecting: 20 } )
ShardingTaskExecutorPoolMaxSize
Type: integer
Default: 2 64 - 1
Available for both
mongod
andmongos
.Maximum number of outbound connections each TaskExecutor connection pool can open to any given
mongod
instance. The maximum possible connections to any given host across all TaskExecutor pools is:ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize The following example sets
ShardingTaskExecutorPoolMaxSize
to20
during startup:mongos --setParameter ShardingTaskExecutorPoolMaxSize=20 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMaxSize: 20 } ) mongos
can have up ton
TaskExecutor connection pools, wheren
is the number of cores. SeetaskExecutorPoolSize
.Tip
See also:
ShardingTaskExecutorPoolMinSize
Type: integer
Default: 1
Available for both
mongod
andmongos
.Minimum number of outbound connections each TaskExecutor connection pool can open to any given
mongod
instance.ShardingTaskExecutorPoolMinSize
connections are created the first time a connection to a new host is requested from the pool. While the pool is idle, the pool maintains this number of connections untilShardingTaskExecutorPoolHostTimeoutMS
milliseconds pass without any application using that pool.For a
mongos
using thewarmMinConnectionsInShardingTaskExecutorPoolOnStartup
parameter, theShardingTaskExecutorPoolMinSize
parameter also controls how many connections to each shard host are established on startup of themongos
instance before it begins accepting incoming client connections.Note
In MongoDB 4.4, the
warmMinConnectionsInShardingTaskExecutorPoolOnStartup
parameter is enabled by default for themongos
.The following example sets
ShardingTaskExecutorPoolMinSize
to2
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 ton
TaskExecutor connection pools, wheren
is the number of cores. SeetaskExecutorPoolSize
.
ShardingTaskExecutorPoolRefreshRequirementMS
Type: integer
Default: 60000 (1 minute)
Available for both
mongod
andmongos
.Maximum time the
mongos
waits before attempting to heartbeat a resting connection in the pool.If set,
ShardingTaskExecutorPoolRefreshRequirementMS
should be greater thanShardingTaskExecutorPoolRefreshTimeoutMS
. Otherwise,mongos
adjusts the value ofShardingTaskExecutorPoolRefreshTimeoutMS
to be less thanShardingTaskExecutorPoolRefreshRequirementMS
.The following example sets
ShardingTaskExecutorPoolRefreshRequirementMS
to90000
during startup:mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshRequirementMS: 90000 } )
ShardingTaskExecutorPoolRefreshTimeoutMS
Type: integer
Default: 20000 (20 seconds)
Available for both
mongod
andmongos
.Maximum time the
mongos
waits for a heartbeat before timing out the heartbeat.If set,
ShardingTaskExecutorPoolRefreshTimeoutMS
should be less thanShardingTaskExecutorPoolRefreshRequirementMS
. Otherwise,mongos
adjusts the value ofShardingTaskExecutorPoolRefreshTimeoutMS
to be less thanShardingTaskExecutorPoolRefreshRequirementMS
.The following example sets
ShardingTaskExecutorPoolRefreshTimeoutMS
to30000
during startup:mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000 During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshTimeoutMS: 30000 } )
ShardingTaskExecutorPoolReplicaSetMatching
New in version 4.2.
Changed in version 5.0: (Also starting in 4.4.5 and 4.2.13)
Type: string
Default: "automatic"
Available for both
mongod
andmongos
.On a
mongos
instance, this parameter sets the policy that determines the minimum size limit of its connection pools to nodes within replica sets.On a
mongod
instance, this parameter sets the policy that determines the minimum size limit of its connection pools to nodes within other replica sets.Note that this parameter only manages connections for operations that are directly related to user requests and CRUD operations.
Available values are:
Matching PolicyDescription"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"
, thereplicaSetMatchingStrategy
still describes the actual policy being used, not"automatic"
. To find the value of theShardingTaskExecutorPoolReplicaSetMatching
, usegetParameter
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 theShardingTaskExecutorPoolMinSize
.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 theShardingTaskExecutorPoolMinSize
.The following example sets the
ShardingTaskExecutorPoolReplicaSetMatching
to"automatic"
during startup:mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic" During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolReplicaSetMatching: "automatic" } )
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 given
mongos
.If the parameter value is
0
or less, the number of Task Executor connection pools is the number of cores with the following exceptions:If the number of cores is less than 4, the number of Task Executor connection pools is 4.
If the number of cores is greater than 64, the number of Task Executor connection pools is 64.
Starting in MongoDB 4.0, the default value of
taskExecutorPoolSize
is1
:In MongoDB 4.0 deployment, you can set
taskExecutorPoolSize
to0
and, on Linux, set AsyncRequestsSenderUseBaton tofalse
for the previous behavior.In MongoDB 4.2+ deployment, MongoDB removes the
AsyncRequestsSenderUseBaton
parameter and always enables the performance enhancement controlled by the parameter.
You can only set this parameter during start-up and cannot change this setting using the
setParameter
database command.mongos --setParameter taskExecutorPoolSize=6
loadRoutingTableOnStartup
New in version 4.4.
Type: boolean
Default: true
Available for
mongos
only.Configures a
mongos
instance to preload the routing table for a sharded cluster on startup. With this setting enabled, themongos
caches the cluster-wide routing table for each sharded collection as part of its startup procedure, before it begins accepting client connections.Without this setting enabled, the
mongos
only loads a routing table as needed for incoming client connections, and only loads the specific routing table for the namespace of a given request.A
mongos
instance with theloadRoutingTableOnStartup
parameter enabled may experience longer startup times, but will result in faster servicing of initial client connections once started.loadRoutingTableOnStartup
is enabled by default.You can only set this parameter on startup, using either the
setParameter
configuration file setting or the--setParameter
command line option.
warmMinConnectionsInShardingTaskExecutorPoolOnStartup
New in version 4.4.
Type: boolean
Default: true
Available for
mongos
only.Configures a
mongos
instance to prewarm its connection pool on startup. With this parameter enabled, themongos
attempts to establishShardingTaskExecutorPoolMinSize
network connections to each shard server as part of its startup procedure, before it begins accepting client connections.A timeout for this behavior can be configured with the
warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
parameter. If this timeout is reached, themongos
will begin accepting client connections regardless of the size of its connection pool.A
mongos
instance with this parameter enabled may experience longer startup times, but will result in faster servicing of initial client connections once started.warmMinConnectionsInShardingTaskExecutorPoolOnStartup
is enabled by default.You can only set this parameter on startup, using either the
setParameter
configuration file setting or the--setParameter
command line option.
warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
New in version 4.4.
Type: integer
Default: 2000 (2 seconds)
Available for
mongos
only.Sets the timeout threshold in milliseconds for a
mongos
to wait forShardingTaskExecutorPoolMinSize
connections to be established per shard host when using thewarmMinConnectionsInShardingTaskExecutorPoolOnStartup
parameter. If this timeout is reached, themongos
will begin accepting client connections regardless of the size of its connection pool.You can only set this parameter on startup, using either the
setParameter
configuration file setting or the--setParameter
command line option.
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 during cloning step of the migration process. This wait is in addition to the
secondaryThrottle
.The default value of
0
indicates no additional wait.The following sets the
migrateCloneInsertionBatchDelayMS
to 200 milliseconds:mongod --setParameter migrateCloneInsertionBatchDelayMS=200 The parameter may also be set using the
setParameter
command: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 during the cloning step of the migration process.
The default value of
0
indicates no maximum number of documents per batch. However, in practice, this results in batches that contain up to 16 MB of documents.The following sets the
migrateCloneInsertionBatchSize
to 100 documents:mongod --setParameter migrateCloneInsertionBatchSize=100 The parameter may also be set using the
setParameter
command:db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchSize: 100 } )
orphanCleanupDelaySecs
Default: 900 (15 minutes)
Available for
mongod
only.Minimum delay before a migrated chunk is deleted from the source shard.
Before deleting the chunk during chunk migration, MongoDB waits for
orphanCleanupDelaySecs
or for in-progress queries involving the chunk to complete on the shard primary, whichever is longer.However, because the shard primary has no knowledge of in-progress queries run on the shard secondaries, queries that use the chunk but are run on secondaries may see documents disappear if these queries take longer than the time to complete the shard primary queries and the
orphanCleanupDelaySecs
.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
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 of deletion during the cleanup stage of chunk migration (or the
cleanupOrphaned
command).In MongoDB 3.4, consider whether _secondaryThrottle is set before modifying the
rangeDeleterBatchDelayMS
. In MongoDB 3.4, the _secondaryThrottle replication delay occurs after each document deletion instead of after the batch deletion.In MongoDB 3.6+, 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
New in version 4.0.5.
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 chunk 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 themongod
.The parameter is also available for MongoDB versions:
MongoDB 3.2.19+
MongoDB 3.4.11+
findChunksOnConfigTimeoutMS
New in version 5.0.
Available for both
mongod
andmongos
.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![](/docs/v5.3/assets/link.svg)
activeFaultDurationSecs
Type: Document
Available for
mongos
only.The amount of time to wait from a 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 themongos
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 amongosh
session that is connected to a runningmongos
: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 thesetParameter
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 invalues
takes two fields:type
, the Health Manager facetintensity
, the intensity level
Health Managers
FacetWhat the Health Observer ChecksconfigServer
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 LevelDescriptioncritical
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 byactiveFaultDurationSecs
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 thecritical
intensity level, issue the following at startup:mongos --setParameter 'healthMonitoringIntensities={ values:[ { type:"dns", intensity: "critical"} ] }' Or if using the
setParameter
command in amongosh
session that is connected to a runningmongos
: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 thesetParameter
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 invalues
takes two fields:type
, the Health Manager facetinterval
, the time interval it runs at, in milliseconds
Health Managers
FacetWhat the Health Observer ChecksconfigServer
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 amongosh
session that is connected to a runningmongos
: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 thesetParameter
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 bydeadline
, Progress Monitor stops the mongos and removes it from the cluster.progressMonitor
FieldsFieldDescriptionUnitsinterval
How often to ensure Health Managers are not stuck or unresponsive.Millisecondsdeadline
Timeout before automatically failing the mongos if a Health Manager check is not making progress.SecondsTo set the
interval
to 1000 milliseconds and thedeadline
to 300 seconds, issue the following at startup:mongos --setParameter 'progressMonitor={"interval": 1000, "deadline": 300}' Or if using the
setParameter
command in amongosh
session that is connected to a runningmongos
: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 thesetParameter
option as in the following example:setParameter: progressMonitor: "{ interval: 1000, deadline: 300 }"
Storage Parameters![](/docs/v5.3/assets/link.svg)
honorSystemUmask
Available for
mongod
only.Default:
false
If
honorSystemUmask
is set totrue
, new files created by MongoDB have permissions in accordance with the user'sumask
settings. You cannot setprocessUmask
ifhonorSystemUmask
is set totrue
.If
honorSystemUmask
is set tofalse
, new files created by MongoDB have permissions set to600
, which gives read and write permissions only to the owner. New directories have permissions set to700
. You can useprocessUmask
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
and500
signifying the number of milliseconds (ms) between journal commits.Consider the following example which sets the
journalCommitInterval
to200
ms:db.adminCommand( { setParameter: 1, journalCommitInterval: 200 } ) Tip
See also:
minSnapshotHistoryWindowInSeconds
New in version 5.0.
Default:
300
Available for
mongod
only.The minimum time window in seconds for which the storage engine keeps the snapshot history. If you query data using read concern
"snapshot"
and specify an atClusterTime value older than the specifiedminSnapshotHistoryWindowInSeconds
,mongod
returns aSnapshotTooOld
error.Specify an integer greater than or equal to (
>=
) 0.Consider the following example which sets the
minSnapshotHistoryWindowInSeconds
to600
seconds:db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 600 } ) 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 tofalse
. By default, whenhonorSystemUmask
is set tofalse
, new files created by MongoDB have permissions set to600
. Use theprocessUmask
parameter to override this default with a customumask
value. The file owner inherits permissions from the systemumask
.You cannot set this parameter if
honorSystemUmask
is set totrue
. You can only set this parameter during start-up and cannot change this setting using thesetParameter
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
to60
seconds:db.adminCommand( { setParameter: 1, syncdelay: 60 } ) Tip
WiredTiger Parameters![](/docs/v5.3/assets/link.svg)
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 and 4.0.12-4.0.x. The file no longer exists starting in version 4.4.The parameter can accept the following values:
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.Available starting in MongoDB 4.2.1 (and 4.0.12)
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
See also:
wiredTigerConcurrentWriteTransactions
Available for
mongod
only.Available for the WiredTiger storage engine only.
Specify the maximum number of concurrent write transactions allowed into the WiredTiger storage engine.
db.adminCommand( { setParameter: 1, wiredTigerConcurrentWriteTransactions: <num> } ) Tip
See also:
wiredTigerEngineRuntimeConfig
Available for
mongod
only.Specify
wiredTiger
storage engine configuration options for a runningmongod
instance. You can only set this parameter using thesetParameter
command and not using the command line or configuration file option.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![](/docs/v5.3/assets/link.svg)
auditAuthorizationSuccess
Type: boolean
Default: false
Note
Available only in MongoDB Enterprise and MongoDB Atlas.
Available for both
mongod
andmongos
.Enables the auditing of authorization successes for the authCheck action.
When
auditAuthorizationSuccess
isfalse
, the audit system only logs the authorization failures forauthCheck
.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 themongod
ormongos
configuration file. The server will fail to start if the parameter is present.Tip
See also:
auditConfigPollingFrequencySecs
New in version 5.0.
Type: integer
Default: 300
A sharded cluster may have servers which maintain audit configuration settings for the cluster. Set the interval, in seconds, for non-configured servers to poll a config server for the current audit generation. If this value returned differs from the previously known value, the initiating node will request the current configuration and update its internal state.
Note
Using the default value of 300 seconds, non-config nodes may lag up to 5 minutes behind a setAuditConfig command.
Transaction Parameters![](/docs/v5.3/assets/link.svg)
coordinateCommitReturnImmediatelyAfterPersistingDecision
New in version 5.0.
Type: boolean
Default: true
Available for
mongod
only.If
true
, the shard transaction coordinator returns a multi-document transaction commit decision to the client as soon as the commit 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.If
false
, the shard transaction coordinator waits for all members to acknowledge a multi-document transaction commit before returning the commit decision to the client.The following example sets
coordinateCommitReturnImmediatelyAfterPersistingDecision
tofalse
:mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=false During runtime, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, coordinateCommitReturnImmediatelyAfterPersistingDecision: false } )
transactionLifetimeLimitSeconds
New in version 4.0.
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
to30
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 changetransactionLifetimeLimitSeconds
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.
maxTransactionLockRequestTimeoutMillis
New in version 4.0.
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 within5
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
to20
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![](/docs/v5.3/assets/link.svg)
planCacheSize
New in version 5.1.
Type: string
Default: 5%
Available for
mongod
only.Sets the size of the plan cache 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
orGB
. 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" } )