Docs Menu
Docs Home
/ /
設定とメンテナンス
Docs Home
/ /
管理
/
設定とメンテナンス
Docs Home
/
データベース マニュアル
/
自己管理型配置
/
管理
/
設定とメンテナンス

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

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

RFC 5802 標準の Salted Challenge Response Authentication Mechanism（SHA-1 ハッシュ関数を使用）。

SCRAM-SHA-256

RFC7677 標準の Salted Challenge Response Authentication Mechanism。256

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

バージョン6.0.7での変更: （ 5.0.18以降でも開始）

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

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

タイプ: 整数

デフォルト: 2

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

接続失敗後の 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

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

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

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

ldapForceMultiThreadMode

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

デフォルト: 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

バージョン 5.2 で変更。

mongod でのみ利用可能です。

デフォルト: 30 秒

注意

MongoDB 5.2以降、LDAP サーバーから取得されたキャッシュされたユーザー情報の更新間隔はldapShouldRefreshUserCacheEntriesに依存します。

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

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

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

ldapUserCacheRefreshInterval

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30 秒

注意

MongoDB 5.2以降、LDAP サーバーから取得されたキャッシュされたユーザー情報の更新間隔はldapShouldRefreshUserCacheEntriesに依存します。

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

mongodが LDAP サーバーからキャッシュしたユーザー情報を更新するまでの間隔（秒単位）。

最大間隔は 86,400 秒（24 時間）です。

次の例では、 ldapUserCacheRefreshIntervalを4000秒に設定します。

mongod --setParameter ldapUserCacheRefreshInterval=4000

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

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

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 90 秒

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

最後にキャッシュを更新したあとに mongod がキャッシュされた LDAP ユーザー情報を保持する間隔（秒単位）。

LDAP サーバーからのユーザー情報の更新に成功せずにldapUserCacheStalenessInterval 秒以上経過すると、mongod が起動します。

  • キャッシュされた LDAP ユーザー情報を無効にします。

  • mongod が LDAP サーバーに接続して LDAP ユーザーを承認するまで、LDAP ユーザーの新しいセッションを認証できません。

  • mongodが LDAP サーバーに接続できない場合、過去に認証された LDAP ユーザーを使用する既存のセッションを承認します。mongod が LDAP サーバーに再接続すると、mongod は LDAP ユーザーが正しく承認されていることを確認します。

最大間隔は 86,400 秒（24 時間）です。

次の例では、 ldapUserCacheStalenessIntervalを4000秒に設定します。

mongod --setParameter ldapUserCacheStalenessInterval=4000

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

db.adminCommand( { setParameter: 1, ldapUserCacheStalenessInterval: 4000 } )
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

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

デフォルト: 2147483647

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

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

ldapConnectionPoolMaximumConnectionsInProgressPerHost

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

デフォルト: 2

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

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

ldapConnectionPoolHostRefreshIntervalMillis

デフォルト: 60000

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

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

ldapConnectionPoolIdleHostTimeoutSecs

デフォルト: 300

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

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

ldapShouldRefreshUserCacheEntries

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

MongoDB 5.2以降、LDAP サーバーから取得されたキャッシュされたユーザー情報の更新間隔はldapShouldRefreshUserCacheEntriesに依存します。

ldapShouldRefreshUserCacheEntriesスタートアップ時にconfiguration file --setParameterまたはコマンドラインで オプションを使用してのみ を設定できます。たとえば、次の例ではldapShouldRefreshUserCacheEntriesが無効になっています。

mongod --setParameter ldapShouldRefreshUserCacheEntries=false
maxValidateMemoryUsageMB

バージョン 5.0 で追加

デフォルト: 200

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

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

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

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

ocspEnabled

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

デフォルト: true

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

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

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

mongod --setParameter ocspEnabled=false ...

MongoDB 6.0以降では、最初の同期中にocspEnabledがtrueに設定されている場合、すべてのノードがOCSPレスポンダに到達できるはずです。

ノードがSTARTUP2状態で失敗した場合、 tlsOCSPVerifyTimeoutSecsを5未満の値に設定します。

Tip

ocspStaplingRefreshPeriodSecs

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

Linuxで利用できます。

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

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

mongod --setParameter ocspStaplingRefreshPeriodSecs=3600 ...

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

Tip

opensslCipherConfig

Linux でのみ利用可能です。

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

TLS/SSL暗号化を使用する場合は、OpenSSL の暗号文字列を指定します。 暗号文字列のリストについては、 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

Linux でのみ利用可能です。

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

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

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

注意

opensslDiffieHellmanParameters が設定されていないが ECDHE が有効になっている場合、 MongoDB はRFC-7919#appendix-A.2 で定義されているように、ffdhe3072 ディフィー ヘルマン パラメータを使用して 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 にのみ含まれています。詳細については、以下を参照してください。

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

tlsOCSPVerifyTimeoutSecs

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

デフォルト: 5

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

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

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

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

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Tip

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

MongoDB4.4 以降、提示されたmongod mongosX.509 証明書が30 mongod/mongosシステム クロックの 日以内に期限切れになる場合、 / は接続時に警告を記録します。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 の両方で使用できます。

注意

エンタープライズ機能

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

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

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

allowRolesFromX509Certificates

デフォルト: true

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

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

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

一般的なパラメータ

allowDiskUseByDefault

デフォルト: True

mongod でのみ利用可能です。

MongoDB 6.0 以降、 100 MB 以上のメモリを必要とするパイプライン ステージでは、デフォルトで一時ファイルをディスクに書き込みます。これらの一時ファイルはパイプラインの実行中ずっと残り、インスタンスのストレージ容量に影響を与える可能性があります。以前のバージョンの MongoDB では、この動作を有効にするには、個々の find コマンドと aggregate コマンドに { allowDiskUse: true } を渡す必要がありました。

個々の find および aggregate コマンドは、次のいずれかの方法で allowDiskUseByDefaultパラメーターを上書きできます。

  • allowDiskUseByDefaultが false に設定されている場合に { allowDiskUse: true } を使用して一時ファイルをディスクに書き込むことを許可する

  • allowDiskUseByDefault が true に設定されている場合に { allowDiskUse: false } を使用して一時ファイルがディスクに書き込むことを禁止する

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

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

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

mongod --setParameter allowDiskUseByDefault=false

allowDiskUseByDefaultはmongodでのみ機能し、 mongosではありません。 mongosは一時ファイルをディスクに書き込みません。 サーバーが実行中に パラメータの値を変更するには、実行中のsetParameter mongoshmongodに接続されている セッションで コマンドを使用します。

db.adminCommand(
  {
      setParameter: 1,
      allowDiskUseByDefault: false
  }
)
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

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

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

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

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

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes

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 は、孤立したカーソルを cursorTimeoutMillis のしきい値を超えた後にクリーンアップします（ただし、それらがセッションに関連付けられていない場合のみ）。

MongoDB は、localLogicalSessionTimeoutMinutes ライフサイクルに従ってセッションに関連付けられたカーソルを、cursorTimeoutMillis の値に関係なくクリーンアップします。長時間アイドル状態が続く場合には、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 でのみ利用可能です。

インデックスを使用できる場合に、インデックスが存在するかどうかに関係なく、一部のコレクション スキャンの実行を防止します。true の場合、MongoDB はコレクションスキャンを必要とするクエリを実行せず、エラーを返します。除外対象には、フィルターのないクエリや、oplog のような上限付きコレクションに対するクエリが含まれます。

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

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

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

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

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

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

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

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

注意

notablescan では、クラスター化インデックスを使用する限界が設定されていないクエリは許可されません。このクエリではコレクションのフル スキャンが必要なためです。詳細については、コレクションスキャンを参照してください。

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 接続を有効にします。

このパラメータは、ホスト オペレーティング システムが 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
indexMaxNumGeneratedKeysPerDocument

バージョン 5.3 で追加。

デフォルト: 100000

メモリ不足エラーを防ぐために、ドキュメントに対して生成されるキーの最大数を制限します。制限を引き上げることは可能ですが、indexMaxNumGeneratedKeysPerDocumentパラメーターで指定された数より多くのキーが操作に必要な場合、操作は失敗します。

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

maxIndexBuildMemoryUsageMegabytes

デフォルト: 200

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

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

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

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

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

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

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

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

Tip

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

警告

ローリングインデックスと複製されたインデックス構築プロセスを同時に実行すると、ビルドの失敗やクラッシュ ループなどの予期しない問題が発生する可能性があるため、避けてください。

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

reportOpWriteConcernCountersInServerStatus

デフォルト: false

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

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

mongod でのみ利用可能です。

タイプ: 整数

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

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

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

バージョン 5.3 で追加。

デフォルト: 15 秒

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

昇格または降格のリクエストを受け取ったサーバーが、タイムアウト内に応答できない場合（サーバーのディスク障害などにより）にサーバーを終了できるようにします。これにより、クラスターは新しいプライマリ ノードを正常に選択でき、引き続き利用ができます。

fassertOnLockTimeoutForStepUpDown のデフォルトは 15 秒です。Fassert が発生したノードを無効にするには fassertOnLockTimeoutForStepUpDown=0 を設定します。

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

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

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

次の例えでは、ノードの fassert を無効にします。

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

ログ パラメータ

logLevel

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

デフォルト : 0（情報）

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

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

  • 実行時にパラメータを設定するには、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 の両方で使用できます。

デフォルト: 0

ログ メッセージのさまざまなコンポーネントの冗長レベルを設定します。冗長レベルにより、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 の冗長レベルを指定すると、このレベルは次のコンポーネントにも適用されます。

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

  • 実行時にパラメータを設定するには、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

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

型: 非負整数

デフォルト: 10

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

切り捨てられた属性フィールドは、maxLogSizeKBまでのフィールド コンテンツを出力し、その制限を超えるフィールド コンテンツを削除して、有効な JSON 形式を保持します。切り捨てられた属性を含むログ エントリでは、ログ エントリの末尾に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

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

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

タイプ: ブール値

デフォルト: true

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

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

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

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

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

mongod --setParameter diagnosticDataCollectionEnabled=false
diagnosticDataCollectionDirectoryPath

タイプ: string

mongos でのみ利用可能です。

警告

フルタイム診断データ取得（FTDC）がdiagnosticDataCollectionEnabledで無効になっている場合、またはsystemLog.destinationがsyslogに設定されている場合、 diagnosticDataCollectionDirectoryPathを設定した後にmongosを再起動する必要があります。

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

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

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

mongos が指定されたディレクトリを作成できない場合、そのインスタンスの診断データ取得は無効になります。パス上に同じ名前のファイルが既に存在する場合、またはプロセスにディレクトリを作成する権限がない場合、 mongos は指定されたディレクトリを作成できない可能性があります。

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

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

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

diagnosticDataCollectionDirectorySizeMB

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

タイプ: 整数

デフォルト: 200

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

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

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

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

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

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

diagnosticDataCollectionFileSizeMB

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

タイプ: 整数

デフォルト: 10

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

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

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

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

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

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

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

diagnosticDataCollectionPeriodMillis

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

タイプ: 整数

デフォルト: 1000

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

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

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

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

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

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

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

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

connectTimeoutMs

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

タイプ: 整数

デフォルト: 10000

レプリカセットモニターの接続タイムアウトをミリ秒単位で設定します。

このパラメーターは、スタートアップ時にのみ使用できます。このパラメータを設定する場合は、500 以上である必要があります。

次の例では、mongod インスタンスの connectTimeoutMs を 700 ミリ秒に設定します。

mongod --setParameter connectTimeoutMs=700
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 アドレスを使用する設定は拒否します。

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

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

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
heartBeatFrequencyMs

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

タイプ: 整数

デフォルト: 10000

replicaSetMonitorProtocol を 'sdam' に設定すると、heartBeatFrequencyMs は hello リクエスト間で待機する時間をミリ秒単位で決定します。

replicaSetMonitorProtocol が 'streamable' に設定されている場合、heartBeatFrequencyMs は hello のラウンドトリップタイム（RTT）測定間の待機時間をミリ秒単位で決定します。RTT測定値はサーバー選択に使用されます。

このパラメーターは、スタートアップ時にのみ使用できます。このパラメータを設定する場合は、500 以上である必要があります。

次の例では、mongod インスタンスの heartBeatFrequencyMs を 700 ミリ秒に設定します。

mongod --setParameter heartBeatFrequencyMs=700
logicalSessionRefreshMillis

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

タイプ: 整数

デフォルト: 300000（5 分）

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

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

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

mongod --setParameter logicalSessionRefreshMillis=600000
localLogicalSessionTimeoutMinutes

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

タイプ: 整数

デフォルト: 30

警告

テスト目的のみ

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

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

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

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

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

mongod --setParameter localLogicalSessionTimeoutMinutes=20
localThresholdMs

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

タイプ: 整数

デフォルト: 15

サーバー選択に使用されるレイテンシ ウィンドウの長さをミリ秒単位で定義します。

このパラメーターは、スタートアップ時にのみ使用できます。このパラメータを設定する場合は、0 以上である必要があります。

次の例では、mongod インスタンスの localThresholdMs を 20 ミリ秒に設定します。

mongod --setParameter localThresholdMs=20
maxAcceptableLogicalClockDriftSecs

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

タイプ: 整数

デフォルト：31536000（1年）

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

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

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

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

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900
maxSessions

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

タイプ: 整数

デフォルト: 1000000

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

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

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

mongod --setParameter maxSessions=1000
oplogBatchDelayMillis

バージョン 6.0 で追加。

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
replicaSetMonitorProtocol

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

型: string

デフォルト: "ストリーム可能"

使用するレプリカ セット モニター プロトコルを決定します。このパラメータを "streamable" に設定すると、Server Discovery and Monitoring（SDAM） 仕様に準拠し、hello リクエストを一定に保つことができます。このパラメータを "sdam"に設定することもできます。これは SDAM 仕様に準拠しています。

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

次の例では、mongod インスタンスで replicaSetMonitorProtocol を "sdam" に設定します。

mongod --setParameter replicaSetMonitorProtocol='sdam'
storeFindAndModifyImagesInSideCollection

バージョン 5.0 で追加

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

タイプ: ブール値

デフォルト: true

再試行可能な findAndModify コマンドに必要な一時ドキュメントをサイド コレクション（config.image_collection）に格納するかどうかを決定します。

storeFindAndModifyImagesInSideCollectionが の場合:

  • true一時的なドキュメントはサイド コレクションに保存されます。

  • falseの場合、一時ドキュメントはレプリカセット oplog にストアされます。

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

注意

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

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

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

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

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

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

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

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

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30

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

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

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

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

localLogicalSessionTimeoutMinutes

enableFlowControl

タイプ: ブール値

デフォルト: true

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

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

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

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

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) モードを指定します。

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

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

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

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

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

initialSyncMethod

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: string

デフォルト: logical

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

最初の同期に使用される方法です。

論理的な最初の同期を使用するには、logical に設定します。ファイル コピー ベースの最初の同期を使用するには、fileCopyBased に設定します。

このパラメーターは、指定されたノードの同期方法にのみ影響します。このパラメーターを 1 つのレプリカセット ノードに設定しても、他のレプリカセット ノードの同期方法には影響しません。

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

maxNumSyncSourceChangesPerHour

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 3

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

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

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

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

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

oplogFetcherUsesExhaust

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

oplogInitialFindMaxSeconds

タイプ: 整数

デフォルト: 60

mongod でのみ利用可能です。

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

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

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

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

replWriterThreadCount

タイプ: 整数

デフォルト: 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

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 設定を使用します。

次の例では、oplog アプリケーションのバッチ サイズを制限するために、 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 } } )
allowMultipleArbiters

mongod でのみ利用可能です。

バージョン 5.3 で追加。

タイプ: ブール値

デフォルト: false

レプリカセットで複数のアービタの使用を許可するかどうかを指定します。

複数のアービタの使用は推奨されません。

  • アービタが複数あると、過半数の書込み保証（write concern）を信頼して使用することができません。MongoDB は、メンバーシップの過半数を計算する際にアービタをカウントしますが、アービタはデータを保存しません。複数のアービタを含めると、データを含む大多数のノードに書き込みが複製される前に、過半数の書込み保証（write concern）操作が成功を返すことが可能です。

  • 複数のアービタにより、レプリカセットにデータ レプリケーション用の十分なセカンダリがない場合でも、レプリカセットは書き込みを受け入れることができます。

詳細については、「複数のアービタに関する懸念」を参照してください。

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

mongod --setParameter allowMultipleArbiters=true

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

balancerMigrationsThrottlingMs

バージョン6.0.6の新機能: （ 5.0.18以降でも利用可能）

タイプ: 整数

デフォルト: 1000

mongod でのみ利用可能です。

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

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

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

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

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

mongod --setParameter balancerMigrationsThrottlingMs=2000

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

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

バージョン 5.3 で追加。

タイプ: 整数

デフォルト: 0

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

シャーディングされたコレクション内のチャンクがデフラグされるときに、バランサーによって実行される連続した分裂コマンドとマージ コマンド間の最小時間間隔（ミリ秒単位）を指定します。chunkDefragmentationThrottlingMSで、分裂コマンドと結合コマンドのレートを制限します。

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

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

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

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

mongod --setParameter chunkDefragmentationThrottlingMS=10

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

db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )
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

opportunisticSecondaryTargeting

バージョン 6.0.0 の新機能。

タイプ: ブール値

デフォルト: 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

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

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

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

バージョン7.1での変更（および7.0.1 ）、 実行時にパラメータを設定できます。

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

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

実行中はmaxCatchUpPercentageBeforeBlockingWritesを変更できません。

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

バージョン 6.0.10 の新機能。

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

型: 整数

デフォルト: 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 64 - 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

バージョン 6.0 で追加。

型: 整数

デフォルト: -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

ShardingTaskExecutorPoolMinSizeForConfigServers

バージョン 6.0 で追加。

型: 整数

デフォルト: -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" が実際に使用されているポリシーを記述します。ShardingTaskExecutorPoolReplicaSetMatchinggetParameterの値を見つけるには、サーバーパラメータの値を返す を使用します。

"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

loadRoutingTableOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

warmMinConnectionsInShardingTaskExecutorPoolOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

Tip

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

mongos でのみ利用可能です。

型: 整数

デフォルト: 2000（2 秒）

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

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

Tip

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

デフォルト: 900（15 分）

mongod でのみ利用可能です。

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

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

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

注意

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

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

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

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

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

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

mongod --setParameter orphanCleanupDelaySecs=1200

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

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

バージョン 6.0.13 で追加: （および 5.0.25）

mongod でのみ利用可能です。

型: 整数

デフォルト: 1000

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

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

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

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

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

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

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

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

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

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

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 20

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

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

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

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

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

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

mongod --setParameter rangeDeleterBatchDelayMS=200

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

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

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト:2147483647 MongoDB5.1.2 と 以降の5.0.6

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

値が 0 の場合、システムがデフォルト値を選択することを示します。

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

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

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

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

mongod --setParameter rangeDeleterBatchSize=32

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

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

Tip

6.0.3より前のバージョンでは、 rangeDeleterBatchSizeの新しい値は、値が変更された後に作成された範囲の削除にのみ適用されます。 既存の範囲削除に新しい値を適用するには、強制的に降格します 。

6.0.3 以降、パラメーターの新しい値は、範囲削除がいつ作成されたかに関係なく、アップデート後に処理されたすべての範囲削除に適用されます。

skipShardingConfigurationChecks

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

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 がスナップショット履歴を保持する最小時間枠を秒単位で指定します。"snapshot" の読み取り保証 (read concern) を使用してデータをクエリし、指定された 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 システムでは使用できません。

storageEngineConcurrentReadTransactions

mongod でのみ利用可能です。

デフォルト: 0

バージョン 6.0 で変更。wiredTigerConcurrentReadTransactions パラメータの名前が storageEngineConcurrentReadTransactions に変更されました。

WiredTiger ストレージエンジンでのみ使用できます。

WiredTiger ストレージエンジンに許可された同時読み取りトランザクションの最大数を指定します。このパラメータに値を指定しない場合、または 0 を指定した場合、 MongoDB はストレージエンジンのデフォルト値 を使用します。WiredTigerストレージエンジンのデフォルト値は 128 です。

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

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

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

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

Tip

wiredTiger.concurrentTransactions

storageEngineConcurrentWriteTransactions

mongod でのみ利用可能です。

デフォルト: 0

バージョン 6.0 で変更。wiredTigerConcurrentReadTransactions パラメータの名前が storageEngineConcurrentReadTransactions に変更されました。

WiredTiger ストレージエンジンでのみ使用できます。

WiredTiger ストレージエンジンに許可された同時書込みトランザクション (write transaction) の最大数を指定します。このパラメータに値を指定しない場合、または 0 を指定した場合、 MongoDB はストレージエンジンのデフォルト値 を使用します。WiredTigerストレージエンジンのデフォルト値は 128 です。

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

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

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

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

Tip

wiredTiger.concurrentTransactions

syncdelay

mongod でのみ利用可能です。

デフォルト: 60

mongod が作業メモリをディスクにフラッシュする間隔を秒単位で指定します。デフォルトでは、mongod は 60 秒ごとにメモリをディスクにフラッシュします。ほとんどの場合、この値を設定せず、デフォルト設定を使用してください。

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

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

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

syncdelay を 60 秒に設定する以下の例を考えてみます。

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

永続的なデータを提供するために、 WiredTigerはチェックポイントを使用します。 詳細については、「ジャーナリングと WiredTiger ストレージ エンジン 」を参照してください。

Tip

upsertMaxRetryAttemptsOnDuplicateKeyError

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

バージョン6.0.25の新機能。

upsert操作で重複キー エラーが発生した場合の最大再試行回数。

タイプ : 整数

デフォルト: 100

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

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

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

重要

MongoDB 8.1 以降では、upsert操作がマルチドキュメントトランザクションで実行される場合、重複キー エラーが発生しても upsert は再試行しません。

次の例では、重複キー エラーが発生したときにサーバーがupsert操作を再試行する最大回数を 50 に設定します。

mongod --setParameter "upsertMaxRetryAttemptsOnDuplicateKeyError=50"

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

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

WiredTiger パラメータ

wiredTigerEngineRuntimeConfig

mongod でのみ利用可能です。

実行中のmongodインスタンスのwiredTigerストレージ エンジン構成オプションを指定します。

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

警告

この設定は WiredTiger と MongoDB の両方に大きな影響を与える可能性があるため、MongoDB エンジニアの指示がない限り、 wiredTigerEngineRuntimeConfigの変更は避けてください。

次の操作プロトタイプを考慮します。

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

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600

wiredTiger 内のファイル ハンドルが閉じられる前のアイドル状態を維持できる時間を秒単位で指定します。

wiredTigerFileHandleCloseIdleTime を 0 に設定すると、アイドル状態のハンドルは閉じられません。

Tip

このパラメーターは大文字と小文字を区別します。 wiredTigerFileHandleCloseIdleTime で w を大文字にして パラメータを実行すると、操作は次のエラー メッセージを返します。

{ "code":2,"codeName":"BadValue","errmsg":"Unknown --setParameter 'WiredTigerFileHandleCloseIdleTime'" }

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、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 秒を使用すると、非 config ノードは setAuditConfig コマンドから最大 5 分遅れることがあります。

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

auditEncryptionHeaderMetadataFile

バージョン 6.0 で追加。

型: string

注意

MongoDB Enterpriseでのみ利用可能です。MongoDB Enterprise と Atlas では構成要件が異なります。

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

監査ログ暗号化用のログ メタデータ監査ヘッダーのパスとファイル名です。ヘッダーは各監査ログ ファイルの上部に配置され、監査ログを解読するためのメタデータが含まれています。ヘッダーも監査ログに保存されます。

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

たとえば、次の例では auditEncryptionHeaderMetadataFile のパスとファイルを設定しています。

mongod --setParameter auditEncryptionHeaderMetadataFile=/auditFiles/auditHeadersMetadataFile.log
auditEncryptKeyWithKMIPGet

バージョン 6.0 で追加。

タイプ: ブール値

デフォルト: false

注意

MongoDB Enterpriseでのみ利用可能です。MongoDB Enterprise と Atlas では構成要件が異なります。

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

KMIP プロトコル バージョン 1.0 または 1.1 のみをサポートする KMIP（キー管理相互運用性プロトコル）サーバーの監査ログ暗号化を有効にします。

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

次の例では、 auditEncryptKeyWithKMIPGetにtrueを設定します。

mongod --setParameter auditEncryptKeyWithKMIPGet=true

トランザクション パラメータ

coordinateCommitReturnImmediatelyAfterPersistingDecision

バージョン 5.0 で追加

バージョン 6.0 および 5.0.10 でアップデート

タイプ: ブール値

デフォルト: false

  • falseに設定すると、シャードトランザクションの調整役は、結果をクライアントに返す前に、参加しているすべてのシャードがマルチドキュメントトランザクションをコミットまたはキャンセルするかどうかの決定を確認するまで待機します。

  • trueに設定すると、シャード トランザクションの調整役は、要求されたトランザクションの書込み保証（ write concern ）で 永続 的な決定が行われるとすぐに、 マルチドキュメントトランザクション をコミットする決定をクライアントに返します。

    クライアントが "majority" 未満の書込み保証 (write concern) をリクエストした場合、決定がクライアントに返された後にコミットがロールバックされる可能性があります。

    トランザクションには「書込みの読み取り」整合性がない場合があります。 つまり、読み取り操作では、その前の書込み操作の結果が表示されない場合があります。 これは、次の場合に発生する可能性があります。

    • トランザクションは複数のシャードに書込み (write) しなければなりません。

    • 読み取りと以前の書込み (write) は、異なるセッションで行われます。

    因果整合性は、同じセッション内で発生する読み取りと書き込みの因果関係のみを保証します。

シャード トランザクションの調整役は、要求されたトランザクションの書込み保証 ( write concern ) で決定が 永続 的になるとすぐに、 マルチドキュメントトランザクション をコミットする決定をクライアントに返します。

クライアントが "majority" 未満の書込み保証 (write concern) をリクエストした場合、決定がクライアントに返された後にコミットがロールバックされる可能性があります。

トランザクションには「書込みの読み取り」整合性がない場合があります。 つまり、読み取り操作には、その前の書込み操作の結果が反映されない場合があります。 これは、次の場合に発生する可能性があります。

  • トランザクションは複数のシャードに書込み (write) しなければなりません。

  • 読み取りと以前の書込み (write) は、異なるセッションで行われます。

因果整合性では、同じセッション内で発生する読み取りと書込みの因果関係のみが保証されます。

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

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

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

例

次の例では、coordinateCommitReturnImmediatelyAfterPersistingDecision に true を設定します。

mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

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

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

バージョン 6.0 で追加。

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

デフォルト: 1000

内部セッション メタデータ削除に関するセッション制限です。メタデータ:

  • ユーザー操作のセッション トランザクション情報が含まれています。

  • config.transactions コレクションに保存されている場合

内部セッションの数がinternalSessionsReapThresholdを超えると、メタデータは削除されます。

internalSessionsReapThresholdを0に設定すると、ユーザー セッションが終了したときにのみ内部セッション メタデータは削除されます。

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

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

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

次の例では、 internalSessionsReapThresholdから500セッションを設定します。

db.adminCommand( { setParameter: 1, internalSessionsReapThreshold: 500 } )

スタートアップ時にinternalSessionsReapThresholdを設定することもできます。 例:

mongod --setParameter internalSessionsReapThreshold=500
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

バージョン 6.0.5 の新機能。

mongod でのみ利用可能です。

タイプ: 10 進数

デフォルト: 0.75

キャッシュの負荷により失敗したトランザクションを再試行するためのしきい値。この値は、ダーティ キャッシュ サイズに対する割合。デフォルト値の 0.75 は、ダーティ キャッシュの 75% を意味します。

ダーティ キャッシュは合計キャッシュ サイズの 20% に制限されます。transactionTooLargeForCacheThreshold を 0.75 に設定すると、サーバは、storage engine キャッシュの合計の 15%（0.75 * 20%）未満を使用するトランザクションのみを再試行します。

この制限は再試行にのみ適用されます。大規模なトランザクションでは、ダーティ キャッシュの transactionTooLargeForCacheThreshold% 以上を使用することができます。ただし、キャッシュの負荷により大規模なトランザクションがロールバックされた場合、サーバーは TransactionTooLargeForCache エラーを発行し、トランザクションを再試行しません。

この動作を無効にするには、transactionTooLargeForCacheThreshold を 1.0 に設定します。

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

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

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

WiredTiger ストレージの詳細については、「storage.wiredTiger オプション」を参照してください。

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

戻る

構成ファイルの設定とコマンドライン オプションのマッピング

次へ

Cluster Parameters

項目一覧