Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
mongodb-parameters(5)	      File Formats Manual	 mongodb-parameters(5)

MONGODB	SERVER PARAMETERS
SYNOPSIS
       MongoDB provides	a number of configuration options that you can set us-
       ing:

	      	the setParameter command:

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

	      	the setParameter configuration setting:

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

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

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

       For  additional	configuration options, see Configuration File Options,
       mongod and mongos.

PARAMETERS
   AUTHENTICATION PARAMETERS
       authenticationMechanisms

	      Available	for both mongod	and mongos.

	      Specifies	the list of authentication mechanisms the  server  ac-
	      cepts.  Set  this	to one or more of the following	values.	If you
	      specify multiple values,	use  a	comma-separated	 list  and  no
	      spaces.  For  descriptions of the	authentication mechanisms, see
	      Authentication.

		     

		          Value

		          Description

		     

		          SCRAM-SHA-1

		          RFC	 5802	 (https://tools.ietf.org/html/rfc5802)
			   standard  Salted  Challenge Response	Authentication
			   Mechanism using the SHA-1 hash function.

		     

		          SCRAM-SHA-256

		          RFC	 7677	 (https://tools.ietf.org/html/rfc7677)
			   standard  Salted  Challenge Response	Authentication
			   Mechanism using the SHA-256 hash function.

		     

		          MONGODB-X509

		          MongoDB TLS/SSL certificate authentication.

		     

		          GSSAPI (Kerberos)

		          External authentication using Kerberos. This	mecha-
			   nism	 is  available	only  in  MongoDB   Enterprise
			   (http://www.mongodb.com/products/mongodb-enter-
			   prise-advanced?tck=docs_server).

		     

		          PLAIN (LDAP SASL)

		          External  authentication  using  LDAP. You can also
			   use PLAIN  for  authenticating  in-database	users.
			   PLAIN transmits passwords in	plain text. This mech-
			   anism  is  available	 only  in  MongoDB  Enterprise
			   (http://www.mongodb.com/products/mongodb-enter-
			   prise-advanced?tck=docs_server).

		     

		          MONGODB-OIDC

		          OpenID Connect is an	authentication layer built  on
			   top	of OAuth2. This	mechanism is available only in
			   MongoDB  Enterprise	 (http://www.mongodb.com/prod-
			   ucts/mongodb-enterprise-advanced?tck=docs_server).

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

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

       awsSTSRetryCount

	      In  previous  versions, AWS IAM authentication retried only when
	      the server returned an HTTP 500 error.

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 2

	      For   MongoDB   deployments   using    AWS    IAM	   credentials
	      (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_creden-
	      tials_access-keys.html)	or   AWS   IAM	environment  variables
	      (https://docs.aws.amazon.com/cli/latest/userguide/cli-config-
	      ure-envvars.html#envvars-list).

	      Maximum number of	AWS IAM	authentication retries after a connec-
	      tion failure.

	      The following example sets awsSTSRetryCount to 15	retries:

		mongod --setParameter awsSTSRetryCount=15

	      Alternatively, the following examples uses the setParameter com-
	      mand within mongosh:

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

       clusterAuthMode

	      Available	for both mongod	and mongos.

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

	      For  more	 information  about TLS/SSL and	MongoDB, see Configure
	      mongod and mongos	for  TLS/SSL  and  TLS/SSL  Configuration  for
	      Clients .

	      This  parameter is only available	at runtime. To set the parame-
	      ter, use the setParameter	command.

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

       enableLocalhostAuthBypass

	      Available	for both mongod	and mongos.

	      Default: true

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      See Localhost Exception for more information.

       enforceUserClusterSeparation

	      Available	for both mongod	and mongos.

	      Set to false to disable the O/OU/DC check	 when  clusterAuthMode
	      is  keyFile in your configuration	file. This allows clients pos-
	      sessing member certificates to authenticate as users  stored  in
	      the  $external  database.	The server won't start if clusterAuth-
	      Mode isn't keyFile in your configuration file.

	      To set the enforceUserClusterSeparation parameter	to false,  run
	      the following command during startup:

		mongod --setParameter enforceUserClusterSeparation=false

	      If  you set the enforceUserClusterSeparation parameter to	false,
	      the server  doesn't  distinguish	between	 client	 certificates,
	      which  applications  use to authenticate,	and intra-cluster cer-
	      tificates, which have privileged access. This has	no  effect  if
	      your  clusterAuthMode  is	keyFile. However, if your clusterAuth-
	      Mode is x509, user certificates that use the allowed scheme  are
	      conflated	 with  cluster certificates and	granted	privileged ac-
	      cess.

	      Your existing certificates are granted  internal	privileges  if
	      you do the following:

		      Create a	user, with a name allowed by this parameter.

		      Set   the   enforceUserClusterSeparation	 parameter  to
		       false.

		      Set clusterAuthMode to x509.

	      You must not upgrade from	keyFile	 to  x509  without  validating
	      that  you've removed users with elevated privileges that the en-
	      forceUserClusterSeparation flag allowed you to create.

       KeysRotationIntervalSec

	      Default: 7776000 seconds (90 days)

	      Specifies	the number of seconds for which	an  HMAC  signing  key
	      (https://en.wikipedia.org/wiki/Hash-based_message_authentica-
	      tion_code)  is valid before rotating to the next one. This para-
	      meter is intended	primarily to facilitate	 authentication	 test-
	      ing.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       ldapForceMultiThreadMode

	      Default: false

	      Enables the performance of concurrent LDAP operations.

	      Only if you are certain that your	instance of libldap is safe to
	      use in this mode,	enable this flag. You may  experience  crashes
	      of  the  MongoDB process if the libldap version you are using is
	      not thread safe.

	      You must use ldapForceMultiThreadMode  to	 use  LDAP  connection
	      pool.  To	enable LDAP connection pool, set ldapForceMultiThread-
	      Mode and ldapUseConnectionPool to	true.

	      If you have any concerns regarding your MongoDB version, OS ver-
	      sion or libldap version, please contact MongoDB Support.

       ldapQueryPassword

	      Available	for both mongod	and mongos.

	      Type: string

	      The password used	to bind	to an LDAP server. You must use	 ldap-
	      QueryUser	with this parameter.

	      If  not  set,  mongod  or	mongos does not	attempt	to bind	to the
	      LDAP server.

       ldapQueryUser

	      Available	for both mongod	and mongos.

	      Type: string

	      The user that binds to an	LDAP server. You must  use  ldapQuery-
	      Password with this parameter.

	      If  not  set,  mongod  or	mongos does not	attempt	to bind	to the
	      LDAP server.

       ldapRetryCount

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 0

	      For MongoDB deployments using LDAP Authorization.

	      Number of	operation retries by the server	LDAP manager  after  a
	      network error.

	      For example, the following sets ldapRetryCount to	3 seconds:

		mongod --ldapRetryCount=3

	      Or, if using the setParameter command within mongosh:

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

       ldapUserCacheInvalidationInterval

	      Available	for mongod only.

	      Starting in MongoDB 5.2, the update interval for cached user in-
	      formation	 retrieved  from  an LDAP server depends on ldapShoul-
	      dRefreshUserCacheEntries:

		      If true,	use ldapUserCacheRefreshInterval.

		      If false, use ldapUserCacheInvalidationInterval.

	      For use with MongoDB deployments using LDAP Authorization.

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

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

	      Defaults to 30 seconds.

       ldapUserCacheRefreshInterval

	      Available	for mongod only.

	      Type: integer

	      Default: 30 seconds

	      Starting in MongoDB 5.2, the update interval for cached user in-
	      formation	 retrieved  from  an LDAP server depends on ldapShoul-
	      dRefreshUserCacheEntries:

		      If true,	use ldapUserCacheRefreshInterval.

		      If false, use ldapUserCacheInvalidationInterval.

	      For MongoDB deployments using LDAP Authorization.

	      The interval in seconds that mongod waits	before refreshing  the
	      cached user information from the LDAP server.

	      The maximum interval is 86,400 seconds (24 hours).

	      For  example, the	following sets ldapUserCacheRefreshInterval to
	      4000 seconds:

		mongod --setParameter ldapUserCacheRefreshInterval=4000

	      Or, if using the setParameter command within mongosh:

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

       ldapUserCacheStalenessInterval

	      Available	for mongod only.

	      Type: integer

	      Default: 90 seconds

	      For MongoDB deployments using LDAP Authorization.

	      The interval in seconds that mongod retains the cached LDAP user
	      information after	the last cache refresh.

	      If more than ldapUserCacheStalenessInterval seconds elapse with-
	      out a successful refresh of the user information from  the  LDAP
	      server, then mongod:

		      Invalidates the cached LDAP user	information.

		      Is  unable  to authenticate new sessions	for LDAP users
		       until mongod connects to	the LDAP server	and authorizes
		       the LDAP	user.

		      Authorizes any existing sessions	 that  use  previously
		       authenticated LDAP users	if mongod is unable to connect
		       to  the LDAP server. When mongod	reconnects to the LDAP
		       server, mongod ensures the LDAP users are correctly au-
		       thorized.

	      The maximum interval is 86,400 seconds (24 hours).

	      For example, the following  sets	ldapUserCacheStalenessInterval
	      to 4000 seconds:

		mongod --setParameter ldapUserCacheStalenessInterval=4000

	      Or, if using the setParameter command within mongosh:

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

       ldapUseConnectionPool

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

	      MongoDB uses the following default values:

		      true on Windows.

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

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

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

       ldapConnectionPoolUseLatencyForHostPriority

	      Default: true

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

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

       ldapConnectionPoolMinimumConnectionsPerHost

	      Default: 1

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

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

       ldapConnectionPoolMaximumConnectionsPerHost

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

	      Default: 2147483647

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

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

       ldapConnectionPoolMaximumConnectionsInProgressPerHost

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

	      Default: 2

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

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

       ldapConnectionPoolHostRefreshIntervalMillis

	      Default: 60000

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

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

       ldapConnectionPoolIdleHostTimeoutSecs

	      Default: 300

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

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

       ldapShouldRefreshUserCacheEntries

	      Available	for mongod only.

	      Type: boolean

	      Default: true

	      For MongoDB deployments using LDAP Authorization.

	      Starting in MongoDB 5.2, the update interval for cached user in-
	      formation	 retrieved  from  an LDAP server depends on ldapShoul-
	      dRefreshUserCacheEntries:

		      If true,	use ldapUserCacheRefreshInterval.

		      If false, use ldapUserCacheInvalidationInterval.

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

		mongod --setParameter ldapShouldRefreshUserCacheEntries=false

       maxValidateMemoryUsageMB

	      Default: 200

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       oidcIdentityProviders

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

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

   OIDCIDENTITYPROVIDERS FIELDS
	      

		   Field

		   Necessity

		   Type

		   Description

	      

		   issuer

		   Required

		   string

		   The	 issuer	 URI  of the IDP that the server should	accept
		    tokens from. This must match the iss field in any JWT used
		    for	authentication.

		    If you specify an unreachable issuer URI, MongoDB:

		    	  Logs a warning.

		    	  Continues server startup, which allows you to	update
			  the issuer URI.

		    	  Reattempts issuer contact. If	 MongoDB  reaches  the
			  issuer URI and validates the access token, authenti-
			  cation  succeeds. If the issuer URI remains unreach-
			  able,	authentication fails.

	      

		   authNamePrefix

		   Required

		   string

		   Unique prefix applied to each generated UserName and Role-
		    Name used in authorization.	authNamePrefix can  only  con-
		    tain the following characters:

		    	  alphanumeric characters (combination of a to z and 0
			  to 9)

		    	  hyphens (-)

		    	  underscores (_)

	      

		   matchPattern

		   Conditional

		   string

		   Regex  pattern used	to determine which IDP should be used.
		    matchPattern matches against usernames. Array order	deter-
		    mines the priority and the first IDP is always selected.

		    matchPattern is required in	some configurations, depending
		    on how the user sets supportsHumanFlows:

		    	  When only one	IdP has	supportsHumanFlows set to true
			  (the default), matchPatterns is optional.

		    	  When multiple	IdP's have supportsHumanFlows  set  to
			  true (the default), each of these requires matchPat-
			  terns.

		    	  matchPatterns	is optional for	any IdP	where support-
			  sHumanFlows is set to	false.

		    This is not	a security mechanism. matchPattern serves only
		    as	an  advisory to	clients. MongoDB accepts tokens	issued
		    by the IDP whose principal names do	not  match  this  pat-
		    tern.

	      

		   clientId

		   Conditional

		   string

		   ID	provided  by  the  IDP to identify the client that re-
		    ceives the access tokens.

		    Required when supportsHumanFlows is	set to true  (the  de-
		    fault).

	      

		   audience

		   Required

		   string

		   Specifies the application or service that the access token
		    is intended	for.

	      

		   requestScopes

		   Optional

		   array[ string ]

		   Permissions	 and  access levels that MongoDB requests from
		    the	IDP.

	      

		   principalName

		   Optional

		   string

		   The	claim to be extracted from the access token containing
		    MongoDB user identifiers.

		    The	default	value is sub (stands for subject).

	      

		   useAuthorizationClaim

		   Optional

		   boolean

		   Determines if the authorizationClaim is required. The  de-
		    fault value	is true.

		    If	the  useAuthorizationClaim  field  is set to true, the
		    server requires an	authorizationClaim  for	 the  identity
		    provider's config. This is the default behavior.

		    If	the  useAuthorizationClaim  field is set to false, the
		    authorizationClaim field is	optional (and ignored if  pro-
		    vided).  Instead, the server does the following:

		    	  Searches  the	token for a claim whose	name is	listed
			  in the principalNameClaim field. This	 is  typically
			  named	sub. For example:

			  sub: "spencer.jackson@example.com"

		    	  Constructs  the  internal  username by concatenating
			  the authNamePrefix, a	forward	 slash	(/),  and  the
			  contents  of	the claim identified by	principalName-
			  Claim	within the access token. For example,  with  a
			  authNamePrefix field value of	"mdbinc", the internal
			  username is:

			  mdbinc/spencer.jackson@example.com

		    	  Looks	for the	user with this username	and authorizes
			  the client with the roles:

			    { user: "mdbinc/spencer.jackson@example.com",
			      db: "$external" }

	      

		   authorizationClaim

		   Conditional

		   string

		   Required, unless useAuthorizationClaim is set to false.

		    Claim  extracted  from  access token that contains MongoDB
		    role names.

	      

		   logClaims

		   Optional

		   array[ string ]

		   List of access token claims	to include in  log  and	 audit
		    messages upon authentication completion.

	      

		   JWKSPollSecs

		   Optional

		   integer

		   Frequency,	in seconds, to request an updated JSON Web Key
		    Set	(JWKS) from the	IDP.  A	setting	of 0 disables polling.

	      

		   supportsHumanFlows

		   Optional

		   bool

		   Whether the	OIDC provider supports human or	machine	 work-
		    flows.  This affects the clientId and matchPattern fields.

		    You	may find it useful to set this field to	false with ma-
		    chine  workload  IdP's  to allow them to omit the clientId
		    when it's unneeded.

		    Default: true.

       This parameter is only available	at startup. To set the parameter,  use
       the setParameter	setting.

       ocspEnabled

	      Available	on Linux and macOS.

	      Default: true

	      The flag that enables or disables	OCSP.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      For example, the following disables OCSP:

		mongod --setParameter ocspEnabled=false	...

	      Starting in MongoDB 6.0, if ocspEnabled is set  to  true	during
	      initial  sync,  all nodes	must be	able to	reach the OCSP respon-
	      der.

	      If a member fails	in the STARTUP2	state, set  tlsOCSPVerifyTime-
	      outSecs to a value that is less than 5.

		      ocspValidationRefreshPeriodSecs

		      tlsOCSPStaplingTimeoutSecs

		      tlsOCSPVerifyTimeoutSecs

       ocspValidationRefreshPeriodSecs

	      Available	on Linux.

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

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

		mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ...

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

		      ocspEnabled

		      tlsOCSPStaplingTimeoutSecs

		      tlsOCSPVerifyTimeoutSecs

       opensslCipherConfig

	      Available	on Linux only

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

	      Specify the cipher string	for OpenSSL when using TLS/SSL encryp-
	      tion.	 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).  Mul-
	      tiple cipher strings can be provided as a	colon-separated	list.

	      This parameter is	only for use with TLS 1.2 or earlier. To spec-
	      ify cipher suites	for use	with TLS 1.3, use  the	opensslCipher-
	      SuiteConfig parameter.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      The use of TLS options is	preferred over SSL  options.  The  TLS
	      options have the same functionality as the SSL options. The fol-
	      lowing  example  configures  a mongod with a opensslCipherConfig
	      cipher string of 'HIGH:!EXPORT:!aNULL@STRENGTH':

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

       opensslCipherSuiteConfig

	      Available	on Linux only

	      Specify the list of supported cipher suites OpenSSL should  per-
	      mit when using TLS 1.3 encryption.

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      For example, the following configures a mongod with a opensslCi-
	      pherSuiteConfig cipher suite of 'TLS_AES_256_GCM_SHA384' for use
	      with TLS 1.3:

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

       opensslDiffieHellmanParameters

	      Available	on Linux only

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

	      This parameter is	not supported for use with TLS 1.3.

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

	      If opensslDiffieHellmanParameters	is unset but ECDHE is enabled,
	      MongoDB  enables	DHE using the ffdhe3072	Diffie-Hellman parame-
	      ter,	 as	  defined	in	 RFC-7919#appendix-A.2
	      (https://tools.ietf.org/html/7919#appendix-A.2).	The  ffdhe3072
	      is a strong parameter (specifically, size	is greater than	1024).
	      Strong parameters	are not	supported with Java 6 and 7 unless ex-
	      tended support has been purchased	from Oracle.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

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

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

       saslauthdPath

	      Available	for both mongod	and mongos.

	      Specify the path to the Unix Domain Socket of the	saslauthd  in-
	      stance to	use for	proxy authentication.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       saslHostName

	      Available	for both mongod	and mongos.

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      saslHostName supports Kerberos authentication and	 is  only  in-
	      cluded in	MongoDB	Enterprise. For	more information, see the fol-
	      lowing:

		      Linux:  Configure  MongoDB with Kerberos	Authentication
		       on Linux

		      Windows:	Configure MongoDB with Kerberos	Authentication
		       on Windows

       saslServiceName

	      Available	for both mongod	and mongos.

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      saslServiceName is only available	in MongoDB Enterprise.

	      Ensure that your driver supports alternate service names.

       scramIterationCount

	      Available	for both mongod	and mongos.

	      Default: 10000

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example,  the	 following  sets  the  scramIterationCount  to
	      12000.

		mongod --setParameter scramIterationCount=12000

	      Or, if using the setParameter command within mongosh:

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

		      db.changeUserPassword()

		      db.createUser()

		      db.updateUser()

       scramSHA256IterationCount

	      Available	for both mongod	and mongos.

	      Default: 15000

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example, the following sets the scramSHA256IterationCount to
	      20000.

		mongod --setParameter scramSHA256IterationCount=20000

	      Or, if using the setParameter command within mongosh:

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

		      db.changeUserPassword()

		      db.createUser()

		      db.updateUser()

       sslMode

	      Available	for both mongod	and mongos.

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

	      For  more	 information  about TLS/SSL and	MongoDB, see Configure
	      mongod and mongos	for  TLS/SSL  and  TLS/SSL  Configuration  for
	      Clients .

	      This  parameter is only available	at runtime. To set the parame-
	      ter, use the setParameter	command.

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

	      tlsMode

       tlsMode

	      Available	for both mongod	and mongos.

	      Set to either:

		      preferTLS

		      requireTLS

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

	      This  parameter is only available	at runtime. To set the parame-
	      ter, use the setParameter	command.

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

	      For more information about TLS/SSL and  MongoDB,	see  Configure
	      mongod  and  mongos  for	TLS/SSL	 and TLS/SSL Configuration for
	      Clients .

	      sslMode

       tlsClusterAuthX509Override

	      Overrides	the clusterAuthX509 configuration options.

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

	      The parameter supports attributes	and extensionValue overrides.

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

       tlsOCSPStaplingTimeoutSecs

	      Available	for Linux.

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      For  example,  the following sets	the tlsOCSPStaplingTimeoutSecs
	      to 20 seconds:

		mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

		      ocspEnabled

		      ocspValidationRefreshPeriodSecs

		      tlsOCSPVerifyTimeoutSecs

       tlsOCSPVerifyTimeoutSecs

	      Available	for Linux and Windows.

	      Default: 5

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      For example, the following sets the tlsOCSPVerifyTimeoutSecs  to
	      20 seconds:

		mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

		      ocspEnabled

		      ocspValidationRefreshPeriodSecs

		      tlsOCSPStaplingTimeoutSecs

       tlsUseSystemCA

	      Available	for mongod only.

	      Type: boolean

	      Default: false

	      Specifies	 whether  MongoDB  loads TLS certificates that are al-
	      ready available to the operating system's	certificate authority.

	      When starting a mongod instance with TLS/SSL enabled,  you  must
	      specify  a  value	 for  the --tlsCAFile flag, the	net.tls.CAFile
	      configuration option, or the tlsUseSystemCA parameter.

	      --tlsCAFile, tls.CAFile, and tlsUseSystemCA are all mutually ex-
	      clusive.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      For example, to set tlsUseSystemCA to true:

		mongod --setParameter tlsUseSystemCA=true

	      For  more	 information  about TLS/SSL and	MongoDB, see Configure
	      mongod and mongos	for  TLS/SSL  and  TLS/SSL  Configuration  for
	      Clients .

       tlsWithholdClientCertificate

	      Available	for both mongod	and mongos.

	      Default: false

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

       tlsX509ClusterAuthDNOverride

	      Available	for both mongod	and mongos.

	      An  alternative  Distinguished  Name  (DN) that the instance can
	      also use to identify members of the deployment.

	      For a MongoDB deployment that uses x.509 certificates for	 clus-
	      terAuthMode,  deployment members identify	each other using x.509
	      certificates   (	 net.tls.clusterFile,	if   specified,	   and
	      net.tls.certificateKeyFile) during intra-cluster communications.
	      For  members  of the same	deployment, the	DN from	their certifi-
	      cates must have the same Organization attributes (O's), the  Or-
	      ganizational  Unit  attributes (OU's), and the Domain Components
	      (DC's).

	      If tlsX509ClusterAuthDNOverride is set for a member, the	member
	      can also use the override	value when comparing the DN components
	      (O's, OU's, and DC's) of the presented certificates. That	is the
	      member   checks	the   presented	  certificates	 against   its
	      net.tls.clusterFile/net.tls.certificateKeyFile.  If the DN  does
	      not  match,  the member checks the presented certificate against
	      the tlsX509ClusterAuthDNOverride value.

	      If set, you must set this	parameter on all members  of  the  de-
	      ployment.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      You  can use this	parameter for a	rolling	update of certificates
	      to new certificates that contain a new DN	value. See Rolling Up-
	      date of x.509 Cluster Certificates that Contain New DN.

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

       tlsX509ExpirationWarningThresholdDays

	      Available	for both mongod	and mongos.

	      Default :	30

	      mongod  /	 mongos	 logs a	warning	on connection if the presented
	      x.509 certificate	expires	within 30 days	of  the	 mongod/mongos
	      system  clock. Use the tlsX509ExpirationWarningThresholdDays pa-
	      rameter to control the certificate expiration warning threshold:

		      Increase	the parameter value to trigger	warnings  far-
		       ther ahead of the certificate expiration	date.

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

		      Set the parameter to 0 to disable the warning.

	      This parameter has a minimum value of 0.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

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

       userCacheInvalidationIntervalSecs

	      Available	for mongos only.

	      Default: 30

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       authFailedDelayMs

	      Available	for both mongod	and mongos.

	      Default: 0

	      Available	in MongoDB Enterprise only.

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

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

       allowRolesFromX509Certificates

	      Available	for both mongod	and mongos.

	      Default: true

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

   GENERAL PARAMETERS
       allowDiskUseByDefault

	      Available	for mongod only.

	      Default: True

	      Starting in MongoDB 6.0, pipeline	stages that require more  than
	      100 megabytes of memory to execute write temporary files to disk
	      by  default.  These temporary files last for the duration	of the
	      pipeline execution and can influence storage space on  your  in-
	      stance.  In  earlier  versions  of MongoDB, you must pass	 { al-
	      lowDiskUse: true } to individual find and	aggregate commands  to
	      enable this behavior.

	      Individual  find	and  aggregate	commands  can override the al-
	      lowDiskUseByDefault parameter by either:

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

		      Using  {	allowDiskUse: false } to prohibit writing tem-
		       porary files out	to disk	when allowDiskUseByDefault  is
		       set to true

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

		mongod --setParameter allowDiskUseByDefault=false

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

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

       httpVerboseLogging

	      Available	for both mongod	and mongos.

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

	      By default, the parameter	is unset.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

		mongos --setParameter httpVerboseLogging=true

       slowConnectionThresholdMillis

	      Available	for both mongod	and mongos.

	      Default: 100

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets slowConnectionThresholdMillis to  250
	      milliseconds.

		mongod --setParameter slowConnectionThresholdMillis=250

	      Or, if using the setParameter command within mongosh:

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

       connPoolMaxConnsPerHost

	      Available	for both mongod	and mongos.

	      Default: 200

	      Sets  the	maximum	size of	the legacy connection pools for	outgo-
	      ing connections to other mongod instances	in the global  connec-
	      tion  pool.  The size of a pool does not prevent the creation of
	      additional connections, but does prevent a connection pool  from
	      retaining	 connections  in  excess  of the value of connPoolMax-
	      ConnsPerHost.

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		mongod --setParameter connPoolMaxConnsPerHost=250

       connPoolMaxInUseConnsPerHost

	      Available	for both mongod	and mongos.

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

	      By default, the parameter	is unset.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

		mongod --setParameter connPoolMaxInUseConnsPerHost=100

	      connPoolMaxConnsPerHost

       globalConnPoolIdleTimeoutMinutes

	      Available	for both mongod	and mongos.

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

	      By default, the parameter	is unset.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

       cursorTimeoutMillis

	      Available	for both mongod	and mongos.

	      Default: 600000 (10 minutes)

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

		mongod --setParameter cursorTimeoutMillis=300000

	      Or, if using the setParameter command within mongosh:

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

	      Setting  cursorTimeoutMillis  to less than or equal to 0 results
	      in all cursors being immediately eligible	for  timeout.	Gener-
	      ally,  the  timeout  value  should  be  greater than the average
	      amount of	time for a query to return results. Use	tools like the
	      cursor.explain() cursor modifier to analyze  the	average	 query
	      time and select an appropriate timeout period.

	      MongoDB cleans up	orphaned cursors linked	to sessions as part of
	      session  management.  This means that orphaned cursors with ses-
	      sion ids do not use cursorTimeoutMillis to control the timeout.

	      For operations that return a cursor  and	have  an  idle	period
	      longer  than localLogicalSessionTimeoutMinutes, use Mongo.start-
	      Session()	to perform the operation within	an  explicit  session.
	      To refresh the session, run the refreshSessions command. For de-
	      tails, see Refresh a Cursor with refreshSessions.

       maxNumActiveUserIndexBuilds

	      Available	for mongod only.

	      Type: integer

	      Default: 3

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

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

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

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

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

	      See also:

		      maxIndexBuildMemoryUsageMegabytes

		      Index Builds on Populated Collections

       notablescan

	      Available	for mongod only.

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

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

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

	      Setting notablescan to 1 can be useful for  testing  application
	      queries,	for  example,  to identify queries that	scan an	entire
	      collection and cannot use	an index.

	      To detect	unindexed queries without notablescan, consider	 read-
	      ing the Analyze Query Performance	and Optimize Query Performance
	      sections and using the logLevel parameter, mongostat and profil-
	      ing.

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      notablescan  does	 not  allow unbounded queries that use a clus-
	      tered index because the queries require a	full collection	 scan.
	      For more information, see	Collection Scans.

       ttlMonitorEnabled

	      Available	for mongod only.

	      Default: true

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      To  disable  this	 worker	thread for a mongod, set ttlMonitorEn-
	      abled to false, as in the	following operations:

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

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

		mongod --setParameter ttlMonitorEnabled=false

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

       tcpFastOpenServer

	      Available	for both mongod	and mongos.

	      Default: true

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

	      Windows

		     The following Windows operating systems support TFO:

			     Microsoft	Windows	Server 2016 and	later.

			     Microsoft	Windows	10 Update 1607 and later.

	      macOS

		     macOS 10.11 (El Capitan) and later	support	TFO.

	      Linux

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

		     Set  the  value of	/proc/sys/net/ipv4/tcp_fastopen	to en-
		     able inbound TFO connections:

			     Set to 2 to enable only inbound TFO connections.

			     Set to 3 to enable inbound and outbound TFO con-
			      nections.

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

	      RFC7413 (https://tools.ietf.org/html/rfc7413).

       tcpFastOpenClient

	      Available	for both mongod	and mongos.

	      Default: true

	      Linux Operating System Only

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

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

	      Set  the value of	/proc/sys/net/ipv4/tcp_fastopen	to enable out-
	      bound TFO	connections:

		      1 to enable only	outbound TFO connections.

		      3 to enable inbound and outbound	TFO connections.

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

	      RFC7413 (https://tools.ietf.org/html/rfc7413).

       tcpFastOpenQueueSize

	      Available	for both mongod	and mongos.

	      Default: 1024

	      As  part	of  establishing a TCP Fast Open (TFO) connection, the
	      client submits a valid TFO cookie	to  the	 mongod/mongos	before
	      completion  of the standard TCP 3-way handshake. The mongod/mon-
	      gos keeps	a queue	of all such pending TFO	connections.

	      The tcpFastOpenQueueSize parameter sets the size of the queue of
	      pending TFO connections. While  the  queue  is  full,  the  mon-
	      god/mongos  falls	back to	the normal three-way handshake for in-
	      coming client requests and ignores the presence of TFO  cookies.
	      Once  the	queue size falls back below the	limit, the mongod/mon-
	      gos begins accepting new TFO cookies.

		      Increasing the default queue size may improve  the  ef-
		       fect  of	 TFO  on  network  performance.	However, large
		       queue sizes also	increase the risk of  server  resource
		       exhaustion due to excessive incoming TFO	requests.

		      Decreasing  the	default	queue size may reduce the risk
		       of resource server resource exhaustion due to excessive
		       incoming	TFO requests.  However,	small queue sizes  may
		       also reduce the effect of TFO on	network	performance.

		       The  minimum  queue size	is 0. A	queue of 0 effectively
		       disables	TFO.

	      This parameter has no effect on host operating systems  that  do
	      not  support or are not configured for TFO connections. See Sup-
	      port for TCP Fast	Open for more information on MongoDB TFO  sup-
	      port.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		      RFC7413 TCP Fast	Open Section  5:  Security  Considera-
		       tions (https://tools.ietf.org/html/rfc7413#section-5)

		      RFC7413	TCP  Fast  Open	 Section  6: TFO Applicability
		       (https://tools.ietf.org/html/rfc7413#section-6)

       disableJavaScriptJIT

	      Available	for mongod only.

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

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

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

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

		mongod --setParameter disableJavaScriptJIT=false

       indexBuildMinAvailableDiskSpaceMB

	      Available	for mongod only.

	      Default: 500 MB

	      Sets the minimum available disk space in megabytes required  for
	      index builds.

	      Must be greater than or equal to 0 MB, and less than or equal to
	      8	TB. 0 disables the minimum disk	space requirement.

	      A	new index build	cannot be started and a	current	index build is
	      cancelled	 if  the  available  disk space	is below indexBuildMi-
	      nAvailableDiskSpaceMB.

	      If you increase indexBuildMinAvailableDiskSpaceMB,  ensure  your
	      server  has  enough  available  disk space. Also,	if you set in-
	      dexBuildMinAvailableDiskSpaceMB too high,	you  might  needlessly
	      prevent  index  builds when there	is enough available disk space
	      and indexBuildMinAvailableDiskSpaceMB could be set lower.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets indexBuildMinAvailableDiskSpaceMB  to
	      650 MB:

		db.adminCommand( { setParameter: 1, indexBuildMinAvailableDiskSpaceMB: 650 } )

	      You  can	also set indexBuildMinAvailableDiskSpaceMB at startup.
	      For example:

		mongod --setParameter indexBuildMinAvailableDiskSpaceMB=650

       indexMaxNumGeneratedKeysPerDocument

	      Default: 100000

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       maxIndexBuildMemoryUsageMegabytes

	      Default: 200

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

	      maxIndexBuildMemoryUsageMegabytes	sets a limit on	how much  mem-
	      ory  the	index  build uses at once. This	can impact performance
	      when the index build process generates and sorts	keys  for  the
	      index.  Increasing the memory limit improves sorting performance
	      during an	index build.

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

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

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

	      Changing maxIndexBuildMemoryUsageMegabytes does not affect an in
	      progress index build if it  has  already	started	 a  collection
	      scan.   However,	a  forced replica set reconfiguration restarts
	      the collection scan and uses the most current maxIndexBuildMemo-
	      ryUsageMegabytes provided.

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

       reportOpWriteConcernCountersInServerStatus

	      Default: false

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

		mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

       watchdogPeriodSeconds

	      Available	for mongod only.

	      Type: integer

	      Default: -1 (disabled)

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

		      The --dbpath directory

		      The journal directory inside the	--dbpath directory

		      The directory of	--logpath file

		      The directory of	--auditPath file

	      Valid values for watchdogPeriodSeconds are:

		      -1  (the	default), to disable/pause Storage Node	Watch-
		       dog, or

		      An integer greater than or equal	to 60.

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

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

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

		mongod --setParameter watchdogPeriodSeconds=60

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

	      Once enabled,

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

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

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

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

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

       tcmallocAggressiveMemoryDecommit

	      To  release  memory back to the operating	system,	consider using
	      tcmallocEnableBackgroundThread instead.

	      Type: integer (0 or 1 only)

	      Default: 0

	      If you enable tcmallocAggressiveMemoryDecommit, MongoDB:

		      releases	a chunk	of memory to system, and

		      attempts	to return all neighboring free chunks.

	      A	value of 1 enables  tcmallocAggressiveMemoryDecommit;  0  dis-
	      ables this parameter.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      If you enable this parameter, the	system will require new	memory
	      allocations for use. Consider enabling tcmallocAggressiveMemory-
	      Decommit	only  on memory-constrained systems and	after pursuing
	      other memory and performance options.

       tcmallocEnableBackgroundThread

	      Type: boolean

	      Default: true

	      If set to	true, tcmallocEnableBackgroundThread creates  a	 back-
	      ground  thread that periodically releases	memory back to the op-
	      erating system. The value	of tcmallocReleaseRate determines  the
	      rate,  in	 bytes	per second, at which the background thread re-
	      leases memory.

	      If tcmallocEnableBackgroundThread	is true	and  tcmallocReleaseR-
	      ate is 0,	MongoDB	still releases memory.

	      For  improved memory usage, we recommend using the default value
	      of true. To learn	more about  improvements  to  performance  and
	      memory management, see Upgraded TCMalloc.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      The following operation sets  tcmallocEnableBackgroundThread  to
	      false:

		mongod --setParameter "tcmallocEnableBackgroundThread=false"

       tcmallocReleaseRate

	      Default: 0

	      Specifies		the	   tcmalloc	   release	  rate
	      (https://github.com/google/tcmalloc/blob/master/docs/tuning.md)
	      in bytes per second. Release rate	refers to the  rate  at	 which
	      MongoDB  releases	 unused	 memory	 to the	system.	If tcmallocRe-
	      leaseRate	is set to 0 MongoDB doesn't release memory back	to the
	      system. Increase this value to return memory faster; decrease it
	      to return	memory slower.

	      If tcmallocEnableBackgroundThread	is true	and  tcmallocReleaseR-
	      ate is 0,	MongoDB	still releases memory.

	      Starting	in MongoDB 8.0,	the default value of tcmallocReleaseR-
	      ate is reduced to	0 due to a tcmalloc upgrade  that  prioritizes
	      CPU performance over memory release. Earlier versions of MongoDB
	      used  an	older  version of tcmalloc that	set the	default	tcmal-
	      locReleaseRate to	1 to balance memory release and	performance.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      To modify	the release rate during	run time, you can use the set-
	      Parameter	command; for example:

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

	      You can also set tcmallocReleaseRate at startup time; for	 exam-
	      ple:

		mongod --setParameter "tcmallocReleaseRate=5.0"

       fassertOnLockTimeoutForStepUpDown

	      Available	for both mongod	and mongos.

	      Default: 15 seconds

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example disables nodes from	fasserting:

		mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

   LOGGING PARAMETERS
       logLevel

	      Available	for both mongod	and mongos.

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

	      The default logLevel is 0	(Informational).

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets the logLevel to 2:

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

		      logComponentVerbosity

		      systemLog.verbosity

       logComponentVerbosity

	      Available	for both mongod	and mongos.

	      Sets the verbosity levels	of various  components	for  log  mes-
	      sages.  The  verbosity  level  determines	the amount of Informa-
	      tional and Debug messages	MongoDB	outputs.

	      The verbosity level can range from 0 to 5:

		      0 is the	MongoDB's default log verbosity	level, to  in-
		       clude Informational messages.

		      1  to  5	increases the verbosity	level to include Debug
		       messages.

	      For a component, you can also specify -1 to inherit the parent's
	      verbosity	level.

	      To specify the verbosity level, use a document  similar  to  the
	      following:

		{
		  verbosity: <int>,
		  <component1>:	{ verbosity: <int> },
		  <component2>:	{
		     verbosity:	<int>,
		     <component3>: { verbosity:	<int> }
		  },
		  ...
		}

	      For  the components, you can specify just	the <component>: <int>
	      in the document, unless you are setting  both  the  parent  ver-
	      bosity level and that of the child component(s) as well:

		{
		  verbosity: <int>,
		  <component1>:	<int> ,
		  <component2>:	{
		     verbosity:	<int>,
		     <component3>: <int>
		  }
		  ...
		}

	      The top-level verbosity field corresponds	to systemLog.verbosity
	      which  sets  the	default	 level for all components. The default
	      value of systemLog.verbosity is 0.

	      The components correspond	to the following settings:

		      accessControl

		      command

		      control

		      ftdc

		      geo

		      index

		      network

		      query

		      replication

		      replication.election

		      replication.heartbeats

		      replication.initialSync

		      replication.rollback

		      recovery

		      sharding

		      storage

		      storage.journal

		      transaction

		      write

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

		      storage.journal	components unless you specify the ver-
		       bosity level for	storage.journal.

		      storage.recovery	components unless you specify the ver-
		       bosity level for	storage.recovery.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

		db.adminCommand( {
		   setParameter: 1,
		   logComponentVerbosity: {
		      verbosity: 1,
		      query: { verbosity: 2 },
		      storage: {
			 verbosity: 2,
			 journal: {
			    verbosity: 1
			 }
		      }
		   }
		} )

	      You can also  set	 parameter  logComponentVerbosity  at  startup
	      time, passing the	verbosity level	document as a string.

		mongod --setParameter "logComponentVerbosity={command: 3}"

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

       maxLogSizeKB

	      Available	for both mongod	and mongos.

	      Type: non-negative integer

	      Default: 10

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

	      Truncated	attribute fields print field content up	to the maxLog-
	      SizeKB limit and excise field content past that limit, retaining
	      valid  JSON  formatting.	Log entries that contain truncated at-
	      tributes append a	truncated object to the	end of the log entry.

	      See log message truncation for more information.

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example sets the maximum log line size to 20 kilo-
	      bytes:

		mongod --setParameter maxLogSizeKB=20

       profileOperationResourceConsumptionMetrics

	      Available	for mongod only.

	      Type: boolean

	      Default: false

	      Flag  that  determines  whether operations collect resource con-
	      sumption metrics and report them in the slow query logs.	If you
	      enable profiling,	these metrics are also included.

	      If set to	true, running the explain command  returns  operation-
	      Metrics when the verbosity is executionStats or higher.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       quiet

	      Available	for both mongod	and mongos.

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

		      connection events;

		      the drop	command, the dropIndexes command, the validate
		       command;	and

		      replication synchronization activities.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

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

	      systemLog.quiet

       redactClientLogData

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Available	in MongoDB Enterprise only.

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

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

	      To enable	log redaction at startup, you can either:

		      Start mongod with the --redactClientLogData option:

			 mongod	--redactClientLogData

		      Set the security.redactClientLogData option in the con-
		       figuration file:

			 security:
			    redactClientLogData: true
			    ...

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

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

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

	      security.redactClientLogData

       redactEncryptedFields

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: true

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

		      If  the	redactClientLogData  parameter	or  the	 secu-
		       rity.redactClientLogData	setting	is set	to  false  and
		       redactEncryptedFields is	set to true (the default), en-
		       crypted fields are redacted from	all log	messages.

		      If   the	  redactClientLogData	parameter   or	 secu-
		       rity.redactClientLogData	setting	is set	to  true,  all
		       fields are redacted, regardless of the redactEncrypted-
		       Fields setting.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

       traceExceptions

	      Available	for both mongod	and mongos.

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

	      This parameter is	only available at runtime. To set the  parame-
	      ter, use the setParameter	command.

	      Consider the following example which sets	the traceExceptions to
	      true:

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

	      systemLog.traceAllExceptions

       suppressNoTLSPeerCertificateWarning

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: false

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      The following operation sets suppressNoTLSPeerCertificateWarning
	      to true:

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

       enableDetailedConnectionHealthMetricLogLines

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: true

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

		     

		          Log Message

		          Description

		     

		          Accepted TLS	connection from	peer

		          Indicates that the server successfully  parsed  the
			   peer	 certificate  during the TLS handshake with an
			   accepted ingress connection.

		     

		          Ingress TLS handshake complete

		          Indicates that the TLS handshake  with  an  ingress
			   connection is complete.

		     

		          Hello completed

		          Indicates  that  the	 initial  connection handshake
			   completed on	an incoming client connection.

			   MongoDB displays the	 log  message  only  with  the
			   first hello command.

		     

		          Auth	metrics	report

		          Specifies the completion of a step in the authenti-
			   cation conversation.

		     

		          Received  first command on ingress connection since
			   session start or auth handshake

		          Indicates that an ingress connection	 received  the
			   first command that is not part of the handshake.

		     

		          Slow	network	response send time

		          Indicates  that the time spent, in milliseconds, to
			   send	the  response  back  to	 the  client  over  an
			   ingress  connection	takes more time	than the dura-
			   tion	defined	by the slowMS server parameter.

		     

		          Completed client-side verification of OCSP request

		          If the peer doesn't include an  OCSP	 (Online  Cer-
			   tificate Status Protocol) response to the TLS hand-
			   shake when an egress	TLS connection is established,
			   the	server	must  send an OCSP request to the cer-
			   tificate authority. MongoDB writes this log message
			   when	the certificate	authority  receives  the  OCSP
			   response.

		     

		          Slow	connection establishment

		          Indicates  that  the	 time taken to send a response
			   back	to the client over an ingress connection takes
			   longer than the threshold specified with the	 slow-
			   ConnectionThresholdMillis  parameter.  MongoDB also
			   emits this log message when the  connection	estab-
			   lishment times out.

		     

		          Operation  timed  out while waiting to acquire con-
			   nection

		          Indicates that an operation timed out while waiting
			   to acquire an egress	connection.

		     

		          Acquired connection for remote operation  and  com-
			   pleted writing to wire

		          Indicates  that  the	server took one	millisecond or
			   longer to write an outgoing request	on  an	egress
			   connection, counting	from the instant when the con-
			   nection establishes.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

   DIAGNOSTIC PARAMETERS
       To  facilitate analysis of the MongoDB server behavior by MongoDB engi-
       neers, MongoDB logs server statistics to	diagnostic files  at  periodic
       intervals.

       For mongod, the diagnostic data files are stored	in the diagnostic.data
       directory under the mongod instance's --dbpath or storage.dbPath.

       For  mongos, the	diagnostic data	files, by default, are stored in a di-
       rectory under the mongos	instance's --logpath or	systemLog.path	direc-
       tory.  The diagnostic data directory is computed	by truncating the log-
       path's file extension(s)	and concatenating diagnostic.data to  the  re-
       maining name.

       For    example,	 if   mongos   has   --logpath	 /var/log/mongodb/mon-
       gos.log.201708015, then the diagnostic data directory is	 /var/log/mon-
       godb/mongos.diagnostic.data/ directory. To specify a different diagnos-
       tic data	directory for mongos, set the diagnosticDataCollectionDirecto-
       ryPath parameter.

       The following parameters	support	diagnostic data	capture	(FTDC):

       The  default  values  for  the diagnostic data capture interval and the
       maximum sizes are chosen	to provide useful data	to  MongoDB  engineers
       with  minimal  impact on	performance and	storage	size. Typically, these
       values will only	need modifications as requested	by  MongoDB  engineers
       for specific diagnostic purposes.

       diagnosticDataCollectionEnabled

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: true

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      For example, the following disables the diagnostic collection:

		mongod --setParameter diagnosticDataCollectionEnabled=false

       diagnosticDataCollectionDirectoryPath

	      Available	for mongos only.

	      Type: String

	      If Full Time Diagnostic Data Capture (FTDC) is disabled with di-
	      agnosticDataCollectionEnabled or if systemLog.destination	is set
	      to syslog, you must restart mongos after setting diagnosticData-
	      CollectionDirectoryPath.

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

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

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

       diagnosticDataCollectionDirectorySizeMB

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 200

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example, the following sets the maximum size of  the	direc-
	      tory to 250 megabytes:

		mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

       diagnosticDataCollectionFileSizeMB

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 10

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example, the following sets the maximum size of  each	 diag-
	      nostic file to 20	megabytes:

		mongod --setParameter diagnosticDataCollectionFileSizeMB=20

	      The  minimum  value  for diagnosticDataCollectionFileSizeMB is 1
	      megabyte.

       diagnosticDataCollectionPeriodMillis

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 1000

	      Specifies	the interval, in milliseconds, at which	to collect di-
	      agnostic data.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example, the following sets the interval to  5000  millisec-
	      onds or 5	seconds:

		mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

	      The  minimum  value  for diagnosticDataCollectionPeriodMillis is
	      100 milliseconds.

   REPLICATION AND CONSISTENCY
       disableSplitHorizonIPCheck

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: false

	      To   configure   cluster	 nodes	 for   split	horizon	   DNS
	      (https://en.wikipedia.org/wiki/Split-horizon_DNS),    use	  host
	      names instead of IP addresses.

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

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

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

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

	      To  allow	configuration changes using IP addresses, set disable-
	      SplitHorizonIPCheck=true using the command line:

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

		setParameter:
		   disableSplitHorizonIPCheck: true

       enableOverrideClusterChainingSetting

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: false

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter enableOverrideClusterChainingSetting=true

       logicalSessionRefreshMillis

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 300000 (5 minutes)

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter logicalSessionRefreshMillis=600000

       localLogicalSessionTimeoutMinutes

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 30

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

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter localLogicalSessionTimeoutMinutes=20

       maxAcceptableLogicalClockDriftSecs

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 31536000	(1 year)

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

       maxSessions

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 1000000

	      The maximum number of sessions that can be cached.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter maxSessions=1000

       oplogBatchDelayMillis

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 0

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

	      Increasing oplogBatchDelayMillis causes MongoDB to  apply	 oplog
	      batches less frequently on secondaries, with each	batch contain-
	      ing  larger amounts of data. This	reduces	IOPS (Input/Output Op-
	      erations Per Second) on secondaries, but adds latency for	writes
	      with write concern "majority".

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter oplogBatchDelayMillis=20

       periodicNoopIntervalSecs

	      Available	for mongod only.

	      Type: integer

	      Default: 10

	      The duration in seconds between noop writes on  each  individual
	      node.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      To modify	this  value  for  a  MongoDB  Atlas  (https://www.mon-
	      godb.com/docs/atlas/)  cluster,  you  must contact Atlas Support
	      (https://www.mongodb.com/docs/atlas/support/).

	      The following example sets  the  periodicNoopIntervalSecs	 to  1
	      second at	startup:

		mongod --setParameter periodicNoopIntervalSecs=1

       storeFindAndModifyImagesInSideCollection

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: true

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

	      If storeFindAndModifyImagesInSideCollection is:

		      true,  the  temporary  documents	are stored in the side
		       collection.

		      false,  the  temporary  documents  are  stored  in  the
		       replica set oplog.

	      Keep  storeFindAndModifyImagesInSideCollection  set  to  true if
	      you:

		      Have a large retryable findAndModify workload.

		      Require more temporary  document	 space	for  retryable
		       findAndModify commands than is available	in the replica
		       set oplog.

	      Secondaries  may	experience increased CPU usage when storeFind-
	      AndModifyImagesInSideCollection is true.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For example, to set storeFindAndModifyImagesInSideCollection  to
	      false during startup:

		mongod --setParameter storeFindAndModifyImagesInSideCollection=false

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       TransactionRecordMinimumLifetimeMinutes

	      Available	for mongod only.

	      Type: integer

	      Default: 30

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

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

		mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

	      localLogicalSessionTimeoutMinutes

       enableFlowControl

	      Type: boolean

	      Default: true

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

       flowControlTargetLagSeconds

	      Type: integer

	      Default: 10

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

	      The specified value must be greater than 0.

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       flowControlWarnThresholdSeconds

	      Type: integer

	      Default: 10

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       initialSyncTransientErrorRetryPeriodSeconds

	      Type: integer

	      Default: 86400

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

       initialSyncSourceReadPreference

	      Available	for mongod only.

	      Type: String

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

		      primary

		      primaryPreferred	 (Default  for voting replica set mem-
		       bers)

		      secondary

		      secondaryPreferred

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

	      If  the  replica set has disabled	chaining, the default initial-
	      SyncSourceReadPreference read preference mode is primary.

	      You cannot specify a tag set or maxStalenessSeconds to  initial-
	      SyncSourceReadPreference.

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       initialSyncMethod

	      Available	for mongod only.

	      Type: String

	      Default: logical

	      Available	only in	MongoDB	Enterprise.

	      Method used for initial sync.

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       maxNumSyncSourceChangesPerHour

	      Type: integer

	      Default: 3

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

       oplogFetcherUsesExhaust

	      Available	for mongod only.

	      Type: boolean

	      Default: true

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

       oplogInitialFindMaxSeconds

	      Available	for mongod only.

	      Type: integer

	      Default: 60

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       replWriterThreadCount

	      Available	for mongod only.

	      Type: integer

	      Default: 16

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      replWriterMinThreadCount

       replWriterMinThreadCount

	      Available	for mongod only.

	      Type: integer

	      Default: 0

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

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

       rollbackTimeLimitSecs

	      Type: 64-bit integer

	      Default: 86400  (1 day)

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

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

       waitForSecondaryBeforeNoopWriteMS

	      Available	for mongod only.

	      Type: integer

	      Default: 10

	      The length of time (in milliseconds) that	a secondary must  wait
	      if  the  afterClusterTime	 is greater than the last applied time
	      from  the	 oplog.	 After	the  waitForSecondaryBeforeNoopWriteMS
	      passes,  if  the afterClusterTime	is still greater than the last
	      applied time, the	secondary makes	a no-op	write to  advance  the
	      last applied time.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example sets the waitForSecondaryBeforeNoopWriteMS
	      to 20 milliseconds:

		mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       createRollbackDataFiles

	      Available	for mongod only.

	      Type: boolean

	      Default: true

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter createRollbackDataFiles=false

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

	      For more information, see	Collect	Rollback Data.

       replBatchLimitBytes

	      Default: 104857600 (100MB)

	      Sets the maximum oplog application batch size in bytes.

	      Values  can  range from 16777216 (16MB) to 104857600 (100MB) in-
	      clusive.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets replBatchLimitBytes to	64 MB to limit
	      the oplog	application batch size:

		mongod --setParameter replBatchLimitBytes=67108864

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       mirrorReads

	      Available	for mongod only.

	      Type: Document

	      Default: { samplingRate: 0.01, maxTimeMS:	1000 }

	      Specifies	 the  settings	for  mirrored reads for	the mongod in-
	      stance. The settings only	take effect when the member is a  pri-
	      mary.

	      The parameter mirrorReads	takes a	JSON document with the follow-
	      ing fields:

		     

		          Field

		          Description

		     

		          samplingRate

		          The sampling	rate used to mirror a subset of	opera-
			   tions  that	support	mirroring to a subset of elec-
			   table (specifically,	 priority greater than 0) sec-
			   ondaries. That is, the  primary  mirrors  reads  to
			   each	 electable secondary at	the specified sampling
			   rate.

			   Valid values	are:

			   

				 	 0.0

				 	 Turns off mirroring.

			   

				 	 1.0

				 	 The primary  mirrors  all  operations
					 that supports mirroring to each elec-
					 table secondary.

			   

				 	 Number	 between  0.0  and 1.0 (exclu-
					 sive)

				 	 The  primary  randomly	 samples  each
					 electable  secondary at the specified
					 rate to be sent mirrored reads.

			   For example,	given a	replica	set with a primary and
			   two electable secondaries and a  sampling  rate  of
			   0.10,  the  primary mirrors reads to	each electable
			   secondary at	the sampling rate of 10	 percent  such
			   that	 one read may be mirrored to one secondary and
			   not to the other or to both or to neither. That is,
			   if the primary receives 100 operations that can  be
			   mirrored, the sampling rate of 0.10 may result in 8
			   reads  being	mirrored to one	secondary and 13 reads
			   to the other	or 10 to each, etc.

			   The default value is	0.01.

		     

		          maxTimeMS

		          The maximum time in milliseconds for	 the  mirrored
			   reads. The default value is 1000.

			   The	maxTimeMS  for	the mirrored reads is separate
			   from	the maxTimeMS of the original read being  mir-
			   rored.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      If  you  specify	from  the configuration	file or	on the command
	      line, enclose the	mirrorReads document in	quotes.

	      For example, the following sets the mirror reads	sampling  rate
	      to 0.10 from the command line:

		mongod --setParameter mirrorReads='{ samplingRate: 0.10	}'

	      Or, to specify in	a configuration	file:

		setParameter:
		   mirrorReads:	'{samplingRate:	0.10}'

	      Or  if  using the	setParameter command in	a mongosh session that
	      is connected to a	running	mongod,	do not enclose the document in
	      quotes:

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

       allowMultipleArbiters

	      Available	for mongod only.

	      Type: boolean

	      Default: false

	      Specifies	whether	the replica set	allows the use of multiple ar-
	      biters.

	      The use of multiple arbiters is not recommended:

		      Multiple	arbiters prevent the reliable use of  the  ma-
		       jority  write concern.  MongoDB counts arbiters in cal-
		       culating	a membership majority,	but  arbiters  do  not
		       store  data.  With  the inclusion of multiple arbiters,
		       it's possible for a majority write operation to	return
		       success	before	the  write replicates to a majority of
		       data bearing nodes.

		      Multiple	arbiters allow replica sets to	accept	writes
		       even  when the replica set doesn't have sufficient sec-
		       ondaries	for data replication.

	      For more information, see	Concerns with Multiple Arbiters.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

		mongod --setParameter allowMultipleArbiters=true

   SHARDING PARAMETERS
       analyzeShardKeyCharacteristicsDefaultSampleSize

	      Available	for mongod only.

	      Type: integer

	      Default: 10000000

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      This  example  sets analyzeShardKeyCharacteristicsDefaultSample-
	      Size to 10000 at startup:

		mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

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

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

       analyzeShardKeyNumMostCommonValues

	      Available	for mongod only.

	      Type: integer

	      Default: 5

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      This example sets	 analyzeShardKeyNumMostCommonValues  to	 3  at
	      startup:

		mongod --setParameter analyzeShardKeyNumMostCommonValues=3

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

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

       analyzeShardKeyNumRanges

	      Available	for mongod only.

	      Type: integer

	      Default: 100

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      This example sets	analyzeShardKeyNumRanges to 50 at startup:

		mongod --setParameter analyzeShardKeyNumRanges=50

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

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

       analyzeShardKeyMonotonicityCorrelationCoefficientThreshold

	      Available	for mongod only.

	      Type: double

	      Default: 0.7

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      This example sets	 analyzeShardKeyMonotonicityCorrelationCoeffi-
	      cientThreshold to	1 at startup:

		mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1

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

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

       autoMergerIntervalSecs

	      Available	for mongod only.

	      Type: integer

	      Default: 3600

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

	      autoMergerIntervalSecs can only be set on	config servers.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter autoMergerIntervalSecs=7200

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

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

       autoMergerThrottlingMS

	      Available	for mongod only.

	      Type: integer

	      Default: 15000

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

	      autoMergerThrottlingMS can only be set on	config servers.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

		mongod --setParameter autoMergerThrottlingMS=60000

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

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

       balancerMigrationsThrottlingMs

	      Available	for mongod only.

	      Type: integer

	      Default: 1000

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      This example sets	balancerMigrationsThrottlingMs	to  2000  mil-
	      liseconds	at startup:

		mongod --setParameter balancerMigrationsThrottlingMs=2000

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       chunkDefragmentationThrottlingMS

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 0

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The  following  example sets chunkDefragmentationThrottlingMS to
	      10 milliseconds:

		mongod --setParameter chunkDefragmentationThrottlingMS=10

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       chunkMigrationConcurrency

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

	      Available	for mongod only.

	      Type: integer

	      Default: 1

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

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

	      Maximum value is 500.

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example sets chunkMigrationConcurrency to 5:

		mongod --setParameter chunkMigrationConcurrency=5

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

	      To configure collection balancing,  see  configureCollectionBal-
	      ancing.

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

       disableResumableRangeDeleter

	      Available	for mongod only.

	      Type: boolean

	      Default: false

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

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

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		mongod --setParameter disableResumableRangeDeleter=false

       enableShardedIndexConsistencyCheck

	      Available	for mongod only.

	      Type: boolean

	      Default: true

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter enableShardedIndexConsistencyCheck=false

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

		      shardedIndexConsistencyCheckIntervalMS parameter

		      shardedIndexConsistency metrics returned	by the server-
		       Status command.

       opportunisticSecondaryTargeting

	      Available	for mongos only.

	      Type: boolean

	      Default: false

	      Determines whether mongos	performs opportunistic	reads  against
	      replica sets.

	      When  this  parameter  is	 set to	true, mongos directs secondary
	      reads to secondaries with	active connections. It sends  the  re-
	      quest  to	 the first secondary that accepts the connection. When
	      this parameter is	set to false, mongos holds secondary reads un-
	      til it can establish a connection	to a specific secondary,  (ex-
	      cept in the case of hedged reads).

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      For   example,  to  set  opportunisticSecondaryTargeting	during
	      startup:

		mongos --setParameter opportunisticSecondaryTargeting=true

       shardedIndexConsistencyCheckIntervalMS

	      Available	for mongod only.

	      Type: integer

	      Default: 600000

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      For example, the following sets the interval at 300000 millisec-
	      onds (5 minutes) at startup:

		mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

		      enableShardedIndexConsistencyCheck parameter

		      shardedIndexConsistency metrics returned	by the server-
		       Status commandq

       enableFinerGrainedCatalogCacheRefresh

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: true

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

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

		      Sharding

		      shardingStatistics.catalogCache

       maxTimeMSForHedgedReads

	      Starting in MongoDB 8.0, hedged reads  are  deprecated.  Queries
	      that  specify  the  read preference nearest no longer use	hedged
	      reads by default.	If you explicitly specify a hedged read,  Mon-
	      goDB performs a hedged read and logs a warning.

	      Available	for mongos only.

	      Type: integer

	      Default: 150

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongos --setParameter maxTimeMSForHedgedReads=200

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

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

		      readHedgingMode

		      Hedged Reads

       maxCatchUpPercentageBeforeBlockingWrites

	      Available	for mongod only.

	      Type: integer

	      Default: 10

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

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      Starting	in  MongoDB 7.1	(and 7.0.1), you can set the parameter
	      during runtime.

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

		mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

	      Starting	in  MongoDB 7.1	(and 7.0.1), you can set the parameter
	      during runtime with the setParameter command:

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

	      Live	Migration      Protocol	      (https://github.com/mon-
	      godb/mongo/blob/master/src/mongo/db/s/README.md#the-live-migra-
	      tion-protocol)

       metadataRefreshInTransactionMaxWaitBehindCritSecMS

	      Available	for mongod only.

	      Type: integer

	      Default: 500

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

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

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

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      For  example,  to	set metadataRefreshInTransactionMaxWaitBehind-
	      CritSecMS	to 400 milliseconds:

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

       queryAnalysisSamplerConfigurationRefreshSecs

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 10

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

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

	      We recommend using the default value.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      Starting	in MongoDB 7.0.1, you can set queryAnalysisSamplerCon-
	      figurationRefreshSecs during run time.

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

		mongod --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

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

		mongos --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

	      To set the value to 30 seconds, run the following:

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

       queryAnalysisWriterIntervalSecs

	      Available	for mongod only.

	      Type: integer

	      Default: 90

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      Starting in MongoDB 7.0.1, you can set queryAnalysisWriterInter-
	      valSecs during run time.

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

		mongod --setParameter queryAnalysisWriterIntervalSecs=60
		To set the value to 60 seconds,	run the	following:

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

       queryAnalysisWriterMaxMemoryUsageBytes

	      Available	for mongod only.

	      Type: integer

	      Default: 100 * 1024 * 1024

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

		mongod --setParameter queryAnalysisWriterMaxMemoryUsageBytes=10000000

       queryAnalysisWriterMaxBatchSize

	      Available	for mongod only.

	      Type: integer

	      Default: 100000

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter queryAnalysisWriterMaxBatchSize=1000

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       queryAnalysisSampleExpirationSecs

	      Available	for mongod only.

	      Type: integer

	      Default: 7 * 24 *	3600

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter queryAnalysisSampleExpirationSecs=691200

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       readHedgingMode

	      Available	for mongos only.

	      Type: string

	      Default: on

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

	      Available	values are:

		     

		          Value

		          Description

		     

		          on

		          The mongos instance supports	hedged reads for  read
			   operations  whose  read preference have enabled the
			   hedged read option.

		     

		          off

		          The mongos instance does not	support	hedged	reads.
			   That	 is,  hedged  reads  are unavailable, even for
			   read	operations whose read preference have  enabled
			   the hedged read option.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongos --setParameter readHedgingMode=off

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

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

		      Hedged Reads

		      maxTimeMSForHedgedReads

       routingTableCacheChunkBucketSize

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 500

	      Specifies	 the  size  of the routing table cache buckets used to
	      implement	chunk grouping optimization. Must be greater than 0.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      For example, to set the cache chunk bucket size to 250 on	a mon-
	      god, issue the following command at startup:

		mongod --setParameter routingTableCacheChunkBucketSize=250

       shutdownTimeoutMillisForSignaledShutdown

	      Available	for mongod only.

	      Type: integer

	      Default: 15000

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

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

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

       mongosShutdownTimeoutMillisForSignaledShutdown

	      Available	for mongos only.

	      Type: integer

	      Default: 15000

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

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

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

       ShardingTaskExecutorPoolHostTimeoutMS

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 300000 (5 minutes)

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example sets ShardingTaskExecutorPoolHostTimeoutMS
	      to 120000	during startup:

		mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolMaxConnecting

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 2

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets ShardingTaskExecutorPoolMaxConnecting
	      to 20 during startup:

		mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolMaxSize

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 2 64 - 1

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

		ShardingTaskExecutorPoolMaxSize	* taskExecutorPoolSize

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following example sets ShardingTaskExecutorPoolMaxSize to 20
	      during startup:

		mongos --setParameter ShardingTaskExecutorPoolMaxSize=20

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

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

	      ShardingTaskExecutorPoolMinSize

       ShardingTaskExecutorPoolMaxSizeForConfigServers

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: -1

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

	      When set to:

		      -1,  ShardingTaskExecutorPoolMaxSize  is	 used. This is
		       the default.

		      an integer value	greater	than -1, overrides the maximum
		       number of outbound connections each  TaskExecutor  con-
		       nection pool can	open to	a configuration	server.

	      Parameter	only applies to	sharded	deployments.

	      The  following example sets ShardingTaskExecutorPoolMaxSize to 2
	      during startup, which sets the maximum number of	outbound  con-
	      nections each TaskExecutor connection pool can open to a config-
	      uration server to	2:

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

		mongos --setParameter ShardingTaskExecutorPoolMaxSizeForConfigServers=2

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolMinSize

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 1

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

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

	      For a mongos using the warmMinConnectionsInShardingTaskExecutor-
	      PoolOnStartup parameter, the ShardingTaskExecutorPoolMinSize pa-
	      rameter  also  controls  how many	connections to each shard host
	      are established on startup of the	mongos instance	before it  be-
	      gins accepting incoming client connections.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The  following example sets ShardingTaskExecutorPoolMinSize to 2
	      during startup:

		mongos --setParameter ShardingTaskExecutorPoolMinSize=2

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

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

		      ShardingTaskExecutorPoolMaxSize

		      warmMinConnectionsInShardingTaskExecutorPoolOnStartup

       ShardingTaskExecutorPoolMinSizeForConfigServers

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: -1

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

	      When set to:

		      -1, ShardingTaskExecutorPoolMinSize is  used.  This  is
		       the default.

		      an integer value	greater	than -1, overrides the minimum
		       number  of  outbound connections	each TaskExecutor con-
		       nection pool can	open to	a configuration	server.

	      Parameter	only applies to	sharded	deployments.

	      The following example sets ShardingTaskExecutorPoolMinSize to  2
	      during  startup,	which sets the minimum number of outbound con-
	      nections each TaskExecutor connection pool can open to a config-
	      uration server to	2:

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

		mongos --setParameter ShardingTaskExecutorPoolMinSizeForConfigServers=2

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolRefreshRequirementMS

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 60000 (1	minute)

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

	      If set, ShardingTaskExecutorPoolRefreshRequirementMS  should  be
	      greater  than  ShardingTaskExecutorPoolRefreshTimeoutMS.	Other-
	      wise, mongos adjusts the	value  of  ShardingTaskExecutorPoolRe-
	      freshTimeoutMS   to  be  less  than  ShardingTaskExecutorPoolRe-
	      freshRequirementMS.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following  example  sets  ShardingTaskExecutorPoolRefreshRe-
	      quirementMS to 90000 during startup:

		mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolRefreshTimeoutMS

	      Available	for both mongod	and mongos.

	      Type: integer

	      Default: 20000 (20 seconds)

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

	      If  set, ShardingTaskExecutorPoolRefreshTimeoutMS	should be less
	      than  ShardingTaskExecutorPoolRefreshRequirementMS.   Otherwise,
	      mongos adjusts the value of ShardingTaskExecutorPoolRefreshTime-
	      outMS  to	 be  less than ShardingTaskExecutorPoolRefreshRequire-
	      mentMS.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets  ShardingTaskExecutorPoolRefreshTime-
	      outMS to 30000 during startup:

		mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

	      During  run time,	you can	also set the parameter with the	setPa-
	      rameter command:

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

       ShardingTaskExecutorPoolReplicaSetMatching

	      Available	for both mongod	and mongos.

	      Type: string

	      Default: "automatic"

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

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

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

	      Available	values are:

		     

		          Matching Policy

		          Description

		     

		          "automatic" (Default)

		          Starting in 5.0, "automatic"	 is  the  new  default
			   value.

			   When	set for	a mongos, the instance follows the be-
			   havior specified for	the "matchPrimaryNode" option.

			   When	set for	a mongod, the instance follows the be-
			   havior specified for	the "disabled" option.

			   If  the  ShardingTaskExecutorPoolReplicaSetMatching
			   is set to "automatic", the replicaSetMatchingStrat-
			   egy still describes the actual policy  being	 used,
			   not "automatic". To find the	value of the Sharding-
			   TaskExecutorPoolReplicaSetMatching,	use getParame-
			   ter which returns the value of the  server  parame-
			   ter.

		     

		          "matchPrimaryNode"

		          When	 set  for  a mongos, the minimum size limit of
			   the instance's connection pool to each secondary of
			   a replica set in the	sharded	cluster	(specifically,
			   shard replica set and config	servers) is  equal  to
			   the	size  of  its  connection pool to that replica
			   set's primary.

			   When	set for	a mongod, the minimum  size  limit  of
			   the instance's connection pool to each secondary of
			   another replica set in the sharded cluster (specif-
			   ically,  shard  replica  set	and config servers) is
			   equal to the	size of	its connection	pool  to  that
			   replica set's primary.

			   If  multiple	shard servers in your topology can ex-
			   perience a rapid influx of cross-shard  operations,
			   do not set this option on your mongod instances.

			   In case of a	primary	stepdown, matchPrimaryNode en-
			   sures  that	any secondary that becomes the primary
			   can handle the current level	of primary  reads  and
			   writes.

		     

		          "matchBusiestNode"

		          When	 set for a mongos, the instance's minimum size
			   limit of the	connection pool	to each	 member	 of  a
			   replica  set	 in the	sharded	cluster	(specifically,
			   shard replica set and config	servers) is  equal  to
			   the	largest	 among the active connection counts to
			   the primary	and  each  secondary  member  of  that
			   replica set.

			   When	 set for a mongod, the instance's minimum size
			   limit of the	connection pool	to each	member of  an-
			   other  replica set in the sharded cluster (specifi-
			   cally, shard	replica	set  and  config  servers)  is
			   equal  to  the  largest among the active connection
			   counts to the primary and each secondary member  of
			   that	replica	set.

			   With	 "matchBusiestNode",  mongos  maintains	enough
			   connections to each secondary to handle the current
			   level of primary and	secondary  reads  and  writes.
			   The	number	of connections to maintain in the pool
			   decreases as	the number of active  connections  de-
			   creases.

		     

		          "disabled"

		          When	 set for a mongos, the instance's minimum num-
			   ber of connections  in  the	instance's  connection
			   pool	 to  each node of a replica set	in the sharded
			   clusterv (specifically, shard replica set and  con-
			   fig	servers) is equal to the ShardingTaskExecutor-
			   PoolMinSize.

			   When	set for	a mongod, the instance's minimum  num-
			   ber	of  connections	 in  the instance's connection
			   pool	to each	node of	another	 replica  set  in  the
			   sharded  cluster  (specifically,  shard replica set
			   and config servers) is equal	to the ShardingTaskEx-
			   ecutorPoolMinSize.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets the ShardingTaskExecutorPoolReplicaS-
	      etMatching to "automatic"	during startup:

		mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       taskExecutorPoolSize

	      Available	for mongos only.

	      Type: integer

	      Default: 1

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

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

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

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

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

	      The default value	of taskExecutorPoolSize	is 1:

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

		mongos --setParameter taskExecutorPoolSize=6

		      ShardingTaskExecutorPoolMaxSize

		      ShardingTaskExecutorPoolMinSize

       loadRoutingTableOnStartup

	      Available	for mongos only.

	      Type: boolean

	      Default: true

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

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

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

	      loadRoutingTableOnStartup	is enabled by default.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       warmMinConnectionsInShardingTaskExecutorPoolOnStartup

	      Available	for mongos only.

	      Type: boolean

	      Default: true

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

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

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

	      warmMinConnectionsInShardingTaskExecutorPoolOnStartup is enabled
	      by default.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		      warmMinConnectionsInShardingTaskExecutorPoolOnStartup-
		       WaitMS

		      ShardingTaskExecutorPoolMinSize

       warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

	      Available	for mongos only.

	      Type: integer

	      Default: 2000 (2 seconds)

	      Sets the timeout threshold in milliseconds for a mongos to  wait
	      for  ShardingTaskExecutorPoolMinSize  connections	 to  be	estab-
	      lished per shard host when using the  warmMinConnectionsInShard-
	      ingTaskExecutorPoolOnStartup   parameter.	 If  this  timeout  is
	      reached, the mongos will begin accepting client connections  re-
	      gardless of the size of its connection pool.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		      warmMinConnectionsInShardingTaskExecutorPoolOnStartup

		      ShardingTaskExecutorPoolMinSize

       migrateCloneInsertionBatchDelayMS

	      Available	for mongod only.

	      Type: Non-negative integer

	      Default: 0

	      Time in milliseconds to wait between batches of insertions  dur-
	      ing cloning step of the migration	process. This wait is in addi-
	      tion to the secondaryThrottle.

	      The default value	of 0 indicates no additional wait.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The  following sets the migrateCloneInsertionBatchDelayMS	to 200
	      milliseconds:

		mongod --setParameter migrateCloneInsertionBatchDelayMS=200

	      The parameter may	also be	set using the setParameter command:

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

       migrateCloneInsertionBatchSize

	      Available	for mongod only.

	      Type: Non-negative integer

	      Default: 0

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following sets  the  migrateCloneInsertionBatchSize  to  100
	      documents:

		mongod --setParameter migrateCloneInsertionBatchSize=100

	      The parameter may	also be	set using the setParameter command:

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

       orphanCleanupDelaySecs

	      Available	for mongod only.

	      Default: 900 (15 minutes)

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

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

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

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following sets the orphanCleanupDelaySecs to 20 minutes:

		mongod --setParameter orphanCleanupDelaySecs=1200

	      This may also be set using the setParameter command:

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

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

       persistedChunkCacheUpdateMaxBatchSize

	      Available	for mongod only.

	      Type: Integer

	      Default: 1000

	      To route and serve operations, shards must know the routing  and
	      ownership	 information  associated  with their collections. This
	      information propogates from a shard's primary node to  its  sec-
	      ondary  nodes through the	replication of the internal cache col-
	      lections config.cache.collections	and  config.cache.chunks.<col-
	      lectionName>.

	      In previous versions, updates on the chunk cache collection were
	      performed	 individually (meaning that an entry was deleted and a
	      new entry	was inserted). Starting	in MongoDB 7.2,	these  updates
	      are performed as a batch of deletions followed by	a batch	of in-
	      sertions.	  The  updated	logic improves performance for collec-
	      tions that contain a large number	of chunks.

	      The  persistedChunkCacheUpdateMaxBatchSize  parameter  specifies
	      the  maximum  batch  size	 used for updating the persisted chunk
	      cache.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets persistedChunkCacheUpdateMaxBatchSize
	      to 700 at	startup:

		mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

	      You can also  set	 persistedChunkCacheUpdateMaxBatchSize	during
	      runtime:

		db.adminCommand( { setParameter: 1, persistedChunkCacheUpdateMaxBatchSize: 700 } )

       rangeDeleterBatchDelayMS

	      Available	for mongod only.

	      Type: Non-negative integer

	      Default: 20

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

	      The _secondaryThrottle replication delay occurs after each batch
	      deletion.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following sets the rangeDeleterBatchDelayMS to 200 millisec-
	      onds:

		mongod --setParameter rangeDeleterBatchDelayMS=200

	      The parameter may	also be	set using the setParameter command:

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

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

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

       rangeDeleterBatchSize

	      Available	for mongod only.

	      Type: Non-negative integer

	      Default: 2147483647 starting in MongoDB 5.1.2 and	5.0.6

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

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets  rangeDeleterBatchSize	 to  32	 docu-
	      ments:

		mongod --setParameter rangeDeleterBatchSize=32

	      The parameter may	also be	set using the setParameter command:

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

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

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

       rangeDeleterHighPriority

	      Available	for mongod only.

	      Type: boolean

	      Default: false

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The following example sets rangeDeleterHighPriority to true:

		mongod --setParameter rangeDeleterHighPriority=true

	      The parameter may	also be	set using the setParameter command:

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

       skipShardingConfigurationChecks

	      Available	for mongod only.

	      Type: boolean

	      Default: false

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

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

		mongod --setParameter skipShardingConfigurationChecks=true

	      Once  maintenance	has completed, remove the skipShardingConfigu-
	      rationChecks parameter when restarting the mongod.

       findChunksOnConfigTimeoutMS

	      Available	for both mongod	and mongos.

	      Type: Non-negative integer

	      Default: 900000

	      The timeout in milliseconds for find operations on chunks.

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

		mongod --setParameter findChunksOnConfigTimeoutMS=1000000

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

   HEALTH MANAGER PARAMETERS
       activeFaultDurationSecs

	      Available	for mongos only.

	      Type: Document

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

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		mongos --setParameter activeFaultDurationSecs=300

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

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

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

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

		setParameter:
		   activeFaultDurationSecs: 300

       healthMonitoringIntensities

	      Available	for mongos only.

	      Type: Array of documents

	      Use this parameter to set	intensity levels for Health Managers.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

		      type, the Health	Manager	facet

		      intensity, the intensity	level

   HEALTH MANAGERS
	      

		   Facet

		   What the Health Observer Checks

	      

		   configServer

		   Cluster health issues related to connectivity to the  con-
		    fig	server.

	      

		   dns

		   Cluster  health  issues  related  to  DNS availability and
		    functionality.

	      

		   ldap

		   Cluster health issues related  to  LDAP  availability  and
		    functionality.

   INTENSITY LEVELS
	      

		   Intensity Level

		   Description

	      

		   critical

		   The	 Health	 Manager  on this facet	is enabled and has the
		    ability to move the	failing	mongos out of the  cluster  if
		    an	error  occurs.	The Health Manager waits the amount of
		    time specified by activeFaultDurationSecs before  stopping
		    and	moving the mongos out of the cluster automatically.

	      

		   non-critical

		   The	 Health	 Manager on this facet is enabled and logs er-
		    rors, but the mongos remains in the	cluster	if errors  are
		    encountered.

	      

		   off

		   The	 Health	 Manager on this facet is disabled. The	mongos
		    does not perform any health	checks on this facet. This  is
		    the	default	intensity level.

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

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

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

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

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

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

	 setParameter:
	    healthMonitoringIntensities: "{ values:[ { type:

       healthMonitoringIntervals

	      Available	for mongos only.

	      Type: Array of documents

	      How often	this Health Manager will run, in milliseconds.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

		      type, the Health	Manager	facet

		      interval, the time interval it runs at, in milliseconds

   HEALTH MANAGERS
	      

		   Facet

		   What the Health Observer Checks

	      

		   configServer

		   Cluster health issues related to connectivity to the  con-
		    fig	server.

	      

		   dns

		   Cluster  health  issues  related  to  DNS availability and
		    functionality.

	      

		   ldap

		   Cluster health issues related  to  LDAP  availability  and
		    functionality.

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

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

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

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

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

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

	 setParameter:
	    healthMonitoringIntervals: "{ values: [{type:

       progressMonitor

	      Available	for mongos only.

	      Type: Document

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

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

   PROGRESSMONITOR FIELDS
	      

		   Field

		   Description

		   Units

	      

		   interval

		   How	often to ensure	Health Managers	are not	stuck or unre-
		    sponsive.

		   Milliseconds

	      

		   deadline

		   Timeout before  automatically  failing  the	 mongos	 if  a
		    Health Manager check is not	making progress.

		   Seconds

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

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

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

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

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

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

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

   STORAGE PARAMETERS
       honorSystemUmask

	      Available	for mongod only.

	      Default: false

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

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

		mongod --setParameter honorSystemUmask=true

	      honorSystemUmask is not available	on Windows systems.

       journalCommitInterval

	      Available	for mongod only.

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      Consider	the  following example which sets the journalCommitIn-
	      terval to	200 ms:

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

	      storage.journal.commitIntervalMs

       minSnapshotHistoryWindowInSeconds

	      Available	for mongod only.

	      Default: 300

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

	      Consider	the following example which sets the minSnapshotHisto-
	      ryWindowInSeconds	to 600 seconds:

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

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

	      To modify	this  value  for  a  MongoDB  Atlas  (https://www.mon-
	      godb.com/docs/atlas/)  cluster,  you  must contact Atlas Support
	      (https://www.mongodb.com/docs/atlas/support/).

       processUmask

	      Available	for mongod only.

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

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      You cannot set this parameter  if	 honorSystemUmask  is  set  to
	      true.

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

		mongod --setParameter processUmask=011

	      processUmask is not available on Windows systems.

       storageEngineConcurrentReadTransactions

	      Available	for mongod only.

	      Type: integer

	      Default: 128

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

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

	      If you use the default value, MongoDB  dynamically  adjusts  the
	      number of	tickets	to optimize performance, with a	highest	possi-
	      ble value	of 128.

	      Starting in MongoDB 7.0, if you set storageEngineConcurrentRead-
	      Transactions  to	a  non-default value, it disables an algorithm
	      that dynamically adjusts the number of concurrent	storage	engine
	      transactions.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

		db.adminCommand( { setParameter: 1, storageEngineConcurrentReadTransactions: <int> } )

	      The wiredTigerConcurrentReadTransactions parameter  was  renamed
	      to storageEngineConcurrentReadTransactions.

	      wiredTiger.concurrentTransactions

       storageEngineConcurrentWriteTransactions

	      Available	for mongod only.

	      Type: integer

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

	      Specify  the maximum number of concurrent	write transactions al-
	      lowed into the WiredTiger	storage	engine.

	      By default,  MongoDB  sets  storageEngineConcurrentWriteTransac-
	      tions to whichever value is higher:

		      Number of cores on the machine running MongoDB

		      4

	      If  you  use  the	default	value, MongoDB dynamically adjusts the
	      number of	tickets	to optimize performance, with a	highest	possi-
	      ble value	of 128.

	      Starting in MongoDB  7.0,	 if  you  set  storageEngineConcurren-
	      tWriteTransactions  to a non-default value, it disables an algo-
	      rithm that dynamically adjusts the number	of concurrent  storage
	      engine transactions.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

		db.adminCommand( { setParameter: 1, storageEngineConcurrentWriteTransactions: <int> } )

	      The  wiredTigerConcurrentWriteTransactions parameter was renamed
	      to storageEngineConcurrentWriteTransactions.

	      wiredTiger.concurrentTransactions

       syncdelay

	      Available	for mongod only.

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

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

	      To provide durable data, WiredTiger uses checkpoints.  For  more
	      details, see Journaling and the WiredTiger Storage Engine.

		      journalCommitInterval

		      storage.syncPeriodSecs

       temporarilyUnavailableBackoffBaseMs

	      Available	for mongod only.

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

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

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

	      Adjust the write retry properties	by modifying the temporarilyU-
	      navailableBackoffBaseMs and temporarilyUnavailableMaxRetries pa-
	      rameters.

	      The parameter accepts:

		     

		          Value

		          Description

		     

		          integer >= 0

		          Defaults to 1 second. The initial delay between re-
			   tries.  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  be-
			   fore	the next retry.

			   To  configure  number of retries, use temporarilyU-
			   navailableMaxRetries.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

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

       temporarilyUnavailableMaxRetries

	      Available	for mongod only.

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

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

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

	      Adjust the write retry properties	by modifying the temporarilyU-
	      navailableBackoffBaseMs and temporarilyUnavailableMaxRetries pa-
	      rameters.

	      The parameter accepts:

		     

		          Value

		          Description

		     

		          integer >= 0

		          Defaults to 10. The maximum number of retries.

			   There is an increasing delay	 between  retries.  To
			   configure the backoff time, use temporarilyUnavail-
			   ableBackoffBaseMs.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

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

   WIREDTIGER PARAMETERS
       wiredTigerConcurrentReadTransactions

	      Available	for mongod only.

	      Type: integer

	      Default: 128

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

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

	      If  you  use  the	default	value, MongoDB dynamically adjusts the
	      number of	tickets	to optimize performance, with a	highest	possi-
	      ble value	of 128.

	      Starting in MongoDB 7.0, if  you	set  wiredTigerConcurrentRead-
	      Transactions  to	a  non-default value, it disables an algorithm
	      that dynamically adjusts the number of concurrent	storage	engine
	      transactions.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

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

	      wiredTiger.concurrentTransactions

       wiredTigerConcurrentWriteTransactions

	      Available	for mongod only.

	      Type: integer

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

	      Specify the maximum number of concurrent write transactions  al-
	      lowed into the WiredTiger	storage	engine.

	      By  default,  MongoDB sets wiredTigerConcurrentWriteTransactions
	      to whichever value is higher:

		      Number of cores on the machine running MongoDB

		      4

	      If you use the default value, MongoDB  dynamically  adjusts  the
	      number of	tickets	to optimize performance, with a	highest	possi-
	      ble value	of 128.

	      Starting	in  MongoDB 7.0, if you	set wiredTigerConcurrentWrite-
	      Transactions to a	non-default value, it  disables	 an  algorithm
	      that dynamically adjusts the number of concurrent	storage	engine
	      transactions.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

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

	      wiredTiger.concurrentTransactions

       wiredTigerEngineRuntimeConfig

	      Available	for mongod only.

	      Specify  wiredTiger  storage  engine configuration options for a
	      running mongod instance.

	      This parameter is	only available at runtime. To set the  parame-
	      ter, use the setParameter	command.

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

	      Consider the following operation prototype:

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

       wiredTigerFileHandleCloseIdleTime

	      Available	for mongod only.

	      Type: integer

	      Default: 600

	      Specifies	 the  amount  of time in seconds that a	file handle in
	      wiredTiger can remain idle before	being closed.

	      If you set wiredTigerFileHandleCloseIdleTime to 0, idle  handles
	      are not closed.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      For example:

		mongod --setParameter wiredTigerFileHandleCloseIdleTime=100000

       See the WiredTiger documentation	for all	available WiredTiger  configu-
       ration		 options	    (http://source.wiredtiger.com/mon-
       godb-5.0/struct_w_t___c_o_n_n_e_c_t_i_o_n.html#).

   AUDITING PARAMETERS
       auditAuthorizationSuccess

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: false

	      Available	  only	 in   MongoDB	Enterprise    (http://www.mon-
	      godb.com/products/mongodb-enterprise-advanced?tck=docs_server)
	      and MongoDB Atlas	(https://cloud.mongodb.com/user#/atlas/login).

	      Enables  the  auditing  of  authorization	 successes for the au-
	      thCheck action.

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

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      To  enable  the audit of authorization successes,	issue the fol-
	      lowing command:

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

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

	      If  runtime  audit configuration is enabled, the auditAuthoriza-
	      tionSuccess parameter should not appear in the mongod or	mongos
	      configuration file. The server will fail to start	if the parame-
	      ter is present.

	      getParameter

       auditConfigPollingFrequencySecs

	      Type: integer

	      Default: 300

	      A	sharded	cluster	may have servers which maintain	audit configu-
	      ration  settings	for the	cluster. Set the interval, in seconds,
	      for non-configured servers to poll a config server for the  cur-
	      rent  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.

	      Using the	default	value of 300 seconds, non-config nodes may lag
	      up to 5 minutes after you	set the	auditConfig cluster parameter.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

       auditEncryptionHeaderMetadataFile

	      Available	for both mongod	and mongos.

	      Type: string

	      Available	  only	 in   MongoDB	Enterprise    (http://www.mon-
	      godb.com/products/mongodb-enterprise-advanced?tck=docs_server).
	      MongoDB  Enterprise  and	Atlas have different configuration re-
	      quirements.

	      Path and file name for logging metadata audit headers for	 audit
	      log  encryption. 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 audit log.

	      This  parameter is only available	at startup. To set the parame-
	      ter, use the setParameter	setting.

	      For example, the following sets the path and file	 for  auditEn-
	      cryptionHeaderMetadataFile:

		mongod --setParameter auditEncryptionHeaderMetadataFile=/auditFiles/auditHeadersMetadataFile.log

       auditEncryptKeyWithKMIPGet

	      Available	for both mongod	and mongos.

	      Type: boolean

	      Default: false

	      Available	   only	  in   MongoDB	 Enterprise   (http://www.mon-
	      godb.com/products/mongodb-enterprise-advanced?tck=docs_server).
	      MongoDB Enterprise and Atlas have	 different  configuration  re-
	      quirements.

	      Enables audit log	encryption for Key Management Interoperability
	      Protocol	(KMIP) servers that only support KMIP protocol version
	      1.0 or 1.1.

	      This parameter is	only available at startup. To set the  parame-
	      ter, use the setParameter	setting.

	      The following example sets auditEncryptKeyWithKMIPGet to true:

		mongod --setParameter auditEncryptKeyWithKMIPGet=true

   TRANSACTION PARAMETERS
       coordinateCommitReturnImmediatelyAfterPersistingDecision

	      Updated in version 6.1

	      Available	for mongod only.

	      Type: boolean

	      Default: false

		      When  set  to  false, the shard transaction coordinator
		       waits for all participating shards to  acknowledge  the
		       decision	 to  either  commit or cancel a	multi-document
		       transaction before returning the	result to the client.

		      When set	to true, the shard transaction coordinator re-
		       turns a multi-document transaction commit  decision  to
		       the client as soon as the decision is made durable with
		       the requested transaction write concern.

		       If  the	client	requested a write concern that is less
		       than "majority",	the commit may roll back after the de-
		       cision is returned to the client.

		       Transactions may	not have "read	your  writes"  consis-
		       tency.	That is, a read	operation may not show the re-
		       sults of	write operations that preceded	it.  This  can
		       happen if:

		          A transaction has to	write to multiple shards.

		          The	read  and the earlier write take place in dif-
			   ferent sessions.

		       Causal consistency only guarantees the causal relation-
		       ship of reads and writes	that  occur  within  the  same
		       session.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The   following	example	  sets	 coordinateCommitReturnImmedi-
	      atelyAfterPersistingDecision to true:

		mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

	      During run time, you can also set	the parameter with the	setPa-
	      rameter command:

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

       internalSessionsReapThreshold

	      Available	for both mongod	and mongos.

	      Default: 1000

	      Session  limit for internal session metadata deletion. The meta-
	      data:

		      Contains	session	transaction information	for user oper-
		       ations.

		      Is stored in the	config.transactions collection.

	      When the number of internal  sessions  is	 greater  than	inter-
	      nalSessionsReapThreshold,	the metadata is	deleted.

	      If you set internalSessionsReapThreshold to 0, the internal ses-
	      sion metadata is only deleted when the user session ends.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The  following example sets internalSessionsReapThreshold	to 500
	      sessions:

		db.adminCommand( { setParameter: 1, internalSessionsReapThreshold: 500 } )

	      You can also set internalSessionsReapThreshold at	 startup.  For
	      example:

		mongod --setParameter internalSessionsReapThreshold=500

       transactionLifetimeLimitSeconds

	      Available	for mongod only.

	      Default: 60

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

	      The cleanup process helps	relieve	storage	cache pressure.

	      The minimum value	for transactionLifetimeLimitSeconds is 1  sec-
	      ond.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The  following  sets  the	 transactionLifetimeLimitSeconds to 30
	      seconds:

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

	      You can also set	parameter  transactionLifetimeLimitSeconds  at
	      startup time.

		mongod --setParameter "transactionLifetimeLimitSeconds=30"

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

	      Starting in MongoDB 5.0, if you change the  transactionLifetime-
	      LimitSeconds  parameter,	you  must also change transactionLife-
	      timeLimitSeconds to the same value on all	config server  replica
	      set members. Keeping this	value consistent:

		      Ensures	the  routing  table history is retained	for at
		       least as	long as	the transaction	lifetime limit on  the
		       shard replica set members.

		      Reduces	the  transaction retry frequency and therefore
		       improves	performance.

       transactionTooLargeForCacheThreshold

	      Available	for mongod only.

	      Type: decimal

	      Default: 0.75

	      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, 0.75, means 75% of the dirty cache.

	      The dirty	cache is limited to 20%	of the total cache size.  When
	      transactionTooLargeForCacheThreshold  is set to 0.75, the	server
	      only retries transactions	that use less than 15% (0.75 * 20%) of
	      the total	storage	engine cache.

	      The limit	only applies to	retries. Large	transactions  can  use
	      more  than  transactionTooLargeForCacheThreshold	percent	of the
	      dirty cache. However, if a large transaction is rolled back  due
	      to  cache	 pressure, the server issues a TransactionTooLargeFor-
	      Cache error and does not retry the transaction.

	      To disable this behavior,	set transactionTooLargeForCacheThresh-
	      old to 1.0.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      For  more	 information  on  WiredTiger   storage,	  see:	 stor-
	      age.wiredTiger Options.

       maxTransactionLockRequestTimeoutMillis

	      Available	for mongod only.

	      Type: integer

	      Default: 5

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

	      If the transaction cannot	acquire	the locks after	 waiting  max-
	      TransactionLockRequestTimeoutMillis, the transaction aborts.

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

	      You can set maxTransactionLockRequestTimeoutMillis to:

		      0 such that if the transaction cannot acquire  the  re-
		       quired locks immediately, the transaction aborts.

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

		      -1 to use the operation specific	timeout.

	      This parameter is	available both at runtime and at startup:

		      To  set	the parameter at runtime, use the setParameter
		       command

		      To set the parameter at startup,	use  the  setParameter
		       setting

	      The following sets the maxTransactionLockRequestTimeoutMillis to
	      20 milliseconds:

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

	      You can also set this parameter during start-up:

		mongod --setParameter maxTransactionLockRequestTimeoutMillis=20

   SLOT-BASED EXECUTION	PARAMETERS
       planCacheSize

	      Available	for mongod only.

	      Type: string

	      Default: 5%

	      Although	the  planCacheSize parameter existed in	prior versions
	      of MongoDB, it had no effect on the  plan	 cache	until  version
	      6.3.

	      Sets  the	 size  of the plan cache only for the slot-based query
	      execution	engine.

	      You can set the planCacheSize value to either:

		      A percentage of the system's total physical  memory  to
		       allocate	for the	plan cache. For	example, "8.5%".

		      The exact amount	of data	to allocate for	the plan cache
		       in either MB or GB. For example,	"100MB"	or "1GB".

	      Increasing the plan cache	size adds more cached query shapes for
	      the  query  planner. This	can improve query performance, but in-
	      creases memory usage.

	      This parameter is	available both at runtime and at startup:

		      To set the parameter at runtime,	use  the  setParameter
		       command

		      To  set	the parameter at startup, use the setParameter
		       setting

	      The  following  startup  command	sets   planCacheSize   to   80
	      megabytes:

		mongod --setParameter planCacheSize="80MB"

	      You  can	also  use  the setParameter command within the MongoDB
	      Shell (https://www.mongodb.com/docs/mongodb-shell/):

		db.adminCommand( { setParameter: 1, planCacheSize: "80MB" } )

							 mongodb-parameters(5)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=mongodb-parameters&sektion=5&manpath=FreeBSD+Ports+14.3.quarterly>

home | help