mongodb/debian/mongodb-parameters.5

.TH mongodb-parameters 5
.SH MONGODB SERVER PARAMETERS
.SH SYNOPSIS
MongoDB provides a number of configuration options that you can set
using:
.RS
.IP \(bu 2
the \fBsetParameter\f1\f1 command:
.IP
.EX
  db.adminCommand( { setParameter: 1, <parameter>: <value>  } )
.EE
.IP \(bu 2
the \fBsetParameter\f1\f1 configuration setting:
.IP
.EX
  setParameter:
     <parameter1>: <value1>
     ...
.EE
.IP \(bu 2
the \fB\-\-setParameter\f1 command\-line option for \fBmongod\f1\f1
and \fBmongos\f1\f1:
.IP
.EX
  mongod \-\-setParameter <parameter>=<value>
  mongos \-\-setParameter <parameter>=<value>
.EE
.RE
.PP
For additional configuration options, see
\fBConfiguration File Options\f1, \fBmongod\f1\f1 and
\fBmongos\f1\f1\&.
.SH PARAMETERS
.SS AUTHENTICATION PARAMETERS
.PP
\fBauthenticationMechanisms\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
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 \fBAuthentication\f1\&.
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Value
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBSCRAM\-SHA\-1\f1
.IP \(bu 4
RFC 5802 (https://tools.ietf.org/html/rfc5802) standard
Salted Challenge Response Authentication Mechanism using the SHA\-1
hash function.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBSCRAM\-SHA\-256\f1
.IP \(bu 4
RFC 7677 (https://tools.ietf.org/html/rfc7677) standard
Salted Challenge Response Authentication Mechanism using the SHA\-256
hash function.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBMONGODB\-X509\f1
.IP \(bu 4
MongoDB TLS/SSL certificate authentication.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBGSSAPI\f1 (Kerberos)
.IP \(bu 4
External authentication using Kerberos. This mechanism is
available only in MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)\&.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBPLAIN\f1 (LDAP SASL)
.IP \(bu 4
External authentication using LDAP. You can also use \fBPLAIN\f1
for authenticating in\-database users. \fBPLAIN\f1 transmits
passwords in plain text. This mechanism is available only in
MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)\&.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBMONGODB\-OIDC\f1
.IP \(bu 4
OpenID Connect is an authentication layer built on top of OAuth2. This mechanism
is available only in MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)\&.
.RE
.RE
.PP
You can only set \fBauthenticationMechanisms\f1\f1 during
start\-up.
.PP
For example, to specify both \fBPLAIN\f1 and \fBSCRAM\-SHA\-256\f1 as the
authentication mechanisms, use the following command:
.PP
.EX
  mongod \-\-setParameter authenticationMechanisms=PLAIN,SCRAM\-SHA\-256 \-\-auth
.EE
.RE
.PP
\fBclusterAuthMode\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Set the \fBclusterAuthMode\f1\f1 to either \fBsendX509\f1 or
\fBx509\f1\&. Useful during \fBrolling upgrade to use x509 for
membership authentication\f1
to minimize downtime.
.PP
For more information about TLS/SSL and MongoDB, see
\fBConfigure mongod\f1 and mongos\f1 for TLS/SSL\f1 and
\fBTLS/SSL Configuration for Clients\f1 .
.PP
.EX
  db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )
.EE
.RE
.PP
\fBenableLocalhostAuthBypass\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Specify \fB0\f1 or \fBfalse\f1 to disable localhost authentication
bypass. Enabled by default.
.PP
\fBenableLocalhostAuthBypass\f1\f1 is not available using
\fBsetParameter\f1\f1 database command. Use the
\fBsetParameter\f1\f1 option in the configuration file or the
\fB\-\-setParameter\f1\f1 option on the
command line.
.PP
See \fBLocalhost Exception\f1 for more information.
.RE
.PP
\fBKeysRotationIntervalSec\f1
.RS
.PP
\fIDefault\f1: 7776000 seconds (90 days)
.PP
Specifies the number of seconds for which an HMAC signing key (https://en.wikipedia.org/wiki/Hash\-based_message_authentication_code)
is valid before rotating to the next one. This parameter is intended
primarily to facilitate authentication testing.
.PP
You can only set \fBKeysRotationIntervalSec\f1\f1 during
start\-up, and cannot change this setting with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapForceMultiThreadMode\f1
.RS
.PP
\fIDefault\f1: false
.PP
Enables the performance of concurrent LDAP operations.
.PP
Only if you are certain that your instance of \fBlibldap\f1
is safe to use in this mode, enable this flag. You may experience
crashes of the MongoDB process if the \fBlibldap\f1 version you are using
is not thread safe.
.PP
You must use \fBldapForceMultiThreadMode\f1\f1 to use LDAP connection
pool. To enable LDAP connection pool, set \fBldapForceMultiThreadMode\f1\f1
and \fBldapUseConnectionPool\f1\f1 to \fBtrue\f1\&.
.PP
If you have any concerns regarding your MongoDB version, OS version or
libldap version, please contact MongoDB Support.
.RE
.PP
\fBldapRetryCount\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 0
.PP
For MongoDB deployments using \fBLDAP Authorization\f1\&.
.PP
Number of operation retries by the server LDAP manager after a
network error.
.PP
For example, the following sets \fBldapRetryCount\f1\f1 to \fB3\f1
seconds:
.PP
.EX
  mongod \-\-ldapRetryCount=3
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, ldapRetryCount: 3 } )
.EE
.RE
.PP
\fBldapUserCacheInvalidationInterval\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Starting in MongoDB 5.2, the update interval for cached user information
retrieved from an LDAP server depends on
\fBldapShouldRefreshUserCacheEntries\f1\f1:
.RS
.IP \(bu 2
If true, use \fBldapUserCacheRefreshInterval\f1\f1\&.
.IP \(bu 2
If false, use \fBldapUserCacheInvalidationInterval\f1\f1\&.
.RE
.PP
For use with MongoDB deployments using
\fBLDAP Authorization\f1\&.
.PP
The interval (in seconds) that the \fBmongod\f1\f1 instance
waits between external user cache flushes. After MongoDB flushes the
external user cache, MongoDB
reacquires authorization data from the LDAP server the
next time an LDAP\-authorized user issues an operation.
.PP
Increasing the value specified increases the amount of time
MongoDB and the LDAP server can be out of sync, but reduces the load on
the LDAP server. Conversely, decreasing the value specified
decreases the time MongoDB and the LDAP server can be out of sync while
increasing the load on the LDAP server.
.PP
Defaults to 30 seconds.
.RE
.PP
\fBldapUserCacheRefreshInterval\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 30 seconds
.PP
Starting in MongoDB 5.2, the update interval for cached user information
retrieved from an LDAP server depends on
\fBldapShouldRefreshUserCacheEntries\f1\f1:
.RS
.IP \(bu 2
If true, use \fBldapUserCacheRefreshInterval\f1\f1\&.
.IP \(bu 2
If false, use \fBldapUserCacheInvalidationInterval\f1\f1\&.
.RE
.PP
For MongoDB deployments using \fBLDAP Authorization\f1\&.
.PP
The interval in seconds that \fBmongod\f1\f1 waits before
refreshing the cached user information from the LDAP server.
.PP
The maximum interval is 86,400 seconds (24 hours).
.PP
For example, the following sets
\fBldapUserCacheRefreshInterval\f1\f1 to \fB4000\f1 seconds:
.PP
.EX
  mongod \-\-setParameter ldapUserCacheRefreshInterval=4000
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, ldapUserCacheRefreshInterval: 4000 } )
.EE
.RE
.PP
\fBldapUserCacheStalenessInterval\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 90 seconds
.PP
For MongoDB deployments using \fBLDAP Authorization\f1\&.
.PP
The interval in seconds that \fBmongod\f1\f1 retains the cached
LDAP user information after the last cache refresh.
.PP
If more than \fBldapUserCacheStalenessInterval\f1\f1 seconds
elapse without a successful refresh of the user information from the
LDAP server, then \fBmongod\f1\f1:
.RS
.IP \(bu 2
Invalidates the cached LDAP user information.
.IP \(bu 2
Is unable to authenticate new sessions for LDAP users until
\fBmongod\f1\f1 connects to the LDAP server and
authorizes the LDAP user.
.IP \(bu 2
Authorizes any existing sessions that use previously authenticated
LDAP users if \fBmongod\f1\f1 is unable to connect to the
LDAP server. When \fBmongod\f1\f1 reconnects to the LDAP
server, \fBmongod\f1\f1 ensures the LDAP users are correctly
authorized.
.RE
.PP
The maximum interval is 86,400 seconds (24 hours).
.PP
For example, the following sets
\fBldapUserCacheStalenessInterval\f1\f1 to \fB4000\f1 seconds:
.PP
.EX
  mongod \-\-setParameter ldapUserCacheStalenessInterval=4000
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, ldapUserCacheStalenessInterval: 4000 } )
.EE
.RE
.PP
\fBldapUseConnectionPool\f1
.RS
.PP
Specifies whether MongoDB should use connection pooling when
connecting to the LDAP server for authentication/authorization.
.PP
MongoDB uses the following default values:
.RS
.IP \(bu 2
true on Windows.
.IP \(bu 2
true on Linux where MongoDB Enterprise binaries are linked against
\fBlibldap_r\f1\&.
.IP \(bu 2
false on Linux where MongoDB Enterprise binaries are linked against
\fBlibldap\f1\&.
.RE
.PP
You can only set \fBldapUseConnectionPool\f1\f1 during
start\-up, and cannot change this setting with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolUseLatencyForHostPriority\f1
.RS
.PP
\fIDefault\f1: true
.PP
A boolean that determines whether the LDAP connection pool (see
\fBldapUseConnectionPool\f1\f1) should use latency of the LDAP
servers to determine the connection order (from lowest latency to
highest).
.PP
You can only set
\fBldapConnectionPoolUseLatencyForHostPriority\f1\f1 during
start\-up, and cannot change this setting during run time with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolMinimumConnectionsPerHost\f1
.RS
.PP
\fIDefault\f1: 1
.PP
The minimum number of connections to keep open to each LDAP server.
.PP
You can only set
\fBldapConnectionPoolMinimumConnectionsPerHost\f1\f1 during
start\-up, and cannot change this setting during run time with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolMaximumConnectionsPerHost\f1
.RS
.PP
\fIChanged starting in MongoDB versions 4.4.15, 5.0.9, and 6.0.0\f1
Changed default value to \fB2147483647\f1\&. In previous versions, the
default is unset.
.PP
\fIDefault\f1: 2147483647
.PP
The maximum number of connections to keep open to each LDAP server.
.PP
You can only set
\fBldapConnectionPoolMaximumConnectionsPerHost\f1\f1 during
start\-up, and cannot change this setting during run time with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolMaximumConnectionsInProgressPerHost\f1
.RS
.PP
\fIChanged starting in MongoDB versions 4.4.15, 5.0.9, and 6.0.0\f1
Changed default value to \fB2\f1\&. In previous versions, the
default is unset.
.PP
\fIDefault\f1: 2
.PP
The maximum number of in\-progress connect operations to each LDAP server.
.PP
You can only set
\fBldapConnectionPoolMaximumConnectionsInProgressPerHost\f1\f1
during start\-up, and cannot change this setting with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolHostRefreshIntervalMillis\f1
.RS
.PP
\fIDefault\f1: 60000
.PP
The number of milliseconds in\-between health checks of the pooled
LDAP connections.
.PP
You can only set
\fBldapConnectionPoolHostRefreshIntervalMillis\f1\f1 during
start\-up, and cannot change this setting with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapConnectionPoolIdleHostTimeoutSecs\f1
.RS
.PP
\fIDefault\f1: 300
.PP
The maximum number of seconds that the pooled connections to an LDAP
server can remain idle before being closed.
.PP
You can only set
\fBldapConnectionPoolIdleHostTimeoutSecs\f1\f1 during
start\-up, and cannot change this setting with the
\fBsetParameter\f1\f1 database command.
.RE
.PP
\fBldapShouldRefreshUserCacheEntries\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
For MongoDB deployments using \fBLDAP Authorization\f1\&.
.PP
Starting in MongoDB 5.2, the update interval for cached user information
retrieved from an LDAP server depends on
\fBldapShouldRefreshUserCacheEntries\f1\f1:
.RS
.IP \(bu 2
If true, use \fBldapUserCacheRefreshInterval\f1\f1\&.
.IP \(bu 2
If false, use \fBldapUserCacheInvalidationInterval\f1\f1\&.
.RE
.PP
You can only set \fBldapShouldRefreshUserCacheEntries\f1\f1
during startup in the \fBconfiguration file\f1\f1 or
with the \fB\-\-setParameter\f1 option on the command line. For example,
the following disables
\fBldapShouldRefreshUserCacheEntries\f1\f1:
.PP
.EX
  mongod \-\-setParameter ldapShouldRefreshUserCacheEntries=false
.EE
.RE
.PP
\fBmaxValidateMemoryUsageMB\f1
.RS
.PP
\fIDefault\f1: 200
.PP
The maximum memory usage limit in megabytes for the
\fBvalidate\f1\f1 command. If the limit is exceeded,
\fBvalidate\f1\f1 returns as many results as possible and warns
that not all corruption might be reported because of the limit.
.PP
You can set \fBmaxValidateMemoryUsageMB\f1\f1 during startup, and
can change this setting using the \fBsetParameter\f1\f1 database
command.
.RE
.PP
\fBoidcIdentityProviders\f1
.RS
.PP
Use this parameter to specify identity provider (IDP) configurations when
using \fBOpenID Connect Authentication\f1\&.
.PP
\fBoidcIdentityProviders\f1 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, \fBoidcIdentityProviders\f1
uses the \fBmatchPattern\f1 field to select an IDP. Array order determines the
priority and the first IDP is always selected.
.SS OIDCIDENTITYPROVIDERS FIELDS
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Field
.IP \(bu 4
Necessity
.IP \(bu 4
Description
.IP \(bu 4
Type
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBissuer\f1
.IP \(bu 4
Required
.IP \(bu 4
The issuer URI of the IDP that the server should accept tokens from. This
must match the \fBiss\f1 field in any JWT used for authentication.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBauthNamePrefix\f1
.IP \(bu 4
Required
.IP \(bu 4
Unique prefix applied to each generated \fBUserName\f1 and \fBRoleName\f1 used
in authorization.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBmatchPattern\f1
.IP \(bu 4
Conditional
.IP \(bu 4
Required when more than one IDP is defined.
.IP
Regex pattern used to determine which IDP should be used. \fBmatchPattern\f1
matches against usernames. Array order determines the priority and the
first IDP is always selected.
.IP
This is not a security mechanism. \fBmatchPattern\f1 serves only as an advisory
to clients. MongoDB accepts tokens issued by the IDP whose principal
names do not match this pattern.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBclientId\f1
.IP \(bu 4
Required
.IP \(bu 4
ID provided by the IDP to identify the client that receives the access tokens.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBaudience\f1
.IP \(bu 4
Required
.IP \(bu 4
Specifies the application or service that the access token is intended for.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBrequestScopes\f1
.IP \(bu 4
Optional
.IP \(bu 4
Permissions and access levels that MongoDB requests from the IDP.
.IP \(bu 4
array[ string ]
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBprincipalName\f1
.IP \(bu 4
Optional
.IP \(bu 4
The claim to be extracted from the access token containing MongoDB user
identifiers.
.IP
The default value is \fBsub\f1 (stands for \fBsubject\f1).
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBauthorizationClaim\f1
.IP \(bu 4
Required
.IP \(bu 4
Claim extracted from access token that contains MongoDB role names.
.IP \(bu 4
string
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBlogClaims\f1
.IP \(bu 4
Optional
.IP \(bu 4
List of access token claims to include in log and audit messages upon
authentication completion.
.IP \(bu 4
array[ string ]
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBJWKSPollSecs\f1
.IP \(bu 4
Optional
.IP \(bu 4
Frequency, in seconds, to request an updated JSON Web Key Set (JWKS) from the IDP.
A setting of 0 disables polling.
.IP \(bu 4
integer
.RE
.RE
.PP
You can only set \fBoidcIdentityProviders\f1 during startup in the
\fBconfiguration file\f1\f1 or with the
\fB\-\-setParameter\f1 option on the command line.
.RE
.PP
\fBocspEnabled\f1
.RS
.PP
Available on Linux and macOS.
.PP
\fIDefault\f1: true
.PP
The flag that enables or disables OCSP.
.PP
You can only set \fBocspEnabled\f1\f1 during startup in the
\fBconfiguration file\f1\f1 or with the
\fB\-\-setParameter\f1 option on the command line. For example, the
following disables OCSP:
.PP
.EX
  mongod \-\-setParameter ocspEnabled=false ...
.EE
.RS
.IP \(bu 2
\fBocspValidationRefreshPeriodSecs\f1\f1
.IP \(bu 2
\fBtlsOCSPStaplingTimeoutSecs\f1\f1
.IP \(bu 2
\fBtlsOCSPVerifyTimeoutSecs\f1\f1
.RE
.RE
.PP
\fBocspValidationRefreshPeriodSecs\f1
.RS
.PP
Available on Linux.
.PP
The number of seconds to wait before refreshing the stapled OCSP
status response. Specify a number greater than or equal to 1.
.PP
You can only set \fBocspValidationRefreshPeriodSecs\f1\f1 during
startup in the \fBconfiguration file\f1\f1 or with
the \fB\-\-setParameter\f1 option on the command line. For example, the
following sets the parameter to 3600 seconds:
.PP
.EX
  mongod \-\-setParameter ocspValidationRefreshPeriodSecs=3600 ...
.EE
.PP
Starting in MongoDB 5.0, the \fBrotateCertificates\f1\f1 command
and \fBdb.rotateCertificates()\f1\f1 method will also refresh any
stapled OCSP responses.
.RS
.IP \(bu 2
\fBocspEnabled\f1\f1
.IP \(bu 2
\fBtlsOCSPStaplingTimeoutSecs\f1\f1
.IP \(bu 2
\fBtlsOCSPVerifyTimeoutSecs\f1\f1
.RE
.RE
.PP
\fBopensslCipherConfig\f1
.RS
.PP
\fIAvailable on Linux only\f1
.PP
With the use of native TLS/SSL libraries, the parameter
\fBopensslCipherConfig\f1\f1 is supported for Linux/BSD and
no longer supported in Windows and macOS. See \fBTLS/SSL\f1\&.
.PP
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 (https://www.openssl.org/docs/man1.1.1/man1/ciphers.html)\&.
Multiple cipher strings can be provided as a colon\-separated list.
.PP
This parameter is only for use with TLS 1.2 or earlier. To specify
cipher suites for use with TLS 1.3, use the
\fBopensslCipherSuiteConfig\f1\f1 parameter.
.PP
You can only set \fBopensslCipherConfig\f1\f1 during start\-up,
and cannot change this setting using the \fBsetParameter\f1\f1
database command.
.PP
For version 4.2 and greater, the use of \fBTLS\f1 options is preferred
over \fBSSL\f1 options. The TLS options have the same functionality as
the \fBSSL\f1 options. For example, the following configures a
\fBmongod\f1\f1 with a \fBopensslCipherConfig\f1\f1
cipher string of \fB\(aqHIGH:!EXPORT:!aNULL@STRENGTH\(aq\f1 in MongoDB 4.2:
.PP
.EX
  mongod \-\-setParameter opensslCipherConfig=\(aqHIGH:!EXPORT:!aNULL@STRENGTH\(aq \-\-tlsMode requireTLS \-\-tlsCertificateKeyFile Certs/server.pem
.EE
.RE
.PP
\fBopensslCipherSuiteConfig\f1
.RS
.PP
\fIAvailable on Linux only\f1
.PP
Specify the list of supported cipher suites OpenSSL should permit
when using TLS 1.3 encryption.
.PP
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 (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.
.PP
This parameter is only for use with TLS 1.3. To specify cipher
strings for use with TLS 1.2 or earlier, use the
\fBopensslCipherConfig\f1\f1 parameter.
.PP
You can only set \fBopensslCipherSuiteConfig\f1\f1 during
start\-up, and cannot change this setting using the
\fBsetParameter\f1\f1 database command. For example, the
following configures a \fBmongod\f1\f1 with a
\fBopensslCipherSuiteConfig\f1\f1 cipher suite of
\fB\(aqTLS_AES_256_GCM_SHA384\(aq\f1 for use with TLS 1.3:
.PP
.EX
  mongod \-\-setParameter opensslCipherSuiteConfig=\(aqTLS_AES_256_GCM_SHA384\(aq \-\-tlsMode requireTLS \-\-tlsCertificateKeyFile Certs/server.pem
.EE
.RE
.PP
\fBopensslDiffieHellmanParameters\f1
.RS
.PP
\fIAvailable on Linux only\f1
.PP
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 \fBEphemeral Diffie\-Hellman (DHE)\f1
cipher suites during TLS/SSL encryption.
.PP
This parameter is not supported for use with TLS 1.3.
.PP
Ephemeral Diffie\-Hellman (DHE) cipher suites (and Ephemeral Elliptic
Curve Diffie\-Hellman (ECDHE) cipher suites) provide
\fBForward Secrecy\f1\&. \fBForward Secrecy\f1 cipher suites
create an ephemeral session key that is protected by the server\(aqs
private key but never transmitted. This ensures that even if a
server\(aqs private key is compromised, you cannot decrypt past
sessions with the compromised key.
.PP
Starting in MongoDB 4.2, if
\fBopensslDiffieHellmanParameters\f1\f1 is unset but
\fBECDHE\f1 is enabled, MongoDB enables DHE using the
\fBffdhe3072\f1 Diffie\-Hellman parameter, as defined in
RFC\-7919#appendix\-A.2 (https://tools.ietf.org/html/7919#appendix\-A.2)\&. The \fBffdhe3072\f1 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.
.PP
You can only set \fBopensslDiffieHellmanParameters\f1\f1 during
startup, and cannot change this setting using the
\fBsetParameter\f1\f1 database command.
.PP
If for performance reasons, you need to disable support for DHE
cipher suites, use the \fBopensslCipherConfig\f1\f1 parameter:
.PP
.EX
  mongod \-\-setParameter opensslCipherConfig=\(aqHIGH:!EXPORT:!aNULL:!DHE:!kDHE@STRENGTH\(aq ...
.EE
.RE
.PP
\fBsaslauthdPath\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Specify the path to the Unix Domain Socket of the \fBsaslauthd\f1
instance to use for proxy authentication.
.RE
.PP
\fBsaslHostName\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fBsaslHostName\f1\f1 overrides MongoDB\(aqs default hostname
detection for the purpose of configuring SASL and Kerberos
authentication.
.PP
\fBsaslHostName\f1\f1 does not affect the hostname of the
\fBmongod\f1\f1 or \fBmongos\f1\f1 instance for any purpose
beyond the configuration of SASL and Kerberos.
.PP
You can only set \fBsaslHostName\f1\f1 during start\-up, and
cannot change this setting using the \fBsetParameter\f1\f1
database command.
.PP
\fBsaslHostName\f1\f1 supports Kerberos authentication and is
only included in MongoDB Enterprise. For more information, see the
following:
.RS
.IP \(bu 2
Linux:
\fBConfigure MongoDB with Kerberos Authentication on Linux\f1
.IP \(bu 2
Windows:
\fBConfigure MongoDB with Kerberos Authentication on Windows\f1
.RE
.RE
.PP
\fBsaslServiceName\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Allows users to override the default \fBKerberos\f1
service name component of the \fBKerberos\f1
principal name, on a per\-instance basis. If unspecified, the
default value is \fBmongodb\f1\&.
.PP
MongoDB only permits setting \fBsaslServiceName\f1\f1 at
startup. The \fBsetParameter\f1\f1 command can not change
this setting.
.PP
\fBsaslServiceName\f1\f1 is only available in MongoDB
Enterprise.
.PP
Ensure that your driver supports alternate service names.
.RE
.PP
\fBscramIterationCount\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: \fB10000\f1
.PP
Changes the number of hashing iterations used for all new
\fBSCRAM\-SHA\-1\f1 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.
.PP
If you modify this value, it does not change the iteration count for
existing passwords. The \fBscramIterationCount\f1\f1 value must
be \fB5000\f1 or greater.
.PP
For example, the following sets the \fBscramIterationCount\f1\f1
to \fB12000\f1\&.
.PP
.EX
  mongod \-\-setParameter scramIterationCount=12000
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, scramIterationCount: 12000 } )
.EE
.RS
.IP \(bu 2
\fBdb.changeUserPassword()\f1\f1
.IP \(bu 2
\fBdb.createUser()\f1\f1
.IP \(bu 2
\fBdb.updateUser()\f1\f1
.RE
.RE
.PP
\fBscramSHA256IterationCount\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: \fB15000\f1
.PP
Changes the number of hashing iterations used for all new
\fBSCRAM\-SHA\-256\f1 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.
.PP
If you modify this value, it does not change iteration count for
existing passwords. The \fBscramSHA256IterationCount\f1\f1 value
must be \fB5000\f1 or greater.
.PP
For example, the following sets the \fBscramSHA256IterationCount\f1\f1
to \fB20000\f1\&.
.PP
.EX
  mongod \-\-setParameter scramSHA256IterationCount=20000
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, scramSHA256IterationCount: 20000 } )
.EE
.RS
.IP \(bu 2
\fBdb.changeUserPassword()\f1\f1
.IP \(bu 2
\fBdb.createUser()\f1\f1
.IP \(bu 2
\fBdb.updateUser()\f1\f1
.RE
.RE
.PP
\fBsslMode\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Set the \fBnet.ssl.mode\f1\f1 to either \fBpreferSSL\f1 or
\fBrequireSSL\f1\&. Useful during \fBrolling upgrade to TLS/SSL\f1 to minimize downtime.
.PP
For more information about TLS/SSL and MongoDB, see
\fBConfigure mongod\f1 and mongos\f1 for TLS/SSL\f1 and
\fBTLS/SSL Configuration for Clients\f1 .
.PP
.EX
  db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } )
.EE
.PP
\fBtlsMode\f1\f1
.RE
.PP
\fBtlsMode\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Set to either:
.RS
.IP \(bu 2
\fBpreferTLS\f1
.IP \(bu 2
\fBrequireTLS\f1
.RE
.PP
The \fBtlsMode\f1\f1 parameter is useful during \fBrolling
upgrade to TLS/SSL\f1 to minimize
downtime.
.PP
.EX
  db.adminCommand( { setParameter: 1, tlsMode: "preferTLS" } )
.EE
.PP
For more information about TLS/SSL and MongoDB, see
\fBConfigure mongod\f1 and mongos\f1 for TLS/SSL\f1 and
\fBTLS/SSL Configuration for Clients\f1 .
.PP
\fBsslMode\f1\f1
.RE
.PP
\fBtlsClusterAuthX509Override\f1
.RS
.PP
Overrides the \fBclusterAuthX509\f1\f1 configuration options.
.PP
.EX
  setParameter:
     tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB Server }
.EE
.PP
The parameter supports \fBattributes\f1 and \fBextensionValue\f1 overrides.
.PP
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 \fBattributes\f1\f1
setting or the \fBattributes\f1 field on the
\fBtlsClusterAuthX509Override\f1\f1 parameter, it checks
the Distinguished Name (DN) values of the certificate.
If the \fBextensionValue\f1\f1 setting or the
\fBextensionValue\f1 field of
the \fBtlsClusterAuthX509Override\f1\f1 parameter is set, it checks
the extension values of the certificate.  If it finds a match,
it authorizes the connection as a peer.
.PP
Use this parameter to rotate certificates when the new certificates have
different attributes or extension values.
.RE
.PP
\fBtlsOCSPStaplingTimeoutSecs\f1
.RS
.PP
Available for Linux.
.PP
The maximum number of seconds the
\fBmongod\f1\f1 / \fBmongos\f1\f1 instance should wait to
receive the OCSP status response for its certificates.
.PP
Specify an integer greater than or equal to (\fB>=\f1) 1. If unset,
\fBtlsOCSPStaplingTimeoutSecs\f1\f1 uses the
\fBtlsOCSPVerifyTimeoutSecs\f1\f1 value.
.PP
You can only set \fBtlsOCSPStaplingTimeoutSecs\f1\f1 during
startup in the \fBconfiguration file\f1\f1 or with
the \fB\-\-setParameter\f1 option on the command line. For example, the
following sets the \fBtlsOCSPStaplingTimeoutSecs\f1\f1 to 20
seconds:
.PP
.EX
  mongod \-\-setParameter tlsOCSPStaplingTimeoutSecs=20 ...
.EE
.RS
.IP \(bu 2
\fBocspEnabled\f1\f1
.IP \(bu 2
\fBocspValidationRefreshPeriodSecs\f1\f1
.IP \(bu 2
\fBtlsOCSPVerifyTimeoutSecs\f1\f1
.RE
.RE
.PP
\fBtlsOCSPVerifyTimeoutSecs\f1
.RS
.PP
Available for Linux and Windows.
.PP
\fIDefault\f1: 5
.PP
The maximum number of seconds that the
\fBmongod\f1\f1 / \fBmongos\f1\f1 should wait for the OCSP
response when verifying server certificates.
.PP
Specify an integer greater than or equal to (\fB>=\f1) 1.
.PP
You can only set \fBtlsOCSPVerifyTimeoutSecs\f1\f1 during
startup in the \fBconfiguration file\f1\f1 or with
the \fB\-\-setParameter\f1 option on the command line. For example, the
following sets the \fBtlsOCSPVerifyTimeoutSecs\f1\f1 to 20
seconds:
.PP
.EX
  mongod \-\-setParameter tlsOCSPVerifyTimeoutSecs=20 ...
.EE
.RS
.IP \(bu 2
\fBocspEnabled\f1\f1
.IP \(bu 2
\fBocspValidationRefreshPeriodSecs\f1\f1
.IP \(bu 2
\fBtlsOCSPStaplingTimeoutSecs\f1\f1
.RE
.RE
.PP
\fBtlsWithholdClientCertificate\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: false
.PP
A TLS certificate is set for a \fBmongod\f1\f1 or
\fBmongos\f1\f1 either by the
\fB\-\-tlsClusterFile\f1\f1 option or by the
\fB\-\-tlsCertificateKeyFile\f1\f1 option when
\fB\-\-tlsClusterFile\f1\f1 is not set. If the TLS
certificate is set, by default, the instance sends the certificate when
initiating intra\-cluster communications with other
\fBmongod\f1\f1 or \fBmongos\f1\f1 instances in
the deployment. Set \fBtlsWithholdClientCertificate\f1 to \fB1\f1 or \fBtrue\f1 to
direct the instance to withhold sending its TLS certificate during these
communications. Use this option with
\fB\-\-tlsAllowConnectionsWithoutCertificates\f1\f1
(to allow inbound connections without certificates) on all members of the
deployment. \fBtlsWithholdClientCertificate\f1 is mutually exclusive with
\fB\-\-clusterAuthMode x509\f1\f1\&.
.RE
.PP
\fBtlsX509ClusterAuthDNOverride\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
An alternative Distinguished Name (DN) that the instance can also
use to identify members of the deployment.
.PP
For a MongoDB deployment that uses x.509 certificates for
\fBclusterAuthMode\f1\f1, deployment members identify
each other using x.509 certificates (
\fBnet.tls.clusterFile\f1\f1, if specified, and
\fBnet.tls.certificateKeyFile\f1\f1) during intra\-cluster
communications. For members of the same deployment, the \fBDN\f1 from
their certificates must have the same Organization attributes
(\fBO\f1\(aqs), the Organizational Unit attributes (\fBOU\f1\(aqs), and the
Domain Components (\fBDC\f1\(aqs).
.PP
If \fBtlsX509ClusterAuthDNOverride\f1\f1 is set for a member,
the member can also use the override value when comparing the \fBDN\f1
components (\fBO\f1\(aqs, \fBOU\f1\(aqs, and \fBDC\f1\(aqs) of the presented
certificates. That is the member checks the presented certificates
against its
\fBnet.tls.clusterFile\f1\f1/\fBnet.tls.certificateKeyFile\f1\f1\&.
If the DN does not match, the member checks the presented
certificate against the \fBtlsX509ClusterAuthDNOverride\f1\f1
value.
.PP
If set, you must set this parameter on all members of the
deployment.
.PP
You can use this parameter for a rolling update of certificates to
new certificates that contain a new \fBDN\f1 value. See
\fBRolling Update of x.509 Cluster Certificates that Contain New DN\f1\&.
.PP
For more information about membership certificate requirements, see
\fBMember Certificate Requirements\f1 for details.
.RE
.PP
\fBtlsX509ExpirationWarningThresholdDays\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1 : 30
.PP
Starting in MongoDB 4.4, \fBmongod\f1\f1 / \fBmongos\f1\f1
logs a warning on connection if the presented x.509 certificate
expires within \fB30\f1 days of the \fBmongod/mongos\f1 system clock.
Use the \fBtlsX509ExpirationWarningThresholdDays\f1\f1 parameter
to control the certificate expiration warning threshold:
.RS
.IP \(bu 2
Increase the parameter value to trigger warnings farther ahead of
the certificate expiration date.
.IP \(bu 2
Decrease the parameter value to trigger warnings closer to the
certificate expiration date.
.IP \(bu 2
Set the parameter to \fB0\f1 to disable the warning.
.RE
.PP
This parameter has a minimum value of \fB0\f1\&.
.PP
You can only set \fBtlsX509ExpirationWarningThresholdDays\f1\f1
during \fBmongod/mongos\f1 startup using either:
.RS
.IP \(bu 2
The \fBsetParameter\f1\f1 configuration setting, \fIor\f1
.IP \(bu 2
The \fBmongod \-\-setParameter\f1\f1 /
\fBmongos \-\-setParameter\f1\f1 command
line option.
.RE
.PP
See \fBx.509 Certificates Nearing Expiry Trigger Warnings\f1 for more
information on x.509 expiration warnings in MongoDB 4.4.
.PP
For more information on x.509 certificate validity, see RFC 5280
4.1.2.5 (https://tools.ietf.org/html/rfc5280#section\-4.1.2.5)\&.
.RE
.PP
\fBsslWithholdClientCertificate\f1
.RS
.PP
Use \fBtlsWithholdClientCertificate\f1\f1 instead.
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: false
.PP
A TLS certificate is set for a \fBmongod\f1\f1 or
\fBmongos\f1\f1 either by the
\fB\-\-tlsClusterFile\f1\f1 option or by the
\fB\-\-tlsCertificateKeyFile\f1\f1 option when
\fB\-\-tlsClusterFile\f1\f1 is not set. If the TLS
certificate is set, by default, the instance sends the certificate when
initiating intra\-cluster communications with other
\fBmongod\f1\f1 or \fBmongos\f1\f1 instances in
the deployment. Set \fBsslWithholdClientCertificate\f1 to \fB1\f1 or \fBtrue\f1 to
direct the instance to withhold sending its TLS certificate during these
communications. Use this option with
\fB\-\-tlsAllowConnectionsWithoutCertificates\f1\f1
(to allow inbound connections without certificates) on all members of the
deployment. \fBsslWithholdClientCertificate\f1 is mutually exclusive with
\fB\-\-clusterAuthMode x509\f1\f1\&.
.RE
.PP
\fBuserCacheInvalidationIntervalSecs\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIDefault\f1: 30
.PP
On a \fBmongos\f1\f1 instance, specifies the interval (in seconds)
at which the \fBmongos\f1\f1 instance checks to determine whether
the in\-memory cache of \fBuser objects\f1 has stale data, and if so,
clears the cache. If there are no changes to user objects,
\fBmongos\f1\f1 will not clear the cache.
.PP
This parameter has a minimum value of \fB1\f1 second and a maximum
value of \fB86400\f1 seconds (24 hours).
.RE
.PP
\fBauthFailedDelayMs\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 0
.PP
Available in MongoDB Enterprise only.
.PP
The number of milliseconds to wait before informing clients that their
authentication attempt has failed. This parameter may be in the range
\fB0\f1 to \fB5000\f1, inclusive.
.PP
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.
.RE
.PP
\fBallowRolesFromX509Certificates\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: true
.PP
A boolean flag that allows or disallows the retrieval of
authorization roles from client x.509 certificates.
.PP
You can only set \fBallowRolesFromX509Certificates\f1\f1 during
startup in the config file or on the command line.
.RE
.SS GENERAL PARAMETERS
.PP
\fBallowDiskUseByDefault\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: True
.PP
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
\fB{ allowDiskUse: true }\f1 to individual \fBfind\f1 and \fBaggregate\f1
commands to enable this behavior.
.PP
Individual \fBfind\f1 and \fBaggregate\f1 commands may override the
\fBallowDiskUseByDefault\f1\f1 parameter by either:
.RS
.IP \(bu 2
Using \fB{ allowDiskUse: true }\f1 to allow writing temporary files out
to disk when \fBallowDiskUseByDefault\f1 is set to \fBfalse\f1
.IP \(bu 2
Using \fB{ allowDiskUse: false }\f1 to prohibit writing temporary files
out to disk when \fBallowDiskUseByDefault\f1 is set to \fBtrue\f1
.RE
.PP
.EX
  mongod \-\-setParameter allowDiskUseByDefault=false
.EE
.PP
\fBallowDiskUseByDefault\f1\f1 only works on \fBmongod\f1\f1
not \fBmongos\f1\f1\&. \fBmongos\f1\f1 never writes temporary
files to disk. Use the \fBsetParameter\f1\f1 command in
a \fBmongosh\f1\f1 session that is connected to a running
\fBmongod\f1\f1 to change the value of the parameter while the
server is running:
.PP
.EX
  db.adminCommand(
    {
        setParameter: 1,
        allowDiskUseByDefault: false
    }
  )
.EE
.RE
.PP
\fBconnPoolMaxShardedConnsPerHost\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 200
.PP
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 \fIdoes\f1 prevent the connection pools from
retaining connections above this limit.
.PP
The parameter is separate from the connections in TaskExecutor
pools. See \fBShardingTaskExecutorPoolMaxSize\f1\f1\&.
.PP
Increase the \fBconnPoolMaxShardedConnsPerHost\f1\f1 value
\fBonly\f1 if the number of connections in a connection pool has a
high level of churn or if the total number of created connections
increase.
.PP
You can only set \fBconnPoolMaxShardedConnsPerHost\f1\f1 during
startup in the config file or on the command line. For example:
.PP
.EX
  mongos \-\-setParameter connPoolMaxShardedConnsPerHost=250
.EE
.RE
.PP
\fBconnPoolMaxShardedInUseConnsPerHost\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets the maximum number of in\-use connections at any given time for
the legacy sharded cluster connection pools.
.PP
By default, the parameter is unset.
.PP
You can only set \fBconnPoolMaxShardedConnsPerHost\f1\f1 during
startup in the config file or on the command line. For example:
.PP
.EX
  mongos \-\-setParameter connPoolMaxShardedInUseConnsPerHost=100
.EE
.PP
\fBconnPoolMaxShardedConnsPerHost\f1\f1
.RE
.PP
\fBshardedConnPoolIdleTimeoutMinutes\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets the time limit that a connection in the legacy sharded cluster
connection pool can remain idle before being closed.
.PP
By default, the parameter is unset.
.PP
You can only set \fBshardedConnPoolIdleTimeoutMinutes\f1\f1 during
startup in the config file or on the command line. For example:
.PP
.EX
  mongos \-\-setParameter shardedConnPoolIdleTimeoutMinutes=10
.EE
.PP
\fBconnPoolMaxShardedConnsPerHost\f1\f1
.RE
.PP
\fBslowConnectionThresholdMillis\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 100
.PP
Sets the time limit in milliseconds to log the establishment of slow
server connections.
.PP
If a connection takes longer to establish than the
\fBslowConnectionThresholdMillis\f1\f1 parameter, an event is
added to the \fBlog\f1 with the message \fBmsg\f1
field set to \fB"Slow connection establishment"\f1\&.
.PP
The following example sets \fBslowConnectionThresholdMillis\f1\f1
to \fB250\f1 milliseconds.
.PP
.EX
  mongod \-\-setParameter slowConnectionThresholdMillis=250
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, slowConnectionThresholdMillis: 250 } )
.EE
.RE
.PP
\fBconnPoolMaxConnsPerHost\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 200
.PP
Sets the maximum size of the legacy connection pools for outgoing connections
to other \fBmongod\f1\f1 instances in the global connection pool. The size
of a pool does not prevent the creation of additional connections,
but \fIdoes\f1 prevent a connection pool from retaining connections in
excess of the value of \fBconnPoolMaxConnsPerHost\f1\f1\&.
.PP
The parameter is separate from the connections in TaskExecutor
pools. See \fBShardingTaskExecutorPoolMaxSize\f1\f1\&.
.PP
\fBOnly\f1 adjust this setting if your driver does \fInot\f1 pool
connections and you\(aqre using authentication in the
context of a sharded cluster.
.PP
You can only set \fBconnPoolMaxConnsPerHost\f1\f1 during startup
in the config file or on the command line. For example:
.PP
.EX
  mongod \-\-setParameter connPoolMaxConnsPerHost=250
.EE
.RE
.PP
\fBconnPoolMaxInUseConnsPerHost\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets the maximum number of in\-use connections at any given time for
for outgoing connections to other \fBmongod\f1\f1 instances in
the legacy global connection pool.
.PP
By default, the parameter is unset.
.PP
You can only set \fBconnPoolMaxInUseConnsPerHost\f1\f1 during
startup in the config file or on the command line. For example:
.PP
.EX
  mongod \-\-setParameter connPoolMaxInUseConnsPerHost=100
.EE
.PP
\fBconnPoolMaxConnsPerHost\f1\f1
.RE
.PP
\fBglobalConnPoolIdleTimeoutMinutes\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets the time limit that connection in the legacy global connection
pool can remain idle before being closed.
.PP
By default, the parameter is unset.
.PP
You can only set \fBglobalConnPoolIdleTimeoutMinutes\f1\f1
during startup in the config file or on the command line. For
example:
.PP
.EX
  mongos \-\-setParameter globalConnPoolIdleTimeoutMinutes=10
.EE
.PP
\fBconnPoolMaxShardedConnsPerHost\f1\f1
.RE
.PP
\fBcursorTimeoutMillis\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 600000 (10 minutes)
.PP
Sets the expiration threshold in milliseconds for idle cursors before
MongoDB removes them; specifically, MongoDB removes cursors that have
been idle for the specified \fBcursorTimeoutMillis\f1\f1\&.
.PP
For example, the following sets the \fBcursorTimeoutMillis\f1\f1
to \fB300000\f1 milliseconds (5 minutes).
.PP
.EX
  mongod \-\-setParameter cursorTimeoutMillis=300000
.EE
.PP
Or, if using the \fBsetParameter\f1\f1 command within
\fBmongosh\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, cursorTimeoutMillis: 300000 } )
.EE
.PP
Setting \fBcursorTimeoutMillis\f1\f1 to less than or equal
to \fB0\f1 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 \fBcursor.explain()\f1\f1
cursor modifier to analyze the average query time and select an appropriate
timeout period.
.RE
.PP
\fBfailIndexKeyTooLong\f1
.RS
.PP
\fIRemoved in 4.4\f1
.RS
.IP \(bu 2
\fBMongoDB 4.4\f1 \fIremoves\f1 the deprecated
\fBfailIndexKeyTooLong\f1\f1 parameter. Attempting to use
this parameter with MongoDB 4.4 will result in an error.
.IP \(bu 2
\fBMongoDB 4.2\f1 \fIdeprecates\f1 the
\fBfailIndexKeyTooLong\f1\f1 parameter and \fIremoves\f1 the
\fBIndex Key Length Limit\f1 for
\fBfeatureCompatibilityVersion\f1 (fCV) set to
\fB"4.2"\f1 or greater.
.RE
.PP
Setting \fBfailIndexKeyTooLong\f1\f1 to \fBfalse\f1 is
a temporary workaround, not a permanent solution to the
problem of oversized index keys. With
\fBfailIndexKeyTooLong\f1\f1 set to \fBfalse\f1, queries can
return incomplete results if they use indexes that skip over
documents whose indexed fields exceed the
\fBIndex Key Length Limit\f1\&.
.PP
\fBfailIndexKeyTooLong\f1\f1 defaults to \fBtrue\f1\&.
.PP
Issue the following command to disable the index key length
validation:
.PP
.EX
  db.adminCommand( { setParameter: 1, failIndexKeyTooLong: false } )
.EE
.PP
You can also set \fBfailIndexKeyTooLong\f1\f1 at startup with the
following option:
.PP
.EX
  mongod \-\-setParameter failIndexKeyTooLong=false
.EE
.RE
.PP
\fBmaxNumActiveUserIndexBuilds\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 3
.PP
Sets the maximum number of concurrent index builds allowed on the
\fBprimary\f1\&. This is a global limit that applies across all
collections.
.PP
Increasing the value of \fBmaxNumActiveUserIndexBuilds\f1 allows
additional concurrent index builds at the cost of increased pressure
on the WiredTiger cache.
.PP
System indexes are not limited to \fBmaxNumActiveUserIndexBuilds\f1,
however a system index build counts against the limit for user index
builds.
.PP
After the server reaches \fBmaxNumActiveUserIndexBuilds\f1, it blocks
additional user index builds until the number of concurrent index
builds drops below the \fBmaxNumActiveUserIndexBuilds\f1 limit. If an
index build is blocked, the server logs this message:
.PP
.EX
  Too many index builds running simultaneously, waiting until the
  number of active index builds is below the threshold.
.EE
.PP
The following command sets a limit of 4 concurrent index builds:
.PP
.EX
  db.adminCommand( { setParameter: 1, maxNumActiveUserIndexBuilds: 4 } )
.EE
.PP
See also:
.RS
.IP \(bu 2
\fBmaxIndexBuildMemoryUsageMegabytes\f1\f1
.IP \(bu 2
\fBIndex Builds on Populated Collections\f1
.RE
.RE
.PP
\fBnotablescan\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specify whether \fBall\f1 queries must use indexes. If \fB1\f1, MongoDB
will not execute queries that require a collection scan and will return an
error.
.PP
Consider the following example which sets \fBnotablescan\f1\f1 to \fB1\f1
or true:
.PP
.EX
  db.adminCommand( { setParameter: 1, notablescan: 1 } )
.EE
.PP
Setting \fBnotablescan\f1\f1 to \fB1\f1 can be useful for testing
application queries, for example, to identify queries that scan an
entire collection and cannot use an index.
.PP
To detect unindexed queries without \fBnotablescan\f1, consider reading
the \fBEvaluate Performance of Current Operations\f1 and
\fBOptimize Query Performance\f1
sections and using the \fBlogLevel\f1\f1 parameter,
\fBmongostat\f1\f1 and \fBprofiling\f1\&.
.PP
Don\(aqt run production \fBmongod\f1\f1 instances with
\fBnotablescan\f1\f1 because preventing collection scans can potentially
affect queries in all databases, including administrative queries.
.RE
.PP
\fBttlMonitorEnabled\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: \fBtrue\f1
.PP
To support \fBTTL Indexes\f1, \fBmongod\f1\f1
instances have a background thread that is responsible for deleting
documents from collections with TTL indexes.
.PP
To disable this worker thread for a \fBmongod\f1\f1, set
\fBttlMonitorEnabled\f1\f1 to \fBfalse\f1, as in the following
operations:
.PP
.EX
  db.adminCommand( { setParameter: 1, ttlMonitorEnabled: false } )
.EE
.PP
Alternately, you may disable the thread at startup time by starting the
\fBmongod\f1\f1 instance with the following option:
.PP
.EX
  mongod \-\-setParameter ttlMonitorEnabled=false
.EE
.PP
Do not run production \fBmongod\f1\f1 instances with
\fBttlMonitorEnabled\f1 disabled, except under guidance from MongoDB
support. Preventing TTL document removal can negatively impact
MongoDB internal system operations that depend on TTL Indexes.
.RE
.PP
\fBtcpFastOpenServer\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: \fBtrue\f1
.PP
Enables support for accepting inbound TCP Fast Open (TFO) connections
to the \fBmongod/mongos\f1 from a client. TFO requires both the
client and \fBmongod/mongos\f1 host machine support and enable
TFO:
.PP
\fBWindows\f1
.RS
.PP
The following Windows operating systems support TFO:
.RS
.IP \(bu 2
Microsoft Windows Server 2016 and later.
.IP \(bu 2
Microsoft Windows 10 Update 1607 and later.
.RE
.RE
.PP
\fBmacOS\f1
.RS
.PP
macOS 10.11 (El Capitan) and later support TFO.
.RE
.PP
\fBLinux\f1
.RS
.PP
Linux operating systems running Linux Kernel 3.7 or later
can support inbound TFO.
.PP
Set the value of \fB/proc/sys/net/ipv4/tcp_fastopen\f1 to
enable inbound TFO connections:
.RS
.IP \(bu 2
Set to \fB2\f1 to enable only inbound TFO connections.
.IP \(bu 2
Set to \fB3\f1 to enable inbound and outbound TFO connections.
.RE
.RE
.PP
This parameter has no effect if the host operating system does not
support \fIor\f1 is not configured to support TFO connections.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.PP
See \fBSupport for TCP Fast Open\f1 for more information on
MongoDB TFO support.
.PP
RFC7413 (https://tools.ietf.org/html/rfc7413)\&.
.RE
.PP
\fBtcpFastOpenClient\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: \fBtrue\f1
.PP
\fILinux Operating System Only\f1
.PP
Enables support for outbound TCP Fast Open (TFO) connections from the
\fBmongod/mongos\f1 to a client. TFO requires both the client
and the \fBmongod/mongos\f1 host machine support and enable TFO.
.PP
Linux operating systems running Linux Kernel 4.11 or later can
support outbound TFO.
.PP
Set the value of \fB/proc/sys/net/ipv4/tcp_fastopen\f1 to enable
outbound TFO connections:
.RS
.IP \(bu 2
\fB1\f1 to enable only outbound TFO connections.
.IP \(bu 2
\fB3\f1 to enable inbound and outbound TFO connections.
.RE
.PP
This parameter has no effect if the host operating system does not
support \fIor\f1 is not configured to support TFO connections.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.PP
See \fBSupport for TCP Fast Open\f1 for more information on
MongoDB TFO support.
.PP
RFC7413 (https://tools.ietf.org/html/rfc7413)\&.
.RE
.PP
\fBtcpFastOpenQueueSize\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: \fB1024\f1
.PP
As part of establishing a TCP Fast Open (TFO) connection, the client
submits a valid TFO cookie to the \fBmongod/mongos\f1 \fIbefore\f1
completion of the standard TCP 3\-way handshake. The
\fBmongod/mongos\f1 keeps a queue of all such pending TFO connections.
.PP
The \fBtcpFastOpenQueueSize\f1 parameter sets the size of the queue of
pending TFO connections. While the queue is full, the
\fBmongod/mongos\f1 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 \fBmongod/mongos\f1
begins accepting new TFO cookies.
.RS
.IP \(bu 2
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.
.IP \(bu 2
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.
.IP
The minimum queue size is \fB0\f1\&. A queue of \fB0\f1 effectively
disables TFO.
.RE
.PP
This parameter has no effect on host operating systems that do
not support or are not configured for TFO connections. See
\fBSupport for TCP Fast Open\f1 for more information on
MongoDB TFO support.
.RS
.IP \(bu 2
RFC7413 TCP Fast Open Section 5: Security Considerations (https://tools.ietf.org/html/rfc7413#section\-5)
.IP \(bu 2
RFC7413 TCP Fast Open Section 6: TFO Applicability (https://tools.ietf.org/html/rfc7413#section\-6)
.RE
.RE
.PP
\fBdisableJavaScriptJIT\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
The MongoDB JavaScript engine uses SpiderMonkey, which implements
Just\-in\-Time (JIT) compilation for improved performance when running scripts.
.PP
To enable the JIT, set \fBdisableJavaScriptJIT\f1\f1 to \fBfalse\f1, as in
the following example:
.PP
.EX
  db.adminCommand( { setParameter: 1, disableJavaScriptJIT: false } )
.EE
.PP
\fB$where\f1\f1 will reuse existing JavaScript interpreter
contexts, so changes to \fBdisableJavaScriptJIT\f1\f1 may not
take effect immediately for these operations.
.PP
Alternately, you may enable the JIT at startup time by starting the
\fBmongod\f1\f1 instance with the following option:
.PP
.EX
  mongod \-\-setParameter disableJavaScriptJIT=false
.EE
.RE
.PP
\fBindexMaxNumGeneratedKeysPerDocument\f1
.RS
.PP
\fIDefault\f1: 100000
.PP
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
\fBindexMaxNumGeneratedKeysPerDocument\f1\f1 parameter specifies,
the operation will fail.
.RE
.PP
\fBmaxIndexBuildMemoryUsageMegabytes\f1
.RS
.PP
\fIDefault\f1:
.RS
.IP \(bu 2
200 (For versions 4.2.3 and later)
.IP \(bu 2
500 (For versions 4.2.2 and earlier)
.RE
.PP
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
\fBcreateIndexes\f1\f1 command or its shell helper
\fBdb.collection.createIndexes()\f1\f1\&.
.PP
The memory consumed by an index build is separate from the
WiredTiger cache memory (see
\fBcacheSizeGB\f1\f1).
.PP
Index builds may be initiated either by a user command such as
\fBcreateIndexes\f1\f1 or by an administrative process such as an
\fBinitial sync\f1\&. Both are subject to the limit
set by \fBmaxIndexBuildMemoryUsageMegabytes\f1\f1\&.
.PP
An \fBinitial sync\f1 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
\fBmaxIndexBuildMemoryUsageMegabytes\f1\f1\&.
.PP
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 \fBRolling Index Builds on Replica Sets\f1\&.
.RS
.IP \(bu 2
For \fBfeature compatibility version (fcv)\f1 \fB"4.2"\f1
and later, the index build memory limit applies to all index builds.
.RE
.RE
.PP
\fBreportOpWriteConcernCountersInServerStatus\f1
.RS
.PP
\fIDefault\f1: false
.PP
A boolean flag that determines whether the
\fBdb.serverStatus()\f1\f1 method and \fBserverStatus\f1\f1
command return \fBopWriteConcernCounters\f1\f1 information. 
.PP
You can only set
\fBreportOpWriteConcernCountersInServerStatus\f1\f1 during
startup in the config file or on the command line. For example:
.PP
.EX
  mongod \-\-setParameter reportOpWriteConcernCountersInServerStatus=true
.EE
.RE
.PP
\fBwatchdogPeriodSeconds\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: \-1 (disabled)
.PP
Determines how frequent the \fBStorage Node Watchdog\f1 checks the status of the monitored
filesystems:
.RS
.IP \(bu 2
The \fB\-\-dbpath\f1\f1 directory
.IP \(bu 2
The \fBjournal\f1 directory inside the \fB\-\-dbpath\f1\f1
directory
.IP \(bu 2
The directory of \fB\-\-logpath\f1\f1 file
.IP \(bu 2
The directory of \fB\-\-auditPath\f1\f1 file
.RE
.PP
Valid values for \fBwatchdogPeriodSeconds\f1\f1 are:
.RS
.IP \(bu 2
\fB\-1\f1 (the default), to disable/pause \fBStorage Node Watchdog\f1, or
.IP \(bu 2
An integer greater than or equal to 60.
.RE
.RS
.IP \(bu 2
If a filesystem on a monitored directory becomes unresponsive,
it can take a maximum of nearly \fItwice\f1 the value of
\fBwatchdogPeriodSeconds\f1\f1 to terminate the
\fBmongod\f1\f1\&.
.IP \(bu 2
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 \fBmongod\f1\f1 uses
\fBstorage.directoryPerDB: true\f1\f1 (or \fB\-\-directoryperdb\f1\f1) and symlinks a database directory to
another volume, the Storage Node Watchdog does not follow the
symlink to monitor the target.
.RE
.PP
To enable \fBStorage Node Watchdog\f1,
\fBwatchdogPeriodSeconds\f1\f1 must be set during startup.
.PP
.EX
  mongod \-\-setParameter watchdogPeriodSeconds=60
.EE
.PP
You can only enable the \fBStorage Node Watchdog\f1 at startup. However, once enabled, you can
pause the \fBStorage Node Watchdog\f1 or
change the \fBwatchdogPeriodSeconds\f1\f1 during run time.
.PP
Once enabled,
.RS
.IP \(bu 2
To pause the \fBStorage Node Watchdog\f1
during run time, set \fBwatchdogPeriodSeconds\f1\f1 to \-1.
.IP
.EX
  db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: \-1 } )
.EE
.IP \(bu 2
To resume or change the period during run time, set
\fBwatchdogPeriodSeconds\f1\f1 to a number greater than or
equal to 60.
.IP
.EX
  db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )
.EE
.RE
.PP
It is an error to set \fBwatchdogPeriodSeconds\f1\f1 at run time if the
\fBStorage Node Watchdog\f1 was not enabled at
startup time.
.RE
.PP
\fBtcmallocReleaseRate\f1
.RS
.PP
Default: 1.0
.PP
Specifies the tcmalloc release rate (TCMALLOC_RELEASE_RATE (https://gperftools.github.io/gperftools/tcmalloc.html#runtime)).
Per https://gperftools.github.io/gperftools/tcmalloc.html#runtime (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]."
.PP
To modify the release rate during run time, you can use the
\fBsetParameter\f1\f1 command; for example:
.PP
.EX
  db.adminCommand( { setParameter: 1, tcmallocReleaseRate: 5.0 } )
.EE
.PP
You can also set \fBtcmallocReleaseRate\f1\f1 at startup time;
for example:
.PP
.EX
  mongod \-\-setParameter "tcmallocReleaseRate=5.0"
.EE
.RE
.PP
\fBfassertOnLockTimeoutForStepUpDown\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Default: 15 seconds
.PP
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.
.PP
\fBfassertOnLockTimeoutForStepUpDown\f1 defaults to 15 seconds. To disable
nodes from fasserting, set \fBfassertOnLockTimeoutForStepUpDown=0\f1\&.
.PP
The following example disables nodes from fasserting:
.PP
.EX
  mongod \-\-setParameter fassertOnLockTimeoutForStepUpDown=0
.EE
.RE
.SS LOGGING PARAMETERS
.PP
\fBlogLevel\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Specify an integer between \fB0\f1 and \fB5\f1 signifying the verbosity
of the \fBlogging\f1, where \fB5\f1 is the
most verbose. 
.PP
The default \fBlogLevel\f1\f1 is \fB0\f1 (Informational).
.PP
The following example sets the \fBlogLevel\f1\f1 to \fB2\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, logLevel: 2 } )
.EE
.RS
.IP \(bu 2
\fBlogComponentVerbosity\f1\f1
.IP \(bu 2
\fBsystemLog.verbosity\f1\f1
.RE
.RE
.PP
\fBlogComponentVerbosity\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets the verbosity levels of various \fBcomponents\f1 for \fBlog messages\f1\&. The verbosity level determines the
amount of \fBInformational and Debug\f1
messages MongoDB outputs. 
.PP
The verbosity level can range from \fB0\f1 to \fB5\f1:
.RS
.IP \(bu 2
\fB0\f1 is the MongoDB\(aqs default log verbosity level, to include
\fBInformational\f1 messages.
.IP \(bu 2
\fB1\f1 to \fB5\f1 increases the verbosity level to include
\fBDebug\f1 messages.
.RE
.PP
For a component, you can also specify \fB\-1\f1 to inherit the parent\(aqs
verbosity level.
.PP
To specify the verbosity level, use a document similar to the
following:
.PP
.EX
  {
    verbosity: <int>,
    <component1>: { verbosity: <int> },
    <component2>: {
       verbosity: <int>,
       <component3>: { verbosity: <int> }
    },
    ...
  }
.EE
.PP
For the components, you can specify just the \fB<component>: <int>\f1
in the document, unless you are setting both the parent verbosity
level and that of the child component(s) as well:
.PP
.EX
  {
    verbosity: <int>,
    <component1>: <int> ,
    <component2>: {
       verbosity: <int>,
       <component3>: <int>
    }
    ...
  }
.EE
.PP
The top\-level \fBverbosity\f1 field corresponds to
\fBsystemLog.verbosity\f1\f1 which sets the default level for all
components. The default value of \fBsystemLog.verbosity\f1\f1 is
\fB0\f1\&.
.PP
The components correspond to the following settings:
.RS
.IP \(bu 2
\fBaccessControl\f1\f1
.IP \(bu 2
\fBcommand\f1\f1
.IP \(bu 2
\fBcontrol\f1\f1
.IP \(bu 2
\fBftdc\f1\f1
.IP \(bu 2
\fBgeo\f1\f1
.IP \(bu 2
\fBindex\f1\f1
.IP \(bu 2
\fBnetwork\f1\f1
.IP \(bu 2
\fBquery\f1\f1
.IP \(bu 2
\fBreplication\f1\f1
.IP \(bu 2
\fBreplication.election\f1\f1
.IP \(bu 2
\fBreplication.heartbeats\f1\f1
.IP \(bu 2
\fBreplication.initialSync\f1\f1
.IP \(bu 2
\fBreplication.rollback\f1\f1
.IP \(bu 2
\fBrecovery\f1\f1
.IP \(bu 2
\fBsharding\f1\f1
.IP \(bu 2
\fBstorage\f1\f1
.IP \(bu 2
\fBstorage.journal\f1\f1
.IP \(bu 2
\fBtransaction\f1\f1
.IP \(bu 2
\fBwrite\f1\f1
.RE
.PP
Unless explicitly set, the component has the verbosity level of its
parent. For example, \fBstorage\f1 is the parent of
\fBstorage.journal\f1\&. That is, if you specify a \fBstorage\f1\f1 verbosity level, this level
also applies to:
.RS
.IP \(bu 2
\fBstorage.journal\f1\f1 components
\fIunless\f1 you specify the verbosity level for
\fBstorage.journal\f1\f1\&.
.IP \(bu 2
\fBstorage.recovery\f1\f1 components
\fIunless\f1 you specify the verbosity level for
\fBstorage.recovery\f1\f1\&.
.RE
.PP
For example, the following sets the \fBdefault verbosity
level\f1\f1 to \fB1\f1, the \fBquery\f1\f1 to \fB2\f1, the
\fBstorage\f1\f1 to \fB2\f1,
and the \fBstorage.journal\f1\f1 to \fB1\f1\&.
.PP
.EX
  db.adminCommand( {
     setParameter: 1,
     logComponentVerbosity: {
        verbosity: 1,
        query: { verbosity: 2 },
        storage: {
           verbosity: 2,
           journal: {
              verbosity: 1
           }
        }
     }
  } )
.EE
.PP
You can also set parameter \fBlogComponentVerbosity\f1\f1 at
startup time, passing the verbosity level document as a string.
.PP
.EX
  mongod \-\-setParameter "logComponentVerbosity={command: 3}"
.EE
.PP
\fBmongosh\f1\f1 also provides the \fBdb.setLogLevel()\f1\f1
to set the log level for a single component. For various ways to set
the log verbosity level, see \fBConfigure Log Verbosity Levels\f1\&.
.RE
.PP
\fBmaxLogSizeKB\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: non\-negative integer
.PP
\fIDefault\f1: 10
.PP
Specifies the maximum size, in kilobytes, for an individual
attribute field in a log entry; attributes exceeding this limit are
truncated.
.PP
Truncated attribute fields print field content up to the
\fBmaxLogSizeKB\f1\f1 limit and excise field content past that
limit, retaining valid JSON formatting. Log entries that contain
truncated attributes append a \fBtruncated\f1 object to the end of the
log entry.
.PP
See \fBlog message truncation\f1 for more
information.
.PP
A value of \fB0\f1 disables truncation entirely. Negative values for
this parameter are not valid.
.PP
Using a large value, or disabling truncation with a value of
\fB0\f1, may adversely affect system performance and negatively
impact database operations.
.PP
The following example sets the maximum log line size to \fB20\f1
kilobytes:
.PP
.EX
  mongod \-\-setParameter maxLogSizeKB=20
.EE
.RE
.PP
\fBquiet\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Sets quiet logging mode. If
\fB1\f1, \fBmongod\f1\f1 will go into a quiet logging
mode which will not log the following events/activities:
.RS
.IP \(bu 2
connection events;
.IP \(bu 2
the \fBdrop\f1\f1 command, the
\fBdropIndexes\f1\f1 command, the
\fBvalidate\f1\f1 command; and
.IP \(bu 2
replication synchronization activities.
.RE
.PP
Consider the following example which sets the
\fBquiet\f1 parameter to \fB1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, quiet: 1 } )
.EE
.PP
\fBsystemLog.quiet\f1\f1
.RE
.PP
\fBredactClientLogData\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
Available in MongoDB Enterprise only.
.PP
Configure the \fBmongod\f1\f1 or \fBmongos\f1\f1 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.
.PP
Use \fBredactClientLogData\f1\f1 in conjunction with
\fBEncryption at Rest\f1 and
\fBTLS/SSL (Transport Encryption)\f1 to assist compliance with
regulatory requirements.
.PP
To enable log redaction at startup, you can either:
.RS
.IP \(bu 2
Start \fBmongod\f1\f1 with the
\fB\-\-redactClientLogData\f1\f1 option:
.IP
.EX
  mongod \-\-redactClientLogData
.EE
.IP \(bu 2
Set the \fBsecurity.redactClientLogData\f1\f1 option in the
\fBconfiguration file\f1:
.IP
.EX
  security:
     redactClientLogData: true
     ...
.EE
.RE
.PP
You can\(aqt use the \fB\-\-setParameter\f1\f1
option to set \fBredactClientLogData\f1\f1 at startup.
.PP
To enable log redaction on a running \fBmongod\f1 or
\fBmongos\f1, use the following command:
.PP
.EX
  db.adminCommand( { setParameter: 1, redactClientLogData : true } )
.EE
.PP
\fBsecurity.redactClientLogData\f1\f1
.RE
.PP
\fBredactEncryptedFields\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: \fBtrue\f1
.PP
Configures \fBmongod\f1\f1 and \fBmongos\f1\f1 to redact field values
of encrypted \fBBinary\f1\f1 data from all
\fBlog messages\f1\&.
.RS
.IP \(bu 2
If the \fBredactClientLogData\f1\f1 parameter or the
\fBsecurity.redactClientLogData\f1\f1 setting is set to \fBfalse\f1 and
\fBredactEncryptedFields\f1 is set to \fBtrue\f1 (the default), encrypted
fields are redacted from all log messages.
.IP \(bu 2
If the \fBredactClientLogData\f1\f1 parameter or
\fBsecurity.redactClientLogData\f1\f1 setting is set to \fBtrue\f1,
all fields are redacted, regardless of the \fBredactEncryptedFields\f1
setting.
.RE
.RE
.PP
\fBtraceExceptions\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Configures \fBmongod\f1\f1 to log full source code stack traces
for every database and socket C++ exception, for use with debugging.
If \fBtrue\f1, \fBmongod\f1\f1 will log full stack traces.
.PP
Consider the following example which sets the
\fBtraceExceptions\f1 to \fBtrue\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, traceExceptions: true } )
.EE
.PP
\fBsystemLog.traceAllExceptions\f1\f1
.RE
.PP
\fBsuppressNoTLSPeerCertificateWarning\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
By default, a \fBmongod\f1\f1 or \fBmongos\f1\f1 with
\fBTLS/SSL enabled\f1 and
\fBnet.ssl.allowConnectionsWithoutCertificates\f1\f1 : \fBtrue\f1
lets clients connect without providing a certificate for
validation while logging an warning. Set
\fBsuppressNoTLSPeerCertificateWarning\f1 to \fB1\f1 or \fBtrue\f1 to
suppress those warnings.
.PP
The following operation sets \fBsuppressNoTLSPeerCertificateWarning\f1
to \fBtrue\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, suppressNoTLSPeerCertificateWarning: true} )
.EE
.RE
.PP
\fBgEnableDetailedConnectionHealthMetricLogLines\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Determines whether to enable specific log messages related to cluster
connection health metrics. If
\fBgEnableDetailedConnectionHealthMetricLogLines\f1\f1 is set to
\fBfalse\f1, the following log messages are turned off, but MongoDB still
collects data on the cluster connection health metrics:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Log Message
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Accepted TLS connection from peer
.IP \(bu 4
Indicates that the server successfully parsed the peer certificate
during the TLS handshake with an accepted ingress connection.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Ingress TLS handshake complete
.IP \(bu 4
Indicates that the TLS handshake with an ingress connection is
complete.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Hello completed
.IP \(bu 4
Indicates that the initial connection handshake completed on an
incoming client connection.
.IP
MongoDB displays the log message only with the first \fBhello\f1
command.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Auth metrics report
.IP \(bu 4
Specifies the completion of a step in the authentication conversation.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Received first command on ingress connection since session start or
auth handshake
.IP \(bu 4
Indicates that an ingress connection received the first command that
is not part of the handshake.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Slow network response send time
.IP \(bu 4
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 \fBslowMS\f1 server parameter.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Completed client\-side verification of OCSP request
.IP \(bu 4
If the peer doesn\(aqt include an OCSP
(Online Certificate Status Protocol) 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.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Slow connection establishment
.IP \(bu 4
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 \fBslowConnectionThresholdMillis\f1\f1 parameter.
MongoDB also emits this log message when the connection establishment
times out.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Operation timed out while waiting to acquire connection
.IP \(bu 4
Indicates that an operation timed out while waiting to acquire an
egress connection.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
Acquired connection for remote operation and completed writing to
wire
.IP \(bu 4
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.
.RE
.RE
.RE
.SS DIAGNOSTIC PARAMETERS
.PP
To facilitate analysis of the MongoDB server behavior by MongoDB
engineers, MongoDB logs server statistics to diagnostic files at
periodic intervals.
.PP
For \fBmongod\f1\f1, the diagnostic data files are stored in the
\fBdiagnostic.data\f1 directory under the \fBmongod\f1\f1 instance\(aqs
\fB\-\-dbpath\f1 or \fBstorage.dbPath\f1\f1\&.
.PP
For \fBmongos\f1\f1, the diagnostic data files, by default, are
stored in a directory under the \fBmongos\f1\f1 instance\(aqs
\fB\-\-logpath\f1 or \fBsystemLog.path\f1\f1 directory. The diagnostic
data directory is computed by truncating the logpath\(aqs file
extension(s) and concatenating \fBdiagnostic.data\f1 to the remaining
name.
.PP
For example, if \fBmongos\f1\f1 has \fB\-\-logpath
/var/log/mongodb/mongos.log.201708015\f1, then the diagnostic data
directory is \fB/var/log/mongodb/mongos.diagnostic.data/\f1 directory. To
specify a different diagnostic data directory for \fBmongos\f1\f1,
set the \fBdiagnosticDataCollectionDirectoryPath\f1\f1 parameter.
.PP
The following parameters support diagnostic data capture (FTDC):
.PP
The default values for the diagnostic data capture interval and the
maximum sizes are chosen to provide useful data to MongoDB engineers
with minimal impact on performance and storage size. Typically, these
values will only need modifications as requested by MongoDB engineers
for specific diagnostic purposes.
.PP
\fBdiagnosticDataCollectionEnabled\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Determines whether to enable the collecting and logging of data for
diagnostic purposes. Diagnostic logging is enabled by default.
.PP
For example, the following disables the diagnostic collection:
.PP
.EX
  mongod \-\-setParameter diagnosticDataCollectionEnabled=false
.EE
.RE
.PP
\fBdiagnosticDataCollectionDirectoryPath\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: String
.PP
If \fBFull Time Diagnostic Data Capture (FTDC)\f1 is
disabled with \fBdiagnosticDataCollectionEnabled\f1\f1 or if
\fBsystemLog.destination\f1\f1 is set to \fBsyslog\f1, you must restart
\fBmongos\f1\f1 after setting
\fBdiagnosticDataCollectionDirectoryPath\f1\&.
.PP
Specify the directory for the diagnostic directory for
\fBmongos\f1\f1\&. If the directory does not exist,
\fBmongos\f1\f1 creates the directory.
.PP
If unspecified, the diagnostic data directory is computed by
truncating the \fBmongos\f1\f1 instance\(aqs \fB\-\-logpath\f1 or
\fBsystemLog.path\f1\f1 file extension(s) and concatenating
\fBdiagnostic.data\f1\&.
.PP
For example, if \fBmongos\f1\f1 has \fB\-\-logpath
/var/log/mongodb/mongos.log.201708015\f1, then the diagnostic data
directory is \fB/var/log/mongodb/mongos.diagnostic.data/\f1\&.
.PP
If the \fBmongos\f1\f1 cannot create the specified directory, the
diagnostic data capture is disabled for that instance. \fBmongos\f1\f1
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.
.RE
.PP
\fBdiagnosticDataCollectionDirectorySizeMB\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 200
.PP
Specifies the maximum size, in megabytes, of the \fBdiagnostic.data\f1
directory. If directory size exceeds this number, the oldest
\fBdiagnostic files in the directory\f1 are automatically deleted based on
the timestamp in the file name.
.PP
For example, the following sets the maximum size of the directory to
\fB250\f1 megabytes:
.PP
.EX
  mongod \-\-setParameter diagnosticDataCollectionDirectorySizeMB=250
.EE
.PP
The minimum value for
\fBdiagnosticDataCollectionDirectorySizeMB\f1\f1 is \fB10\f1
megabytes. \fBdiagnosticDataCollectionDirectorySizeMB\f1\f1 must
be greater than maximum diagnostic file size
\fBdiagnosticDataCollectionFileSizeMB\f1\f1\&.
.RE
.PP
\fBdiagnosticDataCollectionFileSizeMB\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 10
.PP
Specifies the maximum size, in megabytes, of each \fBdiagnostic
file\f1\&. If the file exceeds the maximum
file size, MongoDB creates a new file.
.PP
For example, the following sets the maximum size of each diagnostic
file to \fB20\f1 megabytes:
.PP
.EX
  mongod \-\-setParameter diagnosticDataCollectionFileSizeMB=20
.EE
.PP
The minimum value for
\fBdiagnosticDataCollectionFileSizeMB\f1\f1 is \fB1\f1 megabyte.
.RE
.PP
\fBdiagnosticDataCollectionPeriodMillis\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 1000
.PP
Specifies the interval, in milliseconds, at which to collect
diagnostic data.
.PP
For example, the following sets the interval to
\fB5000\f1 milliseconds or 5 seconds:
.PP
.EX
  mongod \-\-setParameter diagnosticDataCollectionPeriodMillis=5000
.EE
.PP
The minimum value for
\fBdiagnosticDataCollectionPeriodMillis\f1\f1 is \fB100\f1
milliseconds.
.RE
.SS REPLICATION AND CONSISTENCY
.PP
\fBdisableSplitHorizonIPCheck\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.RE
.PP
To configure cluster nodes for split horizon DNS (https://en.wikipedia.org/wiki/Split\-horizon_DNS), use host names
instead of IP addresses.
.PP
Starting in MongoDB v5.0, \fBreplSetInitiate\f1\f1 and
\fBreplSetReconfig\f1\f1 reject configurations that use IP
addresses instead of hostnames.
.PP
Use \fBdisableSplitHorizonIPCheck\f1\f1 to modify nodes that
cannot be updated to use host names. The parameter only applies to the
configuration commands.
.PP
\fBmongod\f1\f1 and \fBmongos\f1\f1 do not rely on
\fBdisableSplitHorizonIPCheck\f1\f1 for validation at startup.
Legacy \fBmongod\f1\f1 and \fBmongos\f1\f1 instances that use IP
addresses instead of host names will start after an upgrade.
.PP
Instances that are configured with IP addresses log a warning to use
host names instead of IP addresses.
.PP
To allow configuration changes using IP addresses, set
\fBdisableSplitHorizonIPCheck=true\f1 using the command line:
.PP
.EX
  /usr/local/bin/mongod  \-\-setParameter disableSplitHorizonIPCheck=true \-f /etc/mongod.conf
.EE
.PP
To allow configuration changes using IP addresses, set
\fBdisableSplitHorizonIPCheck=true\f1 using the node\(aqs configuration
file:
.PP
.EX
  setParameter:
     disableSplitHorizonIPCheck: true
.EE
.PP
If you attempt to update \fBdisableSplitHorizonIPCheck\f1 at run time,
\fBdb.adminCommand()\f1\f1 returns an error:
.PP
.EX
  db.adminCommand( { setParameter: 1, "disableSplitHorizonIPCheck": true } )
  MongoServerError: not allowed to change [disableSplitHorizonIPCheck] at run time
.EE
.PP
\fBenableOverrideClusterChainingSetting\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
If \fBenableOverrideClusterChainingSetting\f1\f1 is \fBtrue\f1,
replica set \fBsecondary\f1 members can replicate data from
other secondary members even if \fBsettings.chainingAllowed\f1\f1 is
\fBfalse\f1\&.
.PP
You can only set \fBenableOverrideClusterChainingSetting\f1\f1 at
startup and cannot change this setting with the
\fBsetParameter\f1\f1 command.
.PP
For example, to set the
\fBenableOverrideClusterChainingSetting\f1\f1 for a
\fBmongod\f1\f1 instance to \fBtrue\f1:
.PP
.EX
  mongod \-\-setParameter enableOverrideClusterChainingSetting=true
.EE
.RE
.PP
\fBlogicalSessionRefreshMillis\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 300000 (5 minutes)
.PP
The interval (in milliseconds) at which the cache refreshes its logical
session records against the main session store.
.PP
You can only set \fBlogicalSessionRefreshMillis\f1\f1 at
startup and cannot change this setting with the
\fBsetParameter\f1\f1 command.
.PP
For example, to set the \fBlogicalSessionRefreshMillis\f1\f1
for a \fBmongod\f1\f1 instance to 10 minutes:
.PP
.EX
  mongod \-\-setParameter logicalSessionRefreshMillis=600000
.EE
.RE
.PP
\fBlocalLogicalSessionTimeoutMinutes\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 30
.PP
This parameter is intended for testing purposes only and not for
production use.
.PP
The time in minutes that a \fBsession\f1 remains active
after its most recent use. Sessions that have not received a new
read/write operation from the client or been refreshed with
\fBrefreshSessions\f1\f1 within this threshold are cleared from the
cache. State associated with an expired session may be cleaned up by the
server at any time.
.PP
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.
.PP
You can only set \fBlocalLogicalSessionTimeoutMinutes\f1\f1 at
startup and cannot change this setting with the
\fBsetParameter\f1\f1 command.
.PP
For example, to set the \fBlocalLogicalSessionTimeoutMinutes\f1\f1
for a test \fBmongod\f1\f1 instance to 20 minutes:
.PP
.EX
  mongod \-\-setParameter localLogicalSessionTimeoutMinutes=20
.EE
.RE
.PP
\fBmaxAcceptableLogicalClockDriftSecs\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 31536000 (1 year)
.PP
The maximum amount by which the current cluster time can be advanced;
specifically, \fBmaxAcceptableLogicalClockDriftSecs\f1\f1 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.
.PP
You cannot advance the cluster time to a new value if the new
cluster time differs from the current cluster time by more than
\fBmaxAcceptableLogicalClockDriftSecs\f1\f1\&.
.PP
You can only set \fBmaxAcceptableLogicalClockDriftSecs\f1\f1 at
startup and cannot change this setting with the
\fBsetParameter\f1\f1 command.
.PP
For example, to set the \fBmaxAcceptableLogicalClockDriftSecs\f1\f1
for a \fBmongod\f1\f1 instance to 15 minutes:
.PP
.EX
  mongod \-\-setParameter maxAcceptableLogicalClockDriftSecs=900
.EE
.RE
.PP
\fBmaxSessions\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 1000000
.PP
The maximum number of sessions that can be cached.
.PP
You can only set \fBmaxSessions\f1\f1 during start\-up.
.PP
For example, to set the \fBmaxSessions\f1\f1
for a \fBmongod\f1\f1 instance to 1000:
.PP
.EX
  mongod \-\-setParameter maxSessions=1000
.EE
.RE
.PP
\fBoplogBatchDelayMillis\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 0
.PP
The number of milliseconds to delay applying batches of oplog
operations on secondary nodes. By default, \fBoplogBatchDelayMillis\f1
is \fB0\f1, meaning oplog batches are applied with no delay. When there
is no delay, MongoDB may apply frequent, small oplog batches to
secondaries.
.PP
Increasing \fBoplogBatchDelayMillis\f1 causes MongoDB to apply oplog
batches less frequently on secondaries, with each batch containing
larger amounts of data. This reduces IOPS (Input/Output
Operations Per Second) on secondaries, but adds latency for writes
with write concern \fB"majority"\f1\f1\&.
.PP
You can only set \fBoplogBatchDelayMillis\f1 at startup. You cannot set
\fBoplogBatchDelayMillis\f1 during run time.
.PP
For example, run the following command to set the
\fBoplogBatchDelayMillis\f1 for a \fBmongod\f1\f1 instance to 20
milliseconds:
.PP
.EX
  mongod \-\-setParameter oplogBatchDelayMillis=20
.EE
.RE
.PP
\fBstoreFindAndModifyImagesInSideCollection\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Determines whether the temporary documents required for
\fBretryable\f1 \fBfindAndModify\f1\f1
commands are stored in the \fIside\f1 collection
(\fBconfig.image_collection\f1).
.PP
If \fBstoreFindAndModifyImagesInSideCollection\f1\f1 is:
.RS
.IP \(bu 2
\fBtrue\f1, the temporary documents are stored in the side
collection.
.IP \(bu 2
\fBfalse\f1, the temporary documents are stored in the \fBreplica
set oplog\f1\&.
.RE
.PP
Keep \fBstoreFindAndModifyImagesInSideCollection\f1\f1 set to
\fBtrue\f1 if you:
.RS
.IP \(bu 2
Have a large \fBretryable\f1
\fBfindAndModify\f1\f1 workload.
.IP \(bu 2
Require more temporary document space for \fBretryable\f1 \fBfindAndModify\f1\f1 commands than is
available in the \fBreplica set oplog\f1\&.
.RE
.PP
\fBSecondaries\f1 may experience increased CPU
usage when \fBstoreFindAndModifyImagesInSideCollection\f1\f1
is \fBtrue\f1\&.
.PP
For example, to set
\fBstoreFindAndModifyImagesInSideCollection\f1\f1 to \fBfalse\f1
during startup:
.PP
.EX
  mongod \-\-setParameter storeFindAndModifyImagesInSideCollection=false
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, storeFindAndModifyImagesInSideCollection: false } )
.EE
.RE
.PP
\fBTransactionRecordMinimumLifetimeMinutes\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 30
.PP
The minimum lifetime a transaction record exists in the
\fBtransactions\f1\f1 collection before the record becomes
eligible for cleanup.
.PP
You can only set \fBTransactionRecordMinimumLifetimeMinutes\f1\f1 at
startup and cannot change this setting with the
\fBsetParameter\f1\f1 command.
.PP
For example, to set the \fBTransactionRecordMinimumLifetimeMinutes\f1\f1
for a \fBmongod\f1\f1 instance to 20 minutes:
.PP
.EX
  mongod \-\-setParameter TransactionRecordMinimumLifetimeMinutes=20
.EE
.PP
\fBlocalLogicalSessionTimeoutMinutes\f1\f1
.RE
.PP
\fBenableFlowControl\f1
.RS
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Enables or disables the mechanism that controls the rate at which the
primary applies its writes with the goal of keeping the secondary members\(aq
\fBmajority committed\f1\f1 lag under a
configurable maximum value.
.PP
For flow control to engage, the replica set/sharded cluster must
have: \fBfeatureCompatibilityVersion (fCV)\f1 of
\fB4.2\f1 and read concern \fBmajority enabled\f1\f1\&. That is, enabled flow
control has no effect if fCV is not \fB4.2\f1 or if read concern
majority is disabled.
.RE
.PP
\fBflowControlTargetLagSeconds\f1
.RS
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 10
.PP
The target maximum \fBmajority committed\f1\f1 lag when running
with flow control. When flow control is enabled, the mechanism
attempts to keep the \fBmajority committed\f1\f1 lag under
the specified seconds. The parameter has no effect if flow control
is disabled.
.PP
The specified value must be greater than 0.
.PP
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.
.RE
.PP
\fBflowControlWarnThresholdSeconds\f1
.RS
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 10
.PP
The amount of time to wait to log a warning once the flow control
mechanism detects the majority commit point has not moved.
.PP
The specified value must be greater than or equal to 0, with 0 to
disable warnings.
.RE
.PP
\fBinitialSyncTransientErrorRetryPeriodSeconds\f1
.RS
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 86400
.PP
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.
.RE
.PP
\fBinitialSyncSourceReadPreference\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: String
.PP
The preferred source for performing \fBinitial sync\f1\&. Specify one of the following read
preference modes:
.RS
.IP \(bu 2
\fBprimary\f1\f1
.IP \(bu 2
\fBprimaryPreferred\f1\f1 (Default for voting replica set members)
.IP \(bu 2
\fBsecondary\f1\f1
.IP \(bu 2
\fBsecondaryPreferred\f1\f1
.IP \(bu 2
\fBnearest\f1\f1 (Default for newly added \fIor\f1 non\-voting replica set members)
.RE
.PP
If the replica set has disabled \fBchaining\f1\f1, the default
\fBinitialSyncSourceReadPreference\f1\f1 read preference mode
is \fBprimary\f1\f1\&.
.PP
You cannot specify a tag set or \fBmaxStalenessSeconds\f1 to
\fBinitialSyncSourceReadPreference\f1\f1\&.
.PP
If the \fBmongod\f1\f1 cannot find a sync source based on the
specified read preference, it logs an error and restarts the initial
sync process. The \fBmongod\f1\f1 exits with an error if it
cannot complete the initial sync process after \fB10\f1 attempts. For
more information on sync source selection, see
\fBInitial Sync Source Selection\f1\&.
.PP
\fBinitialSyncSourceReadPreference\f1\f1 takes precedence over
the replica set\(aqs \fBsettings.chainingAllowed\f1\f1 setting when
selecting an initial sync source. After a replica set member
successfully completes initial sync, it defers to the value of
\fBchainingAllowed\f1\f1 when selecting a replication sync
source.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1
configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RE
.PP
\fBinitialSyncMethod\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: String
.PP
\fIDefault\f1: \fBlogical\f1
.PP
Available only in MongoDB Enterprise.
.PP
Method used for \fBinitial sync\f1\&.
.PP
Set to \fBlogical\f1 to use \fBlogical initial sync\f1\&. Set to \fBfileCopyBased\f1 to
use \fBfile copy based initial sync\f1\&.
.PP
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.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RE
.PP
\fBmaxNumSyncSourceChangesPerHour\f1
.RS
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 3
.PP
\fBSync sources\f1
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
\fBmaxNumSyncSourceChangesPerHour\f1 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.
.PP
This parameter will not prevent a node from starting to sync from
another node if it doesn\(aqt 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.
.RE
.PP
\fBoplogFetcherUsesExhaust\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Enables or disables \fBstreaming replication\f1\&. Set the value to \fBtrue\f1 to enable
streaming replication.
.PP
Set the value to \fBfalse\f1 to disable streaming replication. If
disabled, secondaries fetch batches of \fBoplog\f1
entries by issuing a request to their \fIsync from\f1 source and waiting for a
response. This requires a network roundtrip for each batch of \fBoplog\f1 entries.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RE
.PP
\fBoplogInitialFindMaxSeconds\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 60
.PP
Maximum time in seconds for a member of a \fBreplica set\f1 to wait
for the \fBfind\f1\f1 command to finish during
\fBdata synchronization\f1\&.
.RE
.PP
\fBreplWriterThreadCount\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 16
.PP
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.
.PP
You can only set \fBreplWriterThreadCount\f1\f1 at startup and
cannot change this setting with the \fBsetParameter\f1\f1
command.
.PP
\fBreplWriterMinThreadCount\f1\f1
.RE
.PP
\fBreplWriterMinThreadCount\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 0
.PP
Minimum number of threads to use to apply replicated operations in
parallel. Values can range from 0 to 256 inclusive. You can only set
\fBreplWriterMinThreadCount\f1\f1 at startup and cannot change
this setting with the \fBsetParameter\f1\f1 command.
.PP
Parallel application of replication operations uses up to
\fBreplWriterThreadCount\f1\f1 threads. If
\fBreplWriterMinThreadCount\f1\f1 is configured with a value
less than \fBreplWriterThreadCount\f1\f1, the thread pool will
timeout idle threads until the total count of threads in the thread
pool is equal to \fBreplWriterMinThreadCount\f1\f1\&.
.PP
\fBreplWriterMinThreadCount\f1\f1 must be configured with a value
that is less than or equal to \fBreplWriterThreadCount\f1\f1\&.
.RE
.PP
\fBrollbackTimeLimitSecs\f1
.RS
.PP
\fIType\f1: 64\-bit integer
.PP
\fIDefault\f1: 86400  (1 day)
.PP
Maximum age of data that can be rolled back. Negative values for
this parameter are not valid.
.PP
If the time between the end
of the to\-be\-rolledback instance\(aqs 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.
.PP
To effectively have an unlimited rollback period, set the value to
\fB2147483647\f1 which is the maximum value allowed and equivalent to
roughly 68 years.
.RE
.PP
\fBwaitForSecondaryBeforeNoopWriteMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 10
.PP
The length of time (in milliseconds) that a secondary must wait if
the \fBafterClusterTime\f1 is greater than the last applied time from
the oplog. After the \fBwaitForSecondaryBeforeNoopWriteMS\f1 passes,
if the \fBafterClusterTime\f1 is still greater than the last applied
time, the secondary makes a no\-op write to advance the last applied
time.
.PP
The following example sets the
\fBwaitForSecondaryBeforeNoopWriteMS\f1\f1 to 20 milliseconds:
.PP
.EX
  mongod \-\-setParameter waitForSecondaryBeforeNoopWriteMS=20
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, waitForSecondaryBeforeNoopWriteMS: 20 } )
.EE
.RE
.PP
\fBcreateRollbackDataFiles\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
Flag that determines whether MongoDB creates \fBrollback files\f1 that contains documents affected during a
rollback.
.PP
By default, \fBcreateRollbackDataFiles\f1\f1 is \fBtrue\f1 and
MongoDB creates the rollback files.
.PP
The following example sets \fBcreateRollbackDataFiles\f1\f1
to false so that the rollback files are not created:
.PP
.EX
  mongod \-\-setParameter createRollbackDataFiles=false
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, createRollbackDataFiles: false } )
.EE
.PP
For more information, see \fBCollect Rollback Data\f1\&.
.RE
.PP
\fBreplBatchLimitBytes\f1
.RS
.PP
\fIDefault\f1: 104857600 (100MB)
.PP
Sets the maximum oplog application batch size in bytes.
.PP
Values can range from 16777216 (16MB) to 104857600 (100MB) inclusive.
.PP
The following example sets \fBreplBatchLimitBytes\f1\f1
to 64 MB so that the rollback files are not created:
.PP
.EX
  mongod \-\-setParameter replBatchLimitBytes=67108864
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, replBatchLimitBytes: 64 * 1024 * 1024 } )
.EE
.RE
.PP
\fBmirrorReads\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: Document
.PP
\fIDefault\f1: \fB{ samplingRate: 0.01, maxTimeMS: 1000 }\f1
.PP
Specifies the settings for \fBmirrored reads\f1
for the \fBmongod\f1\f1 instance. The settings only take
effect when the member is a primary.
.PP
The parameter \fBmirrorReads\f1\f1 takes a JSON document with
the following fields:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Field
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBsamplingRate\f1
.IP \(bu 4
The sampling rate used to mirror a subset of \fBoperations
that support mirroring\f1
to a subset of electable (specifically,  \fBpriority
greater than 0\f1\f1) secondaries. That is,
the primary mirrors reads to each electable secondary at the
specified sampling rate.
.IP
Valid values are:
.RS
.IP \(bu 6
.RS
.IP \(bu 8
\fB0.0\f1
.IP \(bu 8
Turns off mirroring.
.RE
.IP \(bu 6
.RS
.IP \(bu 8
\fB1.0\f1
.IP \(bu 8
The primary mirrors all \fBoperations that supports
mirroring\f1 to
each electable secondary.
.RE
.IP \(bu 6
.RS
.IP \(bu 8
Number between \fB0.0\f1 and \fB1.0\f1 (exclusive)
.IP \(bu 8
The primary randomly samples each electable secondary
at the specified rate to be sent mirrored reads.
.RE
.RE
.IP
For example, given a replica set with a primary and two
electable secondaries and a sampling rate of \fB0.10\f1, 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 \fB100\f1
operations that can be mirrored, the sampling rate of
\fB0.10\f1 may result in \fB8\f1 reads being mirrored to one
secondary and \fB13\f1 reads to the other or \fB10\f1 to each,
etc.
.IP
The default value is \fB0.01\f1\&.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBmaxTimeMS\f1
.IP \(bu 4
The maximum time in milliseconds for the mirrored reads. The
default value is \fB1000\f1\&.
.IP
The \fBmaxTimeMS\f1 for the mirrored reads is separate from the
\fBmaxTimeMS\f1 of the original read being mirrored.
.RE
.RE
.PP
You can set \fBmirrorReads\f1\f1 during startup in the
\fBconfiguration file\f1\f1 or with the
\fB\-\-setParameter\f1 option on the command line. If specifying from
the configuration file or on the command line, \fBenclose the\f1
\fBmirrorReads\f1 \fBdocument in quotes\f1\&.
.PP
For example, the following sets the mirror reads sampling rate to
\fB0.10\f1 from the command line:
.PP
.EX
  mongod \-\-setParameter mirrorReads=\(aq{ samplingRate: 0.10 }\(aq
.EE
.PP
Or, to specify in a configuration file:
.PP
.EX
  setParameter:
     mirrorReads: \(aq{samplingRate: 0.10}\(aq
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongod\f1\f1, do \fBnot\f1 enclose the document in quotes:
.PP
.EX
  db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )
.EE
.RE
.PP
\fBallowMultipleArbiters\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
Specifies whether the replica set allows the use of multiple arbiters.
.PP
The use of multiple arbiters is not recommended:
.RS
.IP \(bu 2
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\(aqs possible
for a majority write operation to return success before the write replicates
to a majority of data bearing nodes.
.IP \(bu 2
Multiple arbiters allow replica sets to accept writes even when the
replica set doesn\(aqt have sufficient secondaries for data replication.
.RE
.PP
For more information, see
\fBConcerns with Multiple Arbiters\f1\&.
.PP
The parameter can only be set during startup:
.PP
.EX
  mongod \-\-setParameter allowMultipleArbiters=true
.EE
.RE
.SS SHARDING PARAMETERS
.PP
Starting in version 4.2, MongoDB removes the parameter
\fBAsyncRequestsSenderUseBaton\f1 and always enables the performance
enhancement controlled by the parameter.
.PP
\fBautoMergerIntervalSecs\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 3600
.PP
When AutoMerger is enabled, specifies the amount of time
between automerging rounds, in seconds. The default value
is 3600 seconds, or one hour.
.PP
\fBautoMergerIntervalSecs\f1 can only be set on config servers.
.PP
This example sets \fBautoMergerIntervalSecs\f1 to 7200 milliseconds,
or two hours, at startup:
.PP
.EX
  mongod \-\-setParameter autoMergeInterval=7200
.EE
.PP
During run time, you can set or modify the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, autoMergeInterval: 7200 } )
.EE
.RE
.PP
\fBautoMergerThrottlingMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 15000
.PP
When AutoMerger is enabled, specifies the minimum amount
time between merges initiated by the AutoMerger on the same
collection, in milliseconds.
.PP
\fBautoMergerThrottlingMS\f1 can only be set on config servers.
.PP
This example sets \fBautoMergerThrottlingMS\f1 to 60000 milliseconds,
or one minute, at startup:
.PP
.EX
  mongod \-\-setParameter autoMergerThrottlingMS=60000
.EE
.PP
During run time, you can set or modify the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, autoMergerThrottlingMS: 60000 } )
.EE
.RE
.PP
\fBbalancerMigrationsThrottlingMs\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 1000
.PP
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.
.PP
This example sets \fBbalancerMigrationsThrottlingMs\f1 to 2000
milliseconds at startup:
.PP
.EX
  mongod \-\-setParameter balancerMigrationsThrottlingMs=2000
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, balancerMigrationsThrottlingMs: 2000 } )
.EE
.RE
.PP
\fBchunkDefragmentationThrottlingMS\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 0
.PP
Specifies the minimum time period (in milliseconds) between
consecutive split and merge commands run by the \fBbalancer\f1 when
the \fBchunks\f1 in a \fBsharded\f1 collection
are defragmented. \fBchunkDefragmentationThrottlingMS\f1\f1
limits the rate of split and merge commands.
.PP
The following example sets
\fBchunkDefragmentationThrottlingMS\f1\f1 to \fB10\f1 milliseconds:
.PP
.EX
  mongod \-\-setParameter chunkDefragmentationThrottlingMS=10
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )
.EE
.RE
.PP
\fBchunkMigrationConcurrency\f1
.RS
.PP
\fIAvailable starting in MongoDB 6.3 (and 5.0.15).\f1
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 1
.PP
Specifies an integer that sets the number of threads on the source
shard and the receiving shard for \fBchunk migration\f1\&.
.PP
Increasing the concurrency improves chunk migration performance, but
also increases the workload and disk IOPS usage on the source
shard and the receiving shard.
.PP
Maximum value is 500.
.PP
You should typically use half the total number of CPU cores as
threads. For example, if the total is 16 cores, set
\fBchunkMigrationConcurrency\f1 to 8 threads (or fewer).
.PP
If \fBchunkMigrationConcurrency\f1 is greater than \fB1\f1, the
\fB_secondaryThrottle\f1 configuration setting is ignored. The
\fB_secondaryThrottle\f1 setting determines when the chunk migration
proceeds with the next document in the chunk. For details, see
\fBRange Migration and Replication\f1\&.
.PP
The following example sets \fBchunkMigrationConcurrency\f1 to \fB5\f1:
.PP
.EX
  mongod \-\-setParameter chunkMigrationConcurrency=5
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, chunkMigrationConcurrency: 5 } )
.EE
.PP
To configure collection balancing, see
\fBconfigureCollectionBalancing\f1\f1\&.
.PP
To learn about defragmenting sharded collections, see
\fBDefragment Sharded Collections\f1\&.
.RE
.PP
\fBdisableResumableRangeDeleter\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
If set on a shard\(aqs primary, specifies if range deletion is paused on
the shard. If set to \fBtrue\f1, cleanup of \fBranges\f1
containing \fBorphaned documents\f1 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 \fBfalse\f1\&. This shard can continue to receive
chunks from other shards as long as it does not have a pending range
deletion task in the \fBconfig.rangeDeletions\f1\f1 collection that
overlaps with the incoming chunk\(aqs range.
.PP
When \fBdisableResumableRangeDeleter\f1\f1 is \fBtrue\f1, chunk
migrations fail if \fBorphaned documents\f1
exist on the recipient shard\(aqs primary in the same range as the
incoming chunks.
.PP
The parameter has no effect on the \fBmongod\f1\f1 if it is not
the shard\(aqs primary.
.PP
If you set \fBdisableResumableRangeDeleter\f1\f1 parameter to
\fBtrue\f1, ensure that you apply it consistently for all members in
the shard\(aqs replica set. In the event of a failover, this
setting\(aqs value on the new primary dictates the behavior of the
range deleter.
.PP
You can only set this parameter during start\-up and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
.EX
  mongod \-\-setParameter disableResumableRangeDeleter=false
.EE
.RE
.PP
\fBenableShardedIndexConsistencyCheck\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
If set on the config server\(aqs primary, enables or disables the index
consistency check for sharded collections. The parameter has no
effect on the \fBmongod\f1\f1 if it is not the config server\(aqs
primary.
.PP
The following example sets
\fBenableShardedIndexConsistencyCheck\f1\f1 to \fBfalse\f1 for a
config server primary:
.PP
.EX
  mongod \-\-setParameter enableShardedIndexConsistencyCheck=false
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, enableShardedIndexConsistencyCheck: false } )
.EE
.RS
.IP \(bu 2
\fBshardedIndexConsistencyCheckIntervalMS\f1\f1 parameter
.IP \(bu 2
\fBshardedIndexConsistency\f1\f1 metrics returned by the
\fBserverStatus\f1\f1 command.
.RE
.RE
.PP
\fBopportunisticSecondaryTargeting\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: \fBfalse\f1
.PP
Determines whether \fBmongos\f1 performs opportunistic reads against
replica sets.
.PP
When this parameter is set to \fBtrue\f1, \fBmongos\f1\f1 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
\fBfalse\f1, \fBmongos\f1\f1 holds secondary reads until it can establish
a connection to a specific secondary, (except in the case of
\fBhedged reads\f1).
.PP
Under certain workloads, opportunistic reads may trigger the
opening of unnecessary connections from \fBmongos\f1\f1 to
\fBmongod\f1\f1 and reduce overall performance.
This parameter should not be enabled unless your application has
a specific need for the feature.
.PP
For example, to set \fBopportunisticSecondaryTargeting\f1 during startup:
.PP
.EX
  mongos \-\-setParameter opportunisticSecondaryTargeting=true
.EE
.RE
.PP
\fBshardedIndexConsistencyCheckIntervalMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 600000
.PP
If set on the config server\(aqs primary, the interval, in
milliseconds, at which the config server\(aqs primary checks the index
consistency of sharded collections. The parameter has no effect on
the \fBmongod\f1\f1 if it is not the config server\(aqs primary.
.PP
You can only set the parameter during startup, and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
For example, the following sets the interval at 300000 milliseconds
(5 minutes) at startup:
.PP
.EX
  mongod \-\-setParameter shardedIndexConsistencyCheckIntervalMS=300000
.EE
.RS
.IP \(bu 2
\fBenableShardedIndexConsistencyCheck\f1\f1 parameter
.IP \(bu 2
\fBshardedIndexConsistency\f1\f1 metrics returned by the
\fBserverStatus\f1\f1 commandq
.RE
.RE
.PP
\fBenableFinerGrainedCatalogCacheRefresh\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
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 \fBrouters\f1 who
contact the shard to refresh their shard catalog cache.
.PP
You can only set this parameter during start\-up and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
.EX
  mongod \-\-setParameter enableFinerGrainedCatalogCacheRefresh=true
  mongos \-\-setParameter enableFinerGrainedCatalogCacheRefresh=true
.EE
.RS
.IP \(bu 2
\fBSharding\f1
.IP \(bu 2
\fBshardingStatistics.catalogCache\f1\f1
.RE
.RE
.PP
\fBmaxTimeMSForHedgedReads\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 150
.PP
Specifies the maximum time limit (in milliseconds) for the
\fBhedged read\f1\&. That is, the additional
read sent to hedge the read operation uses the \fBmaxTimeMS\f1 value
of \fBmaxTimeMSForHedgedReads\f1\f1 while the read operation
that is being hedged uses the \fBmaxTimeMS\f1 value specified for the
operation.
.PP
For example, to set the limit to 200 milliseconds, you can issue the
following during startup:
.PP
.EX
  mongos \-\-setParameter maxTimeMSForHedgedReads=200
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, maxTimeMSForHedgedReads: 200 } )
.EE
.RS
.IP \(bu 2
\fBreadHedgingMode\f1\f1
.IP \(bu 2
\fBHedged Reads\f1
.RE
.RE
.PP
\fBmaxCatchUpPercentageBeforeBlockingWrites\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 10
.PP
For \fBmoveChunk\f1\f1 and \fBmoveRange\f1\f1 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 \fBcatchup\f1 phase to the \fBcommit\f1 phase.
.PP
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 \fBupsert\f1\f1
and \fBdelete\f1\f1 operations.
.PP
For example, to set the maximum percentage to 20, you can issue the
following during startup:
.PP
.EX
  mongod \-\-setParameter maxCatchUpPercentageBeforeBlockingWrites=20
.EE
.PP
You cannot change
\fBmaxCatchUpPercentageBeforeBlockingWrites\f1\f1 during run time.
.PP
Live Migration Protocol (https://github.com/mongodb/mongo/blob/master/src/mongo/db/s/README.md#the\-live\-migration\-protocol)
.RE
.PP
\fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 500
.PP
Limits the time a shard waits for a critical section within a
transaction.
.PP
When a query accesses a shard, a \fBchunk migration\f1 or \fBDDL operation\f1 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 \fBmongos\f1\f1,
\fBmongos\f1\f1 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.
.PP
\fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1\f1
limits the maximum time a shard waits within a transaction for the
critical section to be released.
.PP
To reduce the maximum wait time for the critical section within a
transaction, lower the value of
\fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1\f1\&.
.PP
If \fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1\f1
is too low, \fBmongos\f1\f1 could use all of its retry attempts
and return an error.
.PP
You can set
\fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1\f1 at
startup and during run time.
.PP
For example, to set \fBmetadataRefreshInTransactionMaxWaitBehindCritSecMS\f1\f1
to 400 milliseconds:
.PP
.EX
  db.adminCommand( { setParameter: 1, metadataRefreshInTransactionMaxWaitBehindCritSecMS: 400 } )
.EE
.RE
.PP
\fBreadHedgingMode\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: string
.PP
\fIDefault\f1: on
.PP
Specifies whether \fBmongos\f1\f1 supports hedged reads for
those read operations whose \fBread preference\f1 have enabled the hedged read option.
.PP
Available values are:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Value
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBon\f1
.IP \(bu 4
The \fBmongos\f1\f1 instance supports hedged reads for
read operations whose \fBread preference\f1 have enabled the hedged read option.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBoff\f1
.IP \(bu 4
The \fBmongos\f1\f1 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.
.RE
.RE
.PP
For example, to turn off hedged read support for a
\fBmongos\f1\f1 instance, you can issue the following during
startup:
.PP
.EX
  mongos \-\-setParameter readHedgingMode=off
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, readHedgingMode: "off" } )
.EE
.RS
.IP \(bu 2
\fBHedged Reads\f1
.IP \(bu 2
\fBmaxTimeMSForHedgedReads\f1\f1
.RE
.RE
.PP
\fBshutdownTimeoutMillisForSignaledShutdown\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 15000
.PP
Specifies the time (in milliseconds) to wait for any ongoing database
operations to complete before initiating a shutdown of
\fBmongod\f1\f1 in response to a \fBSIGTERM\f1 signal.
.PP
For example, to set the time to 250 milliseconds, you can issue the
following during startup:
.PP
.EX
  mongod \-\-setParameter shutdownTimeoutMillisForSignaledShutdown=250
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongod\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, shutdownTimeoutMillisForSignaledShutdown: 250 } )
.EE
.RE
.PP
\fBmongosShutdownTimeoutMillisForSignaledShutdown\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 15000
.PP
Specifies the time (in milliseconds) to wait for any ongoing database
operations to complete before initiating a shutdown of
\fBmongos\f1\f1 in response to a \fBSIGTERM\f1 signal.
.PP
For example, to set the time to 250 milliseconds, you can issue the
following during startup:
.PP
.EX
  mongos \-\-setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, mongosShutdownTimeoutMillisForSignaledShutdown: 250 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolHostTimeoutMS\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 300000 (5 minutes)
.PP
Maximum time that \fBmongos\f1\f1 goes without communication to a
host before \fBmongos\f1\f1 drops all connections to the host.
.PP
If set, \fBShardingTaskExecutorPoolHostTimeoutMS\f1\f1 should be
greater than the sum of
\fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1 and
\fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1\&. Otherwise,
\fBmongos\f1\f1 adjusts the value of
\fBShardingTaskExecutorPoolHostTimeoutMS\f1\f1 to be greater than the
sum.
.PP
The following example sets
\fBShardingTaskExecutorPoolHostTimeoutMS\f1\f1 to \fB120000\f1
during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolHostTimeoutMS: 120000 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolMaxConnecting\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 2
.PP
Maximum number of simultaneous initiating connections (including
pending connections in setup/refresh state) each TaskExecutor
connection pool can have to a \fBmongod\f1\f1 instance. You can
set this parameter to control the rate at which \fBmongos\f1\f1
adds connections to a \fBmongod\f1\f1 instance.
.PP
If set, \fBShardingTaskExecutorPoolMaxConnecting\f1\f1 should be
less than or equal to \fBShardingTaskExecutorPoolMaxSize\f1\f1\&.
If it is greater, \fBmongos\f1\f1 ignores the
\fBShardingTaskExecutorPoolMaxConnecting\f1\f1 value.
.PP
The following example sets
\fBShardingTaskExecutorPoolMaxConnecting\f1\f1 to \fB20\f1
during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolMaxConnecting=20
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMaxConnecting: 20 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolMaxSize\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 2 64 \- 1
.PP
Maximum number of outbound connections each TaskExecutor connection
pool can open to any given \fBmongod\f1\f1 instance. The maximum
possible connections to any given host across all TaskExecutor pools
is:
.PP
.EX
  ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize
.EE
.PP
The following example sets
\fBShardingTaskExecutorPoolMaxSize\f1\f1 to \fB20\f1
during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolMaxSize=20
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMaxSize: 20 } )
.EE
.PP
\fBmongos\f1\f1 can have up to \fBn\f1 TaskExecutor connection
pools, where \fBn\f1 is the number of cores. See
\fBtaskExecutorPoolSize\f1\f1\&.
.PP
\fBShardingTaskExecutorPoolMinSize\f1\f1
.RE
.PP
\fBShardingTaskExecutorPoolMaxSizeForConfigServers\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: \-1
.PP
Optional override for \fBShardingTaskExecutorPoolMaxSize\f1\f1 to set the maximum number
of outbound connections each TaskExecutor connection pool can open to a
\fBconfiguration server\f1\&.
.PP
When set to:
.RS
.IP \(bu 2
\fB\-1\f1, \fBShardingTaskExecutorPoolMaxSize\f1\f1 is used. This is the default.
.IP \(bu 2
an integer value greater than \fB\-1\f1, overrides the
maximum number of outbound connections each TaskExecutor
connection pool can open to a configuration server.
.RE
.PP
Parameter only applies to sharded deployments.
.PP
The following example sets \fBShardingTaskExecutorPoolMaxSize\f1\f1 to \fB2\f1 during startup, which
sets the maximum number of outbound connections each
TaskExecutor connection pool can open to a configuration server to
\fB2\f1:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolMaxSizeForConfigServers=2
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMaxSizeForConfigServers: 2 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolMinSize\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 1
.PP
Minimum number of outbound connections each TaskExecutor connection
pool can open to any given \fBmongod\f1\f1 instance.
.PP
\fBShardingTaskExecutorPoolMinSize\f1 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 \fBShardingTaskExecutorPoolHostTimeoutMS\f1\f1
milliseconds pass without any application using that pool.
.PP
For a \fBmongos\f1\f1 using the
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1
parameter, the \fBShardingTaskExecutorPoolMinSize\f1 parameter also
controls how many connections to each shard host are established on
startup of the \fBmongos\f1\f1 instance before it begins
accepting incoming client connections.
.PP
In MongoDB 4.4, the
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1
parameter is enabled by default for the \fBmongos\f1\f1\&.
.PP
The following example sets
\fBShardingTaskExecutorPoolMinSize\f1\f1 to \fB2\f1
during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolMinSize=2
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMinSize: 2 } )
.EE
.PP
\fBmongos\f1\f1 can have up to \fBn\f1 TaskExecutor connection
pools, where \fBn\f1 is the number of cores. See
\fBtaskExecutorPoolSize\f1\f1\&.
.RS
.IP \(bu 2
\fBShardingTaskExecutorPoolMaxSize\f1\f1
.IP \(bu 2
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1
.RE
.RE
.PP
\fBShardingTaskExecutorPoolMinSizeForConfigServers\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: \-1
.PP
Optional override for \fBShardingTaskExecutorPoolMinSize\f1\f1 to set the minimum number
of outbound connections each TaskExecutor connection pool can open to a
\fBconfiguration server\f1\&.
.PP
When set to:
.RS
.IP \(bu 2
\fB\-1\f1, \fBShardingTaskExecutorPoolMinSize\f1\f1 is used. This is the default.
.IP \(bu 2
an integer value greater than \fB\-1\f1, overrides the
minimum number of outbound connections each TaskExecutor
connection pool can open to a configuration server.
.RE
.PP
Parameter only applies to sharded deployments.
.PP
The following example sets \fBShardingTaskExecutorPoolMinSize\f1\f1 to \fB2\f1 during startup, which
sets the minimum number of outbound connections each
TaskExecutor connection pool can open to a configuration server to
\fB2\f1:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolMinSizeForConfigServers=2
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolMinSizeForConfigServers: 2 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolRefreshRequirementMS\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 60000 (1 minute)
.PP
Maximum time the \fBmongos\f1\f1 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
\fBminimum size\f1\&.
.PP
If set, \fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1 should be
greater than \fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1\&.
Otherwise, \fBmongos\f1\f1 adjusts the value of
\fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1 to be less than
\fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1\&.
.PP
The following example sets
\fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1 to
\fB90000\f1 during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshRequirementMS: 90000 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolRefreshTimeoutMS\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: integer
.PP
Default: 20000 (20 seconds)
.PP
Maximum time the \fBmongos\f1\f1 waits for a heartbeat before
timing out the heartbeat.
.PP
If set, \fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1 should be
less than \fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1\&.
Otherwise, \fBmongos\f1\f1 adjusts the value of
\fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1 to be less than
\fBShardingTaskExecutorPoolRefreshRequirementMS\f1\f1\&.
.PP
The following example sets
\fBShardingTaskExecutorPoolRefreshTimeoutMS\f1\f1 to
\fB30000\f1 during startup:
.PP
.EX
  mongos \-\-setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshTimeoutMS: 30000 } )
.EE
.RE
.PP
\fBShardingTaskExecutorPoolReplicaSetMatching\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: string
.PP
Default: "automatic"
.PP
On a \fBmongos\f1\f1 instance, this parameter sets the policy
that determines the minimum size limit of its connection pools to
nodes within replica sets.
.PP
On a \fBmongod\f1\f1 instance, this parameter sets the policy
that determines the minimum size limit of its connection pools to
nodes within \fIother\f1 replica sets.
.PP
Note that this parameter only manages connections for operations that
are directly related to user requests and CRUD operations.
.PP
Available values are:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Matching Policy
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fB"automatic"\f1 (Default)
.IP \(bu 4
Starting in 5.0 (and 4.4.5 and 4.2.13), \fB"automatic"\f1 is the
new default value.
.IP
When set for a \fBmongos\f1\f1, the instance follows the
behavior specified for the \fB"matchPrimaryNode"\f1 option.
.IP
When set for a \fBmongod\f1\f1, the instance follows the
behavior specified for the \fB"disabled"\f1 option.
.IP
If the
\fBShardingTaskExecutorPoolReplicaSetMatching\f1\f1 is
set to \fB"automatic"\f1, the
\fBreplicaSetMatchingStrategy\f1\f1 still
describes the actual policy being used, not
\fB"automatic"\f1\&. To find the value of the
\fBShardingTaskExecutorPoolReplicaSetMatching\f1\f1,
use \fBgetParameter\f1\f1 which returns the value of
the server parameter.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fB"matchPrimaryNode"\f1
.IP \(bu 4
When set for a \fBmongos\f1\f1, the minimum size limit
of the instance\(aqs 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\(aqs primary.
.IP
When set for a \fBmongod\f1\f1, the minimum size limit
of the instance\(aqs 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\(aqs primary.
.IP
If multiple shard servers in your topology can experience a
rapid influx of cross\-shard operations, do not set this
option on your \fBmongod\f1\f1 instances.
.IP
In case of a primary stepdown, \fBmatchPrimaryNode\f1 ensures
that any secondary that becomes the primary can handle the
current level of primary reads and writes.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fB"matchBusiestNode"\f1
.IP \(bu 4
When set for a \fBmongos\f1\f1, the instance\(aqs 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.
.IP
When set for a \fBmongod\f1\f1, the instance\(aqs 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.
.IP
With \fB"matchBusiestNode"\f1, \fBmongos\f1\f1 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.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fB"disabled"\f1
.IP \(bu 4
When set for a \fBmongos\f1\f1, the instance\(aqs minimum
number of connections in the instance\(aqs connection pool to
each node of a replica set in the sharded clusterv
(specifically, shard replica set and config servers) is equal
to the \fBShardingTaskExecutorPoolMinSize\f1\f1\&.
.IP
When set for a \fBmongod\f1\f1, the instance\(aqs minimum
number of connections in the instance\(aqs connection pool to
each node of another replica set in the sharded cluster
(specifically, shard replica set and config servers) is equal
to the \fBShardingTaskExecutorPoolMinSize\f1\f1\&.
.RE
.RE
.PP
The following example sets the
\fBShardingTaskExecutorPoolReplicaSetMatching\f1\f1 to
\fB"automatic"\f1 during startup:
.PP
.EX
  mongod \-\-setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1,  ShardingTaskExecutorPoolReplicaSetMatching: "automatic" } )
.EE
.RE
.PP
\fBtaskExecutorPoolSize\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
Type: integer
.PP
Default: 1
.PP
The number of Task Executor connection pools to use for a given
\fBmongos\f1\f1\&.
.PP
If the parameter value is \fB0\f1 or less, the number of Task Executor
connection pools is the number of cores with the following
exceptions:
.RS
.IP \(bu 2
If the number of cores is less than 4, the number of Task Executor
connection pools is 4.
.IP \(bu 2
If the number of cores is greater than 64, the number of Task
Executor connection pools is 64.
.RE
.PP
When running MongoDB 6.2 or newer on Linux, you cannot modify the
\fBtaskExecutorPoolSize\f1\f1 from the default value of \fB1\f1\&.
You may modify this parameter when running MongoDB on Windows or macOS.
.PP
The default value of \fBtaskExecutorPoolSize\f1\f1 is \fB1\f1:
In MongoDB 4.2+ deployments, MongoDB removes the
\fBAsyncRequestsSenderUseBaton\f1 parameter and always enables the
performance enhancement controlled by the parameter.
.PP
You can only set this parameter during start\-up and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
.EX
  mongos \-\-setParameter taskExecutorPoolSize=6
.EE
.RS
.IP \(bu 2
\fBShardingTaskExecutorPoolMaxSize\f1\f1
.IP \(bu 2
\fBShardingTaskExecutorPoolMinSize\f1\f1
.RE
.RE
.PP
\fBloadRoutingTableOnStartup\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
Type: boolean
.PP
\fIDefault\f1: true
.PP
Configures a \fBmongos\f1\f1 instance to preload the routing
table for a sharded cluster on startup. With this setting
enabled, the \fBmongos\f1\f1 caches the cluster\-wide routing
table for each sharded collection as part of its startup procedure,
before it begins accepting client connections.
.PP
Without this setting enabled, the \fBmongos\f1\f1 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.
.PP
A \fBmongos\f1\f1 instance with the
\fBloadRoutingTableOnStartup\f1\f1 parameter enabled may
experience longer startup times, but will result in faster servicing
of initial client connections once started.
.PP
\fBloadRoutingTableOnStartup\f1\f1 is enabled by default.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RE
.PP
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
Type: boolean
.PP
\fIDefault\f1: true
.PP
Configures a \fBmongos\f1\f1 instance to prewarm its connection
pool on startup. With this parameter enabled, the
\fBmongos\f1\f1 attempts to establish
\fBShardingTaskExecutorPoolMinSize\f1\f1 network
connections to each shard server as part of its startup procedure,
before it begins accepting client connections.
.PP
A timeout for this behavior can be configured with the
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS\f1\f1
parameter. If this timeout is reached, the \fBmongos\f1\f1 will
begin accepting client connections regardless of the size of its
connection pool.
.PP
A \fBmongos\f1\f1 instance with this parameter enabled may
experience longer startup times, but will result in faster servicing
of initial client connections once started.
.PP
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1 is
enabled by default.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RS
.IP \(bu 2
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS\f1\f1
.IP \(bu 2
\fBShardingTaskExecutorPoolMinSize\f1\f1
.RE
.RE
.PP
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
Type: integer
.PP
\fIDefault\f1: 2000 (2 seconds)
.PP
Sets the timeout threshold in milliseconds for a
\fBmongos\f1\f1 to wait for \fBShardingTaskExecutorPoolMinSize\f1\f1
connections to be established per shard host when using the
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1
parameter. If this timeout is reached, the \fBmongos\f1\f1 will
begin accepting client connections regardless of the size of its
connection pool.
.PP
You can only set this parameter on startup, using either the
\fBsetParameter\f1\f1 configuration file setting or the
\fB\-\-setParameter\f1\f1 command line option.
.RS
.IP \(bu 2
\fBwarmMinConnectionsInShardingTaskExecutorPoolOnStartup\f1\f1
.IP \(bu 2
\fBShardingTaskExecutorPoolMinSize\f1\f1
.RE
.RE
.PP
\fBmigrateCloneInsertionBatchDelayMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Type: Non\-negative integer
.PP
Default: 0
.PP
Time in milliseconds to wait between batches of insertions during
cloning step of the migration process. This wait is in addition to
the \fBsecondaryThrottle\f1\&.
.PP
The default value of \fB0\f1 indicates no additional wait.
.PP
The following sets the \fBmigrateCloneInsertionBatchDelayMS\f1\f1 to 200
milliseconds:
.PP
.EX
  mongod \-\-setParameter migrateCloneInsertionBatchDelayMS=200
.EE
.PP
The parameter may also be set using the \fBsetParameter\f1\f1
command:
.PP
.EX
  db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchDelayMS: 200 } )
.EE
.RE
.PP
\fBmigrateCloneInsertionBatchSize\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Type: Non\-negative integer
.PP
Default: 0
.PP
The maximum number of documents to insert in a single batch during
the cloning step of the migration process.
.PP
The default value of \fB0\f1 indicates no maximum number of documents
per batch. However, in practice, this results in batches that
contain up to 16 MB of documents.
.PP
The following sets the \fBmigrateCloneInsertionBatchSize\f1\f1 to 100
documents:
.PP
.EX
  mongod \-\-setParameter migrateCloneInsertionBatchSize=100
.EE
.PP
The parameter may also be set using the \fBsetParameter\f1\f1
command:
.PP
.EX
  db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchSize: 100 } )
.EE
.RE
.PP
\fBorphanCleanupDelaySecs\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Default: 900 (15 minutes)
.PP
Minimum delay before a migrated \fBchunk\f1 is deleted from the source
shard.
.PP
Before deleting the chunk during chunk migration, MongoDB waits for
\fBorphanCleanupDelaySecs\f1\f1 or for in\-progress queries
involving the chunk to complete on the shard primary, whichever is
longer.
.PP
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
\fBorphanCleanupDelaySecs\f1\f1\&.
.PP
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.
.PP
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.
.PP
The following sets the \fBorphanCleanupDelaySecs\f1\f1 to 20 minutes:
.PP
.EX
  mongod \-\-setParameter orphanCleanupDelaySecs=1200
.EE
.PP
This may also be set using the \fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, orphanCleanupDelaySecs: 1200 } )
.EE
.RE
.PP
\fBrangeDeleterBatchDelayMS\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Type: Non\-negative integer
.PP
Default: 20
.PP
The amount of time in milliseconds to wait before the next batch of
deletion during the cleanup stage of \fBrange migration\f1 (or the \fBcleanupOrphaned\f1\f1
command).
.PP
The \fB_secondaryThrottle replication delay\f1 occurs after each batch deletion.
.PP
The following sets the \fBrangeDeleterBatchDelayMS\f1\f1 to 200
milliseconds:
.PP
.EX
  mongod \-\-setParameter rangeDeleterBatchDelayMS=200
.EE
.PP
The parameter may also be set using the \fBsetParameter\f1\f1
command:
.PP
.EX
  db.adminCommand( { setParameter: 1, rangeDeleterBatchDelayMS: 200 } )
.EE
.RE
.PP
\fBrangeDeleterBatchSize\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Type: Non\-negative integer
.PP
Default: 2147483647 starting in MongoDB 5.1.2, 5.0.6, and 4.4.12 (128
in earlier MongoDB versions)
.PP
The maximum number of documents in each batch to delete during the
cleanup stage of \fBrange migration\f1
(or the \fBcleanupOrphaned\f1\f1 command).
.PP
A value of \fB0\f1 indicates that the system chooses the default value.
.PP
The following example sets \fBrangeDeleterBatchSize\f1\f1 to 32
documents:
.PP
.EX
  mongod \-\-setParameter rangeDeleterBatchSize=32
.EE
.PP
The parameter may also be set using the \fBsetParameter\f1\f1
command:
.PP
.EX
  db.adminCommand( { setParameter: 1, rangeDeleterBatchSize: 32 } )
.EE
.RE
.PP
\fBskipShardingConfigurationChecks\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Type: boolean
.PP
Default: false
.PP
When \fBtrue\f1, allows for starting a shard member or config server
member as a standalone for maintenance operations. This parameter is
mutually exclusive with the \fB\-\-configsvr\f1\f1 or \fB\-\-shardsvr\f1\f1 options.
.PP
You can only set this parameter during start\-up and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
.EX
  mongod \-\-setParameter skipShardingConfigurationChecks=true
.EE
.PP
Once maintenance has completed, remove the
\fBskipShardingConfigurationChecks\f1\f1 parameter when
restarting the \fBmongod\f1\f1\&.
.RE
.PP
\fBfindChunksOnConfigTimeoutMS\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
Type: Non\-negative integer
.PP
Default: 900000
.PP
The timeout in milliseconds for find operations on
\fBchunks\f1\f1\&.
.PP
If there is a large number of chunks in the cluster and chunk loading
fails with the error \fBExceededTimeLimit\f1, increase the parameter
value:
.PP
.EX
  mongod \-\-setParameter findChunksOnConfigTimeoutMS=1000000
.EE
.RE
.SS HEALTH MANAGER PARAMETERS
.PP
\fBactiveFaultDurationSecs\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: Document
.PP
The amount of time to wait from a \fBHealth Managers Overview\f1 failure until the
\fBmongos\f1 is removed from the cluster, in seconds.
.PP
When a failure is detected and a Health Manager is configured as
\fBcritical\f1, the server waits for the specified interval
before removing the \fBmongos\f1 from the cluster.
.PP
For example, to set the duration from failure to crash to five
minutes, issue the following at startup:
.PP
.EX
  mongos \-\-setParameter activeFaultDurationSecs=300
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand(
    {
        setParameter: 1,
        activeFaultDurationSecs: 300
    }
  )
.EE
.PP
Parameters set with \fBsetParameter\f1\f1 do not persist across
restarts. See the \fBsetParameter page\f1 for details.
.PP
To make this setting persistent, set \fBactiveFaultDurationSecs\f1
in your \fBmongos config file\f1 using the
\fBsetParameter\f1\f1 option as in the following example:
.PP
.EX
  setParameter:
     activeFaultDurationSecs: 300
.EE
.RE
.PP
\fBhealthMonitoringIntensities\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: Array of documents
.PP
Use this parameter to set intensity levels for Health Managers\&.
.PP
\fBhealthMonitoringIntensities\f1 accepts an array of documents,
\fBvalues\f1\&. Each document in \fBvalues\f1 takes two fields:
.RS
.IP \(bu 2
\fBtype\f1, the Health Manager facet
.IP \(bu 2
\fBintensity\f1, the intensity level
.RE
.SS HEALTH MANAGERS
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Facet
.IP \(bu 4
What the Health Observer Checks
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBconfigServer\f1
.IP \(bu 4
Cluster health issues related to connectivity to the config server.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBdns\f1
.IP \(bu 4
Cluster health issues related to DNS availability and functionality.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBldap\f1
.IP \(bu 4
Cluster health issues related to LDAP availability and functionality.
.RE
.RE
.SS INTENSITY LEVELS
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Intensity Level
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBcritical\f1
.IP \(bu 4
The Health Manager on this facet is enabled and has the ability to move the
failing \fBmongos\f1 out of the cluster if an error
occurs. The Health Manager waits the amount of time specified by
\fBactiveFaultDurationSecs\f1\f1 before stopping and moving
the \fBmongos\f1 out of the cluster automatically.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBnon\-critical\f1
.IP \(bu 4
The Health Manager on this facet is enabled and logs
errors, but the \fBmongos\f1 remains in the cluster if
errors are encountered.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBoff\f1
.IP \(bu 4
The Health Manager on this facet is disabled. The \fBmongos\f1 does not perform any health checks on this facet. This
is the default intensity level.
.RE
.RE
.PP
For example, to set the \fBdns\f1 Health Manager facet to the
\fBcritical\f1 intensity level, issue the following at startup:
.PP
.EX
  mongos \-\-setParameter \(aqhealthMonitoringIntensities={ values:[ { type:"dns", intensity: "critical"} ] }\(aq
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand(
    {
        setParameter: 1,
        healthMonitoringIntensities: { values: [ { type: "dns", intensity: "critical" } ] } } )
    }
  )
.EE
.PP
Parameters set with \fBsetParameter\f1\f1 do not persist across
restarts. See the \fBsetParameter page\f1 for details.
.PP
To make this setting persistent, set \fBhealthMonitoringIntensities\f1
in your \fBmongos config file\f1 using the
\fBsetParameter\f1\f1 option as in the following example:
.PP
.EX
  setParameter:
     healthMonitoringIntensities: "{ values:[ { type:\"dns\", intensity: \"critical\"} ] }"
.EE
.RE
.PP
\fBhealthMonitoringIntervals\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: Array of documents
.PP
How often this Health Manager will run, in milliseconds.
.PP
\fBhealthMonitoringIntervals\f1 accepts an array of documents,
\fBvalues\f1\&. Each document in \fBvalues\f1 takes two fields:
.RS
.IP \(bu 2
\fBtype\f1, the Health Manager facet
.IP \(bu 2
\fBinterval\f1, the time interval it runs at, in milliseconds
.RE
.SS HEALTH MANAGERS
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Facet
.IP \(bu 4
What the Health Observer Checks
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBconfigServer\f1
.IP \(bu 4
Cluster health issues related to connectivity to the config server.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBdns\f1
.IP \(bu 4
Cluster health issues related to DNS availability and functionality.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBldap\f1
.IP \(bu 4
Cluster health issues related to LDAP availability and functionality.
.RE
.RE
.PP
For example, to set the \fBldap\f1 Health Manager facet to the
run health checks every 30 seconds, issue the following at startup:
.PP
.EX
  mongos \-\-setParameter \(aqhealthMonitoringIntervals={ values:[ { type:"ldap", interval: "30000"} ] }\(aq
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand(
    {
        setParameter: 1,
        healthMonitoringIntervals: { values: [ { type: "ldap", interval: "30000" } ] } } )
    }
  )
.EE
.PP
Parameters set with \fBsetParameter\f1\f1 do not persist across
restarts. See the \fBsetParameter page\f1 for details.
.PP
To make this setting persistent, set \fBhealthMonitoringIntervals\f1
in your \fBmongos config file\f1 using the
\fBsetParameter\f1\f1 option as in the following example:
.PP
.EX
  setParameter:
     healthMonitoringIntervals: "{ values: [{type: \"ldap\", interval: 200}] }"
.EE
.RE
.PP
\fBprogressMonitor\f1
.RS
.PP
Available for \fBmongos\f1\f1 only.
.PP
\fIType\f1: Document
.PP
\fBProgress Monitor\f1 runs tests
to ensure that Health Manager checks do not become stuck or
unresponsive. Progress Monitor runs these tests in intervals specified
by \fBinterval\f1\&. If a health check begins but does not complete within
the timeout given by \fBdeadline\f1, Progress Monitor stops the
\fBmongos\f1 and removes it from the cluster.
.SS PROGRESSMONITOR FIELDS
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Field
.IP \(bu 4
Description
.IP \(bu 4
Units
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBinterval\f1
.IP \(bu 4
How often to ensure Health Managers are not stuck or unresponsive.
.IP \(bu 4
Milliseconds
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBdeadline\f1
.IP \(bu 4
Timeout before automatically failing the \fBmongos\f1
if a Health Manager check is not making progress.
.IP \(bu 4
Seconds
.RE
.RE
.PP
To set the \fBinterval\f1 to 1000 milliseconds and the \fBdeadline\f1
to 300 seconds, issue the following at startup:
.PP
.EX
  mongos \-\-setParameter \(aqprogressMonitor={"interval": 1000, "deadline": 300}\(aq
.EE
.PP
Or if using the \fBsetParameter\f1\f1 command in a
\fBmongosh\f1\f1 session that is connected to a running
\fBmongos\f1\f1:
.PP
.EX
  db.adminCommand(
    {
        setParameter: 1,
        progressMonitor: { interval: 1000, deadline: 300 } )
    }
  )
.EE
.PP
Parameters set with \fBsetParameter\f1\f1 do not persist across
restarts. See the \fBsetParameter page\f1 for details.
.PP
To make this setting persistent, set \fBprogressMonitor\f1
in your \fBmongos config file\f1 using the
\fBsetParameter\f1\f1 option as in the following example:
.PP
.EX
  setParameter:
     progressMonitor: "{ interval: 1000, deadline: 300 }"
.EE
.RE
.SS STORAGE PARAMETERS
.PP
\fBhonorSystemUmask\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: \fBfalse\f1
.PP
If \fBhonorSystemUmask\f1\f1 is set to \fBtrue\f1, new files
created by MongoDB have permissions in accordance with the
user\(aqs \fBumask\f1 settings. You cannot set \fBprocessUmask\f1\f1
if \fBhonorSystemUmask\f1\f1 is set to \fBtrue\f1\&.
.PP
If \fBhonorSystemUmask\f1\f1 is set to \fBfalse\f1, new files
created by MongoDB have permissions set to \fB600\f1, which gives
read and write permissions only to the owner. New directories have
permissions set to \fB700\f1\&. You can use \fBprocessUmask\f1\f1
to override the default permissions for groups and other users on
all new files created by MongoDB.
.PP
You can only set this parameter during start\-up and cannot change
this setting using the \fBsetParameter\f1\f1 database command.
.PP
.EX
  mongod \-\-setParameter honorSystemUmask=true
.EE
.PP
\fBhonorSystemUmask\f1\f1 is not available on Windows systems.
.RE
.PP
\fBjournalCommitInterval\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specify an integer between \fB1\f1 and \fB500\f1 signifying the number
of milliseconds (ms) between journal commits.
.PP
Consider the following example which sets the
\fBjournalCommitInterval\f1\f1 to \fB200\f1 ms:
.PP
.EX
  db.adminCommand( { setParameter: 1, journalCommitInterval: 200 } )
.EE
.PP
\fBstorage.journal.commitIntervalMs\f1\f1
.RE
.PP
\fBminSnapshotHistoryWindowInSeconds\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: \fB300\f1
.PP
The minimum time window in seconds for which the storage engine keeps
the snapshot history. If you query data using read concern
\fB"snapshot"\f1\f1 and specify an
\fBatClusterTime\f1 value older than the specified
\fBminSnapshotHistoryWindowInSeconds\f1, \fBmongod\f1\f1 returns
a \fBSnapshotTooOld\f1 error.
.PP
Specify an integer greater than or equal to (\fB>=\f1) 0.
.PP
Consider the following example which sets the
\fBminSnapshotHistoryWindowInSeconds\f1 to \fB600\f1 seconds:
.PP
.EX
  db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 600 } )
.EE
.PP
Increasing the value of
\fBminSnapshotHistoryWindowInSeconds\f1\f1 increases disk
usage. For more information, see \fBSnapshot History Retention\f1\&.
.PP
To modify this value for a MongoDB Atlas (https://www.mongodb.com/docs/atlas/) cluster, you
must contact Atlas Support (https://www.mongodb.com/docs/atlas/support/)\&.
.RE
.PP
\fBprocessUmask\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Overrides the default permissions used for groups and other users
when \fBhonorSystemUmask\f1\f1 is set to \fBfalse\f1\&. By default,
when \fBhonorSystemUmask\f1\f1 is set to \fBfalse\f1, new files
created by MongoDB have permissions set to \fB600\f1\&. Use the
\fBprocessUmask\f1 parameter to override this default with a custom
\fBumask\f1 value. The file owner inherits permissions from the system
\fBumask\f1\&.
.PP
You cannot set this parameter if \fBhonorSystemUmask\f1\f1 is set
to \fBtrue\f1\&. You can only set this parameter during start\-up and cannot
change this setting using the \fBsetParameter\f1\f1 database
command.
.PP
Consider the following example, which sets the permissions for groups
and other users to read/write only and retains the system \fBumask\f1
settings for the owner:
.PP
.EX
  mongod \-\-setParameter processUmask=011
.EE
.PP
\fBprocessUmask\f1\f1 is not available on Windows systems.
.RE
.PP
\fBsyncdelay\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specify the interval in seconds between \fBfsync\f1 operations
where \fBmongod\f1\f1 flushes its working memory to disk. By
default, \fBmongod\f1\f1 flushes memory to disk every 60
seconds. In almost every situation you should not set this value
and use the default setting.
.PP
Consider the following example which sets the \fBsyncdelay\f1 to
\fB60\f1 seconds:
.PP
.EX
  db.adminCommand( { setParameter: 1, syncdelay: 60 } )
.EE
.RS
.IP \(bu 2
\fBjournalCommitInterval\f1\f1
.IP \(bu 2
\fBstorage.syncPeriodSecs\f1\f1
.RE
.RE
.PP
\fBtemporarilyUnavailableBackoffBaseMs\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specifies the initial delay before retying a write operation that was
rolled back due to cache pressure.
.PP
In rare circumstances, a write can fail due to cache pressure. When
this happens MongoDB issues a \fBTemporarilyUnavailable\f1 error and
increments the \fBtemporarilyUnavailableErrors\f1 counter in two places:
the slow query log and the \fBFull Time Diagnostic Data Collection
(FTDC)\f1\&.
.PP
Individual operations within multi\-document transactions never return
\fBTemporarilyUnavailable\f1 errors.
.PP
Adjust the write retry properties by modifying the
\fBtemporarilyUnavailableBackoffBaseMs\f1\f1 and
\fBtemporarilyUnavailableMaxRetries\f1\f1 parameters.
.PP
The parameter accepts:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Value
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBinteger >= 0\f1
.IP \(bu 4
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.
.IP
To configure number of retries, use
\fBtemporarilyUnavailableMaxRetries\f1\f1\&.
.RE
.RE
.PP
To set a new value, use \fBdb.adminCommand()\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, temporarilyUnavailableBackoffBaseMs: 3 } )
.EE
.RE
.PP
\fBtemporarilyUnavailableMaxRetries\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specifies the maximum number of retries when a write operation is
rolled back due to cache pressure.
.PP
In rare circumstances, a write can fail due to cache pressure. When
this happens MongoDB issues a \fBTemporarilyUnavailable\f1 error and
increments the \fBtemporarilyUnavailableErrors\f1 counter in two places:
the slow query log and the \fBFull Time Diagnostic Data Collection
(FTDC)\f1\&.
.PP
Individual operations within multi\-document transactions never return
\fBTemporarilyUnavailable\f1 errors.
.PP
Adjust the write retry properties by modifying the
\fBtemporarilyUnavailableBackoffBaseMs\f1\f1 and
\fBtemporarilyUnavailableMaxRetries\f1\f1 parameters.
.PP
The parameter accepts:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Value
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fBinteger >= 0\f1
.IP \(bu 4
Defaults to 10. The maximum number of retries.
.IP
There is an increasing delay between retries. To configure
the backoff time, use
\fBtemporarilyUnavailableBackoffBaseMs\f1\f1\&.
.RE
.RE
.PP
To set a new value, use \fBdb.adminCommand()\f1\f1:
.PP
.EX
  db.adminCommand( { setParameter: 1, temporarilyUnavailableMaxRetries: 5 } )
.EE
.RE
.SS WIREDTIGER PARAMETERS
.PP
\fBwiredTigerMaxCacheOverflowSizeGB\f1
.RS
.PP
MongoDB deprecates the \fBwiredTigerMaxCacheOverflowSizeGB\f1
parameter. The parameter has no effect starting in MongoDB 4.4.
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: 0 (No specified maximum)
.PP
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.
.PP
The parameter can accept the following values:
.RS
.IP \(bu 2
.RS
.IP \(bu 4
Value
.IP \(bu 4
Description
.RE
.IP \(bu 2
.RS
.IP \(bu 4
\fB0\f1
.IP \(bu 4
The default value. If set to \fB0\f1, the file size is
unbounded.
.RE
.IP \(bu 2
.RS
.IP \(bu 4
number >= 0.1
.IP \(bu 4
The maximum size (in GB). If the WiredTigerLAS.wt
file exceeds this size, \fBmongod\f1\f1 exits with a
fatal assertion. You can clear the WiredTigerLAS.wt
file and restart \fBmongod\f1\f1\&.
.RE
.RE
.PP
You can only set this parameter during run time using the
\fBsetParameter\f1\f1 database command:
.PP
.EX
  db.adminCommand( { setParameter: 1, wiredTigerMaxCacheOverflowSizeGB: 100 } )
.EE
.PP
To set the maximum size during start up, use the
\fBstorage.wiredTiger.engineConfig.maxCacheOverflowFileSizeGB\f1\f1
instead.
.RE
.PP
\fBwiredTigerConcurrentReadTransactions\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Available for the WiredTiger storage engine only.
.PP
Specify the maximum number of concurrent read transactions allowed
into the WiredTiger storage engine.
.PP
.EX
  db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: <num> } )
.EE
.PP
\fBwiredTiger.concurrentTransactions\f1\f1
.RE
.PP
\fBwiredTigerConcurrentWriteTransactions\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Available for the WiredTiger storage engine only.
.PP
Specify the maximum number of concurrent write transactions allowed
into the WiredTiger storage engine.
.PP
.EX
  db.adminCommand( { setParameter: 1, wiredTigerConcurrentWriteTransactions: <num> } )
.EE
.PP
\fBwiredTiger.concurrentTransactions\f1\f1
.RE
.PP
\fBwiredTigerEngineRuntimeConfig\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
Specify \fBwiredTiger\f1 storage engine configuration options for a
running \fBmongod\f1\f1 instance. You can \fIonly\f1 set this
parameter using the \fBsetParameter\f1\f1 command and \fInot\f1
using the command line or configuration file option.
.PP
Avoid modifying the \fBwiredTigerEngineRuntimeConfig\f1\f1
unless under the direction from MongoDB engineers as this setting has
major implication across both WiredTiger and MongoDB.
.PP
Consider the following operation prototype:
.PP
.EX
  db.adminCommand({
     "setParameter": 1,
     "wiredTigerEngineRuntimeConfig": "<option>=<setting>,<option>=<setting>"
  })
.EE
.PP
See the WiredTiger documentation for all available
WiredTiger configuration options (http://source.wiredtiger.com/mongodb\-5.0/struct_w_t___c_o_n_n_e_c_t_i_o_n.html#)\&.
.RE
.SS AUDITING PARAMETERS
.PP
\fBauditAuthorizationSuccess\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
Available only in MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)
and MongoDB Atlas (https://cloud.mongodb.com/user#/atlas/login)\&.
.PP
Enables the \fBauditing\f1 of authorization
successes for the \fBauthCheck\f1
action.
.PP
When \fBauditAuthorizationSuccess\f1\f1 is \fBfalse\f1, the
\fBaudit system\f1 only logs the authorization
failures for \fBauthCheck\f1\&.
.PP
To enable the audit of authorization successes, issue the following
command:
.PP
.EX
  db.adminCommand( { setParameter: 1, auditAuthorizationSuccess: true } )
.EE
.PP
Enabling \fBauditAuthorizationSuccess\f1\f1 degrades performance
more than logging only the authorization failures.
.PP
If \fBruntime audit configuration\f1
is enabled, the \fBauditAuthorizationSuccess\f1\f1 parameter
should not appear in the \fBmongod\f1 or \fBmongos\f1 configuration
file. The server will fail to start if the parameter is present.
.PP
\fBgetParameter\f1\f1
.RE
.PP
\fBauditConfigPollingFrequencySecs\f1
.RS
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 300
.PP
A sharded cluster may have servers which maintain audit
configuration settings for the cluster. Set the interval, in
seconds, for non\-configured servers to poll a config server for the
current audit generation. If this value returned differs from the
previously known value, the initiating node will request the current
configuration and update its internal state.
.PP
Using the default value of 300 seconds, non\-config nodes may lag up
to 5 minutes behind a setAuditConfig command.
.RE
.PP
\fBauditEncryptionHeaderMetadataFile\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: string
.PP
Available only in MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)\&.
MongoDB Enterprise and Atlas have different configuration
requirements.
.PP
Path and file name for logging metadata audit headers for \fBaudit
log encryption\f1\&. A header is
placed at the top of each audit log file and contains metadata for
decrypting the audit log. The headers are also stored in the
\fBaudit log\f1\&.
.PP
You can only set \fBauditEncryptionHeaderMetadataFile\f1\f1
during startup in the \fBconfiguration file\f1\f1 or
with the \fB\-\-setParameter\f1 option on the command line. For example,
the following sets the path and file for
\fBauditEncryptionHeaderMetadataFile\f1\f1:
.PP
.EX
  mongod \-\-setParameter auditEncryptionHeaderMetadataFile=/auditFiles/auditHeadersMetadataFile.log
.EE
.RE
.PP
\fBauditEncryptKeyWithKMIPGet\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.PP
Available only in MongoDB Enterprise (http://www.mongodb.com/products/mongodb\-enterprise\-advanced?tck=docs_server)\&.
MongoDB Enterprise and Atlas have different configuration
requirements.
.PP
Enables \fBaudit log encryption\f1 for Key Management
Interoperability Protocol (KMIP) servers that only support KMIP
protocol version 1.0 or 1.1.
.PP
You can only set \fBauditEncryptKeyWithKMIPGet\f1\f1 during
startup in the \fBconfiguration file\f1\f1 or with
the \fB\-\-setParameter\f1 option on the command line. For example, the
following sets \fBauditEncryptKeyWithKMIPGet\f1\f1 to \fBtrue\f1:
.PP
.EX
  mongod \-\-setParameter auditEncryptKeyWithKMIPGet=true
.EE
.RE
.SS TRANSACTION PARAMETERS
.PP
\fBcoordinateCommitReturnImmediatelyAfterPersistingDecision\f1
.RS
.PP
\fIUpdated in version 6.1\f1
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: false
.SS BEHAVIOR WHEN FALSE
.PP
The \fBshard\f1 transaction coordinator waits for
all members to acknowledge the decision to either commit or cancel a
\fBmulti\-document transaction\f1 before
returning the result to the client.
.SS BEHAVIOR WHEN TRUE
.PP
The shard transaction coordinator returns a \fBmulti\-document
transaction\f1 commit decision to the client
as soon as the decision is made \fBdurable\f1 with the requested
transaction \fBwrite concern\f1\&.
.PP
If the client requested a write concern that is less than
\fB"majority"\f1\f1, the commit may roll back after the
decision is returned to the client.
.PP
Transactions may not have "read your writes" consistency. That is, a
read operation may not reflect the results of a write operation that
preceded it. This can happen in the following cases:
.RS
.IP \(bu 2
A transaction has to write to multiple shards.
.IP \(bu 2
The read and the earlier write take place in different sessions.
.RE
.PP
\fBCausal consistency\f1 only guarantees the
causal relationship of reads and writes that occur within the same
session.
.SS EXAMPLE
.PP
The following example sets
\fBcoordinateCommitReturnImmediatelyAfterPersistingDecision\f1 to
\fBtrue\f1:
.PP
.EX
  mongod \-\-setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true
.EE
.PP
During run time, you can also set the parameter with the
\fBsetParameter\f1\f1 command:
.PP
.EX
  db.adminCommand( { setParameter: 1, coordinateCommitReturnImmediatelyAfterPersistingDecision: true } )
.EE
.RE
.PP
\fBinternalSessionsReapThreshold\f1
.RS
.PP
Available for both \fBmongod\f1\f1 and \fBmongos\f1\f1\&.
.PP
\fIDefault\f1: 1000
.PP
Session limit for internal session metadata deletion. The metadata:
.RS
.IP \(bu 2
Contains session transaction information for user operations.
.IP \(bu 2
Is stored in the \fBconfig.transactions\f1\f1 collection.
.RE
.PP
When the number of internal sessions is greater than
\fBinternalSessionsReapThreshold\f1\f1, the metadata is deleted.
.PP
If you set \fBinternalSessionsReapThreshold\f1\f1 to \fB0\f1, the
internal session metadata is only deleted when the user session ends.
.PP
The following example sets \fBinternalSessionsReapThreshold\f1\f1
to \fB500\f1 sessions:
.PP
.EX
  db.adminCommand( { setParameter: 1, internalSessionsReapThreshold: 500 } )
.EE
.PP
You can also set \fBinternalSessionsReapThreshold\f1\f1 at
startup. For example:
.PP
.EX
  mongod \-\-setParameter internalSessionsReapThreshold=500
.EE
.RE
.PP
\fBtransactionLifetimeLimitSeconds\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIDefault\f1: 60
.PP
Specifies the lifetime of \fBmulti\-document transactions\f1\&. Transactions that exceed this limit are
considered expired and will be aborted by a periodic cleanup
process. The cleanup process runs every
\fBtransactionLifetimeLimitSeconds\f1\f1/2 seconds or at least
once every 60 seconds.
.PP
The cleanup process helps relieve storage cache pressure.
.PP
The minimum value for transactionLifetimeLimitSeconds is \fB1\f1
second.
.PP
The following sets the
\fBtransactionLifetimeLimitSeconds\f1\f1 to \fB30\f1
seconds:
.PP
.EX
  db.adminCommand( { setParameter: 1, transactionLifetimeLimitSeconds: 30 } )
.EE
.PP
You can also set parameter \fBtransactionLifetimeLimitSeconds\f1\f1 at
startup time.
.PP
.EX
  mongod \-\-setParameter "transactionLifetimeLimitSeconds=30"
.EE
.PP
To set the parameter for a sharded cluster, the parameter must be
modified for all shard replica set members.
.PP
Starting in MongoDB 5.0, if you change the
\fBtransactionLifetimeLimitSeconds\f1\f1 parameter, you must also
change \fBtransactionLifetimeLimitSeconds\f1\f1 to the same value on
all config server replica set members. Keeping this value consistent:
.RS
.IP \(bu 2
Ensures the routing table history is retained for at least as long as
the transaction lifetime limit on the shard replica set members.
.IP \(bu 2
Reduces the transaction retry frequency and therefore improves
performance.
.RE
.RE
.PP
\fBtransactionTooLargeForCacheThreshold\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: decimal
.PP
\fIDefault\f1: 0.75
.PP
The threshold value for retrying transactions that fail due to cache
pressure. The value is a percentage of the dirty cache size. The
default value, \fB0.75\f1, means 75% of the dirty cache.
.PP
The dirty cache is limited to 20% of the total cache size. When
\fBtransactionTooLargeForCacheThreshold\f1 is set to \fB0.75\f1, the
server only retries transactions that use less than 15%
(\fB0.75 * 20%\f1) of the total storage engine cache.
.PP
The limit only applies to retries. Large transactions can use more
than \fBtransactionTooLargeForCacheThreshold\f1 percent of the dirty
cache. However, if a large transaction is rolled back due to cache
pressure, the server issues a
\fBTransactionTooLargeForCache\f1\f1 error and does not retry the
transaction.
.PP
To disable this behavior, set
\fBtransactionTooLargeForCacheThreshold\f1 to \fB1.0\f1\&.
.PP
For more information on WiredTiger storage, see:
\fBstorage.wiredTiger\f1 Options\f1\&.
.RE
.PP
\fBmaxTransactionLockRequestTimeoutMillis\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: integer
.PP
\fIDefault\f1: 5
.PP
The maximum amount of time in milliseconds that \fBmulti\-document
transactions\f1 should wait to acquire locks
required by the operations in the transaction.
.PP
If the transaction cannot acquire the locks after waiting
\fBmaxTransactionLockRequestTimeoutMillis\f1\f1, the transaction
aborts.
.PP
By default, \fBmulti\-document transactions\f1
wait \fB5\f1 milliseconds. That is, if the transaction cannot acquire
the locks within \fB5\f1 milliseconds, the transaction aborts. If an
operation provides a greater timeout in a lock request,
\fBmaxTransactionLockRequestTimeoutMillis\f1\f1 overrides the
operation\-specific timeout.
.PP
You can set \fBmaxTransactionLockRequestTimeoutMillis\f1\f1 to:
.RS
.IP \(bu 2
\fB0\f1 such that if the transaction cannot acquire the required
locks immediately, the transaction aborts.
.IP \(bu 2
A number greater than \fB0\f1 to wait the specified time to acquire
the required locks. This can help obviate transaction aborts on
momentary concurrent lock acquisitions, like fast\-running metadata
operations. However, this could possibly delay the abort of
deadlocked transaction operations.
.IP \(bu 2
\fB\-1\f1 to use the operation specific timeout.
.RE
.PP
The following sets the
\fBmaxTransactionLockRequestTimeoutMillis\f1\f1 to \fB20\f1
milliseconds:
.PP
.EX
  db.adminCommand( { setParameter: 1, maxTransactionLockRequestTimeoutMillis: 20 } )
.EE
.PP
You can also set this parameter during start\-up:
.PP
.EX
  mongod \-\-setParameter maxTransactionLockRequestTimeoutMillis=20
.EE
.RE
.PP
\fBshouldMultiDocTxnCreateCollectionAndIndexes\f1
.RS
.PP
\fIRemoved in 5.0\f1
.PP
\fIType\f1: boolean
.PP
\fIDefault\f1: true
.PP
A flag that enables or disables the creation of a collection or an
index inside transactions. Set the parameter to:
.RS
.IP \(bu 2
\fBtrue\f1 to enable. (\fIDefault\f1)
.IP \(bu 2
\fBfalse\f1 to disable.
.RE
.PP
You can set the parameter during startup or run time.
.PP
When setting the parameter for a sharded cluster, set the
parameter on all shards.
.PP
To set the parameter at startup, specify the parameter in the
\fBconfiguration file\f1\f1 or with the
\fB\-\-setParameter\f1 option on the command line. For example:
.PP
.EX
  mongod \-\-setParameter shouldMultiDocTxnCreateCollectionAndIndexes=false
.EE
.PP
To modify during run time, you can use the \fBsetParameter\f1\f1
command; for example:
.PP
.EX
  db.adminCommand( { setParameter: 1, shouldMultiDocTxnCreateCollectionAndIndexes: false } )
.EE
.RE
.SS SLOT-BASED EXECUTION PARAMETERS
.PP
\fBplanCacheSize\f1
.RS
.PP
Available for \fBmongod\f1\f1 only.
.PP
\fIType\f1: string
.PP
\fIDefault\f1: 5%
.PP
Although the \fBplanCacheSize\f1 parameter existed in prior versions of
MongoDB, it had no effect on the plan cache until version 6.3.
.PP
Sets the size of the \fBplan cache\f1
only for the \fBslot\-based query execution engine\f1\&.
.PP
You can set the \fBplanCacheSize\f1\f1 value to either:
.RS
.IP \(bu 2
A percentage of the system\(aqs total physical memory to allocate for
the plan cache. For example, \fB"8.5%"\f1\&.
.IP \(bu 2
The exact amount of data to allocate for the plan cache in either
\fBMB\f1 or \fBGB\f1\&. For example, \fB"100MB"\f1 or \fB"1GB"\f1\&.
.RE
.PP
Increasing the plan cache size adds more cached query shapes for the
\fBquery planner\f1\&. This can
improve query performance, but increases memory usage.
.PP
The following startup command sets \fBplanCacheSize\f1\f1 to 80
megabytes:
.PP
.EX
  mongod \-\-setParameter planCacheSize="80MB"
.EE
.PP
You can also use the \fBsetParameter\f1\f1 command within the
MongoDB Shell (https://www.mongodb.com/docs/mongodb\-shell/):
.PP
.EX
  db.adminCommand( { setParameter: 1, planCacheSize: "80MB" } )
.EE
.RE