MongoDB Server Parameters for a Self-Managed Deployment
On this page
Note
Starting in MongoDB 8.0, LDAP authentication and authorization is deprecated. LDAP is available and will continue to operate without changes throughout the lifetime of MongoDB 8. LDAP will be removed in a future major release.
For details, see LDAP Deprecation.
Synopsis
MongoDB provides a number of configuration options that you can set using:
the
setParameter
command:db.adminCommand( { setParameter: 1, <parameter>: <value> } ) the
setParameter
configuration setting:setParameter: <parameter1>: <value1> ... the
--setParameter
command-line option formongod
andmongos
:mongod --setParameter <parameter>=<value> mongos --setParameter <parameter>=<value>
For additional configuration options, see
Self-Managed Configuration File Options, mongod
and
mongos
.
Parameters
Authentication Parameters
authenticationMechanisms
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 on Self-Managed Deployments.
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.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.OpenID Connect is an authentication layer built on top of OAuth2. This mechanism is available only in MongoDB Enterprise.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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
awsSTSRetryCount
Changed in version 7.0: (Also starting in 6.0.7 and 5.0.18)
In previous versions, AWS IAM authentication retried only when the server returned an HTTP 500 error.
Available for both
mongod
andmongos
.Type: integer
Default: 2
For MongoDB deployments using AWS IAM credentials or AWS IAM environment variables.
Maximum number of AWS IAM authentication retries after a connection failure.
The following example sets
awsSTSRetryCount
to15
retries:mongod --setParameter awsSTSRetryCount=15 Alternatively, the following examples uses the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, awsSTSRetryCount: 15 } )
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 .This parameter is only available at runtime. To set the parameter, use the
setParameter
command.db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )
enableLocalhostAuthBypass
Available for both
mongod
andmongos
.Default:
true
Specify
0
orfalse
to disable localhost authentication bypass. Enabled by default.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.See Localhost Exception in Self-Managed Deployments for more information.
enforceUserClusterSeparation
Available for both
mongod
andmongos
.Set to
false
to disable theO/OU/DC
check whenclusterAuthMode
iskeyFile
in your configuration file. This allows clients possessing member certificates to authenticate as users stored in the$external
database. The server won't start ifclusterAuthMode
isn'tkeyFile
in your configuration file.To set the
enforceUserClusterSeparation
parameter tofalse
, run the following command during startup:mongod --setParameter enforceUserClusterSeparation=false If you set the
enforceUserClusterSeparation
parameter tofalse
, the server doesn't distinguish between client certificates, which applications use to authenticate, and intra-cluster certificates, which have privileged access. This has no effect if yourclusterAuthMode
iskeyFile
. However, if yourclusterAuthMode
isx509
, user certificates that use the allowed scheme are conflated with cluster certificates and granted privileged access.Your existing certificates are granted internal privileges if you do the following:
Create a user, with a name allowed by this parameter.
Set the
enforceUserClusterSeparation
parameter tofalse
.Set
clusterAuthMode
tox509
.
You must not upgrade from
keyFile
tox509
without validating that you've removed users with elevated privileges that theenforceUserClusterSeparation
flag allowed you to create.
KeysRotationIntervalSec
Available for both
mongod
andmongos
.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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
ldapForceMultiThreadMode
Available for
mongod
only.Default: false
Enables the performance of concurrent LDAP operations.
Note
Only if you are certain that your instance of
libldap
is safe to use in this mode, enable this flag. You may experience crashes of the MongoDB process if thelibldap
version you are using is not thread safe.You must use
ldapForceMultiThreadMode
to use LDAP connection pool. To enable LDAP connection pool, setldapForceMultiThreadMode
andldapUseConnectionPool
totrue
.Tip
If you have any concerns regarding your MongoDB version, OS version or libldap version, please contact MongoDB Support.
ldapQueryPassword
Available for
mongod
only.Type: string
The password used to bind to an LDAP server. You must use
ldapQueryUser
with this parameter.If not set, mongod or mongos does not attempt to bind to the LDAP server.
ldapQueryUser
Available for
mongod
only.Type: string
The user that binds to an LDAP server. You must use
ldapQueryPassword
with this parameter.If not set, mongod or mongos does not attempt to bind to the LDAP server.
ldapRetryCount
New in version 6.1.
Available for
mongod
only.Type: integer
Default: 0
For MongoDB deployments using LDAP Authorization on Self-Managed Deployments.
Number of operation retries by the server LDAP manager after a network error.
For example, the following sets
ldapRetryCount
to3
seconds:mongod --ldapRetryCount=3 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, ldapRetryCount: 3 } )
ldapUserCacheInvalidationInterval
Changed in version 5.2.
Available for
mongod
only.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 on Self-Managed Deployments.
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 on Self-Managed Deployments.
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 on Self-Managed Deployments.
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 unable to authenticate new sessions for LDAP users until
mongod
connects to the LDAP server and authorizes the LDAP user.Authorizes any existing sessions that use previously authenticated LDAP users if
mongod
is unable to connect to the LDAP server. Whenmongod
reconnects to the LDAP server,mongod
ensures the LDAP users are correctly authorized.
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
Available for
mongod
only.Specifies whether MongoDB should use connection pooling when connecting to the LDAP server for authentication/authorization.
MongoDB uses the following default values:
true on Windows.
true on Linux where MongoDB Enterprise binaries are linked against
libldap_r
.false on Linux where MongoDB Enterprise binaries are linked against
libldap
.
You can only set
ldapUseConnectionPool
during start-up, and cannot change this setting with thesetParameter
database command.
ldapConnectionPoolUseLatencyForHostPriority
Available for
mongod
only.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 run time with thesetParameter
database command.
ldapConnectionPoolMinimumConnectionsPerHost
Available for
mongod
only.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 run time with thesetParameter
database command.
ldapConnectionPoolMaximumConnectionsPerHost
Available for
mongod
only.Changed starting in MongoDB versions 5.0.9 and 6.0.0 Changed default value to
2147483647
. In previous versions, the default is unset.Default: 2147483647
The maximum number of connections to keep open to each LDAP server.
You can only set
ldapConnectionPoolMaximumConnectionsPerHost
during start-up, and cannot change this setting during run time with thesetParameter
database command.
ldapConnectionPoolMaximumConnectionsInProgressPerHost
Available for
mongod
only.Changed starting in MongoDB versions 5.0.9 and 6.0.0 Changed default value to
2
. In previous versions, the default is unset.Default: 2
The maximum number of in-progress connect operations to each LDAP server.
You can only set
ldapConnectionPoolMaximumConnectionsInProgressPerHost
during start-up, and cannot change this setting with thesetParameter
database command.
ldapConnectionPoolHostRefreshIntervalMillis
Available for
mongod
only.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
Available for
mongod
only.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 on Self-Managed Deployments.
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
Available for
mongod
only.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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
oidcIdentityProviders
Available for
mongod
only.Changed in version 8.0: (Also available in 7.3 and 7.0)
Use this parameter to specify identity provider (IDP) configurations when using OpenID Connect Authentication.
oidcIdentityProviders
accepts an array of zero or more identity provider (IDP) configurations. An empty array (default) indicates no OpenID Connect support is enabled.When more than one IDP is defined,
oidcIdentityProviders
uses thematchPattern
field to select an IDP. Array order determines the priority and the first IDP is always selected.Starting in MongoDB 8.0, when multiple identity providers (IDP) are defined, the
oidcIdentityProviders
parameter accepts duplicateissuer
values as long as theaudience
value is unique for each issuer. This is also available in versions 7.3 and 7.0.oidcIdentityProviders Fields
FieldNecessityTypeDescriptionissuer
RequiredstringThe issuer URI of the IDP that the server should accept tokens from. This must match the
iss
field in any JWT used for authentication.Starting in MongoDB 8.0, when multiple identity providers (IDP) are defined, the
oidcIdentityProviders
parameter accepts duplicateissuer
values as long as theaudience
value is unique for each issuer. This is also available in versions 7.3 and 7.0.If you specify an unreachable issuer URI, MongoDB:
Logs a warning.
Continues server startup, which allows you to update the issuer URI.
Reattempts issuer contact. If MongoDB reaches the issuer URI and validates the access token, authentication succeeds. If the issuer URI remains unreachable, authentication fails.
Changed in version 8.0: (Also available in 7.3 and 7.0)
authNamePrefix
RequiredstringUnique prefix applied to each generated
UserName
andRoleName
used in authorization.authNamePrefix
can only contain the following characters:alphanumeric characters (combination of
a
toz
and0
to9
)hyphens (
-
)underscores (
_
)
matchPattern
ConditionalstringRegex pattern used to determine which IDP should be used.
matchPattern
matches against usernames. Array order determines the priority and the first IDP is always selected.matchPattern
is required in some configurations, depending on how the user setssupportsHumanFlows
:When only one IdP has
supportsHumanFlows
set totrue
(the default),matchPatterns
is optional.When multiple IdP's have
supportsHumanFlows
set totrue
(the default), each of these requiresmatchPatterns
.matchPatterns
is optional for any IdP wheresupportsHumanFlows
is set tofalse
.
This is not a security mechanism.
matchPattern
serves only as an advisory to clients. MongoDB accepts tokens issued by the IDP whose principal names do not match this pattern.clientId
ConditionalstringID provided by the IDP to identify the client that receives the access tokens.
Required when
supportsHumanFlows
is set totrue
(the default).audience
RequiredstringSpecifies the application or service that the access token is intended for.
Starting in MongoDB 7.0, only one
audience
oidcIdentityProviders field can be specified for OIDC access tokens.audience
fields with empty arrays or arrays of multiple strings are invalid.When more than one IDP is defined, this must be a unique value for each configuration that shares an
issuer
.requestScopes
Optionalarray[ string ]Permissions and access levels that MongoDB requests from the IDP.principalName
OptionalstringThe claim to be extracted from the access token containing MongoDB user identifiers.
The default value is
sub
(stands forsubject
).useAuthorizationClaim
OptionalbooleanDetermines if the
authorizationClaim
is required. The default value istrue
.If the
useAuthorizationClaim
field is set totrue
, the server requires anauthorizationClaim
for the identity provider's config. This is the default behavior.If the
useAuthorizationClaim
field is set tofalse
, theauthorizationClaim
field is optional (and ignored if provided). Instead, the server does the following:Searches the token for a claim whose name is listed in the
principalNameClaim
field. This is typically namedsub
. For example:sub: "spencer.jackson@example.com"
Constructs the internal username by concatenating the
authNamePrefix
, a forward slash (/
), and the contents of the claim identified byprincipalNameClaim
within the access token. For example, with aauthNamePrefix
field value of "mdbinc", the internal username is:mdbinc/spencer.jackson@example.com
Looks for the user with this username and authorizes the client with the roles:
{ user: "mdbinc/spencer.jackson@example.com", db: "$external" }
New in version 7.2: (Also available in 7.0.5)
authorizationClaim
ConditionalstringRequired, unless
useAuthorizationClaim
is set tofalse
.Claim extracted from access token that contains MongoDB role names.
logClaims
Optionalarray[ string ]List of access token claims to include in log and audit messages upon authentication completion.JWKSPollSecs
OptionalintegerFrequency, in seconds, to request an updated JSON Web Key Set (JWKS) from the IDP. A setting of 0 disables polling.
When more than one IDP is defined, this must be the same value for each configuration that shares an
issuer
.supportsHumanFlows
OptionalboolWhether the OIDC provider supports human or machine workflows. This affects the
clientId
andmatchPattern
fields.You may find it useful to set this field to
false
with machine workload IdP's to allow them to omit theclientId
when it's unneeded.Default:
true
.New in version 7.2.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
ocspEnabled
Available for both
mongod
andmongos
.Available on Linux and macOS.
Default: true
The flag that enables or disables OCSP.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, the following disables OCSP:
mongod --setParameter ocspEnabled=false ... Starting in MongoDB 6.0, if
ocspEnabled
is set totrue
during initial sync, all nodes must be able to reach the OCSP responder.If a member fails in the
STARTUP2
state, settlsOCSPVerifyTimeoutSecs
to a value that is less than5
.
ocspValidationRefreshPeriodSecs
Available for both
mongod
andmongos
.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 for both
mongod
andmongos
.Available on Linux only
With the use of native TLS/SSL libraries, the parameter
opensslCipherConfig
is supported for Linux/BSD and no longer supported in Windows and macOS.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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.The use of
TLS
options is preferred overSSL
options. The TLS options have the same functionality as theSSL
options. The following example configures amongod
with aopensslCipherConfig
cipher string of'HIGH:!EXPORT:!aNULL@STRENGTH'
:mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem
opensslCipherSuiteConfig
Available for both
mongod
andmongos
.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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, the following configures a
mongod
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 for both
mongod
andmongos
.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
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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
Available for both
mongod
andmongos
.Note
Available only in MongoDB Enterprise (except MongoDB Enterprise for Windows).
Specify the path to the Unix Domain Socket of the
saslauthd
instance to use for proxy authentication.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.saslServiceName
is only available in MongoDB Enterprise.Important
Ensure that your driver supports alternate service names.
scramIterationCount
Available for both
mongod
andmongos
.Default:
10000
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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
Available for both
mongod
andmongos
.Default:
15000
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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 .This parameter is only available at runtime. To set the parameter, use the
setParameter
command.db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } )
tlsMode
Available for both
mongod
andmongos
.Set to either:
preferTLS
requireTLS
The
tlsMode
parameter is useful during rolling upgrade to TLS/SSL to minimize downtime.This parameter is only available at runtime. To set the parameter, use the
setParameter
command.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 .
tlsClusterAuthX509Override
Available for both
mongod
andmongos
.New in version 7.0.
Overrides the
clusterAuthX509
configuration options.setParameter: tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB Server } The parameter supports
attributes
andextensionValue
overrides.When the server authenticates connections from members, it analyzes the X.509 certificate to determine whether it belongs to a cluster member. If the server uses the
attributes
setting or theattributes
field on thetlsClusterAuthX509Override
parameter, it checks the Distinguished Name (DN) values of the certificate. If theextensionValue
setting or theextensionValue
field of thetlsClusterAuthX509Override
parameter is set, it checks the extension values of the certificate. If it finds a match, it authorizes the connection as a peer.Use this parameter to rotate certificates when the new certificates have different attributes or extension values.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
tlsOCSPStaplingTimeoutSecs
Available for both
mongod
andmongos
.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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, the following sets the
tlsOCSPStaplingTimeoutSecs
to 20 seconds:mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...
tlsOCSPVerifyTimeoutSecs
Available for both
mongod
andmongos
.Available for Linux and Windows.
Default: 5
The maximum number of seconds that the
mongod
/mongos
should wait for the OCSP response when verifying server certificates.Specify an integer greater than or equal to (
>=
) 1.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, the following sets the
tlsOCSPVerifyTimeoutSecs
to 20 seconds:mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...
tlsUseSystemCA
Available for
mongod
only.Type: boolean
Default: false
Specifies whether MongoDB loads TLS certificates that are already available to the operating system's certificate authority.
Important
When starting a
mongod
instance with TLS/SSL enabled, you must specify a value for the--tlsCAFile
flag, thenet.tls.CAFile
configuration option, or thetlsUseSystemCA
parameter.--tlsCAFile
,tls.CAFile
, andtlsUseSystemCA
are all mutually exclusive.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, to set
tlsUseSystemCA
totrue
:mongod --setParameter tlsUseSystemCA=true For more information about TLS/SSL and MongoDB, see Configure
mongod
andmongos
for TLS/SSL and TLS/SSL Configuration for Clients .
tlsWithholdClientCertificate
Available for both
mongod
andmongos
.Default: false
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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
tlsX509ClusterAuthDNOverride
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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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 Certificates that Contain New DN on Self-Managed Clusters.For more information about membership certificate requirements, see Member Certificate Requirements for details.
tlsX509ExpirationWarningThresholdDays
Available for both
mongod
andmongos
.Default : 30
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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For more information on x.509 certificate validity, see RFC 5280 4.1.2.5.
userCacheInvalidationIntervalSecs
Available for
mongos
only.Default: 30
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).This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
authFailedDelayMs
Available for both
mongod
andmongos
.Default: 0
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
Available for both
mongod
andmongos
.Default: true
A boolean flag that allows or disallows the retrieval of authorization roles from client x.509 certificates.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
General Parameters
allowDiskUseByDefault
Available for
mongod
only.Default: True
Starting in MongoDB 6.0, pipeline stages that require more than 100 megabytes of memory to execute write temporary files to disk by default. These temporary files last for the duration of the pipeline execution and can influence storage space on your instance. In earlier versions of MongoDB, you must pass
{ allowDiskUse: true }
to individualfind
andaggregate
commands to enable this behavior.Individual
find
andaggregate
commands can override theallowDiskUseByDefault
parameter by either:Using
{ allowDiskUse: true }
to allow writing temporary files out to disk whenallowDiskUseByDefault
is set tofalse
Using
{ allowDiskUse: false }
to prohibit writing temporary files out to disk whenallowDiskUseByDefault
is set totrue
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
mongod --setParameter allowDiskUseByDefault=false allowDiskUseByDefault
only works onmongod
notmongos
.mongos
never writes temporary files to disk. Use thesetParameter
command in amongosh
session that is connected to a runningmongod
to change the value of the parameter while the server is running:db.adminCommand( { setParameter: 1, allowDiskUseByDefault: false } )
httpVerboseLogging
Available for both
mongod
andmongos
.Adds more verbose tracing for curl on Linux and macOS. Has no affect on Windows.
By default, the parameter is unset.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
mongos --setParameter httpVerboseLogging=true
slowConnectionThresholdMillis
New in version 6.3.
Available for both
mongod
andmongos
.Default: 100
Sets the time limit in milliseconds to log the establishment of slow server connections.
If a connection takes longer to establish than the
slowConnectionThresholdMillis
parameter, an event is added to the log with the messagemsg
field set to"Slow connection establishment"
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
slowConnectionThresholdMillis
to250
milliseconds.mongod --setParameter slowConnectionThresholdMillis=250 Or, if using the
setParameter
command withinmongosh
:db.adminCommand( { setParameter: 1, slowConnectionThresholdMillis: 250 } )
connPoolMaxConnsPerHost
Available for both
mongod
andmongos
.Default: 200
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.mongod --setParameter connPoolMaxInUseConnsPerHost=100
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.mongos --setParameter globalConnPoolIdleTimeoutMinutes=10
cursorTimeoutMillis
Available for both
mongod
andmongos
.Default: 600000 (10 minutes)
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
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.Warning
MongoDB cleans up orphaned cursors linked to sessions as part of session management. This means that orphaned cursors with session ids do not use
cursorTimeoutMillis
to control the timeout.For operations that return a cursor and have an idle period longer than
localLogicalSessionTimeoutMinutes
, useMongo.startSession()
to perform the operation within an explicit session. To refresh the session, run therefreshSessions
command. For details, see Refresh a Cursor withrefreshSessions
.
maxNumActiveUserIndexBuilds
Available for
mongod
only.Type: integer
Default: 3
Sets the maximum number of concurrent index builds allowed on the primary. This is a global limit that applies across all collections.
Increasing the value of
maxNumActiveUserIndexBuilds
allows additional concurrent index builds at the cost of increased pressure on the WiredTiger cache.System indexes are not limited to
maxNumActiveUserIndexBuilds
, however a system index build counts against the limit for user index builds.After the server reaches
maxNumActiveUserIndexBuilds
, it blocks additional user index builds until the number of concurrent index builds drops below themaxNumActiveUserIndexBuilds
limit. If an index build is blocked, the server logs this message:Too many index builds running simultaneously, waiting until the number of active index builds is below the threshold. This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following command sets a limit of 4 concurrent index builds:
db.adminCommand( { setParameter: 1, maxNumActiveUserIndexBuilds: 4 } ) See also:
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 Analyze Query Performance 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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
Note
notablescan
does not allow unbounded queries that use a clustered index because the queries require a full collection scan. For more information, see Collection Scans.
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
tcpFastOpenClient
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
tcpFastOpenQueueSize
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
disableJavaScriptJIT
Available for
mongod
only.The MongoDB JavaScript engine uses SpiderMonkey, which implements Just-in-Time (JIT) compilation for improved performance when running scripts.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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
indexBuildMinAvailableDiskSpaceMB
New in version 7.1.
Available for
mongod
only.Default: 500 MB
Sets the minimum available disk space in megabytes required for index builds.
Must be greater than or equal to 0 MB, and less than or equal to 8 TB. 0 disables the minimum disk space requirement.
A new index build cannot be started and a current index build is cancelled if the available disk space is below
indexBuildMinAvailableDiskSpaceMB
.Warning
If you increase
indexBuildMinAvailableDiskSpaceMB
, ensure your server has enough available disk space. Also, if you setindexBuildMinAvailableDiskSpaceMB
too high, you might needlessly prevent index builds when there is enough available disk space andindexBuildMinAvailableDiskSpaceMB
could be set lower.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
indexBuildMinAvailableDiskSpaceMB
to 650 MB:db.adminCommand( { setParameter: 1, indexBuildMinAvailableDiskSpaceMB: 650 } ) You can also set
indexBuildMinAvailableDiskSpaceMB
at startup. For example:mongod --setParameter indexBuildMinAvailableDiskSpaceMB=650
indexMaxNumGeneratedKeysPerDocument
Available for both
mongod
andmongos
.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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
maxIndexBuildMemoryUsageMegabytes
Available for
mongod
only.Default: 200
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()
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The memory consumed by an index build is separate from the WiredTiger cache memory (see
cacheSizeGB
).maxIndexBuildMemoryUsageMegabytes
sets a limit on how much memory the index build uses at once. This can impact performance when the index build process generates and sorts keys for the index. Increasing the memory limit improves sorting performance during an index build.Index builds may be initiated either by a user command such as
createIndexes
or by an administrative process such as an initial sync. Both are subject to the limit set bymaxIndexBuildMemoryUsageMegabytes
.An initial sync populates only one collection at a time and has no risk of exceeding the memory limit. However, it is possible for a user to start index builds on multiple collections in multiple databases simultaneously and potentially consume an amount of memory greater than the limit set by
maxIndexBuildMemoryUsageMegabytes
.Tip
To minimize the impact of building an index on replica sets and sharded clusters with replica set shards, use a rolling index build procedure as described on Rolling Index Builds on Replica Sets.
Changing
maxIndexBuildMemoryUsageMegabytes
does not affect an in progress index build if it has already started a collection scan. However, a forced replica set reconfiguration restarts the collection scan and uses the most currentmaxIndexBuildMemoryUsageMegabytes
provided.For feature compatibility version (fcv)
"4.2"
and later, the index build memory limit applies to all index builds.
reportOpWriteConcernCountersInServerStatus
Available for
mongod
only.Default: false
A boolean flag that determines whether the
db.serverStatus()
method andserverStatus
command returnopWriteConcernCounters
information. [1]mongod --setParameter reportOpWriteConcernCountersInServerStatus=true [1] Enabling reportOpWriteConcernCountersInServerStatus
can have a negative performance impact; specifically, when running without TLS.
watchdogPeriodSeconds
Available for
mongod
only.Type: integer
Default: -1 (disabled)
Determines how frequent the Storage Node Watchdog checks the status of the monitored filesystems:
The
--dbpath
directoryThe
journal
directory inside the--dbpath
directoryThe 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 run time.Once enabled,
To pause the Storage Node Watchdog during run time, set
watchdogPeriodSeconds
to -1.db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } ) To resume or change the period during run time, 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 run time if the Storage Node Watchdog was not enabled at startup time.
Warning
tcmallocAggressiveMemoryDecommit
is deprecated in 8.0. MongoDB 8.0 uses an
updated version of tcmalloc
that improves memory fragmentation and management.
See tcmalloc upgrade for more information. To release
memory back to the operating system, consider using tcmallocEnableBackgroundThread
instead.
tcmallocEnableBackgroundThread
Available for both
mongod
andmongos
.New in version 8.0.
Type: boolean
Default: true
If set to
true
,tcmallocEnableBackgroundThread
creates a background thread that periodically releases memory back to the operating system. The value oftcmallocReleaseRate
determines the rate, in bytes per second, at which the background thread releases memory.Note
If
tcmallocEnableBackgroundThread
istrue
andtcmallocReleaseRate
is0
, MongoDB still releases memory.For improved memory usage, we recommend using the default value of
true
. To learn more about improvements to performance and memory management, see Upgraded TCMalloc.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.The following operation sets
tcmallocEnableBackgroundThread
tofalse
:mongod --setParameter "tcmallocEnableBackgroundThread=false"
tcmallocReleaseRate
Available for both
mongod
andmongos
.Changed in version 8.0.
Default: 0
Specifies the TCMalloc release rate in bytes per second. Release rate refers to the rate at which MongoDB releases unused memory to the system. If
tcmallocReleaseRate
is set to0
MongoDB doesn't release memory back to the system. Increase this value to return memory faster; decrease it to return memory slower.Note
If
tcmallocEnableBackgroundThread
istrue
andtcmallocReleaseRate
is0
, MongoDB still releases memory.Starting in MongoDB 8.0, the default value of
tcmallocReleaseRate
is reduced to0
due to a tcmalloc upgrade that prioritizes CPU performance over memory release. Earlier versions of MongoDB used an older version oftcmalloc
that set the defaulttcmallocReleaseRate
to1
to balance memory release and performance.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
To modify the release rate during run time, 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.
Available for both
mongod
andmongos
.Default: 15 seconds
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
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example disables nodes from fasserting:
mongod --setParameter fassertOnLockTimeoutForStepUpDown=0
ingressAdmissionControllerTicketPoolSize
Available for
mongod
only.Default:
1000000
Controls the maximum number of operations admitted concurrently to the ingress queue. The default value of
1000000
represents the numerical equivalent of unbounded, which admits all incoming operations up to the default maximum connections that MongoDB allows.Increasing this value while there are operations waiting on the queue unblocks as many operations as the new pool size permits. Decreasing this value does not block any currently executing operations, but incoming controllable operations are blocked until there are tickets available.
mongod --setParameter ingressAdmissionControllerTicketPoolSize=100000 Warning
Avoid modifying
ingressAdmissionControllerTicketPoolSize
unless directed by MongoDB engineers. This setting has major implications across both WiredTiger and MongoDB.
Logging Parameters
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).This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets the
logLevel
to2
:db.adminCommand( { setParameter: 1, logLevel: 2 } ) [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
.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets the maximum log line size to
20
kilobytes:mongod --setParameter maxLogSizeKB=20
profileOperationResourceConsumptionMetrics
Available for
mongod
only.Type: boolean
Default: false
Flag that determines whether operations collect resource consumption metrics and report them in the slow query logs. If you enable profiling, these metrics are also included.
If set to
true
, running theexplain
command returns operationMetrics when the verbosity isexecutionStats
or higher.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
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, thevalidate
command; andreplication synchronization activities.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
Consider the following example which sets the
quiet
parameter to1
:db.adminCommand( { setParameter: 1, quiet: 1 } )
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 at startup, you can either:
Start
mongod
with the--redactClientLogData
option:mongod --redactClientLogData Set the
security.redactClientLogData
option in the configuration file:security: redactClientLogData: true ...
You can't use the
--setParameter
option to setredactClientLogData
at startup.To enable log redaction on a running
mongod
ormongos
, use the following command:db.adminCommand( { setParameter: 1, redactClientLogData : true } )
redactEncryptedFields
New in version 6.1.0.
Available for both
mongod
andmongos
.Type: boolean
Default:
true
Configures
mongod
andmongos
to redact field values of encryptedBinary
data from all log messages.If the
redactClientLogData
parameter or thesecurity.redactClientLogData
setting is set tofalse
andredactEncryptedFields
is set totrue
(the default), encrypted fields are redacted from all log messages.If the
redactClientLogData
parameter orsecurity.redactClientLogData
setting is set totrue
, all fields are redacted, regardless of theredactEncryptedFields
setting.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.This parameter is only available at runtime. To set the parameter, use the
setParameter
command.Consider the following example which sets the
traceExceptions
totrue
:db.adminCommand( { setParameter: 1, traceExceptions: true } )
suppressNoTLSPeerCertificateWarning
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.The following operation sets
suppressNoTLSPeerCertificateWarning
totrue
:db.adminCommand( { setParameter: 1, suppressNoTLSPeerCertificateWarning: true} )
enableDetailedConnectionHealthMetricLogLines
New in version 7.0.
Available for both
mongod
andmongos
.Type: boolean
Default: true
Determines whether to enable specific log messages related to cluster connection health metrics. If
enableDetailedConnectionHealthMetricLogLines
is set tofalse
, the following log messages are turned off, but MongoDB still collects data on the cluster connection health metrics:Log MessageDescriptionAccepted TLS connection from peerIndicates that the server successfully parsed the peer certificate during the TLS handshake with an accepted ingress connection.Ingress TLS handshake completeIndicates that the TLS handshake with an ingress connection is complete.Hello completedIndicates that the initial connection handshake completed on an incoming client connection.
MongoDB displays the log message only with the first
hello
command.Auth metrics reportSpecifies the completion of a step in the authentication conversation.Received first command on ingress connection since session start or auth handshakeIndicates that an ingress connection received the first command that is not part of the handshake.Slow network response send timeIndicates that the time spent, in milliseconds, to send the response back to the client over an ingress connection takes more time than the duration defined by theslowMS
server parameter.Completed client-side verification of OCSP requestIf the peer doesn't include an OCSP response to the TLS handshake when an egress TLS connection is established, the server must send an OCSP request to the certificate authority. MongoDB writes this log message when the certificate authority receives the OCSP response.Slow connection establishmentIndicates that the time taken to send a response back to the client over an ingress connection takes longer than the threshold specified with theslowConnectionThresholdMillis
parameter. MongoDB also emits this log message when the connection establishment times out.Operation timed out while waiting to acquire connectionIndicates that an operation timed out while waiting to acquire an egress connection.Acquired connection for remote operation and completed writing to wireIndicates that the server took one millisecond or longer to write an outgoing request on an egress connection, counting from the instant when the connection establishes.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
Diagnostic Parameters
To facilitate analysis of the MongoDB server behavior by MongoDB engineers, MongoDB logs server statistics to diagnostic files at periodic intervals.
For mongod
, the diagnostic data files are stored in the
diagnostic.data
directory under the mongod
instance's
--dbpath
or storage.dbPath
.
For mongos
, the diagnostic data files, by default, are
stored in a directory under the mongos
instance's
--logpath
or systemLog.path
directory. The diagnostic
data directory is computed by truncating the logpath's file
extension(s) and concatenating diagnostic.data
to the remaining
name.
For example, if mongos
has --logpath
/var/log/mongodb/mongos.log.201708015
, then the diagnostic data
directory is /var/log/mongodb/mongos.diagnostic.data/
directory. To
specify a different diagnostic data directory for mongos
,
set the diagnosticDataCollectionDirectoryPath
parameter.
The following parameters support diagnostic data capture (FTDC):
Note
The default values for the diagnostic data capture interval and the maximum sizes are chosen to provide useful data to MongoDB engineers with minimal impact on performance and storage size. Typically, these values will only need modifications as requested by MongoDB engineers for specific diagnostic purposes.
diagnosticDataCollectionEnabled
Available for both
mongod
andmongos
.Type: boolean
Default: true
Determines whether to enable the collecting and logging of data for diagnostic purposes. Diagnostic logging is enabled by default.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
For example, the following disables the diagnostic collection:
mongod --setParameter diagnosticDataCollectionEnabled=false
diagnosticDataCollectionDirectoryPath
Available for
mongos
only.Type: String
Warning
If Full Time Diagnostic Data Capture (FTDC) is disabled with
diagnosticDataCollectionEnabled
or ifsystemLog.destination
is set tosyslog
, you must restartmongos
after settingdiagnosticDataCollectionDirectoryPath
.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/
.If the
mongos
cannot create the specified directory, the diagnostic data capture is disabled for that instance.mongos
may not be able to create the specified directory if a file with the same name already exists in the path or if the process does not have permissions to create the directory.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
diagnosticDataCollectionDirectorySizeMB
Available for both
mongod
andmongos
.Type: integer
Default:
200
(400
in sharded clusters)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.Changed in version 8.0:
diagnosticDataCollectionDirectorySizeMB
has a default value of 400 MB formongos
andmongod
instances used in sharded clusters.mongod
instances used in replica set or as standalone servers have a default value of 200 MB.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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
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
andreplSetReconfig
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
andmongos
do not rely ondisableSplitHorizonIPCheck
for validation at startup. Legacymongod
andmongos
instances that use IP addresses instead of host names can 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 This parameter is only available at startup. To set the parameter, use the
setParameter
setting.setParameter: disableSplitHorizonIPCheck: true
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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, to set the
enableOverrideClusterChainingSetting
for amongod
instance totrue
:mongod --setParameter enableOverrideClusterChainingSetting=true
logicalSessionRefreshMillis
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, to set the
maxAcceptableLogicalClockDriftSecs
for amongod
instance to 15 minutes:mongod --setParameter maxAcceptableLogicalClockDriftSecs=900
maxSessions
Available for both
mongod
andmongos
.Type: integer
Default: 1000000
The maximum number of sessions that can be cached.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, to set the
maxSessions
for amongod
instance to 1000:mongod --setParameter maxSessions=1000
oplogBatchDelayMillis
New in version 6.0.
Available for both
mongod
andmongos
.Type: integer
Default: 0
The number of milliseconds to delay applying batches of oplog operations on secondary nodes. By default,
oplogBatchDelayMillis
is0
, meaning oplog batches are applied with no delay. When there is no delay, MongoDB may apply frequent, small oplog batches to secondaries.Increasing
oplogBatchDelayMillis
causes MongoDB to apply oplog batches less frequently on secondaries, with each batch containing larger amounts of data. This reduces IOPS on secondaries, but adds latency for writes with write concern"majority"
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, run the following command to set the
oplogBatchDelayMillis
for amongod
instance to 20 milliseconds:mongod --setParameter oplogBatchDelayMillis=20
periodicNoopIntervalSecs
Available for
mongod
only.Type: integer
Default: 10
The duration in seconds between noop writes on each individual node.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.Note
To modify this value for a MongoDB Atlas cluster, you must contact Atlas Support.
The following example sets the
periodicNoopIntervalSecs
to 1 second at startup:mongod --setParameter periodicNoopIntervalSecs=1
storeFindAndModifyImagesInSideCollection
New in version 5.0.
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
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
For example, to set
storeFindAndModifyImagesInSideCollection
tofalse
during startup:mongod --setParameter storeFindAndModifyImagesInSideCollection=false During run time, 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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.For example, to set the
TransactionRecordMinimumLifetimeMinutes
for amongod
instance to 20 minutes:mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20
enableFlowControl
Available for both
mongod
andmongos
.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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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
Available for both
mongod
andmongos
.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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
flowControlWarnThresholdSeconds
Available for both
mongod
andmongos
.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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
initialSyncTransientErrorRetryPeriodSeconds
Available for both
mongod
andmongos
.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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
initialSyncSourceReadPreference
Available for
mongod
only.Type: String
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
initialSyncMethod
New in version 5.2.
Available for
mongod
only.Type: String
Default:
logical
Available only in MongoDB Enterprise.
Method used for initial sync.
Set to
logical
to use logical initial sync. Set tofileCopyBased
to use file copy based initial sync.This parameter only affects the sync method for the member on which it is specified. Setting this parameter on a single replica set member does not affect the sync method of any other replica set members.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
maxNumSyncSourceChangesPerHour
Available for both
mongod
andmongos
.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.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
oplogFetcherUsesExhaust
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
oplogInitialFindMaxSeconds
Available for
mongod
only.Type: integer
Default: 60
Maximum time in seconds for a member of a replica set to wait for the
find
command to finish during data synchronization.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
replWriterThreadCount
Available for
mongod
only.Type: integer
Default: 16
Maximum number of threads to use to apply replicated operations in parallel. Values can range from 1 to 256 inclusive. However, the maximum number of threads used is capped at twice the number of available cores.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
replWriterMinThreadCount
New in version 5.0.
Available for
mongod
only.Type: integer
Default: 0
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
.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.
rollbackTimeLimitSecs
Available for
mongod
only.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.
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.
To effectively have an unlimited rollback period, set the value to
2147483647
which is the maximum value allowed and equivalent to roughly 68 years.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets the
waitForSecondaryBeforeNoopWriteMS
to 20 milliseconds:mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20 During run time, 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
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
createRollbackDataFiles
to false so that the rollback files are not created:mongod --setParameter createRollbackDataFiles=false During run time, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, createRollbackDataFiles: false } ) For more information, see Collect Rollback Data.
replBatchLimitBytes
Available for both
mongod
andmongos
.Default: 104857600 (100MB)
Sets the maximum oplog application batch size in bytes.
Values can range from 16777216 (16MB) to 104857600 (100MB) inclusive.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
replBatchLimitBytes
to 64 MB to limit the oplog application batch size:mongod --setParameter replBatchLimitBytes=67108864 During run time, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, replBatchLimitBytes: 64 * 1024 * 1024 } )
mirrorReads
Available for
mongod
only.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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
If you specify from the configuration file or on the command line, enclose the
mirrorReads
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
New in version 5.3.
Available for
mongod
only.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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.mongod --setParameter allowMultipleArbiters=true
Sharding Parameters
analyzeShardKeyCharacteristicsDefaultSampleSize
New in version 7.0.
Available for
mongod
only.Type: integer
Default: 10000000
If
sampleRate
andsampleSize
are not set when you runanalyzeShardKey
, specifies the number of documents to sample when calculating shard key characteristics metrics. Must be greater than0
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
analyzeShardKeyCharacteristicsDefaultSampleSize
to10000
at startup:mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, analyzeShardKeyCharacteristicsDefaultSampleSize: 10000 } )
analyzeShardKeyNumMostCommonValues
New in version 7.0.
Available for
mongod
only.Type: integer
Default: 5
Specifies the number of most common shard key values to return. If the collection contains fewer unique shard keys than this value,
analyzeShardKeyNumMostCommonValues
returns that number of most common values. Must be greater than0
and less than or equal to1000
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
analyzeShardKeyNumMostCommonValues
to3
at startup:mongod --setParameter analyzeShardKeyNumMostCommonValues=3 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, analyzeShardKeyNumMostCommonValues: 3 } )
analyzeShardKeyNumRanges
New in version 7.0.
Available for
mongod
only.Type: integer
Default: 100
Specifies the number of ranges to partition the shard key space into when calculating the hotness of shard key ranges. Must be greater than
0
and less than or equal to10000
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
analyzeShardKeyNumRanges
to50
at startup:mongod --setParameter analyzeShardKeyNumRanges=50 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, analyzeShardKeyNumRanges: 50 } )
analyzeShardKeyMonotonicityCorrelationCoefficientThreshold
New in version 7.0.
Available for
mongod
only.Type: double
Default: 0.7
Specifies the
RecordId
correlation coefficient threshold used to determine if a shard key is monotonically changing in insertion order. Must be greater than0
and less than or equal to1
.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
analyzeShardKeyMonotonicityCorrelationCoefficientThreshold
to1
at startup:mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, analyzeShardKeyMonotonicityCorrelationCoefficientThreshold: 1 } )
autoMergerIntervalSecs
New in version 7.0.
Available for
mongod
only.Type: integer
Default: 3600
When AutoMerger is enabled, specifies the amount of time between automerging rounds, in seconds. The default value is 3600 seconds, or one hour.
autoMergerIntervalSecs
can only be set on config servers.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
autoMergerIntervalSecs
to 7200 seconds, or two hours, at startup:mongod --setParameter autoMergerIntervalSecs=7200 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, autoMergerIntervalSecs: 7200 } )
autoMergerThrottlingMS
New in version 7.0.
Available for
mongod
only.Type: integer
Default: 15000
When AutoMerger is enabled, specifies the minimum amount time between merges initiated by the AutoMerger on the same collection, in milliseconds.
autoMergerThrottlingMS
can only be set on config servers.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
autoMergerThrottlingMS
to 60000 milliseconds, or one minute, at startup:mongod --setParameter autoMergerThrottlingMS=60000 During run time, you can set or modify the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, autoMergerThrottlingMS: 60000 } )
balancerMigrationsThrottlingMs
New in version 7.0: (Also available starting in 6.3.1, 6.0.6, 5.0.18)
Available for
mongod
only.Type: integer
Default: 1000
Specifies the minimum amount of time between two consecutive balancing rounds. This allows you to throttle the balancing rate. This parameter only takes effect on config server nodes.
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
This example sets
balancerMigrationsThrottlingMs
to 2000 milliseconds at startup:mongod --setParameter balancerMigrationsThrottlingMs=2000 During run time, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, balancerMigrationsThrottlingMs: 2000 } )
chunkDefragmentationThrottlingMS
New in version 5.3.
Available for both
mongod
andmongos
.Type: integer
Default: 0
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
chunkDefragmentationThrottlingMS
to10
milliseconds:mongod --setParameter chunkDefragmentationThrottlingMS=10 During run time, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )
chunkMigrationConcurrency
Available starting in MongoDB 7.0, 6.3, 6.0.6 (and 5.0.15).
Available for
mongod
only.Type: integer
Default: 1
Specifies an integer that sets the number of threads on the source shard and the receiving shard for chunk migration. Chunk migrations use the number of threads that you set on the receiving shard for both the source and receiving shard.
Increasing the concurrency improves chunk migration performance, but also increases the workload and disk IOPS usage on the source shard and the receiving shard.
Maximum value is 500.
You should typically use half the total number of CPU cores as threads. For example, if the total is 16 cores, set
chunkMigrationConcurrency
to 8 threads (or fewer).If
chunkMigrationConcurrency
is greater than1
, the_secondaryThrottle
configuration setting is ignored. The_secondaryThrottle
setting determines when the chunk migration proceeds with the next document in the chunk. For details, see Range Migration and Replication.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
chunkMigrationConcurrency
to5
:mongod --setParameter chunkMigrationConcurrency=5 During run time, you can also set the parameter with the
setParameter
command:db.adminCommand( { setParameter: 1, chunkMigrationConcurrency: 5 } ) To configure collection balancing, see
configureCollectionBalancing
.To learn about defragmenting sharded collections, see Defragment Sharded Collections.
disableResumableRangeDeleter
Available for
mongod
only.Type: boolean
Default: false
If set on a shard's primary, specifies if range deletion is paused on the shard. If set to
true
, cleanup of ranges containing orphaned documents is paused. The shard can continue to donate chunks to other shards, but the donated documents will not be removed from this shard until you set this parameter 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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.mongod --setParameter disableResumableRangeDeleter=false
enableShardedIndexConsistencyCheck
Available for
mongod
only.Type: boolean
Default: true
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
The following example sets
enableShardedIndexConsistencyCheck
tofalse
for a config server primary:mongod --setParameter enableShardedIndexConsistencyCheck=false During run time, 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.
opportunisticSecondaryTargeting
New in version 6.1.0.
Available for
mongos
only.Type: boolean
Default:
false
Determines whether
mongos
performs opportunistic reads against replica sets.When this parameter is set to
true
,mongos
directs secondary reads to secondaries with active connections. It sends the request to the first secondary that accepts the connection. When this parameter is set tofalse
,mongos
holds secondary reads until it can establish a connection to a specific secondary, (except in the case of hedged reads).Note
This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
For example, to set
opportunisticSecondaryTargeting
during startup:mongos --setParameter opportunisticSecondaryTargeting=true
shardedIndexConsistencyCheckIntervalMS
Available for
mongod
only.Type: integer
Default: 600000
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.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
command.
enableFinerGrainedCatalogCacheRefresh
Note
Deprecated in 8.0
Starting in MongoDB 8.0, the parameter is deprecated and doesn't cause any changes or errors.
Available for both
mongod
andmongos
.Type: boolean
Default: true
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.
This parameter is only available at startup. To set the parameter, use the
setParameter
setting.mongod --setParameter enableFinerGrainedCatalogCacheRefresh=true mongos --setParameter enableFinerGrainedCatalogCacheRefresh=true
maxTimeMSForHedgedReads
Important
Starting in MongoDB 8.0, hedged reads are deprecated. Queries that specify the read preference
nearest
no longer use hedged reads by default. If you explicitly specify a hedged read, MongoDB performs a hedged read and logs a warning.Available for
mongos
only.Type: integer
Default: 150
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.This parameter is available both at runtime and at startup:
To set the parameter at runtime, use the
setParameter
commandTo set the parameter at startup, use the
setParameter
setting
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 } )
maxCatchUpPercentageBeforeBlockingWrites
New in version 5.0.
Available for
mongod
only.Type: integer
Default: 10
For
moveChunk
andmoveRange
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.This parameter is only available at startup. To set the parameter, use the
setParameter
setting.Starting in MongoDB 7.1 (and 7.0.1), you can set the parameter during runtime.
For example, to set the maximum percentage to 20, you can issue the following during startup:
mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20 Starting in MongoDB 7.1 (and 7.0.1), you can set the parameter during runtime with the
setParameter
command:db.adminCommand( { setParameter: 1, maxCatchUpPercentageBeforeBlockingWrites: 20} )
metadataRefreshInTransactionMaxWaitBehindCritSecMS
New in version 5.2: (Also available starting in 5.1.0, 5.0.4)
Available for
mongod
only.Type: integer
Default: 500
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 value of
metadataRefreshInTransactionMaxWaitBehindCritSecMS
.