MongoDB Server ParametersMongoDB服务器参数

Authentication Parameters身份验证参数

authenticationMechanisms

Available for both mongod and mongos.可用于mongod和mongos。

Specifies the list of authentication mechanisms the server accepts. 指定服务器接受的身份验证机制的列表。Set this to one or more of the following values. 将其设置为以下一个或多个值。If you specify multiple values, use a comma-separated list and no spaces. For descriptions of the authentication mechanisms, see Authentication.如果指定多个值，请使用逗号分隔的列表，并且不要使用空格。有关身份验证机制的描述，请参阅身份验证。

Value值	Description描述
SCRAM-SHA-1	RFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function.使用SHA-1散列函数的标准Salted质询-响应认证机制。
SCRAM-SHA-256	RFC 7677 standard Salted Challenge Response Authentication Mechanism using the SHA-256 hash function.使用SHA-256散列函数的标准Salted质询-响应认证机制。
MONGODB-X509	MongoDB TLS/SSL certificate authentication.MongoDB TLS/SSL证书身份验证。
GSSAPI (Kerberos)	External authentication using Kerberos. 使用Kerberos的外部身份验证。This mechanism is available only in MongoDB Enterprise.此机制仅在MongoDB Enterprise中可用。
PLAIN (LDAP SASL)	External authentication using LDAP. 使用LDAP的外部身份验证。You can also use PLAIN for authenticating in-database users. 您还可以使用PLAIN对数据库中的用户进行身份验证。PLAIN transmits passwords in plain text. PLAIN以纯文本形式传输密码。This mechanism is available only in MongoDB Enterprise.此机制仅在MongoDB Enterprise中可用。
MONGODB-OIDC	OpenID Connect is an authentication layer built on top of OAuth2. OpenIDConnect是一个建立在OAuth2之上的身份验证层。This mechanism is available only in MongoDB Enterprise.此机制仅在MongoDB Enterprise中可用。

You can only set authenticationMechanisms during start-up.您只能在启动期间设置authenticationMechanisms。

For example, to specify both PLAIN and SCRAM-SHA-256 as the authentication mechanisms, use the following command:例如，要指定PLAIN和SCRAM-SHA-256作为身份验证机制，请使用以下命令：

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

awsSTSRetryCount

Changed in version 7.0.7.0版更改。(Also starting in 6.0.7, 5.0.18, 4.4.22)

In previous versions, AWS IAM authentication retried only when the server returned an HTTP 500 error.在以前的版本中，只有当服务器返回HTTP 500错误时，才会重试AWS IAM身份验证。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 2

For MongoDB deployments using AWS IAM credentials or AWS IAM environment variables.对于使用AWS IAM凭据或AWS IAM环境变量的MongoDB部署。

Maximim number of AWS IAM authentication retries after a connection failure.连接失败后AWS IAM身份验证重试的最大次数。

The following example sets awsSTSRetryCount to 15 retries:以下示例将awsSTSRetryCount设置为15次重试：

mongod --setParameter awsSTSRetryCount=15

Alternatively, the following examples uses the setParameter command within mongosh:或者，以下示例在mongosh中使用setParameter命令：

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

clusterAuthMode

Available for both mongod and mongos.可用于mongod和mongos。

Set the clusterAuthMode to either sendX509 or x509. Useful during rolling upgrade to use x509 for membership authentication to minimize downtime.将clusterAuthMode设置为sendX509或x509。在滚动升级期间使用x509进行成员身份验证以最大限度地减少停机时间非常有用。

For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .有关TLS/SSL和MongoDB的更多信息，请参阅配置mongod和mongos的TLS/SSL以及针对客户端的TLS/SSL配置。

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

enableLocalhostAuthBypass

Available for both mongod and mongos.可用于mongod和mongos。

Specify 0 or false to disable localhost authentication bypass. Enabled by default.指定0或false以禁用localhost身份验证旁路。默认情况下已启用。

enableLocalhostAuthBypass is not available using setParameter database command. enableLocalhostAuthBypass无法使用setParameter数据库命令。Use the setParameter option in the configuration file or the --setParameter option on the command line.使用配置文件中的setParameter选项或命令行中的--setParameter选项。

See Localhost Exception for more information.有关详细信息，请参阅Localhost异常。

KeysRotationIntervalSec

Default默认值: 7776000 seconds (90 days)

Specifies the number of seconds for which an HMAC signing key is valid before rotating to the next one. 指定HMAC签名键在旋转到下一个键之前有效的秒数。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.您只能在启动期间设置KeysRotationIntervalSec，不能使用setParameter数据库命令更改此设置。

ldapForceMultiThreadMode

New in version 4.2. 4.2版新增。

Default默认值: false

Enables the performance of concurrent LDAP operations.启用并发LDAP操作的性能。

Note

Only if you are certain that your instance of libldap is safe to use in this mode, enable this flag. 只有当您确信您的libldap实例在这种模式下使用是安全的时，才启用此标志。You may experience crashes of the MongoDB process if the libldap version you are using is not thread safe.如果您使用的libldap版本不是线程安全的，那么您可能会遇到MongoDB进程崩溃的情况。

You must use ldapForceMultiThreadMode to use LDAP connection pool. To enable LDAP connection pool, set ldapForceMultiThreadMode and ldapUseConnectionPool to true.必须使用ldapForceMultiThreadMode才能使用LDAP连接池。要启用LDAP连接池，请将ldapForceMultiThreadMode和ldapUseConnectionPool设置为true。

Tip

If you have any concerns regarding your MongoDB version, OS version or libldap version, please contact MongoDB Support.如果您对MongoDB版本、操作系统版本或libldap版本有任何疑问，请联系MongoDB支持。

ldapRetryCount

New in version 6.1. 6.1版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 0

For MongoDB deployments using LDAP Authorization.对于使用LDAP授权的MongoDB部署。

Number of operation retries by the server LDAP manager after a network error.网络错误后服务器LDAP管理器重试操作的次数。

For example, the following sets ldapRetryCount to 3 seconds:例如，以下将ldapRetryCount设置为3秒：

mongod --ldapRetryCount=3

Or, if using the setParameter command within mongosh:或者，如果在mongosh中使用setParameter命令：

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

ldapUserCacheInvalidationInterval

Changed in version 5.2.5.2版更改。

Available for mongod only.仅适用于mongod。

Note

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:从MongoDB 5.2开始，从LDAP服务器检索的缓存用户信息的更新间隔取决于ldapShouldRefreshUserCacheEntries：

• If true, use ldapUserCacheRefreshInterval.如果为true，请使用ldapUserCacheRefreshInterval。
• If false, use ldapUserCacheInvalidationInterval.如果为false，请使用ldapUserCacheInvalidationInterval。

For use with MongoDB deployments using LDAP Authorization.用于使用LDAP授权的MongoDB部署。

The interval (in seconds) that the mongod instance waits between external user cache flushes. mongod实例在外部用户缓存刷新之间等待的时间间隔（以秒为单位）。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.MongoDB刷新外部用户缓存后，下次LDAP授权用户发出操作时，MongoDB会从LDAP服务器重新获取授权数据。

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. 增加指定的值会增加MongoDB和LDAP服务器不同步的时间，但会减少LDAP服务器上的负载。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.相反，减少指定的值可以减少MongoDB和LDAP服务器不同步的时间，同时增加LDAP服务器上的负载。

Defaults to 30 seconds.默认为30秒。

ldapUserCacheRefreshInterval

New in version 5.2. 5.2版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 30 seconds

Note

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:从MongoDB 5.2开始，从LDAP服务器检索的缓存用户信息的更新间隔取决于ldapShouldRefreshUserCacheEntries：

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

For MongoDB deployments using LDAP Authorization.对于使用LDAP授权的MongoDB部署。

The interval in seconds that mongod waits before refreshing the cached user information from the LDAP server.mongod在从LDAP服务器刷新缓存的用户信息之前等待的时间间隔（秒）。

The maximum interval is 86,400 seconds (24 hours).最大间隔为86400秒（24小时）。

For example, the following sets ldapUserCacheRefreshInterval to 4000 seconds:例如，以下将ldapUserCacheRefreshInterval设置为4000秒：

mongod --setParameter ldapUserCacheRefreshInterval=4000

Or, if using the setParameter command within mongosh:或者，如果在mongosh中使用setParameter命令：

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

ldapUserCacheStalenessInterval

New in version 5.2. 5.2版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 90 seconds

For MongoDB deployments using LDAP Authorization.对于使用LDAP授权的MongoDB部署。

The interval in seconds that mongod retains the cached LDAP user information after the last cache refresh.mongod在上次缓存刷新后保留缓存的LDAP用户信息的时间间隔（秒）。

If more than ldapUserCacheStalenessInterval seconds elapse without a successful refresh of the user information from the LDAP server, then mongod:如果超过ldapUserCacheStalenessInterval秒，LDAP服务器上的用户信息没有成功刷新，则mongod:

• Invalidates the cached LDAP user information.使缓存的LDAP用户信息无效。
• Is unable to authenticate new sessions for LDAP users until mongod connects to the LDAP server and authorizes the LDAP user.在mongod连接到LDAP服务器并授权LDAP用户之前，无法为LDAP用户验证新会话。
• Authorizes any existing sessions that use previously authenticated LDAP users if mongod is unable to connect to the LDAP server. 如果mongod无法连接到LDAP服务器，则授权使用先前已验证LDAP用户的任何现有会话。When mongod reconnects to the LDAP server, mongod ensures the LDAP users are correctly authorized.当mongod重新连接到LDAP服务器时，mongod会确保LDAP用户得到正确授权。

The maximum interval is 86,400 seconds (24 hours).最大间隔为86400秒（24小时）。

For example, the following sets ldapUserCacheStalenessInterval to 4000 seconds:例如，以下将ldapUserCacheStalenessInterval设置为4000秒：

mongod --setParameter ldapUserCacheStalenessInterval=4000

Or, if using the setParameter command within mongosh:或者，如果在mongosh中使用setParameter命令：

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

ldapUseConnectionPool

Specifies whether MongoDB should use connection pooling when connecting to the LDAP server for authentication/authorization.指定MongoDB在连接到LDAP服务器进行身份验证/授权时是否应使用连接池。

MongoDB uses the following default values:MongoDB使用以下默认值：

• true on Windows.在Windows上为true。
• true on Linux where MongoDB Enterprise binaries are linked against libldap_r.在Linux上为true，其中MongoDB Enterprise二进制文件链接到libldap_r。
• false on Linux where MongoDB Enterprise binaries are linked against libldap.在Linux上为false，其中MongoDB Enterprise二进制文件是根据libldap链接的。

You can only set ldapUseConnectionPool during start-up, and cannot change this setting with the setParameter database command.您只能在启动期间设置ldapUseConnectionPool，不能使用setParameter数据库命令更改此设置。

ldapConnectionPoolUseLatencyForHostPriority

New in version 4.2.1. 4.2.1版新增。

Default默认值: true

A boolean that determines whether the LDAP connection pool (see ldapUseConnectionPool) should use latency of the LDAP servers to determine the connection order (from lowest latency to highest).一个布尔值，用于确定LDAP连接池（请参阅ldapUseConnectionPool）是否应使用LDAP服务器的延迟来确定连接顺序（从最低延迟到最高延迟）。

You can only set ldapConnectionPoolUseLatencyForHostPriority during start-up, and cannot change this setting during run time with the setParameter database command.您只能在启动期间设置ldapConnectionPoolUseLatencyForHostPriority，而不能在运行时使用setParameter数据库命令更改此设置。

ldapConnectionPoolMinimumConnectionsPerHost

New in version 4.2.1. 4.2.1版新增。

Default默认值: 1

The minimum number of connections to keep open to each LDAP server.对每个LDAP服务器保持打开状态的最小连接数。

You can only set ldapConnectionPoolMinimumConnectionsPerHost during start-up, and cannot change this setting during run time with the setParameter database command.您只能在启动期间设置ldapConnectionPoolMinimumConnectionsPerHost，而不能在运行时使用setParameter数据库命令更改此设置。

ldapConnectionPoolMaximumConnectionsPerHost

New in version 4.2.1. 4.2.1版新增。

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

Default默认值: 2147483647

The maximum number of connections to keep open to each LDAP server.要保持对每个LDAP服务器打开的最大连接数。

You can only set ldapConnectionPoolMaximumConnectionsPerHost during start-up, and cannot change this setting during run time with the setParameter database command.您只能在启动期间设置ldapConnectionPoolMaximumConnectionsPerHost，而不能在运行时使用setParameter数据库命令更改此设置。

ldapConnectionPoolMaximumConnectionsInProgressPerHost

New in version 4.2.1. 4.2.1版新增。

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

Default默认值: 2

The maximum number of in-progress connect operations to each LDAP server.每个LDAP服务器正在进行的连接操作的最大数目。

You can only set ldapConnectionPoolMaximumConnectionsInProgressPerHost during start-up, and cannot change this setting with the setParameter database command.您只能在启动期间设置ldapConnectionPoolMaximumConnectionsInProgressPerHost，不能使用setParameter数据库命令更改此设置。

ldapConnectionPoolHostRefreshIntervalMillis

New in version 4.2.1. 4.2.1版新增。

Default默认值: 60000

The number of milliseconds in-between health checks of the pooled LDAP connections.池LDAP连接的运行状况检查之间的毫秒数。

You can only set ldapConnectionPoolHostRefreshIntervalMillis during start-up, and cannot change this setting with the setParameter database command.您只能在启动期间设置ldapConnectionPoolHostRefreshIntervalMillis，不能使用setParameter数据库命令更改此设置。

ldapConnectionPoolIdleHostTimeoutSecs

New in version 4.2.1. 4.2.1版新增。

Default默认值: 300

The maximum number of seconds that the pooled connections to an LDAP server can remain idle before being closed.到LDAP服务器的池连接在关闭之前可以保持空闲的最大秒数。

You can only set ldapConnectionPoolIdleHostTimeoutSecs during start-up, and cannot change this setting with the setParameter database command.您只能在启动期间设置ldapConnectionPoolIdleHostTimeoutSecs，不能使用setParameter数据库命令更改此设置。

ldapShouldRefreshUserCacheEntries

New in version 5.2. 5.2版新增。

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: true

For MongoDB deployments using LDAP Authorization.对于使用LDAP授权的MongoDB部署。

Starting in MongoDB 5.2, the update interval for cached user information retrieved from an LDAP server depends on ldapShouldRefreshUserCacheEntries:从MongoDB 5.2开始，从LDAP服务器检索的缓存用户信息的更新间隔取决于ldapShouldRefreshUserCacheEntries：

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

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

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

maxValidateMemoryUsageMB

New in version 5.0:5.0版新增：(Also available starting in 4.4.7.)

Default默认值: 200

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

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

oidcIdentityProviders

New in version 7.0. 7.0版新增。

Use this parameter to specify identity provider (IDP) configurations when using OpenID Connect Authentication.

oidcIdentityProviders accepts an array of zero or more identity provider (IDP) configurations. An empty array (default) indicates no OpenID Connect support is enabled. When more than one IDP is defined, oidcIdentityProviders uses the matchPattern field to select an IDP. Array order determines the priority and the first IDP is always selected.

oidcIdentityProviders Fields

Field字段	Necessity必要性	Description描述	Type类型
issuer	Required必要的	The issuer URI of the IDP that the server should accept tokens from. This must match the iss field in any JWT used for authentication.	string
authNamePrefix	Required必要的	Unique prefix applied to each generated UserName and RoleName used in authorization. authNamePrefix can only contain the following characters: alphanumeric characters (combination of a to z and 0 to 9) hyphens (-) underscores (_)	string
matchPattern	Conditional	Required when more than one IDP is defined. Regex pattern used to determine which IDP should be used. matchPattern matches against usernames. Array order determines the priority and the first IDP is always selected. This is not a security mechanism. matchPattern serves only as an advisory to clients. MongoDB accepts tokens issued by the IDP whose principal names do not match this pattern.	string
clientId	Required必要的	ID provided by the IDP to identify the client that receives the access tokens.	string
audience	Required必要的	Specifies the application or service that the access token is intended for.	string
requestScopes	Optional可选的	Permissions and access levels that MongoDB requests from the IDP.	array[ string ]
principalName	Optional可选的	The claim to be extracted from the access token containing MongoDB user identifiers. The default value is sub (stands for subject).	string
authorizationClaim	Required必要的	Claim extracted from access token that contains MongoDB role names.	string
logClaims	Optional可选的	List of access token claims to include in log and audit messages upon authentication completion.	array[ string ]
JWKSPollSecs	Optional可选的	Frequency, in seconds, to request an updated JSON Web Key Set (JWKS) from the IDP. A setting of 0 disables polling.	integer

You can only set oidcIdentityProviders during startup in the configuration file or with the --setParameter option on the command line.

ocspEnabled

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

Tip

See also: 另请参阅：

• ocspValidationRefreshPeriodSecs
• tlsOCSPStaplingTimeoutSecs
• tlsOCSPVerifyTimeoutSecs

ocspValidationRefreshPeriodSecs

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

Starting in MongoDB 5.0, the rotateCertificates command and db.rotateCertificates() method will also refresh any stapled OCSP responses.

Tip

See also: 另请参阅：

• ocspEnabled
• tlsOCSPStaplingTimeoutSecs
• tlsOCSPVerifyTimeoutSecs

opensslCipherConfig

Available on Linux only

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

Specify the cipher string for OpenSSL when using TLS/SSL encryption. For a list of cipher strings, see https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Multiple cipher strings can be provided as a colon-separated list.

Note

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

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

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

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

opensslCipherSuiteConfig

New in version 5.0. 5.0版新增。

Available on Linux only

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

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

Note

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

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

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

opensslDiffieHellmanParameters

Available on Linux only

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

This parameter is not supported for use with TLS 1.3.

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

Note

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

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

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

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

saslauthdPath

Available for both mongod and mongos.可用于mongod和mongos。

Note

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

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

saslHostName

Available for both mongod and mongos.可用于mongod和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: Configure MongoDB with Kerberos Authentication on Linux
• Windows: Configure MongoDB with Kerberos Authentication on Windows

saslServiceName

Available for both mongod and mongos.可用于mongod和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

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 10000

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

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

For example, the following sets the scramIterationCount to 12000.

mongod --setParameter scramIterationCount=12000

Or, if using the setParameter command within mongosh:

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

Tip

See also: 另请参阅：

• db.changeUserPassword()
• db.createUser()
• db.updateUser()

scramSHA256IterationCount

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 15000

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

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

For example, the following sets the scramSHA256IterationCount to 20000.

mongod --setParameter scramSHA256IterationCount=20000

Or, if using the setParameter command within mongosh:

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

Tip

See also: 另请参阅：

• db.changeUserPassword()
• db.createUser()
• db.updateUser()

sslMode

Available for both mongod and mongos.可用于mongod和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 Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .

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

Tip

See also: 另请参阅：

tlsMode

tlsMode

New in version 4.2. 4.2版新增。

Available for both mongod and mongos.可用于mongod和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 Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .

Tip

See also: 另请参阅：

sslMode

tlsClusterAuthX509Override

New in version 7.0. 7.0版新增。

Overrides the clusterAuthX509 configuration options.

setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB Server }

The parameter supports attributes and extensionValue overrides.

When the server authenticates connections from members, it analyzes the X.509 certificate to determine whether it belongs to a cluster member. If the server uses the attributes setting or the attributes field on the tlsClusterAuthX509Override parameter, it checks the Distinguished Name (DN) values of the certificate. If the extensionValue setting or the extensionValue field of the tlsClusterAuthX509Override parameter is set, it checks the extension values of the certificate. If it finds a match, it authorizes the connection as a peer.

Use this parameter to rotate certificates when the new certificates have different attributes or extension values.

tlsOCSPStaplingTimeoutSecs

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

Tip

See also: 另请参阅：

• ocspEnabled
• ocspValidationRefreshPeriodSecs
• tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

New in version 4.4: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 server certificates.

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

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

Tip

See also: 另请参阅：

• ocspEnabled
• ocspValidationRefreshPeriodSecs
• tlsOCSPStaplingTimeoutSecs

tlsWithholdClientCertificate

New in version 4.2. 4.2版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: false

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. 4.2版新增。

Available for both mongod and mongos.可用于mongod和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 Rolling Update of x.509 Cluster Certificates that Contain New DN.

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

tlsX509ExpirationWarningThresholdDays

New in version 4.4. 4.4版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值 : 30

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

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

This parameter has a minimum value of 0.

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

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

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

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

sslWithholdClientCertificate

Deprecated since version 4.2: Use tlsWithholdClientCertificate instead.

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: false

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

Available for mongos only.

Default默认值: 30

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

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 0

Note

Enterprise Feature

Available in MongoDB Enterprise only.

The number of milliseconds to wait before informing clients that their authentication attempt has failed. This parameter may be in the range 0 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

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: true

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

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

General Parameters

allowDiskUseByDefault

Available for mongod only.仅适用于mongod。

Default默认值: True

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

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

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

mongod --setParameter allowDiskUseByDefault=false

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

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

connPoolMaxShardedConnsPerHost

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 200

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

Note

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

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

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

mongos --setParameter connPoolMaxShardedConnsPerHost=250

connPoolMaxShardedInUseConnsPerHost

Available for both mongod and mongos.可用于mongod和mongos。

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

By default, the parameter is unset.默认情况下，该参数是未设置的。

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

mongos --setParameter connPoolMaxShardedInUseConnsPerHost=100

Tip

See also: 另请参阅：

connPoolMaxShardedConnsPerHost

httpVerboseLogging

Available for both mongod and mongos.可用于mongod和mongos。

Adds more verbose tracing for curl on Linux and macOS. Has no affect on Windows.

By default, the parameter is unset.默认情况下，该参数是未设置的。

You can only set httpVerboseLogging during startup in the config file or on the command line. For example:例如：

mongos --setParameter httpVerboseLogging=true

shardedConnPoolIdleTimeoutMinutes

Available for both mongod and mongos.可用于mongod和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

Tip

See also: 另请参阅：

connPoolMaxShardedConnsPerHost

slowConnectionThresholdMillis

New in version 6.3. 6.3版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 100

Sets the time limit in milliseconds to log the establishment of slow server connections.

If a connection takes longer to establish than the slowConnectionThresholdMillis parameter, an event is added to the log with the message msg field set to "Slow connection establishment".

The following example sets slowConnectionThresholdMillis to 250 milliseconds.

mongod --setParameter slowConnectionThresholdMillis=250

Or, if using the setParameter command within mongosh:

db.adminCommand( { setParameter: 1, slowConnectionThresholdMillis: 250 } )

connPoolMaxConnsPerHost

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 200

Sets the maximum size of the legacy connection pools for outgoing connections to other mongod instances in the global connection pool. The size of a pool does not prevent the creation of additional connections, but does prevent a connection pool from retaining connections in excess of the value 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

Available for both mongod and mongos.可用于mongod和mongos。

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

By default, the parameter is unset.默认情况下，该参数是未设置的。

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

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

See also: 另请参阅：

connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes

Available for both mongod and mongos.可用于mongod和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

Tip

See also: 另请参阅：

connPoolMaxShardedConnsPerHost

cursorTimeoutMillis

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: 600000 (10 minutes)

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

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

mongod --setParameter cursorTimeoutMillis=300000

Or, if using the setParameter command within mongosh:

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.

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

failIndexKeyTooLong defaults to true.

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

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

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

mongod --setParameter failIndexKeyTooLong=false

maxNumActiveUserIndexBuilds

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 3

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

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

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

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

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

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

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

See also:

• maxIndexBuildMemoryUsageMegabytes
• Index Builds on Populated Collections

notablescan

Available for mongod only.仅适用于mongod。

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 Evaluate Performance of Current Operations and Optimize Query Performance sections and using the logLevel parameter, 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.仅适用于mongod。

Default默认值: true

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

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

Important

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

tcpFastOpenServer

New in version 4.4. 4.4版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Default默认值: true

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

Windows

The following Windows operating systems support TFO:

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

macOS

macOS 10.11 (El Capitan) and later support TFO.

Linux

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

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

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

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

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

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

Tip

See also: 另请参阅：

RFC7413.

tcpFastOpenClient

New in version 4.4. 4.4版新增。

Available for both mongod and mongos.可用于mongod和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 Support for TCP Fast Open for more information on MongoDB TFO support.

Tip

See also: 另请参阅：

RFC7413.

tcpFastOpenQueueSize

New in version 4.4. 4.4版新增。

Available for both mongod and mongos.可用于mongod和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 Support for TCP Fast Open for more information on MongoDB TFO support.

Tip

See also: 另请参阅：

• RFC7413 TCP Fast Open Section 5: Security Considerations
• RFC7413 TCP Fast Open Section 6: TFO Applicability

disableJavaScriptJIT

Available for mongod only.仅适用于mongod。

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

indexMaxNumGeneratedKeysPerDocument

New in version 5.3. 5.3版新增。

Default默认值: 100000

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

maxIndexBuildMemoryUsageMegabytes

Default默认值:

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

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

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

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

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

Tip

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

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

reportOpWriteConcernCountersInServerStatus

Default默认值: false

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

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

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

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

watchdogPeriodSeconds

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: -1 (disabled)

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

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

Valid values for watchdogPeriodSeconds are:

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

Note

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

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

mongod --setParameter watchdogPeriodSeconds=60

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

Once enabled,

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

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

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

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

Note

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

tcmallocReleaseRate

New in version 4.2.3. 4.2.3版新增。

Default: 1.0

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

To modify the release rate during run time, you can use the setParameter command; for example:例如：

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

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

mongod --setParameter "tcmallocReleaseRate=5.0"

fassertOnLockTimeoutForStepUpDown

New in version 5.3. 5.3版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Default: 15 seconds

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

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

The following example disables nodes from fasserting:

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

Logging Parameters

logLevel

Available for both mongod and mongos.可用于mongod和mongos。

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

The default logLevel is 0 (Informational).

The following example sets the logLevel to 2:

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

Tip

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.可用于mongod和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}"

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

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

maxLogSizeKB

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: non-negative integer

Default默认值: 10

Specifies the maximum size, in kilobytes, for an individual attribute field in a log entry; attributes exceeding this limit are truncated.

Truncated attribute fields print field content up to the maxLogSizeKB limit and excise field content past that limit, retaining valid JSON formatting. Log entries that contain truncated attributes append 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.可用于mongod和mongos。

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

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

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

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

Tip

See also: 另请参阅：

systemLog.quiet

redactClientLogData

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Note

Enterprise Feature

Available in MongoDB Enterprise only.

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

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

To enable log redaction at startup, you can either:

• Start mongod with the --redactClientLogData option:

  mongod --redactClientLogData

• Set the security.redactClientLogData option in the configuration file:

  security:
     redactClientLogData: true
     ...

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

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

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

Tip

See also: 另请参阅：

security.redactClientLogData

redactEncryptedFields

New in version 6.1.0. 6.1.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: true

Configures mongod and mongos to redact field values of encrypted Binary data from all log messages.

• If the redactClientLogData parameter or the security.redactClientLogData setting is set to false and redactEncryptedFields is set to true (the default), encrypted fields are redacted from all log messages.
• If the redactClientLogData parameter or security.redactClientLogData setting is set to true, all fields are redacted, regardless of the redactEncryptedFields setting.

traceExceptions

Available for both mongod and mongos.可用于mongod和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 } )

Tip

See also: 另请参阅：

systemLog.traceAllExceptions

suppressNoTLSPeerCertificateWarning

Available for both mongod and mongos.可用于mongod和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} )

gEnableDetailedConnectionHealthMetricLogLines

New in version 7.0. 7.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: true

Determines whether to enable specific log messages related to cluster connection health metrics. If gEnableDetailedConnectionHealthMetricLogLines is set to false, the following log messages are turned off, but MongoDB still collects data on the cluster connection health metrics:

Log Message	Description描述
Accepted TLS connection from peer	Indicates that the server successfully parsed the peer certificate during the TLS handshake with an accepted ingress connection.
Ingress TLS handshake complete	Indicates that the TLS handshake with an ingress connection is complete.
Hello completed	Indicates that the initial connection handshake completed on an incoming client connection. MongoDB displays the log message only with the first hello command.
Auth metrics report	Specifies the completion of a step in the authentication conversation.
Received first command on ingress connection since session start or auth handshake	Indicates that an ingress connection received the first command that is not part of the handshake.
Slow network response send time	Indicates that the time spent, in milliseconds, to send the response back to the client over an ingress connection takes more time than the duration defined by the slowMS server parameter.
Completed client-side verification of OCSP request	If the peer doesn't include an OCSP response to the TLS handshake when an egress TLS connection is established, the server must send an OCSP request to the certificate authority. MongoDB writes this log message when the certificate authority receives the OCSP response.
Slow connection establishment	Indicates that the time taken to send a response back to the client over an ingress connection takes longer than the threshold specified with the slowConnectionThresholdMillis parameter. MongoDB also emits this log message when the connection establishment times out.
Operation timed out while waiting to acquire connection	Indicates that an operation timed out while waiting to acquire an egress connection.
Acquired connection for remote operation and completed writing to wire	Indicates that the server took one millisecond or longer to write an outgoing request on an egress connection, counting from the instant when the connection establishes.

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):

diagnosticDataCollectionEnabled

Available for both mongod and mongos.可用于mongod和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

Available for mongos only.

Type类型: String

Warning

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

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

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

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

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

diagnosticDataCollectionDirectorySizeMB

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 200

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

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

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

diagnosticDataCollectionFileSizeMB

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 10

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

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

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

The minimum value for diagnosticDataCollectionFileSizeMB is 1 megabyte.

diagnosticDataCollectionPeriodMillis

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 1000

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

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

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

The minimum value for diagnosticDataCollectionPeriodMillis is 100 milliseconds.

Replication and Consistency

disableSplitHorizonIPCheck

New in version 5.0.0. 5.0.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: false

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

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

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

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

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

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

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

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

setParameter:
   disableSplitHorizonIPCheck: true

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

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

enableOverrideClusterChainingSetting

New in version 5.0.2. 5.0.2版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: false

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

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

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

mongod --setParameter enableOverrideClusterChainingSetting=true

logicalSessionRefreshMillis

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 300000 (5 minutes)

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

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

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

mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 30

Warning

For testing purposes only

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

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

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

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

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

mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 31536000 (1 year)

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

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

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

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

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 1000000

The maximum number of sessions that can be cached.

You can only set maxSessions during start-up.

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

mongod --setParameter maxSessions=1000

oplogBatchDelayMillis

New in version 6.0. 6.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 0

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

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

You can only set oplogBatchDelayMillis at startup. You cannot set oplogBatchDelayMillis during run time.

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

mongod --setParameter oplogBatchDelayMillis=20

storeFindAndModifyImagesInSideCollection

New in version 5.1. 5.1版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: true

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

If storeFindAndModifyImagesInSideCollection is:

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

Keep storeFindAndModifyImagesInSideCollection set to true if you:

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

Note

Secondaries may experience increased CPU usage when storeFindAndModifyImagesInSideCollection is true.

For example, to set storeFindAndModifyImagesInSideCollection to false during startup:

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

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

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

TransactionRecordMinimumLifetimeMinutes

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 30

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

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

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

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

See also: 另请参阅：

localLogicalSessionTimeoutMinutes

enableFlowControl

New in version 4.2. 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. 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. 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. 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. 4.4版新增。

Available for mongod only.仅适用于mongod。

Type类型: String

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

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

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

You cannot specify a tag set or maxStalenessSeconds to initialSyncSourceReadPreference.

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

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

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

initialSyncMethod

New in version 5.2. 5.2版新增。

Available for mongod only.仅适用于mongod。

Type类型: String

Default默认值: logical

Available only in MongoDB Enterprise.

Method used for initial sync.

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

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

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

maxNumSyncSourceChangesPerHour

New in version 5.0. 5.0版新增。

Type类型: integer

Default默认值: 3

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

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

oplogFetcherUsesExhaust

New in version 4.4. 4.4版新增。

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: true

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

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

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

oplogInitialFindMaxSeconds

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 60

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

replWriterThreadCount

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 16

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

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

Tip

See also: 另请参阅：

replWriterMinThreadCount

replWriterMinThreadCount

New in version 5.0. 5.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 0

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

Parallel application of replication operations uses up to replWriterThreadCount threads. If replWriterMinThreadCount is configured with a value less than replWriterThreadCount, the thread pool will timeout idle threads until the total count of threads in the thread pool is equal to replWriterMinThreadCount.

replWriterMinThreadCount must be configured with a value that is less than or equal to replWriterThreadCount.

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.

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

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

waitForSecondaryBeforeNoopWriteMS

Available for mongod only.仅适用于mongod。

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 run time, you can also set the parameter with the setParameter command:

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

createRollbackDataFiles

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: true

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 run time, you can also set the parameter with the setParameter command:

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

For more information, see Collect Rollback Data.

replBatchLimitBytes

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 to limit the oplog application batch size:

mongod --setParameter replBatchLimitBytes=67108864

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

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

mirrorReads

New in version 4.4. 4.4版新增。

Available for mongod only.仅适用于mongod。

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 (specifically, priority greater than 0) secondaries. That is, the primary mirrors reads to each electable secondary at the specified sampling rate. Valid values are: 0.0 Turns off mirroring. 1.0 The primary mirrors all operations that supports mirroring to each electable secondary. Number between 0.0 and 1.0 (exclusive) The primary randomly samples each electable secondary at the specified rate to be sent mirrored reads. For example, given a replica set with a primary and two electable secondaries and a sampling rate of 0.10, the primary mirrors reads to each electable secondary at the sampling rate of 10 percent such that one read may be mirrored to one secondary and not to the other or to both or to neither. That is, if the primary 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 mongosh session that is connected to a running mongod, do not enclose the document in quotes:

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

allowMultipleArbiters

New in version 5.3. 5.3版新增。

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: false

Specifies whether the replica set allows the use of multiple arbiters.

The use of multiple arbiters is not recommended:

• Multiple arbiters prevent the reliable use of the majority write concern. MongoDB counts arbiters in calculating a membership majority, but arbiters do not store data. With the inclusion of multiple arbiters, it's possible for a majority write operation to return success before the write replicates to a majority of data bearing nodes.
• Multiple arbiters allow replica sets to accept writes even when the replica set doesn't have sufficient secondaries for data replication.

For more information, see Concerns with Multiple Arbiters.

The parameter can only be set during startup:

mongod --setParameter allowMultipleArbiters=true

Sharding Parameters

analyzeShardKeyCharacteristicsDefaultSampleSize

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 10000000

If sampleRate and sampleSize are not set when you run analyzeShardKey, specifies the number of documents to sample when calculating shard key characteristics metrics. Must be greater than 0.

This example sets analyzeShardKeyCharacteristicsDefaultSampleSize to 10000 at startup:

mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

During run time, you can set or modify the parameter with the setParameter command:

db.adminCommand( { setParameter: 1, analyzeShardKeyCharacteristicsDefaultSampleSize: 10000 } )

analyzeShardKeyNumMostCommonValues

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 5

Specifies the number of most common shard key values to return. If the collection contains fewer unique shard keys than this value, analyzeShardKeyNumMostCommonValues returns that number of most common values. Must be greater than 0 and less than or equal to 1000.

This example sets analyzeShardKeyNumMostCommonValues to 3 at startup:

mongod --setParameter analyzeShardKeyNumMostCommonValues=3

During run time, you can set or modify the parameter with the setParameter command:

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

analyzeShardKeyNumRanges

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 100

Specifies the number of ranges to partition the shard key space into when calculating the hotness of shard key ranges. Must be greater than 0 and less than or equal to 10000.

This example sets analyzeShardKeyNumRanges to 50 at startup:

mongod --setParameter analyzeShardKeyNumRanges=50

During run time, you can set or modify the parameter with the setParameter command:

db.adminCommand( { setParameter: 1, analyzeShardKeyNumRanges: 50 } )

analyzeShardKeyMonotonicityCorrelationCoefficientThreshold

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: double

Default默认值: 0.7

Specifies the RecordId correlation coefficient threshold used to determine if a shard key is monotonically changing in insertion order. Must be greater than 0 and less than or equal to 1.

This example sets analyzeShardKeyMonotonicityCorrelationCoefficientThreshold to 1 at startup:

mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1

During run time, you can set or modify the parameter with the setParameter command:

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

autoMergerIntervalSecs

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 3600

When AutoMerger is enabled, specifies the amount of time between automerging rounds, in seconds. The default value is 3600 seconds, or one hour.

autoMergerIntervalSecs can only be set on config servers.

This example sets autoMergerIntervalSecs to 7200 milliseconds, or two hours, at startup:

mongod --setParameter autoMergeInterval=7200

During run time, you can set or modify the parameter with the setParameter command:

db.adminCommand( { setParameter: 1, autoMergeInterval: 7200 } )

autoMergerThrottlingMS

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 15000

When AutoMerger is enabled, specifies the minimum amount time between merges initiated by the AutoMerger on the same collection, in milliseconds.

autoMergerThrottlingMS can only be set on config servers.

This example sets autoMergerThrottlingMS to 60000 milliseconds, or one minute, at startup:

mongod --setParameter autoMergerThrottlingMS=60000

During run time, you can set or modify the parameter with the setParameter command:

db.adminCommand( { setParameter: 1, autoMergerThrottlingMS: 60000 } )

balancerMigrationsThrottlingMs

New in version 7.0:7.0版新增：(Also available starting in 6.3.1, 6.0.6, 5.0.18)

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 1000

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

This example sets balancerMigrationsThrottlingMs to 2000 milliseconds at startup:

mongod --setParameter balancerMigrationsThrottlingMs=2000

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

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

chunkDefragmentationThrottlingMS

New in version 5.3. 5.3版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 0

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

The following example sets chunkDefragmentationThrottlingMS to 10 milliseconds:

mongod --setParameter chunkDefragmentationThrottlingMS=10

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

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

chunkMigrationConcurrency

Available starting in MongoDB 7.0, 6.3, 6.0.6 (and 5.0.15).

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 1

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

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

Maximum value is 500.

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

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

The following example sets chunkMigrationConcurrency to 5:

mongod --setParameter chunkMigrationConcurrency=5

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

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

To configure collection balancing, see configureCollectionBalancing.

To learn about defragmenting sharded collections, see Defragment Sharded Collections.

disableResumableRangeDeleter

New in version 4.4. 4.4版新增。

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: false

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

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

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

Important

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

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

mongod --setParameter disableResumableRangeDeleter=false

enableShardedIndexConsistencyCheck

New in version 4.4:4.4版新增：(Also available starting in 4.2.6.)

Available for mongod only.仅适用于mongod。

Type类型: boolean

Default默认值: true

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

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

mongod --setParameter enableShardedIndexConsistencyCheck=false

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

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

Tip

See also: 另请参阅：

• shardedIndexConsistencyCheckIntervalMS parameter
• shardedIndexConsistency metrics returned by the serverStatus command.

opportunisticSecondaryTargeting

New in version 6.1.0. 6.1.0版新增。

Available for mongos only.

Type类型: boolean

Default默认值: false

Determines whether mongos performs opportunistic reads against replica sets.

When this parameter is set to true, mongos directs secondary reads to secondaries with active connections. It sends the request to the first secondary that accepts the connection. When this parameter is set to false, mongos holds secondary reads until it can establish a connection to a specific secondary, (except in the case of hedged reads).

Note

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

For example, to set opportunisticSecondaryTargeting during startup:

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

New in version 4.4:4.4版新增：(Also available starting in 4.2.6.)

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 600000

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

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

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

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

See also: 另请参阅：

• enableShardedIndexConsistencyCheck parameter
• shardedIndexConsistency metrics returned by the serverStatus commandq

enableFinerGrainedCatalogCacheRefresh

New in version 4.4. 4.4版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: boolean

Default默认值: true

This parameter allows the catalog cache to be refreshed only if the shard needs to be refreshed. If disabled, any stale chunk will cause the entire chunk distribution for a collection to be considered stale and force all routers who contact the shard to refresh their shard catalog cache.

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

mongod --setParameter enableFinerGrainedCatalogCacheRefresh=true
mongos --setParameter enableFinerGrainedCatalogCacheRefresh=true

Tip

See also: 另请参阅：

• Sharding
• shardingStatistics.catalogCache

maxTimeMSForHedgedReads

New in version 4.4. 4.4版新增。

Available for mongos only.

Type类型: integer

Default默认值: 150

Specifies the maximum time limit (in milliseconds) for the hedged read. That is, the additional read sent to hedge the read operation uses the maxTimeMS value 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 mongosh session that is connected to a running mongos:

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

Tip

See also: 另请参阅：

• readHedgingMode
• Hedged Reads

maxCatchUpPercentageBeforeBlockingWrites

New in version 5.0:5.0版新增：(Also available starting in 4.4.7, 4.2.15)

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 10

For moveChunk and moveRange operations, specifies the maximum percentage of untrasferred data allowed by the migration protocol (expressed in percentage of the total chunk size) to transition from the catchup phase to the commit phase.

Setting a higher catchup percentage can decrease the amount of time it takes for the migration to complete at the cost of increased latency during concurrent upsert and delete operations.

For example, to set the maximum percentage to 20, you can issue the following during startup:

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

You cannot change maxCatchUpPercentageBeforeBlockingWrites during run time.

Tip

See also: 另请参阅：

Live Migration Protocol

metadataRefreshInTransactionMaxWaitBehindCritSecMS

New in version 5.2:5.2版新增：(Also available starting in 5.1.0, 5.0.4)

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 500

Limits the time a shard waits for a critical section within a transaction.

When a query accesses a shard, a chunk migration or DDL operation may already hold the critical section for the collection. If the query finds the critical section is taken, the shard waits until the critical section has been released. When the shard returns control to mongos, mongos retries the query. However, if a multi-shard transaction interacts with an operation that takes the critical section on multiple shards, the interaction can result in a distributed deadlock.

metadataRefreshInTransactionMaxWaitBehindCritSecMS limits the maximum time a shard waits within a transaction for the critical section to be released.

To reduce the maximum wait time for the critical section within a transaction, lower the value of metadataRefreshInTransactionMaxWaitBehindCritSecMS.

Warning

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

You can set metadataRefreshInTransactionMaxWaitBehindCritSecMS at startup and during run time.

For example, to set metadataRefreshInTransactionMaxWaitBehindCritSecMS to 400 milliseconds:

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

queryAnalysisSamplerConfigurationRefreshSecs

New in version 7.0. 7.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type类型: integer

Default默认值: 10

Interval that a sampler (mongos or mongod) refreshes its query analyzer sample rates.

The sample rate configured by the configureQueryAnalyzer command is divided among mongos instances in the sharded cluster or mongod instances in the replica set based on the traffic going through them. To make the sample rate assignment for a mongos or mongod more responsive to the traffic going through it, decrease this value.

We recommend using the default value.

This example sets queryAnalysisSamplerConfigurationRefreshSecs to 60 seconds at startup on a mongod instance:

mongod --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

This example sets queryAnalysisSamplerConfigurationRefreshSecs to 60 seconds at startup on a mongos instance:

mongos --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

queryAnalysisSamplerConfigurationRefreshSecs may only be set at startup.

queryAnalysisWriterIntervalSecs

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 90

Interval that sampled queries are written to disk, in seconds.

This example sets queryAnalysisWriterIntervalSecs to 60 seconds at startup on a mongod instance:

mongod --setParameter queryAnalysisWriterIntervalSecs=60

queryAnalysisWriterIntervalSecs may only be set at startup.

queryAnalysisWriterMaxMemoryUsageBytes

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 100 * 1024 * 1024

Maximum amount of memory in bytes that the query sampling writer is allowed to use. Once the limit is reached, all new queries and diffs are discarded from sampling until the buffer is flushed. Must be greater than 0.

This example sets queryAnalysisWriterMaxMemoryUsageBytes to 10000000 at startup on a mongod instance:

mongod --setParameter queryAnalysisWriterMaxMemoryUsageBytes=10000000

queryAnalysisWriterMaxBatchSize

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 100000

Maximum number of sampled queries to write to disk at once. Must be greater than 0 and less than or equal to 100000.

This example sets queryAnalysisWriterMaxBatchSize to 1000 at startup on a mongod instance:

mongod --setParameter queryAnalysisWriterMaxBatchSize=1000

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

db.adminCommand( { setParameter: 1, queryAnalysisWriterMaxBatchSize: 1000 } )

queryAnalysisSampleExpirationSecs

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 7 * 24 * 3600

Amount of time that a sampled query document exists before being removed by the TTL monitor, in seconds. Must be greater than 0.

This example sets queryAnalysisSampleExpirationSecs to 691200 (8 * 24 * 3600) at startup on a mongod instance:

mongod --setParameter queryAnalysisSampleExpirationSecs=691200

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

db.adminCommand( { setParameter: 1, queryAnalysisSampleExpirationSecs: 691200 } )

readHedgingMode

New in version 4.4. 4.4版新增。

Available for mongos only.

Type类型: string

Default默认值: on

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

Available values are:

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

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

mongos --setParameter readHedgingMode=off

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

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

Tip

See also: 另请参阅：

• Hedged Reads
• maxTimeMSForHedgedReads

shutdownTimeoutMillisForSignaledShutdown

New in version 5.0. 5.0版新增。

Available for mongod only.仅适用于mongod。

Type类型: integer

Default默认值: 15000

Specifies the time (in milliseconds) to wait for any ongoing database operations to complete before initiating a shutdown of mongod in response to a SIGTERM signal.

For example, to set the time to 250 milliseconds, you can issue the following during startup:

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

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

db.adminCommand( { setParameter: 1, shutdownTimeoutMillisForSignaledShutdown: 250 } )

mongosShutdownTimeoutMillisForSignaledShutdown

New in version 5.0. 5.0版新增。

Available for mongos only.

Type类型: integer

Default默认值: 15000

Specifies the time (in milliseconds) to wait for any ongoing database operations to complete before initiating a shutdown of mongos in response to a SIGTERM signal.

For example, to set the time to 250 milliseconds, you can issue the following during startup:

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

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

db.adminCommand( { setParameter: 1, mongosShutdownTimeoutMillisForSignaledShutdown: 250 } )

ShardingTaskExecutorPoolHostTimeoutMS

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 300000 (5 minutes)

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

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.

The following example sets ShardingTaskExecutorPoolHostTimeoutMS to 120000 during startup:

mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolHostTimeoutMS: 120000 } )

ShardingTaskExecutorPoolMaxConnecting

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 2

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.

The following example sets ShardingTaskExecutorPoolMaxConnecting to 20 during startup:

mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

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

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

ShardingTaskExecutorPoolMaxSize

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 2 ⁶⁴ - 1

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

ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

The following example sets ShardingTaskExecutorPoolMaxSize to 20 during startup:

mongos --setParameter ShardingTaskExecutorPoolMaxSize=20

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

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

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

Tip

See also: 另请参阅：

ShardingTaskExecutorPoolMinSize

ShardingTaskExecutorPoolMaxSizeForConfigServers

New in version 6.0. 6.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: -1

Optional override for ShardingTaskExecutorPoolMaxSize to set the maximum number of outbound connections each TaskExecutor connection pool can open to a configuration server.

When set to:

• -1, ShardingTaskExecutorPoolMaxSize is used. This is the default.
• an integer value greater than -1, overrides the maximum number of outbound connections each TaskExecutor connection pool can open to a configuration server.

Parameter only applies to sharded deployments.

The following example sets ShardingTaskExecutorPoolMaxSize to 2 during startup, which sets the maximum number of outbound connections each TaskExecutor connection pool can open to a configuration server to 2:

mongos --setParameter ShardingTaskExecutorPoolMaxSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolMinSize

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 1

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.

The following example sets ShardingTaskExecutorPoolMinSize to 2 during startup:

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

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

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

Tip

See also: 另请参阅：

• ShardingTaskExecutorPoolMaxSize
• warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolMinSizeForConfigServers

New in version 6.0. 6.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: -1

Optional override for ShardingTaskExecutorPoolMinSize to set the minimum number of outbound connections each TaskExecutor connection pool can open to a configuration server.

When set to:

• -1, ShardingTaskExecutorPoolMinSize is used. This is the default.
• an integer value greater than -1, overrides the minimum number of outbound connections each TaskExecutor connection pool can open to a configuration server.

Parameter only applies to sharded deployments.

The following example sets ShardingTaskExecutorPoolMinSize to 2 during startup, which sets the minimum number of outbound connections each TaskExecutor connection pool can open to a configuration server to 2:

mongos --setParameter ShardingTaskExecutorPoolMinSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolRefreshRequirementMS

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 60000 (1 minute)

Maximum time the mongos waits before attempting to heartbeat a resting connection in the pool. An idle connection may be discarded during the refresh if the pool is above its minimum size.

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

The following example sets ShardingTaskExecutorPoolRefreshRequirementMS to 90000 during startup:

mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshRequirementMS: 90000 } )

ShardingTaskExecutorPoolRefreshTimeoutMS

Available for both mongod and mongos.可用于mongod和mongos。

Type: integer

Default: 20000 (20 seconds)

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

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

The following example sets ShardingTaskExecutorPoolRefreshTimeoutMS to 30000 during startup:

mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshTimeoutMS: 30000 } )

ShardingTaskExecutorPoolReplicaSetMatching

New in version 4.2. 4.2版新增。

Changed in version 5.0.5.0版更改。(Also starting in 4.4.5 and 4.2.13)

Available for both mongod and mongos.可用于mongod和mongos。

Type: string

Default: "automatic"

On a mongos instance, this parameter sets the policy that determines the minimum size limit of its connection pools to nodes within replica sets.

On a mongod instance, this parameter sets the policy that determines the minimum size limit of its connection pools to nodes within other replica sets.

Note that this parameter only manages connections for operations that are directly related to user requests and CRUD operations.

Available values are:

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

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

mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"

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

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

taskExecutorPoolSize

Available for mongos only.

Type: integer

Default: 1

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.

When running MongoDB 6.2 or newer on Linux, you cannot modify the taskExecutorPoolSize from the default value of 1. You may modify this parameter when running MongoDB on Windows or macOS.

The default value of taskExecutorPoolSize is 1: In MongoDB 4.2+ deployments, 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

Tip

See also: 另请参阅：

• ShardingTaskExecutorPoolMaxSize
• ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup

New in version 4.4. 4.4版新增。

Available for mongos only.

Type: boolean

Default默认值: true

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. 4.4版新增。

Available for mongos only.

Type: boolean

Default默认值: true

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.

Tip

See also: 另请参阅：

• warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
• ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

New in version 4.4. 4.4版新增。

Available for mongos only.

Type: integer

Default默认值: 2000 (2 seconds)

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.

Tip

See also: 另请参阅：

• warmMinConnectionsInShardingTaskExecutorPoolOnStartup
• ShardingTaskExecutorPoolMinSize

migrateCloneInsertionBatchDelayMS

Available for mongod only.仅适用于mongod。

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

Available for mongod only.仅适用于mongod。

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

Available for mongod only.仅适用于mongod。

Default: 900 (15 minutes)

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

Tip

In all versions, the new value of orphanCleanupDelaySecs is only applied to range deletions created after the value is changed. To apply the new value to existing range deletions, force a step down.

rangeDeleterBatchDelayMS

Available for mongod only.仅适用于mongod。

Type: Non-negative integer

Default: 20

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

The _secondaryThrottle replication delay occurs after each batch deletion.

The following sets the rangeDeleterBatchDelayMS to 200 milliseconds:

mongod --setParameter rangeDeleterBatchDelayMS=200

The parameter may also be set using the setParameter command:

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

Tip

In versions prior to 6.0.3, the new value of rangeDeleterBatchDelayMS is only applied to range deletions created after the value is changed. To apply the new value to existing range deletions, force a step down.

From 6.0.3 on, the new value of the parameter is applied to all the range deletions processed after the update, regardless of when the range deletion was created.

rangeDeleterBatchSize

Available for mongod only.仅适用于mongod。

Type: Non-negative integer

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

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

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

The following example sets rangeDeleterBatchSize to 32 documents:

mongod --setParameter rangeDeleterBatchSize=32

The parameter may also be set using the setParameter command:

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

Tip

In versions prior to 6.0.3, the new value of rangeDeleterBatchSize is only applied to range deletions created after the value is changed. To apply the new value to existing range deletions, force a step down.

From 6.0.3 on, the new value of the parameter is applied to all the range deletions processed after the update, regardless of when the range deletion was created.

rangeDeleterHighPriority

New in version 7.0. 7.0版新增。

Available for mongod only.仅适用于mongod。

Type: boolean

Default: false

When true, prioritizes cleanup of orphaned documents over user operations. By default, this is set to false to prioritize user operations over cleanup of orphaned documents.

The following example sets rangeDeleterHighPriority to true:

mongod --setParameter rangeDeleterHighPriority=true

The parameter may also be set using the setParameter command:

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

skipShardingConfigurationChecks

Available for mongod only.仅适用于mongod。

Type: boolean

Default: false

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

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

mongod --setParameter skipShardingConfigurationChecks=true

Important

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

findChunksOnConfigTimeoutMS

New in version 5.0. 5.0版新增。

Available for both mongod and mongos.可用于mongod和mongos。

Type: Non-negative integer

Default: 900000

The timeout in milliseconds for find operations on chunks.

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

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

Health Manager Parameters

activeFaultDurationSecs

Available for mongos only.

Type类型: Document

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

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

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

mongos --setParameter activeFaultDurationSecs=300

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

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

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

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

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

Available for mongos only.

Type类型: Array of documents

Use this parameter to set intensity levels for Health Managers.

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

• type, the Health Manager facet
• intensity, the intensity level

Health Managers

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

Intensity Levels

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

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

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

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

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

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

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

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

healthMonitoringIntervals

Available for mongos only.

Type类型: Array of documents

How often this Health Manager will run, in milliseconds.

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

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

Health Managers

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

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

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

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

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

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

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

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

progressMonitor

Available for mongos only.

Type类型: Document

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

progressMonitor Fields

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

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

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

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

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

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

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

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

Storage Parameters

honorSystemUmask

Available for mongod only.仅适用于mongod。

Default默认值: false

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

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

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

mongod --setParameter honorSystemUmask=true

Note

honorSystemUmask is not available on Windows systems.

journalCommitInterval

Available for mongod only.仅适用于mongod。

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

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

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

Tip

See also: 另请参阅：

storage.journal.commitIntervalMs

minSnapshotHistoryWindowInSeconds

New in version 5.0. 5.0版新增。

Available for mongod only.仅适用于mongod。

Default默认值: 300

The minimum time window in seconds for which the storage engine keeps the snapshot history. If you query data using read concern "snapshot" and specify an atClusterTime value older than the specified minSnapshotHistoryWindowInSeconds, mongod returns a SnapshotTooOld error.

Specify an integer greater than or equal to (>=) 0.

Consider the following example which sets the minSnapshotHistoryWindowInSeconds to 600 seconds:

db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 600 } )

Note

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

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

processUmask

New in version 4.4. 4.4版新增。

Available for mongod only.仅适用于mongod。

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

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

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

mongod --setParameter processUmask=011

Note

processUmask is not available on Windows systems.

syncdelay

Available for mongod only.仅适用于mongod。

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

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

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

Tip

See also: 另请参阅：

• journalCommitInterval
• storage.syncPeriodSecs

temporarilyUnavailableBackoffBaseMs

Available for mongod only.仅适用于mongod。

Specifies the initial delay before retying a write operation that was rolled back due to cache pressure.

In rare circumstances, a write can fail due to cache pressure. When this happens MongoDB issues a TemporarilyUnavailable error and increments the temporarilyUnavailableErrors counter in two places: the slow query log and the Full Time Diagnostic Data Capture (FTDC).

Individual operations within multi-document transactions never return TemporarilyUnavailable errors.

Adjust the write retry properties by modifying the temporarilyUnavailableBackoffBaseMs and temporarilyUnavailableMaxRetries parameters.

The parameter accepts:

Value值	Description描述
integer >= 0	Defaults to 1 second. The initial delay between retries. The value increases with each retry to a maximum of 55 seconds. A larger value increases the chance that the cache pressure will be reduced before the next retry. To configure number of retries, use temporarilyUnavailableMaxRetries.

To set a new value, use db.adminCommand():

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

New in version 6.1.0. 6.1.0版新增。

temporarilyUnavailableMaxRetries

Available for mongod only.仅适用于mongod。

Specifies the maximum number of retries when a write operation is rolled back due to cache pressure.

In rare circumstances, a write can fail due to cache pressure. When this happens MongoDB issues a TemporarilyUnavailable error and increments the temporarilyUnavailableErrors counter in two places: the slow query log and the Full Time Diagnostic Data Capture (FTDC).

Individual operations within multi-document transactions never return TemporarilyUnavailable errors.

Adjust the write retry properties by modifying the temporarilyUnavailableBackoffBaseMs and temporarilyUnavailableMaxRetries parameters.

The parameter accepts:

Value值	Description描述
integer >= 0	Defaults to 10. The maximum number of retries. There is an increasing delay between retries. To configure the backoff time, use temporarilyUnavailableBackoffBaseMs.

To set a new value, use db.adminCommand():

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

New in version 6.1.0. 6.1.0版新增。

WiredTiger Parameters

wiredTigerMaxCacheOverflowSizeGB

Note

Deprecated in MongoDB 4.4

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

Available for mongod only.仅适用于mongod。

Default默认值: 0 (No specified maximum)

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

The parameter can accept the following values:

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

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

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

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

New in version 4.2.1. 4.2.1版新增。

wiredTigerConcurrentReadTransactions

Changed in version 7.0.7.0版更改。

Available for mongod only.仅适用于mongod。

Starting in MongoDB 7.0, this parameter is available for all storage engines. In earlier versions, this parameter is available for the WiredTiger storage engine only.

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

Important

Starting in MongoDB 7.0, this parameter disables an algorithm that dynamically adjusts the number of concurrent storage engine transactions.

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

Tip

See also: 另请参阅：

wiredTiger.concurrentTransactions

wiredTigerConcurrentWriteTransactions

Changed in version 7.0.7.0版更改。

Available for mongod only.仅适用于mongod。

Starting in MongoDB 7.0, this parameter is available for all storage engines. In earlier versions, this parameter is available for the WiredTiger storage engine only.

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

Important

Starting in MongoDB 7.0, this parameter disables an algorithm that dynamically adjusts the number of concurrent storage engine transactions.

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

Tip

See also: 另请参阅：

wiredTiger.concurrentTransactions

wiredTigerEngineRuntimeConfig

Available for mongod only.仅适用于mongod。

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.