自己管理型配置の MongoDB Server パラメーター

項目一覧

Synopsis

パラメーター
認証パラメータ
一般的なパラメータ
ログパラメータ
診断パラメータ
レプリケーションと整合性
シャーディングパラメータ
ヘルスマネージャーパラメータ
ストレージパラメータ
WiredTiger パラメータ
監査パラメータ
トランザクションパラメータ

MongoDB5.0 は 10 月2024 をもってサポートを終了します。このバージョンのドキュメントはサポート対象外になりました。配置をアップグレードするには、 MongoDB を参照してください。5.0 60アップグレード手順。

Synopsis

MongoDB には、以下を使用して設定できるさまざまな構成オプションがあります。

setParameterコマンド
```
db.adminCommand( { setParameter: 1, <parameter>: <value>  } )
```
setParameter構成設定。
```
setParameter:
   <parameter1>: <value1>
   ...
```
mongod および mongos の --setParameter コマンドラインオプション。
```
mongod --setParameter <parameter>=<value>
mongos --setParameter <parameter>=<value>
```

追加の構成オプションについては、自己管理型構成ファイルオプション、 mongod 、およびmongosを参照してください。

パラメーター

認証パラメータ

authenticationMechanisms

mongod と mongos の両方で使用できます。

サーバーが受け入れる認証メカニズムの一覧を指定します。これを、次の 1 つ以上の値に設定します。複数の値を指定する場合は、スペースを入れずにコンマ区切りのリストを使用します。認証メカニズムの説明については、「自己管理型配置での認証」を参照してください。

値	説明
SCRAM-SHA-1	SHA-1 ハッシュ関数を使用する RFC5802 標準の Salted Challenge Response Authentication Mechanismです。
SCRAM-SHA-256	SHA-256 ハッシュ関数を使用する RFC 7677 標準の Salted Challenge Response Authentication Mechanism。
MONGODB-X509	MongoDB TLS/SSL 証明書認証。
GSSAPI（Kerberos）	Kerberos を使用する外部認証。このメカニズムは MongoDB Enterprise でのみ使用できます。
PLAIN（LDAP SASL）	LDAP を使用する外部認証。データベース内のユーザー認証には、`PLAIN` を使用することもできます。`PLAIN` はパスワードをプレーンテキストで送信します。このメカニズムは MongoDB Enterprise でのみ使用できます。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、認証メカニズムとして PLAIN と SCRAM-SHA-256 の両方を指定するには、次のコマンドを使用します。

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

awsSTSRetryCount

バージョン5.0.18で変更。

以前のバージョンでは、AWS IAM 認証は、サーバーが HTTP 500 エラーを返した場合にのみ再試行されていました。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 2

Amazon Web ServicesIAM MongoDB認証情報を使用した配置の場合またはAmazon Web Services IAM 環境変数。

接続失敗後の AWS IAM 認証の最大再試行回数。

次の例では、 awsSTSRetryCountに15の再試行を設定します。

mongod --setParameter awsSTSRetryCount=15

あるいは、次の例では、setParameter mongosh内でコマンドを使用します。

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

clusterAuthMode

mongod と mongos の両方で使用できます。

clusterAuthMode に sendX509 または x509 を設定します。ローリングアップグレード中にメンバーシップ認証に x509 を使用するとダウンタイムを最小限に抑えるために役立ちます。

TLS/SSL と MongoDB の詳細については、「mongod と mongos の TLS/SSL 設定」および「クライアントの TLS/SSL 設定」を参照してください。

このパラメーターは実行時にのみ使用できます。パラメーターを設定するには、 setParameterコマンドを使用します。

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

enableLocalhostAuthBypass

mongod と mongos の両方で使用できます。

ローカルホスト認証バイパスを無効にするには、 0 または false を指定します。デフォルトでは有効になっています。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

詳細については、「自己管理型配置での Localhost 例外」を参照してください。

KeysRotationIntervalSec

バージョン 3.6 の新機能。

デフォルト：7776000 秒（90 日）

HMAC 署名鍵が次の鍵にローテーションするまで有効な秒数を指定します。このパラメータは主に認証テストを容易にすることを目的としています。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

ldapForceMultiThreadMode

デフォルト: false

同時 LDAP 操作のパフォーマンスを有効にします。

注意

libldap のインスタンスがこのモードで安全に使用できることが確実な場合にのみ、このフラグを有効にしてください。使用している libldap バージョンがスレッドセーフでない場合、MongoDB プロセスがクラッシュする可能性があります。

LDAP 接続プールを使用するには、 ldapForceMultiThreadModeを使用する必要があります。 LDAP 接続プールを有効にするには、 ldapForceMultiThreadModeとldapUseConnectionPoolをtrueに設定します。

Tip

MongoDB のバージョン、OS のバージョン、または libldap のバージョンについて心配な場合は、MongoDB サポートにお問い合わせください。

ldapQueryPassword

mongod と mongos の両方で使用できます。

型: string

LDAP サーバーにバインドするために使用されるパスワード。このパラメータではldapQueryUserを使用する必要があります。

設定されていない場合、mongod または mongos は LDAP サーバーにバインドしません。

ldapQueryUser

mongod と mongos の両方で使用できます。

型: string

LDAP サーバーにバインドするユーザー。このパラメータではldapQueryPasswordを使用する必要があります。

設定されていない場合、mongod または mongos は LDAP サーバーにバインドしません。

ldapRetryCount

バージョン 6.1 で追加。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 0

自己管理型配置で LDAP 認証を使用する MongoDB 配置の場合。

ネットワークエラーが発生した場合にサーバー LDAP マネージャーによって再試行される操作の回数。

次の例では、 ldapRetryCountを3秒に設定します。

mongod --ldapRetryCount=3

または、mongosh内でsetParameterコマンドを使用する場合。

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

ldapUserCacheInvalidationInterval

自己管理型配置で LDAP 認証を使用する MongoDB 配置で使用します。mongod インスタンスでのみ使用できます。

mongodインスタンスが外部ユーザーキャッシュのフラッシュ間で待機する間隔（秒単位）。MongoDB が外部ユーザーキャッシュをフラッシュした後、次に LDAP で承認されたユーザーが操作を発行するときに、MongoDB は LDAP サーバーから承認データを再取得する必要があります。

指定する値を大きくすると、MongoDB と LDAP サーバーが同期するまでの間隔が長くなりますが、LDAP サーバーの負荷は軽減されます。逆に、指定する値を小さくすると、MongoDB と LDAP サーバーが同期するまでの感覚は短くなりますが、LDAP サーバーの負荷は増加します。

デフォルトは 30 秒です。

ldapUseConnectionPool

MongoDB が認証および承認のために LDAP サーバーに接続するときに接続プーリングを使用するかどうかを指定します。

MongoDB では、次のデフォルト値が使用されます。

Windows では true
MongoDB Enterprise バイナリが libldap_r にリンクされている Linux では true。
MongoDB Enterprise バイナリが libldap にリンクされている Linux では false。

ldapUseConnectionPoolが設定できるのはスタートアップ時のみです。setParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolUseLatencyForHostPriority

デフォルト: true

LDAP 接続プール（ldapUseConnectionPoolを参照）が LDAP サーバーのレイテンシを使用して接続順序（最小レイテンシから最大レイテンシまで）を決定するかどうかを決めるブール値。

ldapConnectionPoolUseLatencyForHostPriorityはスタートアップ時にのみ設定でき、実行中にsetParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolMinimumConnectionsPerHost

デフォルト: 1

各 LDAP サーバーに対して開始したままにしておく接続の最小数。

ldapConnectionPoolMinimumConnectionsPerHostはスタートアップ時にのみ設定でき、実行中にsetParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolMaximumConnectionsPerHost

バージョン 4.2.1 の新機能。

MongoDB バージョン5.0.9以降で変更 デフォルト値を2147483647に変更しました。以前のバージョンのデフォルトは未設定です。

デフォルト: 2147483647

各 LDAP サーバーに対して開始したままにしておく接続の最大数。

ldapConnectionPoolMaximumConnectionsPerHostはスタートアップ時にのみ設定でき、実行中にsetParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolMaximumConnectionsInProgressPerHost

バージョン 4.2.1 の新機能。

MongoDB バージョン5.0.9以降で変更 デフォルト値を2に変更しました。以前のバージョンのデフォルトは未設定です。

デフォルト: 2

各 LDAP サーバーに対して進行中の接続操作の最大数。

ldapConnectionPoolMaximumConnectionsInProgressPerHostが設定できるのはスタートアップ時のみです。setParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolHostRefreshIntervalMillis

デフォルト: 60000

プールされたLDAP接続のヘルスチェック間隔（ミリ秒単位）。

ldapConnectionPoolHostRefreshIntervalMillisが設定できるのはスタートアップ時のみです。setParameterデータベースコマンドを使用してこの設定を変更することはできません。

ldapConnectionPoolIdleHostTimeoutSecs

デフォルト: 300

LDAPサーバーにプールされた接続がクローズされるまでにアイドル状態を維持できる最大時間（秒）。

ldapConnectionPoolIdleHostTimeoutSecsが設定できるのはスタートアップ時のみです。setParameterデータベースコマンドを使用してこの設定を変更することはできません。

maxValidateMemoryUsageMB

バージョン 5.0 で追加

デフォルト: 200

validateコマンドのメモリ使用上限（メガバイト）。上限を超えた場合、validate は可能な限り多くの結果を返し、制限によりすべての破損が報告されない可能性があることを警告します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

ocspEnabled

Linux および macOS で利用できます。

デフォルト: true

OCSP を有効または無効にするフラグです。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、次の例では OCSP が無効になります。

mongod --setParameter ocspEnabled=false ...

Tip

ocspValidationRefreshPeriodSecs

Linuxで利用できます。

ステープリングされた OCSP ステータス応答をリフレッシュする前に待機する時間（秒単位）。1 以上の数値を指定します。

ocspValidationRefreshPeriodSecsスタートアップ時にconfiguration file --setParameterまたはコマンドラインでオプションを使用してのみを設定できます。次の例では、パラメータを3600秒に設定します。

mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ...

MongoDB 5.0 以降では、rotateCertificates コマンドと db.rotateCertificates() メソッドによって、ステープリングされた OCSP 応答もリフレッシュされます。

Tip

以下も参照してください。

ocspEnabled
tlsOCSPStaplingTimeoutSecs
tlsOCSPVerifyTimeoutSecs

opensslCipherConfig

バージョン 3.6 の新機能。

Linux でのみ利用可能です。

ネイティブ TLS/SSL ライブラリを使用することで、パラメータopensslCipherConfigは Linux/BSD でサポートされ、Windows と macOS ではサポートされなくなりました。

TLS/SSL 暗号化を使用する場合は、OpenSSL の暗号stringを指定します。暗号文字列のリストについては、 https://www.openssl.org/docs/man1.1.1 /man1 /ciphers.html を参照してください。。複数の暗号文字列をコロン区切りのリストとして提供できます。

注意

このパラメータは TLS 1.2またはそれ以前のバージョンでのみ使用します。 TLS 1.3で使用する暗号スイートを指定するには、 opensslCipherSuiteConfigパラメーターを使用します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

SSLオプションよりもTLSオプションの使用が優先されます。 TLS オプションはSSLオプションと同じ機能を持ちます。次の例では、のmongod opensslCipherConfig暗号を持つstring 'HIGH:!EXPORT:!aNULL@STRENGTH'を構成します。

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

opensslCipherSuiteConfig

バージョン 5.0 で追加

Linux でのみ利用可能です。

TLS 1.3 暗号化を使用するときに OpenSSL が許可する、サポート対象の暗号スイートのリストを指定します。

TLS で使用する暗号スイートのリストについては、1.3 https://www.opensl.org/docs/man1.1.1 /man3 /SSL_CTX_set_cipher_list.html を参照してください。。複数の暗号スイートは、コロン区切りのリストとして提供できます。

注意

このパラメータは TLS 1.3でのみ使用します。 TLS 1.2またはそれ以前のバージョンで使用する暗号文字列を指定するには、 opensslCipherConfigパラメータを使用します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

次の例では、TLS 1.3で使用するためにmongodは、'TLS_AES_256_GCM_SHA384'のopensslCipherSuiteConfig暗号スイートで構成します。

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

opensslDiffieHellmanParameters

バージョン 3.6 の新機能。

Linux でのみ利用可能です。

TLS 1.2 以前を使用する場合は、OpenSSL ディフィーヘルマンパラメータを含む PEM ファイルに対するパスを指定します。OpenSSL ディフィーヘルマンパラメータを指定すると、TLS/SSL 暗号化中にエフェメラルディフィーヘルマン（DHE）暗号スイートのサポートが有効になります。

TLS 1.3 では、このパラメータの使用はサポートされていません。

エフェメラルディフィーヘルマン（DHE）暗号スイート（およびエフェメラル楕円曲線ディフィーヘルマン（ECDHE）暗号スイート）では、フォワードシークレシーが提供されます。フォワードシークレシー暗号スイートは、サーバーの秘密キーで保護されているが送信されない一時的なセッション鍵を作成します。これにより、サーバーの秘密キーが侵害された場合でも、侵害された鍵で過去のセッションを復号化することはできません。

注意

opensslDiffieHellmanParametersが設定されていないが ECDHE が有効になっている場合、MongoDB はffdhe3072 RFC-7919 #appendix-A2 で定義されているように、ディフィーヘルマンパラメータを使用して DHE を有効にします。。ffdhe3072は強力なパラメータ（具体的には、サイズが1024より大きい場合）。 Oracle から延長サポートを購入しない限り、Java 6および7ではサポートされていません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

パフォーマンス上の理由で、DHE 暗号スイートのサポートを無効にする必要がある場合は、opensslCipherConfigパラメーターを使用します。

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

saslauthdPath

注意

MongoDB Enterprise でのみ利用可能です（MongoDB Enterprise for Windows を除く）。

mongod と mongos の両方で使用できます。

プロキシ認証に使用する saslauthd インスタンスの Unix ドメインソケットへのパスを指定します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

saslHostName

mongod と mongos の両方で使用できます。

saslHostName は、SASL および Kerberos 認証を構成するために、MongoDB のデフォルトのホスト名検出を上書きします。

saslHostNameは、SASL と Kerberos の構成以外の目的で、 mongodまたはmongosインスタンスのホスト名に影響を与えません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

注意

saslHostName は、Kerberos 認証をサポートしており、MongoDB Enterprise にのみ含まれています。詳細については、以下を参照してください。

Linux: Linuxで Kerberos 認証を使用して自己管理型 MongoDB を構成する
Windows: Windowsで Kerberos 認証を使用して自己管理型 MongoDB を構成する

saslServiceName

mongod と mongos の両方で使用できます。

ユーザーがインスタンスごとに、Kerberos プリンシパル名のデフォルトの Kerberos サービス名コンポーネントを上書きできるようにします。指定しない場合、デフォルト値は mongodb です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

saslServiceName は MongoDB Enterprise でのみ利用可能です。

重要

ドライバーが代替サービス名をサポートしていることを確認します。

scramIterationCount

デフォルト: 10000

mongod と mongos の両方で使用できます。

すべての新しい SCRAM-SHA-1 パスワードに使用されるハッシュ反復回数を変更します。反復回数を増やすと、クライアントが MongoDB への認証に必要な時間は長くなりますが、パスワードはブルートフォース攻撃の影響を受けにくくなります。デフォルト値は、最も一般的なユースケースと要件に最適です。

この値を変更しても、既存のパスワードの反復回数は変更されません。 scramIterationCountの値は5000以上である必要があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例ではscramIterationCountを12000に設定します。

mongod --setParameter scramIterationCount=12000

または、mongosh内でsetParameterコマンドを使用する場合。

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

Tip

以下も参照してください。

scramSHA256IterationCount

デフォルト: 15000

mongod と mongos の両方で使用できます。

すべての新しい SCRAM-SHA-256 パスワードに使用されるハッシュ反復回数を変更します。反復回数を増やすと、クライアントが MongoDB への認証に必要な時間は長くなりますが、パスワードはブルートフォース攻撃の影響を受けにくくなります。デフォルト値は、最も一般的なユースケースと要件に最適です。

この値を変更しても、既存のパスワードの反復回数は変更されません。 scramSHA256IterationCountの値は5000以上である必要があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例ではscramSHA256IterationCountを20000に設定します。

mongod --setParameter scramSHA256IterationCount=20000

または、mongosh内でsetParameterコマンドを使用する場合。

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

Tip

以下も参照してください。

sslMode

mongod と mongos の両方で使用できます。

net.ssl.mode に preferSSL または requireSSL を設定します。TLS/SSL へのローリングアップグレード中に、ダウンタイムを最小限に抑えるために役立ちます。

TLS/SSL と MongoDB の詳細については、「mongod と mongos の TLS/SSL 設定」および「クライアントの TLS/SSL 設定」を参照してください。

このパラメーターは実行時にのみ使用できます。パラメーターを設定するには、 setParameterコマンドを使用します。

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

Tip

以下も参照してください。

tlsMode

tlsMode

mongod と mongos の両方で使用できます。

次のいずれかに設定します。

preferTLS
requireTLS

tlsModeパラメータは、TLS/SSL へのローリングアップグレード中に、ダウンタイムを最小限に抑えるために役立ちます。

このパラメーターは実行時にのみ使用できます。パラメーターを設定するには、 setParameterコマンドを使用します。

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

TLS/SSL と MongoDB の詳細については、「mongod と mongos の TLS/SSL 設定」および「クライアントの TLS/SSL 設定」を参照してください。

Tip

以下も参照してください。

sslMode

tlsOCSPStaplingTimeoutSecs

Linuxで利用できます。

mongod インスタンスまたは mongos インスタンスが証明書の OCSP ステータス応答を受信するまでに待機する最大秒数。

以上の整数を指定します（ >= ） 1 。設定されていない場合、 tlsOCSPStaplingTimeoutSecsはtlsOCSPVerifyTimeoutSecs値を使用します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

次の例では、tlsOCSPStaplingTimeoutSecsを 20 秒に設定します。

mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

Tip

以下も参照してください。

ocspEnabled
ocspValidationRefreshPeriodSecs
tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

Linux および Windows で利用できます。

デフォルト: 5

サーバー証明書を検証するときに、mongod または mongos が OCSP 応答を待機する最大秒数。

1 以上（>=）の整数を指定します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

次の例では、tlsOCSPVerifyTimeoutSecsを 20 秒に設定します。

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Tip

以下も参照してください。

ocspEnabled
ocspValidationRefreshPeriodSecs
tlsOCSPStaplingTimeoutSecs

tlsUseSystemCA

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

MongoDB がオペレーティングシステムの証明機関で既に使用可能な TLS 証明書をロードするかどうかを指定します。

重要

mongodTLS/SSL を有効にしてインスタンスを起動する場合は、--tlsCAFile フラグ、net.tls.CAFile 構成オプション、tlsUseSystemCA パラメータのいずれかの値を指定する必要があります。

--tlsCAFile、tls.CAFile、tlsUseSystemCA は、すべて相互に排他的です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、 tlsUseSystemCAをtrueに設定するには、次の操作を実行します。

mongod --setParameter tlsUseSystemCA=true

TLS/SSL と MongoDB の詳細については、「mongod と mongos の TLS/SSL 設定」および「クライアントの TLS/SSL 設定」を参照してください。

tlsWithholdClientCertificate

mongod と mongos の両方で使用できます。

TLS 証明書は、mongod または mongos に対して、--tlsClusterFileオプションによって、または--tlsClusterFile が設定されていない場合は --tlsCertificateKeyFileオプションによって設定されます。TLS 証明書が設定されている場合、デフォルトでは、インスタンスは配置内の他の mongod インスタンスまたは mongos インスタンスとのクラスター内通信を開始するときに証明書を送信します。tlsWithholdClientCertificate に 1 または true を設定すると、これらの通信中に TLS 証明書の送信を保留するようにインスタンスに指示します。このオプションを、（証明書なしでインバウンド接続を許可する場合に）配置のすべてのノードで --tlsAllowConnectionsWithoutCertificatesとともに使用します。tlsWithholdClientCertificate と --clusterAuthMode x509 は排他関係にあります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

tlsX509ClusterAuthDNOverride

mongod と mongos の両方で使用できます。

インスタンスが配置のノードを識別するためにも使用できるDN（Distinguished Name、代替識別名）。

clusterAuthMode に x.509 証明書を使用する MongoDB 配置では、配置ノードは、クラスター内通信中に x.509 証明書（指定されている場合は net.tls.clusterFile 、および net.tls.certificateKeyFile ）を使用して相互を識別します。同じ配置のノードの場合、証明書の DN に含まれる組織属性（O）、組織単位属性（OU）、およびドメインコンポーネント（DC）は同じである必要があります。

ノードに tlsX509ClusterAuthDNOverride が設定されている場合、ノードは提示された証明書の DN コンポーネント（O 、 OU 、およびDC）を比較するときにオーバーライド値を使用することもできます。つまり、ノードは提示された証明書を net.tls.clusterFile / net.tls.certificateKeyFile と照合します。DN が一致しない場合、ノードは提示された証明書を tlsX509ClusterAuthDNOverride 値と照合します。

注意

設定されている場合配置のすべてのノードにこのパラメーターを設定する必要があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

このパラメータを使用して、新しいDN値を含む新しい証明書に、証明書のローリングアップデートを行うことができます。 x のローリングアップデートを参照してください。自己管理型クラスター上の新しい識別名を含む509証明書

メンバーシップ証明書要件の詳細については、「メンバー証明書の要件」を参照してください。

tlsX509ExpirationWarningThresholdDays

mongod と mongos の両方で使用できます。

デフォルト : 30

が x を表示した場合、 mongod / mongosは接続時に警告を記録します。 509証明書はmongod/mongosシステムクロックから30日以内に期限切れになります。証明書の有効期限警告しきい値を制御するには、 tlsX509ExpirationWarningThresholdDaysパラメータを使用します。

証明書の有効期限よりもかなり前に警告を発報するには、パラメーターの値を大きくします。
証明書の有効期限が近づくと警告を発報するには、パラメーター値を小さくします。
警告を無効にするには、パラメーターに 0 を設定します。

このパラメーターの最小値は 0 です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

x の詳細については、こちらを参照してください。509 証明書の有効性については、 RFC52804.1.2.5 を参照してください。

userCacheInvalidationIntervalSecs

デフォルト: 30

mongos でのみ利用可能です。

mongos インスタンスでは、mongos インスタンスがユーザーオブジェクトのメモリ内キャッシュに古いデータがあるかどうかを確認し、古いデータがある場合はキャッシュをクリアする間隔（秒単位）を指定します。ユーザーオブジェクトに変更がない場合、 mongos はキャッシュをクリアしません。

このパラメーターの最小値は 1 秒、最大値は 86400 秒（24 時間）です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

authFailedDelayMs

デフォルト: 0

mongod と mongos の両方で使用できます。

バージョン 3.4 で追加。

注意

エンタープライズ機能

MongoDB Enterprise でのみ使用できます。

認証が失敗したことをクライアントに通知するまでに待機するミリ秒数。このパラメーターの範囲は 0 から 5000（両端を含む）です。

このパラメーターを設定すると、データベースに対するブルートフォースログイン攻撃にかかる時間が長くなります。ただし、MongoDB サーバーからの応答を待っているクライアントは引き続きサーバーのリソースを消費するため、サーバーが同時に他の多くのクライアントへのアクセスを拒否している場合は、正常なログイン試行に悪影響を与える可能性があります。

allowRolesFromX509Certificates

デフォルト: true

mongod と mongos の両方で使用できます。

クライアントの x.509 証明書から承認ロールを取得することを許可または禁止するブール値フラグ。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

一般的なパラメータ

httpVerboseLogging

mongod と mongos の両方で使用できます。

Linux および macOS 上の curl に詳細なトレース機能を追加します。Windows への影響はありません。

デフォルトでは、このパラメータは設定されていません。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

mongos --setParameter httpVerboseLogging=true

connPoolMaxConnsPerHost

デフォルト: 200

mongod と mongos の両方で使用できます。

グローバル接続プール内の他の mongod インスタンスに対する、送信接続用のレガシー接続プールの最大サイズを設定します。プールのサイズによって追加の接続の作成が妨げられることはありませんが、接続プールが connPoolMaxConnsPerHost の値を超える接続を保持することは防止されます。

注意

パラメーターは TaskExecutor プール内の接続とは別です。詳しくはShardingTaskExecutorPoolMaxSizeを参照してください。

ドライバーが接続をプールせず、シャーディングされたクラスターのコンテキストで認証を使用している場合にのみ、この設定を調整してください。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

バージョン3.6.3の新機能。

mongod と mongos の両方で使用できます。

レガシーグローバル接続プール内の他の mongod インスタンスへの送信接続について、常に使用中の接続の最大数を設定します。

デフォルトでは、このパラメータは設定されていません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

以下も参照してください。

connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes

バージョン3.6.3の新機能。

mongod と mongos の両方で使用できます。

レガシーグローバル接続プール内の接続が閉じられる前にアイドル状態を維持できる時間制限を設定します。

デフォルトでは、このパラメータは設定されていません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

cursorTimeoutMillis

デフォルト：600000（10分）

mongod と mongos の両方で使用できます。

MongoDB がアイドルカーソルを削除する前に、アイドルカーソルの有効期限のしきい値をミリ秒単位で設定します。具体的には、MongoDB は指定されたcursorTimeoutMillisでアイドル状態になっているカーソルを削除します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次の例ではcursorTimeoutMillisを300000ミリ秒（ 5分）に設定します。

mongod --setParameter cursorTimeoutMillis=300000

または、mongosh内でsetParameterコマンドを使用する場合。

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

cursorTimeoutMillisを0以下に設定すると、すべてのカーソルはすぐにタイムアウトの対象となります。一般的に、タイムアウト値はクエリが結果を返すまでの平均時間よりも大きくなければなりません。 cursor.explain()カーソル修飾子などのツールを使用して平均クエリ時間を分析し、適切なタイムアウト期間を選択します。

警告

MongoDB は、セッション管理の一環として、セッションにリンクされた孤立したカーソルをクリーンアップします。つまり、セッション ID を持つ孤立したカーソルでは、タイムアウトを制御するためにcursorTimeoutMillisは使用されません。

カーソルを返し、アイドル期間がlocalLogicalSessionTimeoutMinutesより長い操作は、 Mongo.startSession()を使用して明示的なセッション内で操作を実行します。セッションを更新するには、 refreshSessionsコマンドを実行します。詳細については、「 refreshSessionsを使用してカーソルを更新する」を参照してください。

maxNumActiveUserIndexBuilds

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 3

プライマリ上で許可される同時インデックス構築の最大数を設定します。これはすべてのコレクションに適用されるグローバルな制限です。

maxNumActiveUserIndexBuilds の値を増やすと、追加の同時インデックス構築が可能になりますが、WiredTiger キャッシュへの負荷が増大します。

システムインデックスは maxNumActiveUserIndexBuilds に制限されませんが、システムインデックスの構築はユーザーインデックス構築の制限に含まれます。

サーバーが maxNumActiveUserIndexBuilds に達すると、同時インデックス構築の数が maxNumActiveUserIndexBuilds 制限を下回るまで、追加のユーザーインデックス構築をブロックします。インデックス構築がブロックされると、サーバーは次のメッセージをログに記録します。

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

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次のコマンドにより、4つの同時インデックス構築の制限が設定されます。

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

以下も参照してください。

notablescan

mongod でのみ利用可能です。

すべてのクエリでインデックスを使用する必要があるかどうかを指定します。1 の場合、MongoDB はコレクションスキャンを必要とするクエリを実行せず、エラーを返します。

notablescanを1または true に設定する次の例を考えてみます。

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

notablescanを1に設定すると、コレクション全体をスキャンし、インデックスを使用できないクエリを識別するなど、アプリケーションクエリをテストする場合に役立ちます。

notablescanのないインデックスなしのクエリを検出するには、「現在の操作のパフォーマンスを評価する」および「クエリパフォーマンスを最適化する」セクションを読み、 logLevelパラメータ、 mongostat 、およびプロファイリングの使用を検討してください。

コレクションスキャンを行わない場合、管理クエリを含むすべてのデータベースのクエリに影響する可能性があるため、本番環境のmongodインスタンスをnotablescanで実行しないでください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

ttlMonitorEnabled

mongod でのみ利用可能です。

デフォルト: true

TTL インデックスをサポートするために、mongod インスタンスには、TTL インデックスを持つコレクションからドキュメントを削除するバックグラウンドスレッドがあります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

mongodのこのワーカースレッドを無効にするには、次の操作のようにttlMonitorEnabledをfalseに設定します。

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

あるいは、次のオプションを使用して mongod インスタンスを開始することにより、スタートアップ時にスレッドを無効にすることもできます。

mongod --setParameter ttlMonitorEnabled=false

重要

MongoDB サポートからのガイダンスがない限り、 ttlMonitorEnabledを無効にして本番環境のmongodインスタンスを実行しないでください。 TTL ドキュメントの削除を行わない場合、 TTL インデックスに依存する MongoDB の内部システム操作に悪影響を与える可能性があります。

tcpFastOpenServer

mongod と mongos の両方で使用できます。

デフォルト: true

クライアントから mongod/mongos へのインバウンド TCP Fast Open（TFO）接続を受け入れるためのサポートを有効にします。TFO にはクライアントと mongod/mongos ホストマシンの両方で次のように TFO がサポートされ、有効である必要があります。

Windows

次の Windows オペレーティングシステムは TFO をサポートしています。

Microsoft Windows Server 2016 以降。
Microsoft Windows 10 Update 1607 以降。

MacOS

macOS 10.11（El Capitan）以降は TFO をサポートしています。

Linux

Linux カーネル 3.7 以降を実行している Linux オペレーティングシステムは、インバウンド TFO をサポートできます。

インバウンド TFO 接続を有効にするには、 /proc/sys/net/ipv4/tcp_fastopen の値を設定します。

インバウンド TFO 接続のみを有効にするには、 2 を設定します。
インバウンド TFO 接続およびアウトバウンド TFO 接続を有効にするには、 3 を設定します。

このパラメータは、ホストオペレーティングシステムが TFO 接続をサポートしていないか、またはサポートするように構成されていない場合、影響はありません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

RFC7413.

tcpFastOpenClient

mongod と mongos の両方で使用できます。

デフォルト: true

Linux オペレーティングシステムのみ。

mongod/mongos からクライアントへのアウトバウンド TCP Fast Open（TFO）接続のサポートを有効にします。TFO では、クライアントと mongod/mongos ホストマシンの両方で TFO がサポートされ、有効である必要があります。

Linux カーネル 4.11 以降を実行している Linux オペレーティングシステムは、アウトバウンド TFO をサポートできます。

アウトバウンド TFO 接続を有効にするには、次のように /proc/sys/net/ipv4/tcp_fastopen の値を設定します。

1 に設定すると、アウトバウンド TFO 接続のみを有効にします。
3 に設定すると、インバウンドおよびアウトバウンドの TFO 接続を有効にします。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

RFC7413.

tcpFastOpenQueueSize

mongod と mongos の両方で使用できます。

デフォルト: 1024

TCP Fast Open（TFO）接続を確立する一環として、クライアントは標準の TCP 3 ウェイハンドシェイクが完了する前に、有効な TFO クッキーを mongod/mongos に送信します。mongod/mongos は、保留中のすべての TFO 接続に対するキューを 1 つ保持します。

tcpFastOpenQueueSize パラメーターには、保留中の TFO 接続のキューのサイズを設定します。キューがいっぱいになると、mongod/mongos はクライアントからの受信リクエストに対して通常の 3 ウェイハンドシェイクに戻り、TFO クッキーの存在を無視します。キューのサイズが制限値を下回ると、 mongod/mongos は新しい TFO クッキーの受け入れを開始します。

デフォルトのキューサイズを増やすと、TFO がネットワークパフォーマンスに与える影響が改善される可能性があります。ただし、キューサイズが大きいと、過剰な受信 TFO リクエストによってサーバーリソースが枯渇するリスクも高まります。
デフォルトのキューサイズを小さくすると、過剰な受信 TFO リクエストによるリソースサーバーのリソース枯渇のリスクを軽減できます。ただし、キューのサイズが小さいと、ネットワークパフォーマンスに与える TFO の効果も小さくなる可能性があります。
キューの最小サイズは 0 です。0 のキューは、TFO を効果的に無効にします。

このパラメータは、TFO 接続をサポートしていない、または TFO 接続用に構成されていないホストオペレーティングシステムには影響しません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

disableJavaScriptJIT

mongod でのみ利用可能です。

MongoDB JavaScript エンジンは、SpiderMonkey を使用します。SpiderMonkey は、スクリプト実行中のパフォーマンスを向上させるためにJIT（Just-in-Time、実行時）コンパイルを実装しています。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

JIT を有効にするには、次の例のようにdisableJavaScriptJITをfalseに設定します。

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

注意

$whereは既存の JavaScript インタープリタコンテキストを再利用するため、disableJavaScriptJITへの変更はこれらの操作に対してすぐに有効にならない可能性があります。

あるいは、次のオプションを使用して mongod インスタンスを開始することにより、起動時に JIT を有効にすることもできます。

mongod --setParameter disableJavaScriptJIT=false

maxIndexBuildMemoryUsageMegabytes

デフォルト: 200

一度に1つのコレクションで実行されるインデックス構築が消費するメモリ量を、構築の期間中に制限します。指定されたメモリ量は、単一の createIndexes コマンドまたはそのシェルヘルパー db.collection.createIndexes() を使用して構築されるすべてのインデックス間で共有されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

インデックス構築によって消費されるメモリは、WiredTiger キャッシュメモリとは別です（詳細は cacheSizeGB を参照してください）。

maxIndexBuildMemoryUsageMegabytes は、インデックスのビルドが一度に使用するメモリの量の制限を設定します。これは、インデックス構築プロセスでインデックスのキーを生成およびソートする際のパフォーマンスに影響を与える可能性があります。メモリ制限を増やすと、インデックス構築中のソートパフォーマンスが向上します。

インデックスのビルドは、インデックスの作成などのユーザーコマンドまたは最初の同期などの管理プロセスによって開始される場合があります。どちらもmaxIndexBuildMemoryUsageMegabytesが設定した制限の対象となります。

最初の同期操作では一度に 1 つのコレクションのみが取り込まれるため、メモリ制限を超えるリスクはありません。ただし、ユーザーが複数のデータベースの複数のコレクションに対して同時にインデックスビルドを開始し、 maxIndexBuildMemoryUsageMegabytesで設定された制限以上のメモリを消費する可能性があります。

Tip

レプリカセットおよびレプリカセットシャードを含むシャーディングされたクラスターへのインデックス構築の影響を最小限に抑えるには、「レプリカセットでのローリングインデックス構築」で説明されているローリングインデックス構築手順を使用してください。

maxIndexBuildMemoryUsageMegabytesを変更しても、コレクションスキャンがすでに開始されている場合は、進行中のインデックスビルドには影響しません。ただし、レプリカセットを強制的に再構成すると、コレクションスキャンが再起動され、提供されている最新のmaxIndexBuildMemoryUsageMegabytesが使用されます。

機能の互換性バージョン (fcv) "4.2" 以降では、インデックス構築でのメモリ制限がすべてのインデックス構築に適用されます。

reportOpWriteConcernCountersInServerStatus

デフォルト: false

db.serverStatus() メソッドと serverStatus コマンドが opWriteConcernCounters 情報を返すかどうかを決定するブール値のフラグです。[1]

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

[1]	`reportOpWriteConcernCountersInServerStatus`を有効にするとパフォーマンスに悪影響が及ぶ可能性があります。（具体的には、TLSなしで実行している場合）。

watchdogPeriodSeconds

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: -1（無効）

ストレージノードウォッチドッグがモニター対象ファイルシステムのステータスをチェックする頻度を決定します。

--dbpath ディレクトリ
が有効な場合のディレクトリ内のjournal ディレクトリ--dbpathjournaling
--logpath ファイルのディレクトリ
--auditPath ファイルのディレクトリ

watchdogPeriodSecondsの有効な値は次のとおりです。

-1 （デフォルト）、Storage Node Watchdog を無効化もしくは一時停止します、または
60以上の整数。

注意

モニター対象ディレクトリのファイルシステムが応答しなくなった場合、を終了するには、の値の最大watchdogPeriodSeconds 2 倍mongod がかかることがあります
監視対象ディレクトリの中に他のボリュームへのシンボリックリンクである場合、Storage Node Watchdog はシンボリックリンクのターゲットの監視は行いません。たとえば、mongod が storage.directoryPerDB: true（または --directoryperdb）を使用してデータベースディレクトリを別のボリュームにシンボリックリンクする場合、Storage Node Watchdog はシンボリックリンクに従ってターゲットを監視することはありません。

Storage Node Watchdog を有効にするには、スタートアップ中にwatchdogPeriodSecondsを設定する必要があります。

mongod --setParameter watchdogPeriodSeconds=60

Storage Node Watchdog を有効にできるのは、スタートアップ時のみです。ただし、有効にすると、実行中に Storage Node Watchdog を一時停止したり、watchdogPeriodSecondsを変更したりできるようになります。

有効にすると、停止や変更に次の操作が必要です。

実行中に Storage Node Watchdog を一時停止するには、watchdogPeriodSecondsを -1に設定します。
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )
```
実行中に期間を再開または変更するには、 watchdogPeriodSecondsを60以上の数値に設定します。
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )
```

注意

watchdogPeriodSecondsスタートアップ時に Storage Node Watchdog が有効になっていない場合、実行時に設定するとエラーが発生します。

tcmallocAggressiveMemoryDecommit

タイプ: 整数（0 または 1 のみ）

デフォルト: 0

tcmallocAggressiveMemoryDecommit を有効にすると、MongoDB は次のように動作します。

メモリのチャンクをシステムに解放
隣り合うすべてのフリーチャンクを返そうとする

値が 1 の場合、tcmallocAggressiveMemoryDecommit が有効になり、値が 0 場合、このパラメータが無効になります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

このパラメータを有効にすると、システムでは新しいメモリ割り当てが必要になります。メモリが制限されたシステムでのみ、他のメモリおよびパフォーマンスオプションを検討した後で、tcmallocAggressiveMemoryDecommit を有効にすることを検討します。

tcmallocAggressiveMemoryDecommitを使用するとパフォーマンスが低下する可能性がありますが、 tcmallocReleaseRateを使用するよりも優先されます。

tcmallocReleaseRate

デフォルト: 1.0

tcmalloc の解放率（TCMALLOC_RELEASE_RATE）を指定します。https ://gperftools.github.io/gperftools/tcmalloc.html#runtime によれば、TCMALLOC_RELEASE_RATE は、「madvise(MADV_DONTNEED) をサポートするシステムで、未使用のメモリをシステムに解放するレートです。ゼロの場合、メモリを解放してシステムに戻さないことを意味します。このフラグを大きくするとメモリの戻りが速くなり、小さくするとメモリの戻りが遅くなります。妥当なレートは、[0,10] の範囲です」と説明されています。

注意

tcmallocAggressiveMemoryDecommittcmallocReleaseRateを使用した場合にパフォーマンスが大幅に低下しない限り、の代わりにtcmallocAggressiveMemoryDecommit を使用することを検討してください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

実行時にリリースレートを変更するには、setParameter コマンドを使用します。以下に例を示します。

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

起動時にtcmallocReleaseRateを設定することもできます。例:

mongod --setParameter "tcmallocReleaseRate=5.0"

ログパラメータ

logLevel

mongod と mongos の両方で使用できます。

ログの冗長度を表す 0 から 5 までの整数を指定します。5 が最も冗長度が高いことを表します。[2]

デフォルトのlogLevelは0 （情報）です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 logLevelを2に設定します。

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

Tip

以下も参照してください。

[2]	MongoDB バージョン 4.2 以降では、ログメッセージにデバッグの冗長レベル（1 ～ 5）が含まれるようになりました。たとえば、冗長レベルが 2 の場合、MongoDB は `D2` をログに出力します。以前のバージョンでは、MongoDB のログメッセージではデバッグレベルに `D` しか指定されていませんでした。

logComponentVerbosity

mongod と mongos の両方で使用できます。

ログメッセージのさまざまなコンポーネントの冗長レベルを設定します。冗長レベルにより、MongoDB が出力する情報メッセージとデバッグメッセージの量が決定されます。[3]

冗長レベルは次のように 0 から 5 までの範囲で指定できます。

0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。
1 冗長レベルを5 まで上げることによって、デバッグメッセージを含めることができます。

コンポーネントの場合、-1 を指定して親の冗長レベルを継承することもできます。

冗長レベルを指定するには、次のようなドキュメントを使用します。

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

コンポーネントについては、親コンポーネントと子コンポーネントの両方の冗長レベルの両方を設定する場合を除き、ドキュメント内の <component>: <int> だけを指定できます。

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

最上位の verbosity フィールドは、すべてのコンポーネントに対するデフォルトレベルを設定する systemLog.verbosity に対応します。systemLog.verbosity のデフォルト値は 0 です。

コンポーネントは、次の設定に対応しています。

明示的に設定されない限り、コンポーネントの冗長レベルは親の冗長レベルになります。たとえば、storage は storage.journal の親です。つまり、 storage の冗長レベルを指定すると、このレベルは次のコンポーネントにも適用されます。

storage.journal に対して冗長レベルを指定しない場合の、storage.journal。
storage.recovery に対して冗長レベルを指定しない場合の、storage.recovery。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次の例では、 default verbosity levelを1に、 queryを2に、 storageを2に、 storage.journalを1に設定します。

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

また、起動時にパラメータlogComponentVerbosityを設定して、冗長レベルドキュメントを string として渡すこともできます。

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

mongoshには、単一のコンポーネントのログレベルを設定するためのdb.setLogLevel() } も用意されています。ログの冗長レベルを設定するさまざまな方法については、「ログの冗長レベルの構成」を参照してください。

[3]	MongoDB バージョン 4.2 以降では、ログメッセージにデバッグの冗長レベル（1 ～ 5）が含まれるようになりました。たとえば、冗長レベルが 2 の場合、MongoDB は `D2` をログに出力します。以前のバージョンでは、MongoDB のログメッセージではデバッグレベルに `D` しか指定されていませんでした。

maxLogSizeKB

バージョン 3.4 で追加。

mongod と mongos の両方で使用できます。

型: 非負整数

デフォルト: 10

ログエントリの個々の属性フィールドの最大サイズをキロバイト単位で指定します。この制限を超える属性は切り捨てられます。

切り捨てられた属性フィールドでは、有効な JSON 形式が保持され、その制限を超えるとフィールド値がmaxLogSizeKBの制限まで表示されます。切り捨てられた属性を含むログ全体では、ログエントリの末尾にtruncatedオブジェクトが追加されます。

詳細については、「ログメッセージの切り捨て」を参照してください。

値が 0 の場合は、切り捨てを完全に無効にします。このパラメーターでは負の値は無効です。

警告

大きな値を使用するか、0 を指定して切り捨てを無効にすると、システムのパフォーマンスが悪くなり、データベース操作に悪影響を及ぼす可能性があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、最大ログ行サイズを20 キロバイトに設定します。

mongod --setParameter maxLogSizeKB=20

quiet

mongod と mongos の両方で使用できます。

quiet ロギングモードを設定します。1 の場合、mongod は quiet ロギングモードになり、次のイベントおよびアクティビティはログに記録されません。

接続イベント
drop コマンド、dropIndexes コマンド、validate コマンド、および
レプリケーション同期アクティビティ

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

quiet パラメーターに1 を設定する次の例えを考えてみます。

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

Tip

以下も参照してください。

systemLog.quiet

redactClientLogData

バージョン 3.4 で追加。

mongod と mongos の両方で使用できます。

タイプ: ブール値

注意

エンタープライズ機能

MongoDB Enterprise でのみ使用できます。

ロギングする前に、特定のログイベントに付随するメッセージをリダクションするには、mongodまたは mongos を構成します。これにより、データベースに格納されている機密性が高い可能性のあるデータをプログラムが診断ログに書き込むことを防止します。エラーコードや操作コード、行番号、ソースファイル名などのメタデータは、引き続きログに表示されます。

規制要件へのコンプライアンスの補助に、redactClientLogData を保管時の暗号化および TLS/SSL（トランスポート暗号化）と組み合わせて使用します。

スタートアップ時にログのリダクションを有効にするには、次のいずれかを実行します。

次のように、--redactClientLogData オプションで mongod を開始します。
```
mongod --redactClientLogData
```
構成ファイルで security.redactClientLogData オプションを設定します。
```
security:
   redactClientLogData: true
   ...
```

起動時に--setParameter redactClientLogDataを設定するためにオプションを使用することはできません。

実行中の mongod または mongos でログリダクションを有効にするには、次のコマンドを使用します。

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

Tip

以下も参照してください。

security.redactClientLogData

traceExceptions

mongod と mongos の両方で使用できます。

デバッグで使用するために、すべてのデータベース例外およびソケット C++ 例外の完全なソースコードスタックトレースをログに記録するように mongod を構成します。trueの場合、mongod は完全なスタックトレースをログに記録します。

このパラメーターは実行時にのみ使用できます。パラメーターを設定するには、 setParameterコマンドを使用します。

traceExceptions に true を設定する次の例を考えてみます。

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

Tip

以下も参照してください。

systemLog.traceAllExceptions

suppressNoTLSPeerCertificateWarning

mongod と mongos の両方で使用できます。

タイプ: ブール値

デフォルト: false

デフォルトでは、mongod mongosTLS/SSL が有効になっているまたはとnet.ssl.allowConnectionsWithoutCertificates :true により、クライアントは警告をログに記録しながら検証のための証明書を提供せずに接続できます。これらの警告を抑制するには、 suppressNoTLSPeerCertificateWarningを1またはtrueに設定します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

次の操作では、suppressNoTLSPeerCertificateWarning に true を設定します。

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

診断パラメータ

MongoDB エンジニアが MongoDB サーバーの動作を簡単に分析できるように、MongoDB は定期的にサーバーの統計情報を診断ファイルに記録します。

mongod の場合、診断データファイルは mongod インスタンスの --dbpath または storage.dbPath 配下のdiagnostic.data ディレクトリに保存されます

mongos の場合、診断データファイルは、デフォルトで、mongosインスタンスの --logpath または systemLog.path ディレクトリ配下ディレクトリに保存されます。診断データディレクトリは、ログパスのファイル拡張子を切り捨てて、残りの名前に diagnostic.data を連結することによって命名します。

例えば、mongos に --logpath /var/log/mongodb/mongos.log.201708015がある場合、データディレクトリは /var/log/mongodb/mongos.diagnostic.data/ ディレクトリです。mongosに別の診断データディレクトリを指定するには、diagnosticDataCollectionDirectoryPathパラメーターを設定します。

次のパラメータは診断データ取得（FTDC）をサポートします。

注意

診断データの取得間隔および最大サイズのデフォルト値は、パフォーマンスとストレージサイズへの影響を最小限に抑えながら、MongoDB エンジニアに有用なデータを提供するために選択されています。通常、これらの値は、特定の診断目的のために MongoDB エンジニアから要求がある場合にのみ変更する必要があります。

diagnosticDataCollectionEnabled

バージョン 3.2 で追加。

バージョン3.4.14での変更: mongodとmongosの両方で利用できます。

タイプ: ブール値

デフォルト: true

診断目的でデータの収集とログの記録を有効にするかどうかを決定します。診断用ログの記録はデフォルトで有効になっています。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次のようにすると、診断コレクションが無効になります。

mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionDirectoryPath

バージョン3.4.14の新機能。

タイプ: string

mongos でのみ利用可能です。

mongos の診断ディレクトリを指定します。ディレクトリが存在しない場合は、mongos がディレクトリを作成します。

指定されていない場合、診断データディレクトリは、mongos インスタンスの --logpath ファイル拡張子または systemLog.path ファイル拡張子を切り捨て、diagnostic.data を連結することによって命名されます。

たとえば、 mongos が --logpath /var/log/mongodb/mongos.log.201708015 を保有している場合、診断データディレクトリは /var/log/mongodb/mongos.diagnostic.data/ になります。

重要

mongosが指定されたディレクトリを作成できない場合、そのインスタンスの診断データ取得は無効になります。これは多くの場合、次のことが原因で発生します。

パス上に同じ名前のファイルが既に存在する、または
プロセスにはディレクトリを作成する権限がありません。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

diagnosticDataCollectionDirectorySizeMB

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 200

diagnostic.dataディレクトリの最大サイズをメガバイト単位で指定します。ディレクトリのサイズがこの数を超えると、ファイル名のタイムスタンプに基づいて、ディレクトリ内の最も古い診断ファイルが自動的に削除されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次の例では、ディレクトリの最大サイズを 250 メガバイトに設定します。

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

diagnosticDataCollectionDirectorySizeMBの最小値は10メガバイトです。diagnosticDataCollectionDirectorySizeMBは、最大診断ファイルサイズdiagnosticDataCollectionFileSizeMBより大きくなければなりません。

diagnosticDataCollectionFileSizeMB

バージョン 3.2 で追加。

バージョン3.4.14での変更: mongodとmongosの両方で利用できます。

タイプ: 整数

デフォルト: 10

各診断ファイルの最大サイズをメガバイト単位で指定します。ファイルの最大ファイルサイズを超える場合、MongoDB は新しいファイルを作成します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次の例では、各診断ファイルの最大サイズを 20 メガバイトに設定します。

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

diagnosticDataCollectionFileSizeMBの最小値は1メガバイトです。

diagnosticDataCollectionPeriodMillis

バージョン 3.2 で追加。

バージョン3.4.14での変更: mongodとmongosの両方で利用できます。

タイプ: 整数

デフォルト: 1000

診断データを収集する間隔をミリ秒単位で指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、次の例では間隔を5000 ミリ秒（5 秒）に設定します。

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

diagnosticDataCollectionPeriodMillisの最小値は100ミリ秒です。

レプリケーションと整合性

disableSplitHorizonIPCheck

バージョン 5.0.0 の新機能。

mongod と mongos の両方で使用できます。

タイプ: ブール値

デフォルト: false

スプリットホライズンDNS のクラスターノードを構成するには IP アドレスの代わりにホスト名を使用します。

MongoDB v5.0 以降の replSetInitiate と replSetReconfig では、ホスト名の代わりに IP アドレスを使用する設定は拒否します。

ホスト名を使用するように更新できないノードを変更するには、 disableSplitHorizonIPCheckを使用します。このパラメーターはコンフィギュレーションコマンドにのみ適用されます。

mongodおよびmongosは、スタートアップ時の検証に関してdisableSplitHorizonIPCheckに依存しません。ホスト名の代わりに IP アドレスを使用する従来のmongodおよびmongosインスタンスは、アップグレード後に起動できます。

IP アドレスで設定されたインスタンスでは、IP アドレスの代わりにホスト名を使用するように警告がログに記録されます。

スプリットホライズンDNS のクラスターノードを構成するには IP アドレスの代わりにホスト名を使用します。

MongoDB v5.0 以降の replSetInitiate と replSetReconfig では、ホスト名の代わりに IP アドレスを使用する設定は拒否します。

IP アドレスで設定されたインスタンスでは、IP アドレスの代わりにホスト名を使用するように警告がログに記録されます。

IP アドレスを使用した構成の変更を行うには、次のコマンドラインを使用して disableSplitHorizonIPCheck=true を設定します。

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

IP アドレスを使用した構成の変更を行うには、ノードの構成ファイルを使用してdisableSplitHorizonIPCheck=trueを設定します。

setParameter:
   disableSplitHorizonIPCheck: true

実行時にdisableSplitHorizonIPCheckを更新しようとすると、 db.adminCommand()はエラーを返します。

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

enableOverrideClusterChainingSetting

バージョン 5.0.2 の新機能。

mongod と mongos の両方で使用できます。

タイプ: ブール値

デフォルト: false

enableOverrideClusterChainingSetting が true の場合、レプリカセットのセカンダリノードは、settings.chainingAllowed が false であっても、他のセカンダリノードからデータを複製できます。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、インスタンスのをに設定するには、次の手順に従います。enableOverrideClusterChainingSettingmongodtrue

mongod --setParameter enableOverrideClusterChainingSetting=true

logicalSessionRefreshMillis

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 300000（5 分）

キャッシュがメインセッションストアに対して論理セッションレコードをリフレッシュする間隔（ミリ秒単位）。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

logicalSessionRefreshMillismongodたとえば、10 インスタンスのを分に設定するには、次の手順に従います。

mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes

バージョン 3.6 の新機能。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 30

警告

テスト目的のみ

このパラメーターはテスト目的のみで使用するものであり、本番環境での使用を目的としたものではありません。

セッションが最後に使用されてからアクティブな状態である時間（分単位）。クライアントから新しい読み取りもしくは書き込み操作を受信していないセッション、またはこのしきい値内に refreshSessions で更新されていないセッションは、キャッシュからクリアされます。期限切れのセッションに関連付けられた状態は、サーバーによっていつでもクリーンアップされる可能性があります。

このパラメーターは、それが設定されているインスタンスにのみ適用されます。レプリカセットとシャーディングされたクラスターにこのパラメーターを設定するには、すべてのノードに同じ値を指定する必要があります。そうでない場合は、セッションが正しく機能しません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

localLogicalSessionTimeoutMinutesたとえば、テスト用mongod 20インスタンスのを分に設定するには、次の手順を実行します。

mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs

バージョン 3.6 の新機能。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト：31536000（1年）

現在のクラスター時間を進める最大量。具体的には、 maxAcceptableLogicalClockDriftSecsはクラスター時間の新しい値と現在のクラスター時間の最大差です。クラスター時間は、操作の順序付けに使用される論理時間です。

新しいクラスター時間が現在のクラスター時間とmaxAcceptableLogicalClockDriftSecsを超えて異なる場合、クラスター時間を新しい値に進めることはできません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

maxAcceptableLogicalClockDriftSecsmongodたとえば、15 インスタンスのを分に設定するには、次の手順に従います。

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 1000000

キャッシュできるセッションの最大数です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、インスタンスのをに設定するには、次の手順に従います。maxSessionsmongod1000

mongod --setParameter maxSessions=1000

oplogBatchDelayMillis

バージョン 5.0.10 の新機能。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 0

セカンダリノードで oplog 操作のバッチの適用を遅延させる時間（ミリ秒数）。デフォルトでは、oplogBatchDelayMillis は 0 であり、oplog バッチが遅延なく適用されることを意味します。遅延がない場合、MongoDB は頻繁に小さな oplog バッチをセカンダリに適用することがあります。

oplogBatchDelayMillisを増やすと、MongoDB はセカンダリに oplog バッチを適用する頻度が低くなり、各バッチに含まれるデータの量が増えます。これにより、セカンダリの IOPSは削減されますが、書込み保証 (write concern "majority"による書込みのレイテンシが増加します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、mongod インスタンスのoplogBatchDelayMillis を 20 ミリ秒に設定するには、次のコマンドを実行します。

mongod --setParameter oplogBatchDelayMillis=20

periodicNoopIntervalSecs

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

各ノードでの noop の書込み (write) 間隔（秒単位）。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

注意

MongoDB Atlas クラスターのこの値を変更するには、Atlas サポートに問い合わせる必要があります。

次の例では、起動時に periodicNoopIntervalSecs を 1 秒に設定します。

mongod --setParameter periodicNoopIntervalSecs=1

storeFindAndModifyImagesInSideCollection

バージョン 5.0 で追加

mongod と mongos の両方で使用できます。

タイプ: ブール値

デフォルト: false

再試行可能なfindAndModifyコマンドに必要な一時ドキュメントをサイドコレクション（コンフィギュレーションデータベース内のimage_collection ）に保存するかどうかを決定します。

storeFindAndModifyImagesInSideCollectionがの場合:

true一時的なドキュメントはサイドコレクションに保存されます。
falseの場合、一時ドキュメントはレプリカセット oplog にストアされます。

次の場合は、 storeFindAndModifyImagesInSideCollectionをtrueに設定しておきます。

再試行可能な大規模な findAndModify ワークロードがある。
再試行可能な findAndModify コマンドには、レプリカセット oplog で使用可能なスペースよりも多くの一時ドキュメントスペースが必要です。

注意

storeFindAndModifyImagesInSideCollectionがtrueの場合、セカンダリで CPU 使用率が増加する可能性があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、起動時にstoreFindAndModifyImagesInSideCollectionをfalseに設定するには、次のようにします。

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

TransactionRecordMinimumLifetimeMinutes

バージョン 3.6 の新機能。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30

レコードがクリーンアップの対象となるまでに transactions コレクションにトランザクションレコードが存在する最低限の期間です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

TransactionRecordMinimumLifetimeMinutesmongodたとえば、20 インスタンスのを分に設定するには、次の手順に従います。

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

以下も参照してください。

localLogicalSessionTimeoutMinutes

enableFlowControl

タイプ: ブール値

デフォルト: true

セカンダリノードの majority committed ラグを構成可能上限以下に保つことを目的として、プライマリが書き込みを行うレートを制御するメカニズムを有効または無効にします。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

注意

フロー制御を有効にするには、レプリカセットおよびシャーディングされたクラスターは、4.2 の FCV（featureCompatibilityVersion）を有し、かつ読み取り保証（read concern）がmajority enabled である必要があります。つまり、FCV が 4.2 でない場合や、読み取り保証（read concern）の過半数が無効になっている場合、フロー制御を有効にしても効果はありません。

flowControlTargetLagSeconds

タイプ: 整数

デフォルト: 10

フロー制御で実行する場合に指標となる最大 majority committed ラグです。フロー制御が有効になっている場合、このメカニズムでは majority committed ラグを指定された秒数未満に維持しようとします。フロー制御が無効になっている場合、このパラメーターによる影響はありません。

0 より大きい値を指定しなければなりません。

一般的には、デフォルト設定のままで十分ですが、デフォルト値を変更する場合、値を増やすのではなく減らした方がより有用な場合があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

flowControlWarnThresholdSeconds

タイプ: 整数

デフォルト: 10

フロー制御メカニズムが過半数のコミットポイントが移動していないことを検出してからログに警告を記録するまでの待ち時間。

指定する値は 0 以上である必要があり、0 の場合は警告が無効になります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

initialSyncTransientErrorRetryPeriodSeconds

タイプ: 整数

デフォルト: 86400

一時的なネットワークエラーによって中断された場合に、最初の同期を実行するセカンダリがプロセスの再開を試みる時間（秒単位）。デフォルト値は 24 時間に相当します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

initialSyncSourceReadPreference

mongod でのみ利用可能です。

タイプ: string

最初の同期を実行するための推奨ソースです。次のいずれかの読み込み設定 (read preference) モードを指定します。

primary
primaryPreferred （レプリカセットのノードに投票するためのデフォルト値）
secondary
secondaryPreferred
nearest（新しく追加されたレプリカセットノードまたは投票権のないレプリカセットノードのデフォルト）

レプリカセットでchainingが無効になっている場合、デフォルトのinitialSyncSourceReadPreference読み込み設定（read preference）モードはprimaryです。

タグセットまたはmaxStalenessSecondsをinitialSyncSourceReadPreferenceに指定することはできません。

mongod が指定された読み込み設定 (read preference) に基づいて同期ソースを見つけられない場合は、エラーをログに記録し、最初の同期プロセスを再開します。10 回試行した後に最初の同期プロセスを完了できない場合、mongod はエラーで終了します。同期ソースの選択の詳細については、「最初の同期ソースの選択」を参照してください。

最初の同期ソースを選択すると、 initialSyncSourceReadPreferenceはレプリカセットのsettings.chainingAllowed設定よりも優先されます。レプリカセットメンバーが最初の同期を正常に完了した後、レプリケーション同期ソースを選択する際は、 chainingAllowedの値に従います。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

maxNumSyncSourceChangesPerHour

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 3

同期ソースは、同期ソースが更新されるたび、およびノードが oplog エントリのバッチを取得するたびに評価されます。1 時間に maxNumSyncSourceChangesPerHour を超えるソース変更があった場合、ノードはその同期ソースの再評価を一時的に停止します。このパラメーターに大きい値を設定すると、ノードが不要なソース変更を行う可能性があります。

このパラメーターは、ノードが同期ソースを持っていない場合、ノードが別のノードから同期を開始するのを防ぐものではありません。同期ソースが無効になると、ノードは再評価を行います。同様に、プライマリが変更されてチェーニングが無効になっている場合、ノードは新しいプライマリと同期するように更新されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

oplogFetcherUsesExhaust

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

ストリーミングレプリケーションを有効または無効にします。ストリーミングレプリケーションを有効にするには、値を true に設定します。

ストリーミングレプリケーションを無効にするには、値を false に設定します。無効にすると、セカンダリはソースから同期のリクエストを発行して応答を待つことで、oplog エントリのバッチを取得します。これには、oplog エントリのバッチごとにネットワーク上の往復が必要です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

oplogInitialFindMaxSeconds

バージョン 3.6 の新機能。

タイプ: 整数

デフォルト: 60

mongod でのみ利用可能です。

データ同期中、レプリカセットのノードが find コマンドの完了まで待機する最長時間（秒）です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

replWriterThreadCount

バージョン 3.2 で追加。

タイプ: 整数

デフォルト: 16

mongod でのみ利用可能です。

複製された操作を並列に適用するために使用するスレッドの最大数。値の範囲は 1 から 256 までです。ただし、使用されるスレッドの最大数は、使用可能なコア数の 2 倍に制限されます。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

replWriterMinThreadCount

replWriterMinThreadCount

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 0

mongod でのみ利用可能です。

複製された操作を並列に適用するために使用するスレッドの最小数。値の範囲は 0 から 256 までです。replWriterMinThreadCountはスタートアップでのみ設定でき、setParameterコマンドでこの設定を変更することはできません。

レプリケーション操作の並列適用では最大replWriterThreadCountのスレッドが使用されます。replWriterMinThreadCountがreplWriterThreadCount未満の値で構成されている場合、スレッドプール内のスレッドの合計数がreplWriterMinThreadCountになるまで、スレッドプールはアイドルスレッドをタイムアウトします。

replWriterMinThreadCountは、 replWriterThreadCount以下の値で構成する必要があります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

rollbackTimeLimitSecs

型: 64 ビット整数

デフォルト: 86400（1 日）

ロールバックできるデータの最大経過時間。このパラメーターでは負の値は無効です。

ロールバック対象インスタンスの oplog が終了してから、共通点（ソースノードとロールバック対象ノードが同じデータを持っていた最後のポイント）の後の最初の操作までの時間がこの値を超えると、ロールバックは失敗します。

実質的に無制限のロールバック期間を設定するには、値を 2147483647 に設定します。これは許容される最大値であり、約 68 年に相当します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

waitForSecondaryBeforeNoopWriteMS

バージョン 3.6 の新機能。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

afterClusterTime が oplog から最後に適用された時間よりも大きい場合にセカンダリが待機する必要がある時間（ミリ秒単位）。waitForSecondaryBeforeNoopWriteMS が経過した後に、afterClusterTime が最後に適用された時間よりもまだ大きい場合、セカンダリは最後に適用された時間を進めるためにノーオペレーション（no-op）書き込みを行います。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 waitForSecondaryBeforeNoopWriteMSを20ミリ秒に設定します。

mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

createRollbackDataFiles

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

MongoDB がロールバック中に影響を受けたドキュメントを含むロールバックファイルを作成するかどうかを決定するフラグです。

デフォルトでは、createRollbackDataFilesはtrueであり、MongoDB はロールバックファイルを作成します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 createRollbackDataFilesを false に設定して、ロールバックファイルは作成されません。

mongod --setParameter createRollbackDataFiles=false

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

詳細については、「ロールバックデータの収集」を参照してください。

replBatchLimitBytes

Default: 104857600 (100MB)

oplog アプリケーションの最大バッチサイズをバイト単位で設定します。

値の範囲は 16777216（16 MB）から 104857600（100 MB）までです。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、ロールバックファイルは作成されないように、 replBatchLimitBytesを64 MB に設定しています。

mongod --setParameter replBatchLimitBytes=67108864

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

mirrorReads

mongod でのみ利用可能です。

バージョン 4.4 で追加。

型: ドキュメント

デフォルト: { samplingRate: 0.01, maxTimeMS: 1000 }

mongod インスタンスのミラーリングされた読み取りの設定を指定します。設定が有効になるのは、そのノードがプライマリである場合のみです。

パラメーターmirrorReadsは、次のフィールドを含む JSON document を受け取ります。

フィールド

説明

samplingRate

ミラーリングをサポートする操作のサブセットを、選択可能なセカンダリ（具体的には priority greater than 0）のサブセットへミラーリングするために使用するサンプリングレート。つまり、プライマリは、指定されたサンプリングレートで選択可能な各セカンダリに読み取りをミラーリングします。

有効な値は次のとおりです。

`0.0`	ミラーリングをオフにします。
`1.0`	プライマリは、ミラーリングをサポートするすべての操作を、選挙可能な各セカンダリにミラーリングします。
`0.0` から `1.0` までの数字（両端を含まない）	プライマリは、選択可能な各セカンダリを指定されたレートでランダムにサンプリングし、ミラーリングされた読み取りを送信します。

たとえば、プライマリと 2 つの選択可能なセカンダリがあり、サンプリングレートが 0.10 のレプリカセットでは、プライマリは選択可能な各セカンダリに対して 10% のサンプリングレートで読み取りをミラーリングします。これにより、ある読み取りは一方のセカンダリにミラーリングされ、もう一方のセカンダリにはミラーリングされない、または両方にミラーリングされる、もしくはどちらにもミラーされない場合があります。つまり、プライマリがミラーリング可能な 100 の操作を受け取った場合、サンプリングレートが 0.10 では、一方のセカンダリには 8 個の読み取りが、もう一方のセカンダリには 13 個の読み取りがミラーリングされたり、それぞれに 10 個の読み取りがミラーリングされたりという結果になります。

デフォルト値は 0.01 です。

maxTimeMS

ミラーリングされた読み取りの最大時間（ミリ秒単位）。デフォルト値は 1000 です。

ミラーリングされた読み取りの maxTimeMS は、ミラーリングされる元の読み取りの maxTimeMS とは異なります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

構成ファイルから、またはコマンドラインでを指定する場合は、 mirrorReadsドキュメントを引用符で囲みます。

たとえば、次の例では、コマンドラインからミラーリング読み取りのサンプリングレートを 0.10 に設定します。

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

または、構成ファイルに次のように指定します。

setParameter:
   mirrorReads: '{samplingRate: 0.10}'

または、実行中のsetParameter mongoshに接続されているセッションでmongod コマンドを使用する場合は、ドキュメントを引用符で囲みません。

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

シャーディングパラメータ

balancerMigrationsThrottlingMs

バージョン5.0.18の新機能。

タイプ: 整数

デフォルト: 1000

mongod でのみ利用可能です。

連続する 2 つのバランシングラウンド間隔の最小時間を指定します。これにより、バランシングレートを調整できます。このパラメーターは、コンフィギュレーションサーバーノードでのみ有効です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時に balancerMigrationsThrottlingMs を 2000 ミリ秒に設定しています。

mongod --setParameter balancerMigrationsThrottlingMs=2000

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

chunkMigrationConcurrency

MongoDB 5.0.15以降で利用可能。

タイプ: 整数

デフォルト: 1

mongod でのみ利用可能です。

チャンク移行のソースシャードと受信シャードのスレッド数を設定する整数を指定します。チャンク移行では、ソースシャードと受信シャードの両方について、受信側のシャードに設定したスレッド数を使用します。

同時実行数を増やすと、チャンク移行のパフォーマンスは向上しますが、ソースシャードと受信シャードのワークロードとディスク IOPS の使用量も増加します。

最大値は 500 です。

通常、CPU コアの全体数の半分をスレッドとして使用する必要があります。たとえば、コアが全部で 16 個の場合、 chunkMigrationConcurrency に 8 スレッド（またはそれ以下）を設定します。

chunkMigrationConcurrencyが1より大きい場合、 _secondaryThrottle構成設定は無視されます。 _secondaryThrottle設定は、チャンクの移行がチャンク内の次のドキュメントに進むタイミングを決定します。詳細については、「チャンクの移行とレプリケーション」を参照してください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、chunkMigrationConcurrency に 5 を設定します。

mongod --setParameter chunkMigrationConcurrency=5

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

disableResumableRangeDeleter

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

シャードのプライマリに設定されている場合、シャードで範囲の削除を一時停止するかどうかを指定します。 trueに設定すると、 :: 孤立したドキュメントを含むチャンク範囲のクリーンアップが一時停止されます。シャードは引き続き他のシャードにチャンクを提供できますが、提供されたドキュメントは、このパラメータをfalseに設定するまで、このシャードから削除されません。このシャードは、受信チャンクの範囲と重複するconfig.rangeDeletionsコレクションに保留中の範囲削除タスクがない限り、他のシャードからチャンクを引き続き受け取ることができます。

disableResumableRangeDeleter が trueの場合、孤立したドキュメントが受信チャンクと同じ範囲の受信シャードのプライマリサーバーに存在する場合、チャンクの移行は失敗します。

シャードのプライマリでない場合、このパラメーターは mongod には影響しません。

重要

disableResumableRangeDeleter パラメーターを true に設定する場合は、シャードのレプリカセット内のすべてのノードに一貫して適用するようにしてください。フェイルオーバーが発生した場合、新しいプライマリでのこの設定値によって範囲削除の動作が決まります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongod --setParameter disableResumableRangeDeleter=false

enableShardedIndexConsistencyCheck

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

コンフィギュレーションサーバーのプライマリに設定されている場合、シャーディングされたコレクションのインデックス整合性チェックを有効または無効にします。コンフィギュレーションサーバーのプライマリでない場合、このパラメーターは mongod には影響しません。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、コンフィギュレーションサーバーのプライマリでenableShardedIndexConsistencyCheckをfalseに設定します。

mongod --setParameter enableShardedIndexConsistencyCheck=false

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

Tip

以下も参照してください。

shardedIndexConsistencyCheckIntervalMS parameter
shardedIndexConsistency コマンドによって返された serverStatus メトリクス。

opportunisticSecondaryTargeting

バージョン 5.0.10 の新機能。

タイプ: ブール値

デフォルト: false

mongos でのみ利用可能です。

mongosレプリカセットに対して便宜的読み取りを実行するかどうかを決定します。

このパラメーターに true が設定されている場合、mongos はアクティブな接続を持つセカンダリにセカンダリ読み取りを指示します。接続を受け入れた最初のセカンダリにリクエストを送ります。このパラメーターに false が設定されている場合、mongos は、特定のセカンダリへの接続を確立できるまでセカンダリ読み取りを保持します（ヘッジされた読み取りの場合を除く）。

注意

特定のワークロードでは、便宜的読み取りによって mongos から mongod への不要な接続が発生し、全体的なパフォーマンスが低下する可能性があります。アプリケーションでこの機能が個別に必要な場合を除き、このパラメーターを有効にしないでください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、起動時に opportunisticSecondaryTargetingを設定するには、次のようにします。

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600000

コンフィギュレーションサーバーのプライマリに設定されている場合、コンフィギュレーションサーバーのプライマリがシャーディングされたコレクションのインデックスの整合性をチェックする間隔（ミリ秒単位）です。コンフィギュレーションサーバーのプライマリでない場合、このパラメーターは mongod には影響しません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、次の例では、起動時に間隔を 300000 ミリ秒（5 分）に設定します。

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

以下も参照してください。

enableShardedIndexConsistencyCheck parameter
shardedIndexConsistencyコマンドによって返されたメトリクス serverStatus

enableFinerGrainedCatalogCacheRefresh

mongod と mongos の両方で使用できます。

タイプ: ブール値

デフォルト: true

このパラメータにより、シャードを更新する必要がある場合にのみカタログキャッシュを更新可能になります。無効の場合、古いチャンクがあると、コレクションのチャンク配布全体が古いと見なされ、シャードにアクセスするすべてのルーターにシャードカタログキャッシュの更新が強制されます。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

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

Tip

以下も参照してください。

maxTimeMSForHedgedReads

mongos でのみ利用可能です。

タイプ: 整数

デフォルト: 150

ヘッジされた読み取りの最大時間制限（ミリ秒単位）を指定します。つまり、読み取り操作をヘッジするために送信される追加の読み取りでは、 maxTimeMSForHedgedReadsのmaxTimeMS値が使用され、ヘッジされている読み取り操作では、操作に指定されたmaxTimeMS値が使用されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、制限を 200 ミリ秒に設定するには、起動時に以下を発行します。

mongos --setParameter maxTimeMSForHedgedReads=200

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

Tip

以下も参照してください。

maxCatchUpPercentageBeforeBlockingWrites

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

moveChunk操作の場合、 catchupフェーズからcommitフェーズに移行するために移行プロトコルによって許可される未転送データの最大パーセンテージ（合計チャンクサイズの割合で表す）を指定します。

キャッチアップ率を高く設定すると、移行が完了するまでの時間は短縮されますが、upsert および delete 操作の同時実行時のレイテンシが高くなります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、最大パーセンテージを 20 に設定するには、起動時に以下を発行します。

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

Tip

以下も参照してください。

ライブ移行プロトコル

metadataRefreshInTransactionMaxWaitBehindCritSecMS

バージョン 5.2 の新機能（5.1.0、5.0.4 以降でも利用可能）

タイプ: 整数

デフォルト: 500

mongod でのみ利用可能です。

トランザクション内の重要なセクションに対するシャードの待ち時間を制限します。

クエリがシャードにアクセスしたときに、チャンク移行またはDDL 操作によってコレクションのクリティカルセクションがすでに専有されている可能性があります。クエリでクリティカルセクションが専有されていることが検出された場合、シャードはクリティカルセクションが解放されるまで待機します。シャードが制御を mongos に戻すと、mongos はクエリを再試行します。ただし、マルチシャードトランザクションが、複数のシャードのクリティカルセクションを占有する操作とやりとりする場合、そのやりとりにより分散デッドロックが発生する可能性があります。

metadataRefreshInTransactionMaxWaitBehindCritSecMS は、クリティカルセクションが解放されるまで、シャードがトランザクション内で待機する最大時間を制限します。

トランザクション内のクリティカルセクションの最大待機時間を短縮するには、 metadataRefreshInTransactionMaxWaitBehindCritSecMSの値を低くします。

警告

metadataRefreshInTransactionMaxWaitBehindCritSecMSが低すぎる場合、 mongosは再試行をすべて使用してエラーを返す可能性があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、metadataRefreshInTransactionMaxWaitBehindCritSecMSを 400 ミリ秒に設定するには、次のようにします。

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

readHedgingMode

mongos でのみ利用可能です。

型: string

デフォルト: オン

読み込み設定（read preference）でヘッジされた読み取りオプションが有効になっている読み取り操作に対して、mongos がヘッジされた読み取りをサポートするかどうかを指定します。

使用可能な値は次のとおりです。

値	説明
`on`	`mongos` インスタンスは、読み込み設定（read preference）でヘッジされた読み取りオプションが有効になっている読み取り操作に対してヘッジされた読み取りをサポートします。
`off`	`mongos` インスタンスはヘッジされた読み取りをサポートしていません。つまり、読み込み設定（read preference）でヘッジされた読み取りオプションが有効になっている読み取り操作であっても、ヘッジされた読み取りは使用できません。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、mongos インスタンスでヘッジされた読み取りサポートを無効にするには、起動時に以下を実行します。

mongos --setParameter readHedgingMode=off

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

Tip

以下も参照してください。

routingTableCacheChunkBucketSize

バージョン5.0.21の新機能。

mongod と mongos の両方で使用できます。

タイプ: 整数

デフォルト: 500

チャンクグループ最適化の実装に使用されるルーティングテーブルキャッシュのバケットのサイズを指定します。0 以上である必要があります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

たとえば、mongod のキャッシュチャンクバケットサイズを 250 に設定するには、起動時に次のコマンドを実行します。

mongod --setParameter routingTableCacheChunkBucketSize=1000

shutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 15000

mongod でのみ利用可能です。

SIGTERM シグナルに応答して mongod のシャットダウンを開始する前に、進行中のデータベース操作が完了するまで待機する時間（ミリ秒単位）を指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、時間を 250 ミリ秒に設定するには、起動時に次のコマンドを発行します。

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

または実行中のに接続されているsetParametermongoshmongod セッションでコマンドを使用する場合は以下のようになります。

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

mongosShutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 15000

mongos でのみ利用可能です。

SIGTERM シグナルに応答して mongos のシャットダウンを開始する前に、進行中のデータベース操作が完了するまで待機する時間（ミリ秒単位）を指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、時間を 250 ミリ秒に設定するには、起動時に次のコマンドを発行します。

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

ShardingTaskExecutorPoolHostTimeoutMS

型: 整数

デフォルト: 300000（5 分）

mongod と mongos の両方で使用できます。

mongos がホストへのすべての接続を切断するまでに、mongos でホストとの通信が無い最大時間。

設定されている場合、ShardingTaskExecutorPoolHostTimeoutMSは、ShardingTaskExecutorPoolRefreshRequirementMSおよびShardingTaskExecutorPoolRefreshTimeoutMSの合計よりも大きくする必要があります。それ以外の場合、mongosはShardingTaskExecutorPoolHostTimeoutMSの値を合計より大きくなるように調整します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolHostTimeoutMSを120000に設定します。

mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolMaxConnecting

バージョン 3.6 の新機能。

型: 整数

デフォルト: 2

mongod と mongos の両方で使用できます。

各 TaskExecutor 接続プールが mongod インスタンスに対して持つことができる同時開始接続の最大数（セットアップまたはリフレッシュ状態の保留中の接続を含む）。このパラメーターを設定すると、mongos が mongod インスタンスに接続を追加するレートを制御できます。

設定されている場合、 ShardingTaskExecutorPoolMaxConnectingはShardingTaskExecutorPoolMaxSize以下である必要があります。値が大きい場合、 mongosはShardingTaskExecutorPoolMaxConnectingの値を無視します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolMaxConnectingを20に設定します。

mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolMaxSize

型: 整数

デフォルト: 2 ⁶⁴ - 1

mongod と mongos の両方で使用できます。

各 TaskExecutor 接続プールが任意の mongod インスタンスに対して開くことができるアウトバウンド接続の最大数。すべての TaskExecutor プールにおいて、任意のホストへの最大接続数は次のとおりです。

ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolMaxSizeを20に設定します。

mongos --setParameter ShardingTaskExecutorPoolMaxSize=20

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

mongosは最大n TaskExecutor 接続プールを持つことができます。ここで、 nはコアの数です。詳しくはtaskExecutorPoolSizeを参照してください。

Tip

以下も参照してください。

ShardingTaskExecutorPoolMinSize

ShardingTaskExecutorPoolMaxSizeForConfigServers

バージョン 5.0.10 の新機能。

型: 整数

デフォルト: -1

mongod と mongos の両方で使用できます。

ShardingTaskExecutorPoolMaxSize各 TaskExecutor 接続プールが構成サーバーに対して開始できるアウトバウンド接続の最大数を設定するためのの任意の上書きです。

設定値:

-1で、ShardingTaskExecutorPoolMaxSizeが使用されます。これがデフォルトです。
-1 より大きい整数値の場合、各 TaskExecutor 接続プールが構成サーバーに対し開始できるアウトバウンド接続の最大数を上書きします。

パラメータはシャーディングされた配置にのみ適用されます。

次の例では、スタートアップ時にShardingTaskExecutorPoolMaxSizeを2に設定し、各 TaskExecutor 接続プールが構成サーバーに開くことができる送信接続の最大数を2に設定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

mongos --setParameter ShardingTaskExecutorPoolMaxSizeForConfigServers=2

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolMinSize

型: 整数

デフォルト: 1

mongod と mongos の両方で使用できます。

各 TaskExecutor 接続プールが任意の mongod インスタンスに対して開くことができるアウトバウンド接続の最小数。

ShardingTaskExecutorPoolMinSize で、プールから新しいホストへの接続が初めて要求されたときに、接続が作成されます。プールがアイドル状態の間、そのプールを使用するアプリケーションがない状態でShardingTaskExecutorPoolHostTimeoutMSミリ秒が経過するまで、プールはこの数の接続を維持します。

warmMinConnectionsInShardingTaskExecutorPoolOnStartupパラメーターを使用するmongosの場合、ShardingTaskExecutorPoolMinSizeパラメーターはmongosインスタンスのスタートアップ時にクライアントからの着信接続を受け入れる前に、各シャードホストに確立される接続数も制御します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolMinSizeを2に設定します。

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

mongosは最大n TaskExecutor 接続プールを持つことができます。ここで、 nはコアの数です。詳しくはtaskExecutorPoolSizeを参照してください。

Tip

以下も参照してください。

ShardingTaskExecutorPoolMaxSize
warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolMinSizeForConfigServers

バージョン 5.0.10 の新機能。

型: 整数

デフォルト: -1

mongod と mongos の両方で使用できます。

ShardingTaskExecutorPoolMinSize各 TaskExecutor 接続プールが構成サーバーに対して開始できるアウトバウンド接続の最小数を設定するためのの任意の上書きです。

設定値:

-1で、ShardingTaskExecutorPoolMinSizeが使用されます。これがデフォルトです。
-1 より大きい整数値の場合、各 TaskExecutor 接続プールが構成サーバーに対し開始できるアウトバウンド接続の最小数を上書きします。

パラメータはシャーディングされた配置にのみ適用されます。

次の例では、起動時にShardingTaskExecutorPoolMinSizeを2に設定します。これにより、各 TaskExecutor 接続プールが構成サーバーに対して開始できるアウトバウンド接続の最小数が2に設定されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

mongos --setParameter ShardingTaskExecutorPoolMinSizeForConfigServers=2

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolRefreshRequirementMS

型: 整数

デフォルト: 60000（1 分）

mongod と mongos の両方で使用できます。

プール内のアイドル接続をハートビートするまでにmongosが待機する最大時間。

設定されている場合、 ShardingTaskExecutorPoolRefreshRequirementMSはShardingTaskExecutorPoolRefreshTimeoutMSより大きくする必要があります。それ以外の場合、 mongosはShardingTaskExecutorPoolRefreshTimeoutMSの値をShardingTaskExecutorPoolRefreshRequirementMSより小さくなるように調整します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolRefreshRequirementMSを90000に設定します。

mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolRefreshTimeoutMS

型: 整数

デフォルト: 20000（20 秒）

mongod と mongos の両方で使用できます。

mongos でハートビートがタイムアウトするまでにハートビートを待つ最大時間。

設定されている場合、 ShardingTaskExecutorPoolRefreshTimeoutMSはShardingTaskExecutorPoolRefreshRequirementMSより小さくなければなりません。それ以外の場合、 mongosはShardingTaskExecutorPoolRefreshTimeoutMSの値をShardingTaskExecutorPoolRefreshRequirementMSより小さくなるように調整します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolRefreshTimeoutMSを30000に設定します。

mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

ShardingTaskExecutorPoolReplicaSetMatching

バージョン 5.0 での変更。

mongod と mongos の両方で使用できます。

タイプ: string

デフォルト: "自動"

mongos インスタンスでは、このパラメーターは、レプリカセット内のノードへの接続プールの最小サイズ制限を決定するポリシーを設定します。

mongodインスタンスでは、このパラメーターは、他のレプリカセット内のノードへの接続プールの最小サイズ制限を決定するポリシーを設定します。

このパラメーターは、ユーザーリクエストおよび CRUD 操作に直接関連する操作に対する接続のみを管理することに注意してください。

使用可能な値は次のとおりです。

マッチングポリシー	説明
`"automatic"` （デフォルト）	5.0以降では、 `"automatic"`が新しいデフォルト値です。 `mongos` に設定すると、インスタンスは `"matchPrimaryNode"` オプションに指定された動作に従います。 `mongod` に設定すると、インスタンスは `"disabled"` オプションに指定された動作に従います。警告: がに設定されている場合、ではなくに、`ShardingTaskExecutorPoolReplicaSetMatching` `"automatic"replicaSetMatchingStrategy"automatic"`ではなく、実際に使用されているポリシーが記述されます。`ShardingTaskExecutorPoolReplicaSetMatching` `getParameter`の値を見つけるには、サーバーパラメータの値を返すを使用します。
`"matchPrimaryNode"`	`mongos` に設定すると、シャーディングされたクラスター内のレプリカセットの各セカンダリ（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プールの最小サイズ制限は、そのレプリカセットのプライマリへの接続プールのサイズと同じになります。 `mongod` に設定すると、シャーディングされたクラスター内の別のレプリカセットの各セカンダリ（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プールの最小サイズ制限は、そのレプリカセットのプライマリへの接続プールのサイズと同じになります。警告:トポロジー内の複数のシャードサーバーでシャード間の操作が急増する可能性がある場合は、`mongod` インスタンスにこのオプションを設定しないでください。プライマリが降格する場合、`matchPrimaryNode` はプライマリになるすべてのセカンダリが現在のレベルのプライマリの読み取りと書き込みを処理できるようにします。
`"matchBusiestNode"`	`mongos` に設定すると、シャーディングされたクラスター内のレプリカセットの各ノード（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プールの最小サイズ制限は、そのレプリカセットのプライマリと各セカンダリへのアクティブな接続数の最大値に等しくなります。 `mongod` に設定すると、シャーディングされたクラスター内の別のレプリカセットの各ノード（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プールの最小サイズ制限は、そのレプリカセットのプライマリと各セカンダリへのアクティブな接続数の最大値に等しくなります。 `"matchBusiestNode"` を使用すると、`mongos` は各セカンダリへの十分な接続を維持し、プライマリとセカンダリの現在のレベルの読み取りと書き込みを処理します。アクティブな接続の数が減少すると、プール内で維持する接続の数も減少します。
`"disabled"`	`mongos`に設定すると、シャーディングされた clusterv 内のレプリカセットの各ノード（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プール内のインスタンスの最小接続数は`ShardingTaskExecutorPoolMinSize` と等しくなります。 `mongod`に設定すると、シャーディングされたシャーディングされたクラスターの別のレプリカセットの各ノード（具体的には、シャードレプリカセットとコンフィギュレーションサーバー）に対するインスタンスの接続プール内のインスタンスの最小接続数は`ShardingTaskExecutorPoolMinSize` と等しくなります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時にShardingTaskExecutorPoolReplicaSetMatchingを"automatic"に設定します。

mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

taskExecutorPoolSize

型: 整数

デフォルト: 1

mongos でのみ利用可能です。

特定の mongos に使用する Task Executor 接続プールの数。

パラメーター値が 0 以下の場合、Task Executor 接続プールの数はコアの数になります。ただし、次の例外があります。

コア数が 4 未満の場合、Task Executor 接続プールの数は 4 です。
コアの数が 64 より大きい場合、Task Executor 接続プールの数は 64 です。

重要

taskExecutorPoolSizeLinuxでの値を変更する前に、 MongoDBサポートのプロンプトに問い合わせてください。このパラメーターを変更すると、パフォーマンスが低下する可能性があります。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

mongos --setParameter taskExecutorPoolSize=6

Tip

以下も参照してください。

ShardingTaskExecutorPoolMaxSize
ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

シャーディングされたクラスターのルーティングテーブルを起動時にプリロードするように mongos インスタンスを設定します。この設定を有効にすると、mongos は、クライアント接続の受け入れを開始する前に、起動手順の一部として、各シャーディングされたコレクションのクラスター全体のルーティングテーブルをキャッシュします。

この設定が有効になっていない場合、mongos は受信クライアント接続に必要なルーティングテーブルのみをロードし、与えられたリクエストの名前空間の特定のルーティングテーブルのみをロードします。

mongosloadRoutingTableOnStartupパラメータが有効になっているインスタンスでは起動時間が長くなる可能性がありますが、起動後は初期クライアント接続のサービスが高速化されます。

loadRoutingTableOnStartup は、デフォルトで有効になっています。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

warmMinConnectionsInShardingTaskExecutorPoolOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

mongos でのみ利用可能です。

起動時に接続プールを事前にウォームアップするようにmongosインスタンスを構成します。このパラメータを有効にすると、 mongosは、クライアント接続の受け入れを開始する前に、起動手順の一部として各シャードサーバーへのShardingTaskExecutorPoolMinSizeネットワーク接続を確立しようとします。

この動作のタイムアウトはwarmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMSパラメーターで構成できます。このタイムアウトに達すると、接続プールのサイズに関係なく、 mongosはクライアント接続の受け入れを開始します。

このパラメーターが有効になっている mongos インスタンスでは起動時間が長くなる可能性がありますが、起動後は初期クライアント接続のサービスが高速化されます。

warmMinConnectionsInShardingTaskExecutorPoolOnStartup は、デフォルトで有効になっています。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

mongos でのみ利用可能です。

型: 整数

デフォルト: 2000（2 秒）

mongos でのみ利用可能です。

mongosShardingTaskExecutorPoolMinSizeパラメータを使用する場合、シャードホストごとに接続が確立されるまでwarmMinConnectionsInShardingTaskExecutorPoolOnStartup が待機するためのタイムアウトしきい値をミリ秒単位で設定します。このタイムアウトに達すると、接続プールのサイズに関係なく、 mongosはクライアント接続の受け入れを開始します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

Tip

以下も参照してください。

warmMinConnectionsInShardingTaskExecutorPoolOnStartup
ShardingTaskExecutorPoolMinSize

migrateCloneInsertionBatchDelayMS

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 0

移行プロセスのクローン作成ステップ中に挿入バッチの間で待機する時間（ミリ秒）。この待機時間は、secondaryThrottle に追加されます。

デフォルト値の 0 は、追加の待機がないことを示します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 migrateCloneInsertionBatchDelayMSを200ミリ秒に設定します。

mongod --setParameter migrateCloneInsertionBatchDelayMS=200

このパラメーターは次のように setParameter コマンドを使用して設定することもできます。

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

migrateCloneInsertionBatchSize

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 0

移行プロセスのクローン作成ステップで、1つのバッチに挿入するドキュメントの最大数。

デフォルト値 0 は、バッチあたりのドキュメントの最大数がないことを示します。ただし、実際には、最大 16 MB のドキュメントを含むバッチが生成されます。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 migrateCloneInsertionBatchSizeを100ドキュメントに設定します。

mongod --setParameter migrateCloneInsertionBatchSize=100

このパラメーターは次のように setParameter コマンドを使用して設定することもできます。

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

orphanCleanupDelaySecs

バージョン 3.6 の新機能。

デフォルト: 900（15 分）

mongod でのみ利用可能です。

移行されたチャンクがソースシャードから削除されるのを遅延させる最小時間です。

チャンクの移行中にチャンクを削除する前に、MongoDB はorphanCleanupDelaySecsまたは、チャンクに関連する進行中のクエリがシャードプライマリで完了するまで待機します。どちらか長い方で完了します。

ただし、シャードプライマリはシャードセカンダリで実行されている進行中のクエリを認識していないため、チャンクを使用するがセカンダリで実行されるクエリでは、シャードプライマリクエリを完了するまでの時間よりも長い時間がかかると、ドキュメントが消えてしまう可能性があります。 orphanCleanupDelaySecs 。

注意

この動作は、チャンク移行の前に開始される進行中のクエリにのみ影響します。チャンク移行が開始した後に開始されるクエリでは、移行チャンクは使用されません。

シャードにストレージの制約がある場合は、この値を一時的に下げることを検討してください。シャードセカンダリで 15 分を超えるクエリを実行中の場合は、この値を増やすことを検討してください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、orphanCleanupDelaySecsを 20 分に設定します。

mongod --setParameter orphanCleanupDelaySecs=1200

これは以下のように setParameter コマンドを使用して設定することもできます。

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

persistedChunkCacheUpdateMaxBatchSize

バージョン5.0.25の新機能。

mongod でのみ利用可能です。

型: 整数

デフォルト: 1000

操作をルーティングして処理するには、シャードがコレクションに関連するルーティング情報と所有者情報を知っている必要があります。この情報は、内部キャッシュコレクション config.cache.collections と config.cache.chunks.<collectionName> のレプリケーションを通して、シャードのプライマリノードからセカンダリノードに伝わります。

以前のバージョンでは、チャンクキャッシュコレクションのアップデートは個別に実行されていました（つまり、エントリが削除され、新しいエントリが挿入されていた）。MongoDB 5.0.25 以降、これらのアップデートは、削除のバッチとそれに続く挿入のバッチの実行として行われます。アップデートされたロジックにより、多数のチャンクを含むコレクションのパフォーマンスが向上します。

persistedChunkCacheUpdateMaxBatchSize パラメーターは、永続化したチャンクキャッシュの更新に使用される最大バッチサイズを指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、起動時に persistedChunkCacheUpdateMaxBatchSize を 700 に設定します。

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

実行時に persistedChunkCacheUpdateMaxBatchSize を設定することもできます。

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

rangeDeleterBatchDelayMS

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 20

チャンク移行（またはcleanupOrphanedコマンド）のクリーンアップステージ中に次の削除バッチを実行するまでに待機する時間（ミリ秒単位）。

MongoDB3.4 では、を変更する前に、rangeDeleterBatchDelayMS _secondaryThrottle が設定されているかどうかを検討してください。MongoDB 3.4では、 _secondaryThrottle レプリケーションの遅延は、バッチの削除後ではなく、各ドキュメントの削除後に発生します。

MongoDB 3.6 + では、 _secondaryThrottle レプリケーションの遅延は、バッチの削除ごとに発生します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 rangeDeleterBatchDelayMSを200ミリ秒に設定します。

mongod --setParameter rangeDeleterBatchDelayMS=200

このパラメーターは次のように setParameter コマンドを使用して設定することもできます。

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

rangeDeleterBatchSize

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト:2147483647 MongoDB 以降の5.0.6

チャンク移行のクリーンアップステージ中に削除する各バッチ内のドキュメントの最大数（またはcleanupOrphanedコマンド）。

値が 0 の場合、システムがデフォルト値を選択することを示します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、rangeDeleterBatchSize を 32 ドキュメントに設定します。

mongod --setParameter rangeDeleterBatchSize=32

このパラメーターは次のように setParameter コマンドを使用して設定することもできます。

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

skipShardingConfigurationChecks

バージョン3.6.3の新機能。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

true の場合、シャードノードまたはコンフィギュレーションサーバーノードをスタンドアロンとして起動してメンテナンス操作を行うことができます。このパラメーターは、--configsvr または --shardsvr オプションと相互に排他的です。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongod --setParameter skipShardingConfigurationChecks=true

重要

メンテナンスが完了したら、mongodを再起動するときにskipShardingConfigurationChecksパラメーターを削除します。

findChunksOnConfigTimeoutMS

バージョン 5.0 で追加

mongod と mongos の両方で使用できます。

タイプ: 非負整数

デフォルト: 900000

chunksでの検索操作のタイムアウト時間（ミリ秒）。

クラスターに多数のチャンクがあり、チャンクのロードがエラー ExceededTimeLimit で失敗する場合は、次のようにパラメーターの値を増やしてください。

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

ヘルスマネージャーパラメータ

activeFaultDurationSecs

型: ドキュメント

mongos でのみ利用可能です。

ヘルスマネージャーの障害からmongosがクラスターから排除されるまでの待機時間（秒単位）。

障害が検出され、ヘルスマネージャーが critical に構成されている場合、サーバーは指定された間隔だけ待機してから、クラスターから mongos を削除します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

たとえば、障害からクラッシュまでの期間を 5 分に設定するには、起動時に次のコマンドを発行します。

mongos --setParameter activeFaultDurationSecs=300

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの activeFaultDurationSecs を設定します。

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

型: ドキュメントの配列

mongos でのみ利用可能です。

このパラメータを使用して、ヘルスマネージャーの強度レベルを設定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

healthMonitoringIntensities はドキュメントの配列 values を受け取ります。values の各ドキュメントは 2 個のフィールドを取ります。

type、ヘルスマネージャーファセット
intensity、強度レベル

ヘルスマネージャー

Facet	ヘルスオブザーバーがチェックする内容
`configServer`	コンフィギュレーションサーバーに対する接続に関連するクラスターの健全性の問題。
`dns`	DNS の可用性と機能に関連するクラスターの健全性の問題。
`ldap`	LDAP の可用性と機能に関するクラスターの健全性の問題。

強度レベル

強度レベル	説明
`critical`	このファセットのヘルスマネージャーは有効になっており、エラーが発生した場合に障害のあるmongosをクラスターから移動する機能があります。ヘルスマネージャーは、 `activeFaultDurationSecs`で指定された時間待機してから、 mongosを自動的に停止してクラスターから移動します。
`non-critical`	このファセットのヘルスマネージャーは有効になっており、エラーをログに記録しますが、エラーが発生した場合、mongos はクラスター内に残ります。
`off`	このファセットのヘルスマネージャーは無効です。mongos は、このファセットでヘルスチェックを実行しません。これは、デフォルトの強度レベルです。

たとえば、dns ヘルスマネージャーファセットを強度レベル critical に設定するには、スタートアップ時に以下を実行します。

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

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの healthMonitoringIntensities を設定します。

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

healthMonitoringIntervals

型: ドキュメントの配列

mongos でのみ利用可能です。

このヘルスマネージャーの実行頻度（ミリ秒単位）です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

healthMonitoringIntervals はドキュメントの配列 values を受け取ります。values の各ドキュメントは 2 個のフィールドを取ります。

type、ヘルスマネージャーファセット
interval、実行の間隔（ミリ秒単位）

ヘルスマネージャー

Facet	ヘルスオブザーバーがチェックする内容
`configServer`	コンフィギュレーションサーバーに対する接続に関連するクラスターの健全性の問題。
`dns`	DNS の可用性と機能に関連するクラスターの健全性の問題。
`ldap`	LDAP の可用性と機能に関するクラスターの健全性の問題。

たとえば、30 秒ごとにヘルスチェックを実行するように ldap ヘルスマネージャーファセットを設定するには、スタートアップ時に次のコマンドを発行します。

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

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの healthMonitoringIntervals を設定します。

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

progressMonitor

型: ドキュメント

mongos でのみ利用可能です。

プログレスモニターは、ヘルスマネージャーのチェックが停止したり、応答しなくなったりしないよう確認するためのテストを実行します。プログレスモニターは、interval で指定された間隔でこれらのテストを実行します。ヘルスチェックが開始されたが、deadline で指定されたタイムアウト内に完了しない場合、プログレスモニターは mongos を停止し、クラスターから削除します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

`progressMonitor` フィールド

フィールド	説明	単位
`interval`	ヘルスマネジャーが、停止したり、応答しなくなったりしないよう確認する頻度。	ミリ秒
`deadline`	ヘルスマネージャーのチェックが進行していない場合に、mongos を自動的に失敗させるまでの中断時間。	秒

interval を 1000 ミリ秒に設定し、deadline を 300 秒に設定するには、スタートアップ時に次のコマンドを発行します。

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

または実行中のに接続されているsetParametermongoshmongos セッションでコマンドを使用する場合は以下のようになります。

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの progressMonitor を設定します。

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

ストレージパラメータ

honorSystemUmask

バージョン 3.6 の新機能。

mongod でのみ利用可能です。

デフォルト: false

honorSystemUmaskがtrueに設定されている場合、MongoDB によって作成された新しいファイルには、ユーザーのumask設定に従って権限が付与されます。 processUmaskhonorSystemUmaskがに設定されている場合、true を設定することはできません。

honorSystemUmaskがfalseに設定されている場合、MongoDB によって作成される新しいファイルの権限は600に設定され、読み取りと書込みの権限が所有者のみに付与されます。新しいディレクトリの権限は700に設定されています。 processUmaskを使用して、MongoDB によって作成されたすべての新しいファイルに対するグループや他のユーザーのデフォルト権限を上書きできます。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

mongod --setParameter honorSystemUmask=true

注意

honorSystemUmask は、Windows システムでは使用できません。

journalCommitInterval

mongod でのみ利用可能です。

ジャーナルコミット間のミリ秒数（ms）を表す 1 から500 までの整数を指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

journalCommitIntervalを200ミリ秒に設定する次の例を考えてみます。

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

Tip

以下も参照してください。

storage.journal.commitIntervalMs

minSnapshotHistoryWindowInSeconds

バージョン 5.0 で追加

デフォルト: 300

mongod でのみ利用可能です。

storage engine がスナップショット履歴を保持する最小時間枠を秒単位で指定します。読み取り保証（read concern） :readconcern: スナップショットを使用してデータをクエリし、指定されたminSnapshotHistoryWindowInSecondsよりも前のatClusterTime値を指定すると、 mongodはSnapshotTooOldエラーを返します。

警告

シャーディングされたクラスターでは、コンフィギュレーションコンフィギュレーションサーバーノードのデフォルトのminSnapshotHistoryWindowInSeconds 値を変更すると、内部操作が失敗する可能性があります。

コンフィギュレーションサーバーノードで minSnapshotHistoryWindowInSeconds を 0 に設定しないでください。このパラメータを 0 に設定すると、指定された atClusterTime を持つコンフィギュレーションサーバーを対象に snapshot 読み取りを実行している内部操作が失敗します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

（>=）0 以上の整数を指定します。

minSnapshotHistoryWindowInSeconds を 600 秒に設定する以下の例を考えてみます。

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

注意

minSnapshotHistoryWindowInSecondsの値を増やすと、ディスク使用量が増加します。詳細については、「スナップショット履歴の保持」を参照してください。

MongoDB Atlas クラスターのこの値を変更するには、Atlas サポートに問い合わせる必要があります。

processUmask

mongod でのみ利用可能です。

honorSystemUmaskがfalseに設定されている場合、グループや他のユーザーに使用されるデフォルトの権限を上書きします。デフォルトでは、 honorSystemUmaskがfalseに設定されている場合、MongoDB によって作成される新しいファイルの権限は600に設定されます。このデフォルトをカスタムumask値で上書きするには、 processUmaskパラメーターを使用します。ファイル所有者は、システムumaskから権限を継承します。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

honorSystemUmaskがtrueに設定されている場合、このパラメータを設定することはできません。

グループと他のユーザーの権限を読み取り/書き込みのみに設定し、所有者のシステム umask 設定を保持する次の例を考えてみます。

mongod --setParameter processUmask=011

注意

processUmask は、Windows システムでは使用できません。

syncdelay

mongod でのみ利用可能です。

mongod が作業メモリをディスクにフラッシュする間隔を秒単位で指定します。デフォルトでは、mongod は 60 秒ごとにメモリをディスクにフラッシュします。ほとんどの場合、この値を設定せず、デフォルト設定を使用してください。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

syncdelay を 60 秒に設定する以下の例を考えてみます。

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

永続的なデータを提供するために、 WiredTigerはチェックポイントを使用します。詳細については、「ジャーナリングと WiredTiger ストレージエンジン」を参照してください。

Tip

以下も参照してください。

WiredTiger パラメータ

wiredTigerConcurrentReadTransactions

mongod でのみ利用可能です。

WiredTiger ストレージエンジンでのみ使用できます。

WiredTiger storage engine に許可された同時読み取りトランザクションの最大数を指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

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

Tip

以下も参照してください。

wiredTiger.concurrentTransactions

wiredTigerConcurrentWriteTransactions

mongod でのみ利用可能です。

WiredTiger ストレージエンジンでのみ使用できます。

WiredTiger storage engine に許可された同時書込みトランザクション (write transaction) の最大数を指定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

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

Tip

以下も参照してください。

wiredTiger.concurrentTransactions

wiredTigerEngineRuntimeConfig

mongod でのみ利用可能です。

実行中のmongodインスタンスのwiredTigerストレージエンジン構成オプションを指定します。

このパラメーターは実行時にのみ使用できます。パラメーターを設定するには、 setParameterコマンドを使用します。

警告

この設定は WiredTiger と MongoDB の両方に大きな影響を与える可能性があるため、MongoDB エンジニアの指示がない限り、 wiredTigerEngineRuntimeConfigの変更は避けてください。

次の操作プロトタイプを考慮します。

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

wiredTigerFileHandleCloseIdleTime

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600

wiredTiger 内のファイルハンドルが閉じられる前のアイドル状態を維持できる時間を秒単位で指定します。

wiredTigerFileHandleCloseIdleTime を 0 に設定すると、アイドル状態のハンドルは閉じられません。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

以下に例を挙げます。

mongod --setParameter wiredTigerFileHandleCloseIdleTime=100000

利用可能なすべての WiredTiger 構成オプションについては、WiredTiger のドキュメントを参照してください。

監査パラメータ

auditAuthorizationSuccess

タイプ: ブール値

デフォルト: false

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

mongod と mongos の両方で使用できます。

authCheck アクションの承認成功の監査を有効にします。

auditAuthorizationSuccessがfalseの場合、監査システムはauthCheckの承認の失敗のみを記録します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

承認成功の監査を有効にするには、次のコマンドを発行します。

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

auditAuthorizationSuccessを有効にすると、承認の失敗のみをログに記録する場合よりもパフォーマンスが低下します。

ランタイム監査構成が有効になっている場合、auditAuthorizationSuccessパラメーターはmongodまたはmongos構成ファイルに表示されません。パラメーターが存在する場合、サーバーは起動に失敗します。

Tip

以下も参照してください。

getParameter

auditConfigPollingFrequencySecs

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 300

シャーディングされたクラスターには、クラスターの監査構成設定を維持するサーバーが存在する場合があります。構成されていないサーバーが現在の監査生成についてコンフィギュレーションサーバーをポーリングする間隔を秒単位で設定します。返されたこの値が以前の既知の値と異なる場合、開始ノードは現在の構成をリクエストし、その内部状態をアップデートします。

注意

デフォルト値の300秒を使用すると、 auditConfigクラスターパラメータを設定した後、非 config ノードでは最大5分かかることがあります。

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、setParameter 設定を使用します。

トランザクションパラメータ

coordinateCommitReturnImmediatelyAfterPersistingDecision

バージョン 5.0 で追加

バージョン5.0.10で更新

タイプ: ブール値

デフォルト: false

falseに設定すると、シャードトランザクションの調整役は、結果をクライアントに返す前に、参加しているすべてのシャードがマルチドキュメントトランザクションをコミットまたはキャンセルするかどうかの決定を確認するまで待機します。
trueに設定すると、シャードトランザクションの調整役は、要求されたトランザクションの書込み保証（ write concern ）で永続的な決定が行われるとすぐに、マルチドキュメントトランザクションをコミットする決定をクライアントに返します。
クライアントが "majority" 未満の書込み保証 (write concern) をリクエストした場合、決定がクライアントに返された後にコミットがロールバックされる可能性があります。
トランザクションには「書込みの読み取り」整合性がない場合があります。つまり、読み取り操作では、その前の書込み操作の結果が表示されない場合があります。これは、次の場合に発生する可能性があります。
- トランザクションは複数のシャードに書込み (write) しなければなりません。
- 読み取りと以前の書込み (write) は、異なるセッションで行われます。
因果整合性は、同じセッション内で発生する読み取りと書き込みの因果関係のみを保証します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

例

次の例では、coordinateCommitReturnImmediatelyAfterPersistingDecision に true を設定します。

mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

次のように、実行中に setParameter コマンドを使用してパラメーターを設定することもできます。

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

transactionLifetimeLimitSeconds

mongod でのみ利用可能です。

デフォルト: 60

マルチドキュメントトランザクションの有効期間を指定します。この制限を超えるトランザクションは期限切れと見なされ、定期的なクリーンアッププロセスによって中断されます。クリーンアッププロセスは、transactionLifetimeLimitSeconds/2秒ごと、または少なくとも 60 秒ごとに 1 回実行されます。

クリーンアッププロセスは、ストレージキャッシュの負荷軽減に役立ちます。

transactionLifetimeLimitSeconds の最小値は 1 秒です。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 transactionLifetimeLimitSecondsを30秒に設定します。

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

スタートアップ時にパラメータtransactionLifetimeLimitSecondsを設定することもできます。

mongod --setParameter "transactionLifetimeLimitSeconds=30"

シャーディングされたクラスターのパラメーターを設定するには、すべてのシャードレプリカセットのノードパラメーターを変更する必要があります。

MongoDB 5.0以降では、transactionLifetimeLimitSeconds パラメーターを変更する場合、すべてのコンフィギュレーションサーバーレプリカセットノードに対して、同じtransactionLifetimeLimitSeconds 値に変更する必要があります。この値の一貫性を保つには、次の点に注意してください。

ルーティングテーブルの履歴が、少なくともシャードレプリカセットノードのトランザクションライフタイム制限と同じ期間保持されるよう確認します。
トランザクションの再試行頻度を減らし、パフォーマンスを向上させます。

transactionTooLargeForCacheThreshold

バージョン5.0.16の新機能。

mongod でのみ利用可能です。

タイプ: 10 進数

デフォルト: 0.75

キャッシュの負荷により失敗したトランザクションを再試行するためのしきい値。この値は、ダーティキャッシュサイズに対する割合。デフォルト値の 0.75 は、ダーティキャッシュの 75% を意味します。

ダーティキャッシュは合計キャッシュサイズの 20% に制限されます。transactionTooLargeForCacheThreshold を 0.75 に設定すると、サーバは、storage engine キャッシュの合計の 15%（0.75 * 20%）未満を使用するトランザクションのみを再試行します。

この制限は再試行にのみ適用されます。大規模なトランザクションでは、ダーティキャッシュの transactionTooLargeForCacheThreshold% 以上を使用することができます。ただし、キャッシュの負荷により大規模なトランザクションがロールバックされた場合、サーバーは TransactionTooLargeForCache エラーを発行し、トランザクションを再試行しません。

この動作を無効にするには、transactionTooLargeForCacheThreshold を 1.0 に設定します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

maxTransactionLockRequestTimeoutMillis

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 5

マルチドキュメントトランザクションがトランザクション内の操作に必要なロックを取得するために待機する最大時間（ミリ秒単位）。

トランザクションがmaxTransactionLockRequestTimeoutMillis待機した後にロックを取得できない場合、トランザクションは中止されます。

デフォルトでは、マルチドキュメントトランザクションは5ミリ秒待機します。つまり、トランザクションが5ミリ秒以内にロックを取得できない場合、トランザクションは中止されます。操作によってロックリクエストのタイムアウトが長くなった場合、 maxTransactionLockRequestTimeoutMillisは操作固有のタイムアウトを上書きします。

maxTransactionLockRequestTimeoutMillisは次のように設定できます。

0 この場合、トランザクションが必要なロックをすぐに取得できないと、トランザクションは中止されます。
必要なロックを取得するために指定された時間待機するには、0 より大きい数値を指定します。これにより、高速に実行されているメタデータ操作など、一時的な同時ロック取得でトランザクションが中断されるのを防ぐことができます。ただし、これにより、デッドロックしたトランザクション操作の中止が遅れる可能性があります。
-1 、操作固有のタイムアウトを使用します。

このパラメーターは、実行時とスタートアップ時に両方で使用できます。

実行時にパラメータを設定するには、 setParameterコマンドを使用します
スタートアップ時にパラメータを設定するには、 setParameter設定を使用します

次の例では、 maxTransactionLockRequestTimeoutMillisを20ミリ秒に設定します。

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

このパラメータは、起動時に設定することもできます。

mongod --setParameter maxTransactionLockRequestTimeoutMillis=20

戻る

構成ファイルの設定とコマンドラインオプションのマッピング

バックアップ方法

Synopsis

パラメーター

認証パラメータ

注意

Tip

Tip

以下も参照してください。

Tip

以下も参照してください。

注意

注意

注意

注意

MongoDB Enterprise でのみ利用可能です（MongoDB Enterprise for Windows を除く）。

注意

重要

Tip

以下も参照してください。

Tip

以下も参照してください。

Tip

以下も参照してください。

Tip

以下も参照してください。

Tip

以下も参照してください。

Tip

以下も参照してください。

重要

注意

注意

エンタープライズ機能

一般的なパラメータ

注意

Tip

以下も参照してください。

警告

重要

Tip

以下も参照してください。

Tip

以下も参照してください。

Tip

以下も参照してください。

注意

Tip

注意

注意

注意

ログ パラメータ

Tip

以下も参照してください。

警告

Tip

以下も参照してください。

注意

エンタープライズ機能

Tip

以下も参照してください。

Tip

以下も参照してください。

診断パラメータ

注意

重要

レプリケーションと整合性

警告

テスト目的のみ

注意

注意

Tip

以下も参照してください。

注意

Tip

以下も参照してください。

シャーディング パラメータ

重要

Tip

以下も参照してください。

注意

Tip

ログパラメータ

シャーディングパラメータ

ヘルスマネージャーパラメータ

`progressMonitor` フィールド

ストレージパラメータ

トランザクションパラメータ