MONGODB-PARAMETERS(5)

NAME
mongodb-parameters - MongoDB setParameter Options

  On this page

•   Synopsis

•   Parameters

•   Authentication Parameters

•   General Parameters

•   Logging Parameters

•   Diagnostic Parameters

•   Logical Session Parameters

•   Replication Parameters

•   Sharding Parameters

•   Storage Parameters

•   WiredTiger Parameters

•   Auditing Parameters

•   Transaction Parameters

SYNOPSIS

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

•   the setParameter command:

    db.adminCommand( { setParameter: 1, <parameter>: <value>  } )

•   the setParameter configuration setting:

    setParameter:
       <parameter1>: <value1>
       ...

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

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

    For additional configuration options, see /reference/configuration-options, mongod and mongos.

PARAMETERS

  Authentication Parameters

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

    Available for both mongod and mongos.

    Specifies the list of authentication mechanisms the server accepts. 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 /core/authentication.
    Value | Description
    SCRAM-SHA-1 | RFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function.
    SCRAM-SHA-256 | RFC 7677 standard Salted Challenge Response Authentication Mechanism using the SHA-256 hash function. Requires featureCompatibilityVersion set to 4.0. New in version 4.0.
    MONGODB-X509 | MongoDB TLS/SSL certificate authentication.
    GSSAPI (Kerberos) | External authentication using Kerberos. This mechanism is available only in MongoDB Enterprise.
    PLAIN (LDAP SASL) | External authentication using LDAP. You can also use PLAIN for authenticating in-database users. PLAIN transmits passwords in plain text. This mechanism is available only in MongoDB Enterprise.

    You can only set authenticationMechanisms during start-up.

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

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

clusterAuthMode
    Available for both mongod and mongos.

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

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

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

enableLocalhostAuthBypass
    Available for both mongod and mongos.

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

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

    See localhost-exception for more information.

KeysRotationIntervalSec
    New in version 3.6.

    Default: 7776000 seconds (90 days)

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

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

ldapUserCacheInvalidationInterval
    For use with MongoDB deployments using security-ldap-external. Available for mongod instances only.

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

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

    Defaults to 30 seconds.

ldapUseConnectionPool
    New in version 4.0.9.

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

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

•   true on Windows.

•   true on Linux where MongoDB Enterprise binaries are linked against libldap_r.

•   false on Linux where MongoDB Enterprise binaries are linked against libldap.

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

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

ldapConnectionPoolUseLatencyForHostPriority
    New in version 4.2.1 and 4.0.13

    Default: true

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

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

ldapConnectionPoolMinimumConnectionsPerHost
    New in version 4.2.1 and 4.0.13

    Default: 1

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

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

ldapConnectionPoolMaximumConnectionsPerHost
    New in version 4.2.1 and 4.0.13

    Changed in version 4.4 Changed default value to 2. In previous versions, the default is unset.

    Default: 2

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

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

ldapConnectionPoolMaximumConnectionsInProgressPerHost
    New in version 4.2.1 and 4.0.13

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

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

ldapConnectionPoolHostRefreshIntervalMillis
    New in version 4.2.1 and 4.0.13

    Default: 60000

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

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

ldapConnectionPoolIdleHostTimeoutSecs
    New in version 4.2.1 and 4.0.13

    Default: 300

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

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

ocspEnabled
    New in version 4.4: Available on Linux and macOS.

    Default: true

    The flag that enables or disables OCSP.

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

    mongod --setParameter ocspEnabled=false ...

    SEE ALSO:

•   ocspValidationRefreshPeriodSecs

•   tlsOCSPStaplingTimeoutSecs

•   tlsOCSPVerifyTimeoutSecs

ocspValidationRefreshPeriodSecs
    New in version 4.4: Available on Linux.

    The number of seconds to wait before refreshing the stapled OCSP status response. Specify a number greater than or equal to 1.

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

    mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ...

    SEE ALSO:

•   ocspEnabled

•   tlsOCSPStaplingTimeoutSecs

•   tlsOCSPVerifyTimeoutSecs

opensslCipherConfig
    New in version 3.6.

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

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

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

    For version 4.2 and greater, the use of TLS options is preferred over SSL options. The TLS options have the same functionality as the SSL options.

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

    For versions 4.0 and earlier:

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

opensslDiffieHellmanParameters
    New in version 3.6.

    Available on Linux only

    Specify the path to the PEM file that contains the OpenSSL Diffie-Hellman parameters. Specifying the OpenSSL Diffie-Hellman parameters enables support for dhe cipher suites during TLS/SSL encryption.

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

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

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

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

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

saslauthdPath
    NOTE: Available only in MongoDB Enterprise (except MongoDB Enterprise for Windows).

    Available for both mongod and mongos.

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

saslHostName
    Available for both mongod and mongos.

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

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

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

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

•   Linux: /tutorial/control-access-to-mongodb-with-kerberos-authentication

•   Windows: /tutorial/control-access-to-mongodb-windows-with-kerberos-authentication

saslServiceName
    Available for both mongod and mongos.

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

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

    saslServiceName is only available in MongoDB Enterprise.

    IMPORTANT: Ensure that your driver supports alternate service names.

scramIterationCount
    Default: 10000

    Available for both mongod and mongos.

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

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

    For example, the following sets the scramIterationCount to 12000.

    mongod --setParameter scramIterationCount=12000

    Or, if using the setParameter command within the mongo shell:

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

    SEE ALSO:

•   db.changeUserPassword()

•   db.createUser()

•   db.updateUser()

scramSHA256IterationCount
    New in version 4.0.

    Default: 15000

    Available for both mongod and mongos.

    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 be 5000 or greater.

    For example, the following sets the scramSHA256IterationCount to 20000.

    mongod --setParameter scramSHA256IterationCount=20000

    Or, if using the setParameter command within the mongo shell:

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

    SEE ALSO:

•   db.changeUserPassword()

•   db.createUser()

•   db.updateUser()

sslMode
    Available for both mongod and mongos.

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

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

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

    SEE ALSO: tlsMode

tlsMode
    New in version 4.2.

    Available for both mongod and mongos.

    Set to either:

•   preferTLS

•   requireTLS

    The tlsMode parameter is useful during rolling upgrade to TLS/SSL to minimize downtime.

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

    For more information about TLS/SSL and MongoDB, see /tutorial/configure-ssl and /tutorial/configure-ssl-clients .

    SEE ALSO: sslMode

tlsOCSPStaplingTimeoutSecs
    New in version 4.4: Available for Linux.

    The maximum number of seconds the mongod/mongos instance should wait to receive the OCSP status response for its certificates.

    Specify an integer greater than or equal to (>=) 1. If unset, tlsOCSPStaplingTimeoutSecs uses the tlsOCSPVerifyTimeoutSecs value.

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

    mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

    SEE ALSO:

•   ocspEnabled

•   ocspValidationRefreshPeriodSecs

•   tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs
    New in version 4.4: Available for Linux and Windows.

    Default: 5

    The maximum number of seconds that the mongod/mongos should wait for the OCSP response when verifying client certificates.

    Specify an integer greater than or equal to (>=) 1. Default is unlimited.

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

    mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

    SEE ALSO:

•   ocspEnabled

•   ocspValidationRefreshPeriodSecs

•   tlsOCSPStaplingTimeoutSecs

tlsWithholdClientCertificate
    Default: false

    New in version 4.2.

    Available for both mongod and mongos.

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

tlsX509ClusterAuthDNOverride
    New in version 4.2.

    Available for both mongod and mongos.

    An alternative Distinguished Name (DN) that the instance can 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, and net.tls.certificateKeyFile) during intra-cluster communications. For members of the same deployment, the DN 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 the DN components (O's, OU's, and DC's) of the presented certificates. That is the member checks the presented certificates against its net.tls.clusterFile/net.tls.certificateKeyFile. If the DN does not match, the member checks the presented certificate against the tlsX509ClusterAuthDNOverride value.

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

    You can use this parameter for a rolling update of certificates to new certificates that contain a new DN value. See /tutorial/rotate-x509-membership-certificates.

    For more information about membership certificate requirements, see x509-member-certificate-requirements for details.

tlsX509ExpirationWarningThresholdDays
    New in version 4.4.

    Default : 30

    Available for both mongod and mongos.

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

•   Increase the parameter value to trigger warnings farther ahead of the certificate expiration date.

•   Decrease the parameter value to trigger warnings closer to the certificate expiration date.

•   Set the parameter to 0 to disable the warning.

    This parameter has a minimum value of 0.

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

•   The setParameter configuration setting, or

•   The mongod --setParameter / mongos --setParameter command line option.

    See 4.4-rel-notes-certificate-expiration-warning for more information on x.509 expiration warnings in MongoDB 4.4.

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

sslWithholdClientCertificate
    Default: false

    Deprecated since version 4.2: Use tlsWithholdClientCertificate instead.

    Available for both mongod and mongos.

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

userCacheInvalidationIntervalSecs
    Default: 30

    Available for mongos only.

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

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

authFailedDelayMs
    Default: 0

    Available for both mongod and mongos.

    New in version 3.4.

Enterprise Feature

    Available in MongoDB Enterprise only.

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

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

allowRolesFromX509Certificates
    Default: true

    Available for both mongod and mongos.

    Available starting in MongoDB 4.0.11 (and 3.6.14 and 3.4.22)

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

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

  General Parameters

connPoolMaxShardedConnsPerHost
    Default: 200

    Available for both mongod and mongos.

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

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

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

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

    mongos --setParameter connPoolMaxShardedConnsPerHost=250

connPoolMaxShardedInUseConnsPerHost
    New in version 3.6.3.

    Available for both mongod and mongos.

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

    By default, the parameter is unset.

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

    mongos --setParameter connPoolMaxShardedInUseConnsPerHost=100

    SEE ALSO: connPoolMaxShardedConnsPerHost

shardedConnPoolIdleTimeoutMinutes
    New in version 3.6.3.

    Available for both mongod and mongos.

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

    By default, the parameter is unset.

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

    mongos --setParameter shardedConnPoolIdleTimeoutMinutes=10

    SEE ALSO: connPoolMaxShardedConnsPerHost

connPoolMaxConnsPerHost
    Default: 200

    Available for both mongod and mongos.

    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 of connPoolMaxConnsPerHost.

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

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

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

    mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost
    New in version 3.6.3.

    Available for both mongod and mongos.

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

    By default, the parameter is unset.

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

    mongod --setParameter connPoolMaxInUseConnsPerHost=100

    SEE ALSO: connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes
    New in version 3.6.3.

    Available for both mongod and mongos.

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

    By default, the parameter is unset.

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

    mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

    SEE ALSO: connPoolMaxShardedConnsPerHost

cursorTimeoutMillis
    Default: 600000 (i.e. 10 minutes)

    Available for both mongod and mongos.

    Sets the expiration threshold in milliseconds for idle cursors before MongoDB removes them; i.e. MongoDB removes cursors that have been idle for the specified cursorTimeoutMillis.

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

    mongod --setParameter cursorTimeoutMillis=300000

    Or, if using the setParameter command within the mongo shell:

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

    Setting cursorTimeoutMillis to less than or equal to 0 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 the cursor.explain() cursor modifier to analyze the average query time and select an appropriate timeout period.

failIndexKeyTooLong
    Removed in 4.4

    IMPORTANT:

•   MongoDB 4.4 removes the deprecated failIndexKeyTooLong parameter. Attempting to use this parameter with MongoDB 4.4 will result in an error.

•   MongoDB 4.2 deprecates the failIndexKeyTooLong parameter and removes the Index Key Length Limit for featureCompatibilityVersion (fCV) set to "4.2" or greater.

    For MongoDB 2.6 through MongoDB versions with featureCompatibilityVersion (fCV) set to "4.0" or earlier, Index Key Length Limit applies. If you attempt to insert or update a document whose index field exceeds the Index Key Length Limit, the operation will fail and return an error to the client.

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

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

    failIndexKeyTooLong defaults to true.

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

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

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

    mongod --setParameter failIndexKeyTooLong=false

notablescan
    Available for mongod only.

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

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

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

    Setting notablescan to 1 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 /tutorial/evaluate-operation-performance and /tutorial/optimize-query-performance-with-indexes-and-projections sections and using the logLevel parameter, /reference/program/mongostat and profiling.

    Don't run production mongod instances with notablescan because preventing collection scans can potentially affect queries in all databases, including administrative queries.

ttlMonitorEnabled
    Available for mongod only.

    To support TTL Indexes, mongod instances have a background thread that is responsible for deleting documents from collections with TTL indexes.

    To disable this worker thread for a mongod, set ttlMonitorEnabled to false, 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

tcpFastOpenServer
    New in version 4.4.

    Available for both mongod and mongos.

    Default: true

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

Windows
    The following Windows operating systems support TFO:

•   Microsoft Windows Server 2016 and later.

•   Microsoft Windows 10 Update 1607 and later.

macOS
    macOS 10.11 (El Capitan) and later support TFO.

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

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

•   Set to 2 to enable only inbound TFO connections.

•   Set to 3 to enable inbound and outbound TFO connections.

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

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

    See 4.4-rel-notes-tcp-fast-open for more information on MongoDB TFO support.

    SEE ALSO: RFC7413.

tcpFastOpenClient
    New in version 4.4.

    Available for both mongod and mongos.

    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 the mongod/mongos host machine support and enable TFO.

    Linux operating systems running Linux Kernel 4.11 or later can support outbound TFO.

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

•   1 to enable only outbound TFO connections.

•   3 to enable inbound and outbound TFO connections.

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

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

    See 4.4-rel-notes-tcp-fast-open for more information on MongoDB TFO support.

    SEE ALSO: RFC7413.

tcpFastOpenQueueSize
    New in version 4.4.

    Available for both mongod and mongos.

    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. The mongod/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, the mongod/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, the mongod/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 of 0 effectively disables TFO.

    This parameter has no effect on host operating systems that do not support or are not configured for TFO connections. See 4.4-rel-notes-tcp-fast-open for more information on MongoDB TFO support.

    SEE ALSO:

•   RFC7413 TCP Fast Open Section 5: Security Considerations

•   RFC7413 TCP Fast Open Section 6: TFO Applicability

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

    Available for mongod only.

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

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

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

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

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

    mongod --setParameter disableJavaScriptJIT=false

maxIndexBuildMemoryUsageMegabytes
    New in version 3.4.

    Default:

•   200 (For versions 4.2.3 and later)

•   500 (For versions 4.2.2 and earlier)

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

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

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

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

  Tip

To minimize the impact of building an index on replica sets and sharded clusters with replica set shards, use a rolling index build procedure as described on /tutorial/build-indexes-on-replica-sets.

Changed in version 4.2.

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

•   For feature compatibility version (fcv) "4.0", the index build memory limit only applies to foreground index builds.

reportOpWriteConcernCountersInServerStatus
    New in version 4.0.6.

    Default: false

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

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

    mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

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

watchdogPeriodSeconds
    Available for mongod only.

    Type: integer

    Default: -1 (disabled)

    NOTE:

•   Starting in MongoDB 4.2, the Storage Node Watchdog is available in both the Community and MongoDB Enterprise editions.

•   In earlier versions (3.2.16+, 3.4.7+, 3.6.0+, 4.0.0+), the Storage Node Watchdog is only available in MongoDB Enterprise edition.

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

•   The --dbpath directory

•   The journal directory inside the --dbpath directory if journaling is enabled

•   The directory of --logpath file

•   The directory of --auditPath file

    Valid values for watchdogPeriodSeconds are:

•   -1 (the default), to disable/pause Storage Node Watchdog, or

•   An integer greater than or equal to 60.

    NOTE:

•   If a filesystem on a monitored directory becomes unresponsive, it can take a maximum of nearly twice the value of watchdogPeriodSeconds to terminate the mongod.

•   If any of its monitored directory is a symlink to other volumes, the Storage Node Watchdog does not monitor the symlink target. For example, if the mongod uses storage.directoryPerDB: true (or --directoryperdb) and symlinks a database directory to another volume, the Storage Node Watchdog does not follow the symlink to monitor the target.

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

    mongod --setParameter watchdogPeriodSeconds=60

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

    Once enabled,

•   To pause the Storage Node Watchdog during runtime, set watchdogPeriodSeconds to -1.

    db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )

•   To resume or change the period during runtime, set watchdogPeriodSeconds to a number greater than or equal to 60.

    db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )

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

tcmallocReleaseRate
    New in version 4.2.3: Also available in 3.6.17+ and 4.0.14+

    Default: 1.0

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

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

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

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

    mongod --setParameter "tcmallocReleaseRate=5.0"

  Logging Parameters

logLevel
    Available for both mongod and mongos.

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

    The default logLevel is 0 (Informational).

    The following example sets the logLevel to 2:

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

    SEE ALSO:

•   logComponentVerbosity

•   systemLog.verbosity

[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 specified D for Debug level.

logComponentVerbosity
    Available for both mongod and mongos.

    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 to 5:

•   0 is the MongoDB's default log verbosity level, to include Informational messages.

•   1 to 5 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 to systemLog.verbosity which sets the default level for all components. The default value of systemLog.verbosity is 0.

    The components correspond to the following settings:

•   accessControl

•   command

•   control

•   ftdc

•   geo

•   index

•   network

•   query

•   replication

•   replication.election

•   replication.heartbeats

•   replication.initialSync

•   replication.rollback

•   recovery

•   sharding

•   storage

•   storage.journal

•   transaction

•   write

    Unless explicitly set, the component has the verbosity level of its parent. For example, storage is the parent of storage.journal. That is, if you specify a storage verbosity level, this level also applies to:

•   storage.journal components unless you specify the verbosity level for storage.journal.

•   storage.recovery components unless you specify the verbosity level for storage.recovery.

    For example, the following sets the default verbosity level to 1, the query to 2, the storage to 2, and the storage.journal to 1.

    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}"

    The mongo shell also provides the db.setLogLevel() to set the log level for a single component. For various ways to set the log verbosity level, see log-messages-configure-verbosity.

[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 specified D for Debug level.

maxLogSizeKB
    New in version 3.4.

    Available for both mongod and mongos.

    Type: non-negative integer

    Default: 10

    Specifies the maxium 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 formating. Log entires that contain truncated attributes append a truncated object to the end of the log entry.

    See log message truncation for more information.

    A value of 0 disables truncation entirely. Negative values for this parameter are not valid.

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

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

    mongod --setParameter maxLogSizeKB=20

quiet
    Available for both mongod and mongos.

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

•   connection events;

•   the drop command, the dropIndexes command, the diagLogging command, the validate command, and the clean command; and

•   replication synchronization activities.

    Consider the following example which sets the quiet to 1:

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

    SEE ALSO: systemLog.quiet

redactClientLogData
    New in version 3.4.

    Available for both mongod and mongos.

    Type: boolean

Enterprise Feature

    Available in MongoDB Enterprise only.

    Configure the mongod or mongos 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 /core/security-encryption-at-rest and /core/security-transport-encryption to assist compliance with regulatory requirements.

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

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

    SEE ALSO: security.redactClientLogData

traceExceptions
    Available for both mongod and mongos.

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

    Consider the following example which sets the traceExceptions to true:

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

    SEE ALSO: systemLog.traceAllExceptions

suppressNoTLSPeerCertificateWarning
    New in version 4.0.1.

    Available for both mongod and mongos.

    Type: boolean

    Default: false

    By default, a mongod or mongos with TLS/SSL enabled and net.ssl.allowConnectionsWithoutCertificates : true lets clients connect without providing a certificate for validation while logging an warning. Set suppressNoTLSPeerCertificateWarning to 1 or true to suppress those warnings.

    The following operation sets suppressNoTLSPeerCertificateWarning to true:

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

  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
    New in version 3.2.

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

    Type: boolean

    Default: true

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

    For example, the following disables the diagnostic collection:

    mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionDirectoryPath
    New in version 3.4.14.

    Type: String

    Available for mongos only.

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

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

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

    IMPORTANT: If mongos cannot create the specified directory, e.g. a file exists with the same name in the path or the process does not have permissions to create the directory, the diagnostic data capture will be disabled for that instance.

diagnosticDataCollectionDirectorySizeMB
    New in version 3.2.

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

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

    Type: integer

    Default: 200

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

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

    mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

diagnosticDataCollectionFileSizeMB
    New in version 3.2.

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

    Type: integer

    Default: 10

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

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

    mongod --setParameter diagnosticDataCollectionFileSizeMB=20

    The minimum value for diagnosticDataCollectionFileSizeMB is 1 megabyte.

diagnosticDataCollectionPeriodMillis
    New in version 3.2.

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

    Type: integer

    Default: 1000

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

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

    mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

    The minimum value for diagnosticDataCollectionPeriodMillis is 100 milliseconds.

  Logical Session Parameters

logicalSessionRefreshMillis

Availability

    New in version 4.0.4 (and version 3.6.9).

    Available for both mongod and mongos.

    Type: integer

    Default: 300000 (i.e. 5 minutes)

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

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

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

    mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes
    New in version 3.6.

    Available for both mongod and mongos.

    Type: integer

    Default: 30

For testing purposes only

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

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

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

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

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

    mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs
    New in version 3.6.

    Available for both mongod and mongos.

    Type: integer

    Default: 31536000 (1 year)

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

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

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

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

    mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions
    New in version 4.0.1.

    Available for both mongod and mongos.

    Type: integer

    Default: 1000000

    The maximum number of sessions that can be cached.

    You can only set maxSessions during start-up.

    For example, to set the maxSessions for a mongod instance to 1000:

    mongod --setParameter maxSessions=1000

TransactionRecordMinimumLifetimeMinutes
    New in version 3.6.

    Available for mongod only.

    Type: integer

    Default: 30

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

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

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

    mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

    SEE ALSO: localLogicalSessionTimeoutMinutes

  Replication Parameters

enableFlowControl
    New in version 4.2.

    Type: boolean

    Default: true

    Enables or disables the mechanism that controls the rate at which the primary applies its writes with the goal of keeping the secondary members' majority committed lag under a configurable maximum value.

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

flowControlTargetLagSeconds
    New in version 4.2.

    Type: integer

    Default: 10

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

    The specified value must be greater than 0.

    In general, the default settings should suffice; however, if modifying from the default value, decreasing, rather than increasing, the value may prove to be more useful.

flowControlWarnThresholdSeconds
    New in version 4.2.

    Type: integer

    Default: 10

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

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

initialSyncTransientErrorRetryPeriodSeconds
    New in version 4.4.

    Type: integer

    Default: 86400

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

initialSyncSourceReadPreference
    New in version 4.4.

    Type: String

    Available for mongod only.

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

•   primary

•   primaryPreferred (Default for voting replica set members)

•   secondary

•   secondaryPreferred

•   nearest (Default for newly added or non-voting replica set members)

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

    You cannot specify a tag set or maxStalenessSeconds to initialSyncSourceReadPreference.

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

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

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

oplogInitialFindMaxSeconds
    New in version 3.6.

    Type: integer

    Default: 60

    Available for mongod only.

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

replWriterThreadCount
    New in version 3.2.

    Type: integer

    Default: 16

    Available for mongod only.

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

rollbackTimeLimitSecs
    Type: 64-bit integer

    Default: 86400 (1 day)

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

    Starting in MongoDB 4.2+ and 4.0.13+, if the time between the end of the to-be-rolledback instance's oplog and the first operation after the common point (the last point where the source node and the to-be-rolledback node had the same data) exceeds this value, the rollback will fail.

    In MongoDB 4.0.0-4.0.12, if the time between the end of the to-be-rolledback instance's oplog and the common point (the last point where the source node and the to-be-rolledback node had the same data) exceeds this value, the rollback will fail.

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

    New in version 4.0.

waitForSecondaryBeforeNoopWriteMS
    New in version 3.6.

    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 the waitForSecondaryBeforeNoopWriteMS passes, if the afterClusterTime is still greater than the last applied time, the secondary makes a no-op write to advance the last applied time.

    The following example sets the waitForSecondaryBeforeNoopWriteMS to 20 milliseconds:

    mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

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

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

createRollbackDataFiles
    Available for mongod only.

    Type: boolean

    Default: true

    New in version 4.0.

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

    By default, createRollbackDataFiles is true and MongoDB creates the rollback files.

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

    mongod --setParameter createRollbackDataFiles=false

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

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

    For more information, see rollback-data-files.

enableElectionHandoff
    New in version 4.0.2.

    Type: boolean

    Default: true

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

    An eligible secondary must be caught up with the stepped down primary and have priority greater than 0. If multiple secondary members meet this criteria, the stepped down primary selects the eligible secondary with the highest priority. If the more than one eligible secondary members have the same priority, the stepped down primary selects the secondary with the lowest _id. The stepped down primary does not wait for the effects of the handoff.

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

replBatchLimitBytes
    Default: 104857600 (100MB)

    Sets the maximum oplog application batch size in bytes.

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

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

    mongod --setParameter replBatchLimitBytes=67108864

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

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

    New in version 4.0.10.

mirrorReads
    Available for mongod only.

    New in version 4.4

    Type: Document

    Default: { samplingRate: 0.01, maxTimeMS: 1000 }

    Specifies the settings for mirrored reads for the mongod instance. The settings only take effect when the member is a primary.

    The parameter mirrorReads takes a JSON document with the following fields:
    Field | Description
    samplingRate | The sampling rate used to mirror a subset of operations that support mirroring to a subset of electable (i.e. priority greater than 0) secondaries. That is, the primary mirrors reads to each electable secondary at the specified sampling rate. Valid values are greater than or equal to 0.0 and less than or equal to 1.0. Value of 0.0 turns off mirroring. 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 receives 100 operations that can be mirrored, the sampling rate of 0.10 may result in 8 reads being mirrored to one secondary and 13 reads to the other or 10 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 the maxTimeMS of the original read being mirrored.

    You can set mirrorReads during startup in the configuration file or with the --setParameter option on the command line. If specifying 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 a mongo shell connected to a running mongod, do not enclose the document in quotes:

    db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )

  Sharding Parameters

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

enableShardedIndexConsistencyCheck
    New in version 4.4 (and 4.2.6).

    Type: boolean

    Default: true

    Available for mongod only.

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

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

    mongod --setParameter enableShardedIndexConsistencyCheck=false

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

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

    SEE ALSO:

•   shardedIndexConsistencyCheckIntervalMS parameter

•   shardedIndexConsistency metrics returned by the serverStatus command.

shardedIndexConsistencyCheckIntervalMS
    New in version 4.4 (and 4.2.6).

    Type: integer

    Default: 600000

    Available for mongod only.

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

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

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

    mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

    SEE ALSO:

•   enableShardedIndexConsistencyCheck parameter

•   shardedIndexConsistency metrics returned by the serverStatus commandq

maxTimeMSForHedgedReads
    New in version 4.4.

    Type: integer

    Default: 150

    Available for mongos only.

    Specifies the maximimum time limit (in milliseconds) for the hedged read. That is, the additional read sent to hedge the read operation uses the maxTimeMS value of maxTimeMSForHedgedReads while the read operation that is being hedged uses the maxTimeMS value specified for the operation.

    For example, to set the limit to 200 milliseconds, you can issue the following during startup:

    mongos --setParameter maxTimeMSForHedgedReads=200

    Or if using the setParameter command in a mongo shell connected to a running mongos:

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

    SEE ALSO:

•   readHedgingMode

•   mongos-hedged-reads

readHedgingMode
    New in version 4.4.

    Type: string

    Default: on

    Available for mongos only.

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

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

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

    mongos --setParameter readHedgingMode=off

    Or if using the setParameter command in a mongo shell connected to a running mongos:

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

    SEE ALSO:

•   mongos-hedged-reads

•   maxTimeMSForHedgedReads

replMonitorMaxFailedChecks
    Available in MongoDB 3.2 only

    Type: integer

    Default: 30

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

    When the number of consecutive unsuccessful attempts exceeds this parameter value, the mongod or mongos instance denotes the monitored replica set as unavailable. If the monitored replica set is the config server replica set:

•   For MongoDB 3.2.0-3.2.9, the monitoring mongod or mongos instance will become unusable and needs to be restarted. See the v3.2 troubleshooting guide for more details.

•   For MongoDB 3.2.10 and later 3.2-series, see also timeOutMonitoringReplicaSets.

timeOutMonitoringReplicaSets
    Available in MongoDB 3.2.10 and later 3.2-series only

    Type: integer

    Default: false

    The flag that determines whether the mongod or mongos instance should stop its attempt to reach the monitored replica set after unsuccessfully trying replMonitorMaxFailedChecks number of times.

    If the monitored replica set is the config server replica set and timeOutMonitoringReplicaSets is set to true, you must restart mongod or mongos if the mongod or mongos instance cannot reach any of the config servers for the specified number of times. See the v3.2 troubleshooting guide for more details.

ShardingTaskExecutorPoolHostTimeoutMS
    Type: integer

    Default: 300000 (i.e. 5 minutes)

    Available for mongos only.

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

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

    If set, ShardingTaskExecutorPoolHostTimeoutMS should be greater than the sum of ShardingTaskExecutorPoolRefreshRequirementMS and ShardingTaskExecutorPoolRefreshTimeoutMS. Otherwise, mongos adjusts the value of ShardingTaskExecutorPoolHostTimeoutMS to be greater than the sum.

    mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

ShardingTaskExecutorPoolMaxConnecting
    New in version 3.6.

    Type: integer

    Default: 2

    Available for mongos only.

    Maximum number of simultaneous initiating connections (including pending connections in setup/refresh state) each TaskExecutor connection pool can have to a mongod instance. You can set this parameter to control the rate at which mongos adds connections to a mongod instance.

    If set, ShardingTaskExecutorPoolMaxConnecting should be less than or equal to ShardingTaskExecutorPoolMaxSize. If it is greater, mongos ignores the ShardingTaskExecutorPoolMaxConnecting value.

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

    mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

ShardingTaskExecutorPoolMaxSize
    Type: integer

    Default: 264 - 1

    Available for mongos only.

    Maximum number of outbound connections each TaskExecutor connection pool can open to any given mongod instance. The maximum possible connections to any given host across all TaskExecutor pools is:

    ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

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

    mongos --setParameter ShardingTaskExecutorPoolMaxSize=4

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

    SEE ALSO: ShardingTaskExecutorPoolMinSize

ShardingTaskExecutorPoolMinSize
    Type: integer

    Default: 1

    Available for both mongod and mongos.

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

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

    For a mongos using the warmMinConnectionsInShardingTaskExecutorPoolOnStartup parameter, the ShardingTaskExecutorPoolMinSize parameter also controls how many connections to each shard host are established on startup of the mongos instance before it begins accepting incoming client connections.

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

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

    mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

    SEE ALSO:

•   ShardingTaskExecutorPoolMaxSize

•   warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolRefreshRequirementMS
    Type: integer

    Default: 60000 (1 minute)

    Available for mongos only.

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

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

    If set, ShardingTaskExecutorPoolRefreshRequirementMS should be greater than ShardingTaskExecutorPoolRefreshTimeoutMS. Otherwise, mongos adjusts the value of ShardingTaskExecutorPoolRefreshTimeoutMS to be less than ShardingTaskExecutorPoolRefreshRequirementMS.

    mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

ShardingTaskExecutorPoolRefreshTimeoutMS
    Type: integer

    Default: 20000 (20 seconds)

    Available for mongos only.

    Maximum time the mongos waits for a heartbeat before timing out the heartbeat.

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

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

    mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

ShardingTaskExecutorPoolReplicaSetMatching
    New in version 4.2.

    Type: string

    Default: "matchPrimaryNode"

    Available for mongos only.

    The policy that determines the minimum size limit of the mongos instance's connection pools to the sharded cluster's replica set secondaries.

    Available values are:
    Matching Policy | Description
    "matchPrimaryNode" (Default) | For each replica set in the sharded cluster (i.e. shard replica set and config servers), the minimum size limit of the mongos instance's connection pool to each secondary of that replica set is equal to the size of its connection pool to the primary. In case of primary stepdown, matchPrimaryNode ensures that any secondary that becomes the primary can handle the current level of primary reads and writes.
    "matchBusiestNode" | For each replica set in the sharded cluster (i.e. shard replica set and config servers), the minimum size limit of the mongos instance's connection pool to each member of that replica set is equal to the largest among the active connections counts to the primary and each secondary members. With "matchBusiestNode", mongos maintains enough connections to each secondary to handle the current level of primary and secondary reads and writes. The number of connections to maintain in the pool decreases as the number of active connections decreases.
    "disabled" | For each replica set in the sharded cluster (i.e. shard replica set and config servers), the minimum number of connections in the mongos instance's connection pool to each secondary is equal to the ShardingTaskExecutorPoolMinSize.

    The following example sets the ShardingTaskExecutorPoolReplicaSetMatching to "matchBusiestNode" during startup:

    mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="matchBusiestNode"

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

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

taskExecutorPoolSize
    Changed in version 4.0.

    Type: integer

    Default: 1

    Available for mongos only.

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

    If the parameter value is 0 or less, the number of Task Executor connection pools is the number of cores with the following exceptions:

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

•   If the number of cores is greater than 64, the number of Task Executor connection pools is 64.

    Starting in MongoDB 4.0, the default value of taskExecutorPoolSize is 1:

•   In MongoDB 4.0 deployment, you can set taskExecutorPoolSize to 0 and, on Linux, set AsyncRequestsSenderUseBaton to false for the previous behavior.

•   In MongoDB 4.2+ deployment, MongoDB removes the AsyncRequestsSenderUseBaton parameter and always enables the performance enhancement controlled by the parameter.

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

    mongos --setParameter taskExecutorPoolSize=6

    SEE ALSO:

•   ShardingTaskExecutorPoolMaxSize

•   ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup
    New in version 4.4.

    Type: boolean

    Default: true

    Available for mongos only.

    Configures a mongos instance to preload the routing table for a sharded cluster on startup. With this setting enabled, the mongos caches the cluster-wide routing table for each sharded collection as part of its startup procedure, before it begins accepting client connections.

    Without this setting enabled, the mongos only loads a routing table as needed for incoming client connections, and only loads the specific routing table for the namespace of a given request.

    A mongos instance with the loadRoutingTableOnStartup parameter enabled may experience longer startup times, but will result in faster servicing of initial client connections once started.

    loadRoutingTableOnStartup is enabled by default.

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

warmMinConnectionsInShardingTaskExecutorPoolOnStartup
    New in version 4.4.

    Type: boolean

    Default: true

    Available for mongos only.

    Configures a mongos instance to prewarm its connection pool on startup. With this parameter enabled, the mongos attempts to establish ShardingTaskExecutorPoolMinSize network connections to each shard server as part of its startup procedure, before it begins accepting client connections.

    A timeout for this behavior can be configured with the warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS parameter. If this timeout is reached, the mongos will begin accepting client connections regardless of the size of its connection pool.

    A mongos instance with this parameter enabled may experience longer startup times, but will result in faster servicing of initial client connections once started.

    warmMinConnectionsInShardingTaskExecutorPoolOnStartup is enabled by default.

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

    SEE ALSO:

•   warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

•   ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
    New in version 4.4.

    Type: integer

    Default: 2000 (i.e. 2 seconds)

    Available for mongos only.

    Sets the timeout threshold in milliseconds for a mongos to wait for ShardingTaskExecutorPoolMinSize connections to be established per shard host when using the warmMinConnectionsInShardingTaskExecutorPoolOnStartup parameter. If this timeout is reached, the mongos will begin accepting client connections regardless of the size of its connection pool.

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

    SEE ALSO:

•   warmMinConnectionsInShardingTaskExecutorPoolOnStartup

•   ShardingTaskExecutorPoolMinSize

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

    Available for mongod only.

    Type: Non-negative integer

    Default: 0

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

    The default value of 0 indicates no additional wait.

    The following sets the migrateCloneInsertionBatchDelayMS to 200 milliseconds:

    mongod --setParameter migrateCloneInsertionBatchDelayMS=200

    The parameter may also be set using the setParameter command:

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

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

    Available for mongod only.

    Type: Non-negative integer

    Default: 0

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

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

    The following sets the migrateCloneInsertionBatchSize to 100 documents:

    mongod --setParameter migrateCloneInsertionBatchSize=100

    The parameter may also be set using the setParameter command:

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

orphanCleanupDelaySecs
    New in version 3.6.

    Default: 900 (15 minutes)

    Available for mongod only.

    Minimum delay before a migrated chunk is deleted from the source shard.

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

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

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

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

    The following sets the orphanCleanupDelaySecs to 20 minutes:

    mongod --setParameter orphanCleanupDelaySecs=1200

    This may also be set using the setParameter command:

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

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

    Available for mongod only.

    Type: Non-negative integer

    Default: 20

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

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

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

    The following sets the rangeDeleterBatchDelayMS to 200 milliseconds:

    mongod --setParameter rangeDeleterBatchDelayMS=200

    The parameter may also be set using the setParameter command:

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

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

    Available for mongod only.

    Type: Non-negative integer

    Default: 0

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

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

    The following sets the rangeDeleterBatchSize to 100 documents:

    mongod --setParameter rangeDeleterBatchSize=100

    The parameter may also be set using the setParameter command:

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

skipShardingConfigurationChecks
    New in version 3.6.3.

    Available for mongod only.

    Type: boolean

    Default: false

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

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

    mongod --setParameter skipShardingConfigurationChecks=true

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

    The parameter is also available for MongoDB versions:

•   MongoDB 3.2.19+

•   MongoDB 3.4.11+

  Storage Parameters

journalCommitInterval
    Available for mongod only.

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

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

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

    SEE ALSO: storage.journal.commitIntervalMs

syncdelay
    Available for mongod only.

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

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

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

    SEE ALSO:

•   journalCommitInterval

•   storage.syncPeriodSecs

honorSystemUmask
    New in version 3.6.

    Default: false

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

    If honorSystemUmask is set to false, new files created by MongoDB have permissions set to 600, which gives read and write permissions only to the owner. New directories have permissions set to 700.

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

    mongod --setParameter honorSystemUmask=true

    NOTE: honorSystemUmask is not available on Windows systems.

  WiredTiger Parameters

wiredTigerMaxCacheOverflowSizeGB

Deprecated in MongoDB 4.4

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

    Default: 0 (No specified maximum)

    Available for mongod only.

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

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

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

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

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

    Available starting in MongoDB 4.2.1 (and 4.0.12)

wiredTigerConcurrentReadTransactions
    Available for mongod only.

    Available for the WiredTiger storage engine only.

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

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

    SEE ALSO: wiredTiger.concurrentTransactions

wiredTigerConcurrentWriteTransactions
    Available for mongod only.

    Available for the WiredTiger storage engine only.

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

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

    SEE ALSO: wiredTiger.concurrentTransactions

wiredTigerEngineRuntimeConfig
    Available for mongod only.

    Specify wiredTiger storage engine configuration options for a running mongod instance. You can only set this parameter using the setParameter command and not using the command line or configuration file option.

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

    Consider the following operation prototype:

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

    See the WiredTiger documentation for all available WiredTiger configuration options.

  Auditing Parameters

auditAuthorizationSuccess
    Default: false

    NOTE: Available only in MongoDB Enterprise and MongoDB Atlas.

    Available for both mongod and mongos.

    Enables the auditing of authorization successes for the authCheck action.

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

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

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

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

    SEE ALSO: getParameter

  Transaction Parameters

transactionLifetimeLimitSeconds
    New in version 4.0.

    Available for mongod only.

    Default: 60

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

    The cleanup process helps relieve storage cache pressure.

    The minimum value for transactionLifetimeLimitSeconds is 1 second.

    The following sets the transactionLifetimeLimitSeconds to 30 seconds:

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

    You can also set parameter transactionLifetimeLimitSeconds at startup time.

    mongod --setParameter "transactionLifetimeLimitSeconds=30"

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

maxTransactionLockRequestTimeoutMillis
    New in version 4.0.

    Available for mongod only.

    Type: integer

    Default: 5

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

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

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

    You can set maxTransactionLockRequestTimeoutMillis to:

•   0 such that if the transaction cannot acquire the required locks immediately, the transaction aborts.

•   A number greater than 0 to wait the specified time to acquire the required locks. This can help obviate transaction aborts on momentary concurrent lock acquisitions, like fast-running metadata operations. However, this could possibly delay the abort of deadlocked transaction operations.

•   -1 to use the operation specific timeout.

    The following sets the maxTransactionLockRequestTimeoutMillis to 20 milliseconds:

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

    You can also set this parameter during start-up:

    mongod --setParameter maxTransactionLockRequestTimeoutMillis=20

AUTHOR
MongoDB Documentation Project

COPYRIGHT
2008-2020