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

注意

MongoDB 8.0以降、 LDAP認証と認可は非推奨です。 LDAP は使用可能であり、 MongoDB 8のサポート期間中に変更されずに動作し続けます。 LDAP は将来のメジャーリリースで削除される予定です。

詳しくは、「 LDAP の非推奨」を参照してください。

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を参照してください。

パラメーター

認証パラメータ

allowRolesFromX509Certificates

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

デフォルト: true

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

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

authenticationMechanisms

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

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

値	説明
SCRAM-SHA-1	RFC5802 標準の Salted Challenge Response Authentication Mechanism。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 でのみ使用できます。
MONGODB-OIDC	OpenID Connect は、OAuth2 上にビルドされた認証レイヤーです。このメカニズムは MongoDB Enterprise でのみ使用できます。

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

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

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

authFailedDelayMs

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

デフォルト: 0

注意

エンタープライズ機能

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

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

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

awsSTSRetryCount

バージョン7.0の変更：（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の詳細については、「自己管理型配置の TLS/SSL 用にとを構成するmongodmongos とクライアントの TLS/SSL 構成を参照してください。

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

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

enableLocalhostAuthBypass

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

デフォルト: true

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

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

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

enforceUserClusterSeparation

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

構成ファイルでclusterAuthModeがkeyFileである場合にO/OU/DCチェックを無効にするには、 falseに設定します。これにより、メンバー証明書を持つクライアントは、 $externalデータベースに保存されているユーザーとして認証できるようになります。構成ファイルでclusterAuthModeがkeyFileでない場合、サーバーは起動しません。

enforceUserClusterSeparationパラメータをfalseに設定するには、起動時に次のコマンドを実行します。

mongod --setParameter enforceUserClusterSeparation=false

JWKSMinimumQuiescePeriodSecs

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

デフォルト : 60 秒（1 分）

特定の IdP の JWKSetURI エンドポイントの後続の取得の間に渡す必要がある最小時間間隔を指定します。RSA公開キーが休止期間内に複数回変更された場合、休止期間を手動で短縮しない限り、そのキーは最大 1 分間、期待どおりに動作しない可能性があります。このパラメーターをゼロに設定すると、休止期間がなく、キーを繰り返し更新できます。

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

KeysRotationIntervalSec

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

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

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

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

ldapConnectionPoolHostRefreshIntervalMillis

mongod でのみ利用可能です。

デフォルト: 60000

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

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

ldapConnectionPoolIdleHostTimeoutSecs

mongod でのみ利用可能です。

デフォルト: 300

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

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

ldapConnectionPoolMaximumConnectionsInProgressPerHost

mongod でのみ利用可能です。

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

デフォルト: 2

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

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

ldapConnectionPoolMaximumConnectionsPerHost

mongod でのみ利用可能です。

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

デフォルト: 2147483647

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

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

ldapConnectionPoolMinimumConnectionsPerHost

mongod でのみ利用可能です。

デフォルト: 1

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

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

ldapConnectionPoolUseLatencyForHostPriority

mongod でのみ利用可能です。

デフォルト: true

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

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

ldapForceMultiThreadMode

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

デフォルト: false

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

注意

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

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

Tip

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

ldapQueryPassword

mongod でのみ利用可能です。

型: string

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

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

ldapQueryUser

mongod でのみ利用可能です。

型: string

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

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

ldapRetryCount

バージョン 6.1 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 0

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

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

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

mongod --ldapRetryCount=3

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

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

ldapShouldRefreshUserCacheEntries

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

true の場合は、ldapUserCacheRefreshIntervalを使用します。
false の場合は、ldapUserCacheInvalidationIntervalを使用します。

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

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

ldapUseConnectionPool

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

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

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

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

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

ldapUserCacheInvalidationInterval

バージョン 5.2 で変更。

mongod でのみ利用可能です。

デフォルト: 30 秒

注意

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

true の場合は、ldapUserCacheRefreshIntervalを使用します。
false の場合は、ldapUserCacheInvalidationIntervalを使用します。

自己管理型配置で LDAP 認証を使用する MongoDB 配置で使用します。

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

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

ldapUserCacheRefreshInterval

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30 秒

注意

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

true の場合は、ldapUserCacheRefreshIntervalを使用します。
false の場合は、ldapUserCacheInvalidationIntervalを使用します。

自己管理型配置で 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 } )

maxValidateMemoryUsageMB

mongod でのみ利用可能です。

バージョン 5.0 で追加

デフォルト: 200

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

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

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

ocspEnabled

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

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

デフォルト: true

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

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

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

mongod --setParameter ocspEnabled=false ...

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

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

ocspStaplingRefreshPeriodSecs

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

Linuxで利用できます。

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

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

mongod --setParameter ocspStaplingRefreshPeriodSecs=3600 ...

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

Tip

ocspEnabled
tlsOCSPStaplingTimeoutSecs
tlsOCSPVerifyTimeoutSecs

oidcIdentityProviders

mongod でのみ利用可能です。

バージョン 8.0 での変更: （7.3 および 7.0 でも利用可能）

OpenID Connect 認証を使用する場合、このパラメータを使用して IDP（アイデンティティプロバイダー）構成を指定します。

oidcIdentityProviders は、0 個以上の IdP（ID プロバイダー）構成の配列を受け入れます。空の配列（デフォルト）は、OpenID Connect サポートが有効になっていないことを示します。

複数の IdP が定義されている場合、 oidcIdentityProviders は matchPattern フィールドを使用して IdP を選択します。配列順が優先順位を決定し、常に最初のIdPが選択されます。

MongoDB 8.0 以降では、複数の ID プロバイダー（IDP）が定義されている場合、audience 値が各発行者に対して一意である限り、oidcIdentityProviders パラメータは重複する issuer 値を受け入れます。これは、バージョン 7.3 および 7.0 でも利用できます。

oidcIdentityProviders フィールド

フィールド

必要性

タイプ

説明

issuer

必須

string

サーバーがトークンを受け入れるべき IdP の発行者 URI。これは、認証に使用されるすべての JWT の issフィールドと一致する必要があります。

MongoDB 8.0以降では、複数の ID プロバイダー（IDP）が定義されている場合、 audience値が各発行者に対して一意である限り、 oidcIdentityProvidersパラメータは重複するissuer値を受け入れます。これは、バージョン7.3および7でも利用できます。 0 。

到達不能な発行者 URI を指定すると、MongoDB は次の処理を実行します。

警告をログに記録します。
サーバーの起動を続行します。これにより、発行者 URI を更新できます。
発行者への接続を再試行します。MongoDB が発行者 URI に到達し、アクセストークンを検証すると、認証は成功します。発行者 URI に到達できない状態の場合、認証は失敗します。

バージョン 8.0 での変更: （7.3 および 7.0 でも利用可能）

authNamePrefix

必須

string

生成された UserName と RoleName に適用される承認用の一意のプレフィックス。authNamePrefix には、次の文字のみを含めることができます。

英数字（a ～ z と 0 ～ 9 の組み合わせ）
ハイフン（-）
アンダースコア（_）

matchPattern

条件付き

string

どの IdP を使用するかを決定するために使用する正規表現パターン。 matchPattern がユーザー名と一致します。配列の順序が優先順位を決定するので、常に最初の IdP が選択されます。

matchPattern が一部の構成では必須となり、ユーザーがsupportsHumanFlowsをどのように設定するかに応じて決まります。

1 つの IdP のみでsupportsHumanFlows が true（デフォルト）に設定されている場合、matchPatterns は任意です。
複数の IdP でsupportsHumanFlows が true（デフォルト）に設定されている場合、それぞれに対して matchPatterns が必要です。
matchPatterns は、supportsHumanFlows が false に設定されているすべての IdP で任意です。

これはセキュリティの仕組みではありません。 matchPattern は顧客への助言としてのみ機能します。 MongoDB は、このパターンに一致しないプリンシパル名の IdP が発行したトークンを受け入れます。

clientId

条件付き

string

アクセストークンを受信するクライアントを識別するために IdP によって提供されるID 。

supportsHumanFlows にtrue（デフォルト）が設定されている場合に必須です。

audience

必須

string

アクセストークンの対象となるアプリケーションまたはサービスを指定します。

MongoDB 7.0以降、 OIDC アクセストークンには、 audience oidcIdentityProviders フィールドのみを指定できます。空の配列または複数の文字列の配列を持つaudienceフィールドは無効です。

複数の IdP が定義されている場合、これは issuer を共有する構成ごとに一意の値である必要があります。

requestScopes

任意

array[ string ]

MongoDB がIdP に要求するパーミッションとアクセスレベル。

重要:デフォルトでは 、Compass やmongosh などのクライアントはoidc offline_accessIdP からとのスコープをリクエスト。 IdP がoidc もoffline_access もサポートしていない場合、クライアントはそれらをリクエストしません。 IdP がoidc offline_accessをサポートするがをサポートしていない場合は、頻繁に再認証を行う必要があります。

principalName

任意

string

MongoDB ユーザー識別子を含むアクセストークンから抽出されるクレーム。

デフォルト値は sub（subject を表す）です。

useAuthorizationClaim

任意

ブール値

authorizationClaimが必要かどうかを判断します。デフォルト値はtrueです。

useAuthorizationClaim フィールドが true に設定されている場合、サーバーは IdP の構成に authorizationClaim が必要です。これはデフォルトの動作です。

useAuthorizationClaim フィールドに false が設定されている場合、authorizationClaim フィールドは任意（存在した場合は無視）です。代わりに、サーバーは次の処理を行います。

principalNameClaim フィールドに名前が一覧化されているクレームをトークンから検索します。通常、これには sub という名前がついています。たとえば次のとおりです。
sub: "spencer.jackson@example.com"
authNamePrefix、フォワードスラッシュ（/）、アクセストークン内の principalNameClaim で識別されるクレームの内容を連結して、内部ユーザー名を作成します。たとえば、authNamePrefix フィールドの値が「mdbinc」の場合、内部ユーザー名は次のようになります。
mdbinc/spencer.jackson@example.com
このユーザー名を持つユーザーを検索し、クライアントにロールを承認します。
```
{ user: "mdbinc/spencer.jackson@example.com",
  db: "$external" }
```

バージョン 7.2 の新機能（7.0.5 でも利用可能）

authorizationClaim

条件付き

string

useAuthorizationClaim に false が設定されていない場合は必須です。

MongoDB ロール名を含むアクセストークンから抽出されたクレーム。

logClaims

任意

array[ string ]

認証完了時にログおよび監査メッセージに含めるアクセストークンクレームのリスト。

JWKSPollSecs

任意

integer

更新された JWKS（ JSON Web Key Set）をIdP からリクエスト頻度（秒単位）。 0 を設定すると、ポーリングは無効になります。

複数の IdP が定義されている場合、これは issuer を共有する構成ごとに同じ値である必要があります。

supportsHumanFlows

任意

ブール

OIDC プロバイダーが人間のワークフローまたは機械のワークフローをサポートするか。これは、clientId フィールドと matchPattern フィールドに影響します。

マシンワークロード IdP でこのフィールドに false を設定して、不要な場合に clientId を省略できるようにすると便利な場合があります。

デフォルト: true 。

バージョン 7.2 で追加。

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

opensslCipherConfig

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

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

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

バージョン 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

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

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

pessimisticConnectivityCheckForAcceptedConnections

Linux でのみ利用可能です。

タイプ: ブール値

デフォルト: false

true に設定すると、サーバーは受け入れた接続を処理する前にその接続の有効性を確認し、クライアント側で終了された接続を即座に破棄するよう指示します。

このパラメーターを小さいインスタンスタイプで有効にすることを検討してください。新しい接続確立時のレイテンシをわずかに犠牲にしてでも、すでにクライアント側で閉じられた接続の処理にかかるサーバー負荷を軽減したい場合に使用できます。

saslauthdPath

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

注意

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

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

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

saslHostName

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

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

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

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

注意

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

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

saslServiceName

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

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

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

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

重要

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

scramIterationCount

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

デフォルト: 10000

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

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

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

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

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

mongod --setParameter scramIterationCount=12000

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

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

Tip

scramSHA256IterationCount

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

デフォルト: 15000

すべての新しい 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の詳細については、「自己管理型配置の TLS/SSL 用にとを構成するmongodmongos とクライアントの TLS/SSL 構成を参照してください。

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

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

Tip

tlsMode

tlsClusterAuthX509Override

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

バージョン 7.0 で追加。

clusterAuthX509 構成オプションを上書きします。

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

このパラメーターは attributes および extensionValue の上書きサポートします。

サーバーはノードからの接続を認証するときに、X.509証明書を分析して、クラスターノードに属しているかどうかを判断します。サーバーが attributes 設定または tlsClusterAuthX509Override パラメーターの attributes フィールドを使用する場合、証明書の識別名（DN）値を確認します。extensionValue 設定または tlsClusterAuthX509Override パラメーターの extensionValue フィールドが設定されている場合は、証明書の拡張値を確認します。一致するものが見つかった場合は、接続をピアとして承認します。

このパラメーターを使用して、新しい証明書の属性または拡張値が異なる場合に証明書をローテーションします。

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

tlsMode

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

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

preferTLS
requireTLS

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

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

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

TLS/SSL とMongoDBの詳細については、「自己管理型配置の TLS/SSL 用にとを構成するmongodmongos とクライアントの TLS/SSL 構成を参照してください。

Tip

sslMode

tlsOCSPStaplingTimeoutSecs

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

Linuxで利用できます。

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

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

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

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

mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

Tip

ocspEnabled
ocspStaplingRefreshPeriodSecs
tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

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

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

デフォルト: 5

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

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

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

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

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Tip

ocspEnabled
ocspStaplingRefreshPeriodSecs
tlsOCSPStaplingTimeoutSecs

tlsUseSystemCA

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

重要

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

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

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

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

mongod --setParameter tlsUseSystemCA=true

TLS/SSL とMongoDBの詳細については、「自己管理型配置の TLS/SSL 用にとを構成するmongodmongos とクライアントの TLS/SSL 構成を参照してください。

tlsWithholdClientCertificate

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

デフォルト: false

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 値を含む新しい証明書に、証明書のローリングアップデートを実行できます。「自己管理型クラスターで clusterAuthX509 属性を使用せずに x.509 証明書をローテーションする」を参照してください。

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

tlsX509ExpirationWarningThresholdDays

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

デフォルト : 30

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

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

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

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

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

userCacheInvalidationIntervalSecs

mongos でのみ利用可能です。

デフォルト: 30

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

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

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

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

一般的なパラメータ

allowDiskUseByDefault

mongod でのみ利用可能です。

デフォルト: True

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

connPoolMaxConnsPerHost

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

デフォルト: 200

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

注意

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

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

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

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

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

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

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

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

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

connPoolMaxConnsPerHost

cursorTimeoutMillis

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

デフォルト：600000（10分）

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 を使用してカーソルをリフレッシュする」を参照してください。

fassertOnLockTimeoutForStepUpDown

バージョン 5.3 で追加。

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

デフォルト: 15 秒

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

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

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

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

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

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

globalConnPoolIdleTimeoutMinutes

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

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

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

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

mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

httpVerboseLogging

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

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

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

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

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

mongos --setParameter httpVerboseLogging=true

indexBuildMinAvailableDiskSpaceMB

バージョン 7.1 で追加。

mongod でのみ利用可能です。

Default: 500 MB

インデックスビルドに必要な最小使用ディスク領域をメガバイト単位で設定します。

0MB 以上、8TB 以下である必要があります。 0 の場合、最小ディスク容量が無効になります。

使用可能なディスク容量がindexBuildMinAvailableDiskSpaceMB未満の場合、新しいインデックスビルドを開始できず、現在のインデックスビルドがキャンセルされます。

警告

indexBuildMinAvailableDiskSpaceMBを増やす場合は、サーバーに使用可能なディスク容量が十分にあることを確認してください。また、 indexBuildMinAvailableDiskSpaceMBを高く設定しすぎると、使用可能なディスク容量が十分にある場合にインデックスのビルドが不必要に妨げられ、 indexBuildMinAvailableDiskSpaceMBが低く設定される可能性があります。

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

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

次の例では、 indexBuildMinAvailableDiskSpaceMBを650 MB に設定します。

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

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

mongod --setParameter indexBuildMinAvailableDiskSpaceMB=650

indexMaxNumGeneratedKeysPerDocument

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

バージョン 5.3 で追加。

デフォルト: 100000

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

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

ingressAdmissionControllerTicketPoolSize

mongod でのみ利用可能です。

デフォルト: 1000000

イングレスキューで同時に許可される操作の最大数を制御します。デフォルト値の 1000000 は、無制限の数値同等値を表し、MongoDB が許可するデフォルトの最大接続数まですべての受信操作を許可します。

キューで待機している操作がある間にこの値を増やすと、新しいプールサイズが許容する限りの操作がブロック解除されます。この値を減らしても、現在実行中の操作はブロックされませんが、受信される制御可能な操作は、チケットが空くまでブロックされます。

mongod --setParameter ingressAdmissionControllerTicketPoolSize=100000

警告

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

ingressConnectionEstablishmentRateLimiterEnabled

バージョン 8.2 の新機能: （8.1.1 および 8.0.12 でも利用可能）

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

タイプ: ブール値

デフォルト: false

新規接続の確立に対するレート制限が有効かどうかを決定します。有効にすると、MongoDB はレート制限を適用し、1 秒あたりに確立できる新しい接続の数を制御します。

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

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

ingressConnectionEstablishmentRatePerSec

バージョン 8.2 の新機能: （8.1.1 および 8.0.12 でも利用可能）

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

タイプ: int32

デフォルト: disabled

最小: 1

レート制限が有効な場合、1 秒あたりに確立できる新規接続の最大数を指定します。

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

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

ingressConnectionEstablishmentBurstCapacitySecs

バージョン 8.2 の新機能: （8.1.1 および 8.0.12 でも利用可能）

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

型: double

デフォルト: disabled

最小: 1

レート制限が開始される前に、サーバーが許容できる接続確立数を何秒分とするかを定義します。これにより、サーバーは、次のレート制限で指定された制限を超える一時的な接続要求のバーストを処理できます: ingressConnectionEstablishmentRatePerSec。

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

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

ingressConnectionEstablishmentMaxQueueDepth

バージョン 8.2 の新機能: （8.1.1 および 8.0.12 でも利用可能）

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

タイプ: int32

デフォルト: 0（無効）

接続確立キュー内の最大接続試行回数を指定します。キューがこの接続試行数に達すると、サーバーは新しい接続試行を拒否します。

0 のデフォルト値は、サーバーが確立のためにキューに入るすべての接続を拒否することを意味します。

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

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

ingressConnectionEstablishmentRateLimiterBypass

バージョン 8.2 の新機能: （8.1.1 および 8.0.12 でも利用可能）

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

型: string 配列

デフォルト: []

サーバーが接続確立レート制限から除外する必要がある IP アドレスと CIDR 範囲のリストを提供します。これにより、特定の信頼できるクライアントがレート制限の制約を回避できるようになります。

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

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

maxIndexBuildMemoryUsageMegabytes

mongod でのみ利用可能です。

Default (absolute): 200
Minimum (absolute): 50
Maximum (percent): 0.8

1 つのコレクションにおいて同時インデックスが実行中に消費するメモリ量を制限します。指定された量のメモリは、単一の createIndexes コマンドまたはそのシェルヘルパー db.collection.createIndexes() を使用してビルドされたすべてのインデックス間で共有されます。制限を増やすと、インデックス構築プロセスでインデックスキーが生成およびソートされる際のソートパフォーマンスが向上します。インデックス構築によって消費されるメモリは、 WiredTigerキャッシュメモリとは別です（cacheSizeGB を参照)。

この値を 0-0.8 に設定すると、ビルドをメモリの割合に制限できます。
この値を 1.0 以上に設定すると、ビルドを絶対数のメガバイトに制限できます。

この設定で割り当てられる値が 50 MB 未満の場合、mongod は最小値 50 MB を使用します。パーセンテージの設定が 0.8 より大きい場合、mongod は使用可能なメモリの最大 80% を使用します。

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

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

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

reportOpWriteConcernCountersInServerStatus

mongod でのみ利用可能です。

デフォルト: false

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

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

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

slowConnectionThresholdMillis

バージョン 6.3 で追加。

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

デフォルト: 100

低速のサーバー接続の確立をログに記録する際の時間制限をミリ秒単位で設定します。

接続の確立にslowConnectionThresholdMillisパラメーターよりも長い時間がかかる場合、メッセージmsgフィールドで"Slow connection establishment"に設定されたイベントがログに追加されます。

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

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

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

mongod --setParameter slowConnectionThresholdMillis=250

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

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

警告

tcmallocAggressiveMemoryDecommit は 8.0 では非推奨です。MongoDB 8.0 は、メモリの断片化と管理を改善する更新バージョンの tcmalloc を使用します。詳細は tcmalloc のアップグレードを参照してください。メモリを解放してオペレーティングシステムに戻すには、代わりに tcmallocEnableBackgroundThread の使用を検討してください。

tcmallocEnableBackgroundThread

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

バージョン8.0の新機能。

タイプ: ブール値

デフォルト: true

trueに設定すると、tcmallocEnableBackgroundThread はメモリを定期的にオペレーティングシステムに解放するバックグラウンドスレッドを作成します。tcmallocReleaseRate の値によって、バックグラウンドスレッドがメモリを解放する速度が 1 秒あたりのバイト単位で決まります。

注意

tcmallocEnableBackgroundThread が true で tcmallocReleaseRate が 0 の場合でも、MongoDB はメモリを解放します。

メモリ使用量を改善するには、デフォルト値の true を使用することをお勧めします。パフォーマンスとメモリ管理の改善の詳細については、「アップグレードされた TCMalloc」を参照してください。

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

次の操作では、tcmallocEnableBackgroundThread に false を設定します。

mongod --setParameter "tcmallocEnableBackgroundThread=false"

tcmallocReleaseRate

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

バージョン8.0で変更。

デフォルト: 0

TCMalloc の解放率（1 秒あたりのバイト数）を指定します。解放率とは、 MongoDB が未使用のメモリをシステムに解放する速度を指します。tcmallocReleaseRate が 0 に設定されている場合、 MongoDB はメモリを解放してシステムに戻すことはありません。この値を増やすと、メモリの戻りが速くなります。メモリの戻りが遅くするには、それを減らします。

注意

tcmallocEnableBackgroundThread が true で tcmallocReleaseRate が 0 の場合でも、MongoDB はメモリを解放します。

MongoDB8.0 以降では、メモリ解放よりもtcmallocReleaseRate 0CPU パフォーマンスを優先する tcmalloc のアップグレードが行われているため、のデフォルト値はに削減されています。

以前のバージョンでは、 MongoDB は次のような古いバージョンの tcmalloc を使用していました。

デフォルトのtcmallocReleaseRate を 1 に設定します。
0 から 10 までの tcmallocReleaseRate の値を受け入れました。

重要

Windows 、PPC、s390x などの tcmalloc-gperf を使用するプラットフォームでMongoDBを実行すると、tcmallocReleaseRate は以前のMongoDBバージョンと同じ動作をします。

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

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

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

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

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

mongod --setParameter "tcmallocReleaseRate=2097152"

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

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

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

Tip

RFC7413.

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 の内部システム操作に悪影響を与える可能性があります。

watchdogPeriodSeconds

mongod でのみ利用可能です。

タイプ: 整数

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

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

--dbpath ディレクトリ
--dbpath ディレクトリ内の journal ディレクトリ
--logpath ファイルのディレクトリ
--auditPath ファイルのディレクトリ

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

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

注意

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

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

mongod --setParameter watchdogPeriodSeconds=60

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

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

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

注意

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

ログパラメータ

enableDetailedConnectionHealthMetricLogLines

バージョン 7.0 で追加。

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

タイプ: ブール値

デフォルト: true

クラスター接続の正常性メトリクスに関連する特定のログメッセージを有効にするかどうかを決定します。enableDetailedConnectionHealthMetricLogLinesがfalseに設定されている場合、次のログメッセージはオフになりますが、MongoDB は引き続きクラスター接続の正常性メトリクスに関するデータを収集します。

ログメッセージ	説明
ピアからの TLS 接続を受け入れました	受け付けた Ingress 接続での TLS ハンドシェイク中に、サーバーがピア証明書を正常に解析したことを示します。
Ingress TLS ハンドシェイクが完了しました	Ingress 接続での TLS ハンドシェイクが完了したことを示します。
Hello 処理が完了しました	受信クライアント接続で初期接続ハンドシェイクが完了したことを示します。 MongoDB は最初の `hello` コマンドでのみログメッセージを表示します。
認証メトリクスレポート	認証の交信のステップの完了を指定します。
セッションの開始または認証ハンドシェイク以降、Ingress 接続で最初のコマンドを受信しました	ハンドシェイクの一部ではない最初のコマンドを Ingress 接続が受信したことを示します。
ネットワーク応答の送信時間が遅くなっています	Ingress 接続を介してクライアントに応答を返すのにかかる時間（ミリ秒単位）が、`slowMS` サーバーパラメーターで定義された時間よりも長くかかることを示します。
OCSP リクエストのクライアント側での検証が完了しました	Egress TLS 接続が確立されたときにピアが TLS ハンドシェイクに対して OCSP 応答を含めない場合、サーバーは認証局に OCSP 要求を送信する必要があります。MongoDB は、認証局が OCSP 応答を受信したときに、このログメッセージを書き込みます。
接続の確立が遅くなっています	Ingress 接続を介してクライアントに応答を返すのにかかる時間が、`slowConnectionThresholdMillis` パラメーターで指定されたしきい値よりも長くかかることを示します。MongoDB は、接続確立がタイムアウトしたときにもこのログメッセージを発行します。
接続の取得待ちの間に操作がタイムアウトしました	Egress 接続の取得待ちの間に操作がタイムアウトしたことを示します。
リモート操作用の接続を取得し、通信での書き込みを完了しました	接続が確立された瞬間から起算して、サーバーが Egress 接続で送信リクエストを書き込むのに 1 ミリ秒以上かかったことを示します。

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

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

logComponentVerbosity

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

デフォルト: 0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

logLevel

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

デフォルト : 0（情報）

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

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

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

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

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

Tip

[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

redactEncryptedFields

バージョン 6.1.0 の新機能。

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

タイプ: ブール値

デフォルト: true

すべてのログメッセージからの暗号化された Binary データのフィールド値を編集するように mongod と mongos を構成します。

redactClientLogDataパラメーターまたはsecurity.redactClientLogData設定がfalseに設定され、 redactEncryptedFieldsがtrue（デフォルト）に設定されている場合、暗号化されたフィールドはすべてのログメッセージから削除されます。
redactClientLogDataパラメーターまたはsecurity.redactClientLogData設定がtrueに設定されている場合、 redactEncryptedFields設定に関係なく、すべてのフィールドが編集されます。

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

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

suppressNoTLSPeerCertificateWarning

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

タイプ: ブール値

デフォルト: false

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

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

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

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

traceExceptions

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

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

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

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

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

Tip

systemLog.traceAllExceptions

診断パラメータ

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 エンジニアから要求がある場合にのみ変更する必要があります。

diagnosticDataCollectionDirectoryPath

mongos でのみ利用可能です。

タイプ: string

警告

フルタイム診断データ取得（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 の両方で使用できます。

タイプ: 整数

デフォルト: 250（シャーディングされたクラスターでは 500）

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

バージョン 8.0 で変更: シャーディングされたクラスターで使用される mongos および mongod インスタンスにおいて、diagnosticDataCollectionDirectorySizeMB のデフォルト値は 400 MB です。レプリカセットまたはスタンドアロンサーバーとして使用される mongod インスタンスのデフォルト値は 200 MB です。

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

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

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

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

diagnosticDataCollectionEnabled

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

タイプ: ブール値

デフォルト: true

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

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

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

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

mongod --setParameter diagnosticDataCollectionEnabled=false

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ミリ秒です。

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

allowMultipleArbiters

バージョン 5.3 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

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

アービタが複数あると、過半数の書込み保証（write concern）を信頼して使用することができません。MongoDB は、メンバーシップの過半数を計算する際にアービタをカウントしますが、アービタはデータを保存しません。複数のアービタを含めると、データを含む大多数のノードに書き込みが複製される前に、過半数の書込み保証（write concern）操作が成功を返すことが可能です。
複数のアービタにより、レプリカセットにデータレプリケーション用の十分なセカンダリがない場合でも、レプリカセットは書き込みを受け入れることができます。

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

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

mongod --setParameter allowMultipleArbiters=true

connectTimeoutMs

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

タイプ: 整数

デフォルト: 10000

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

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

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

mongod --setParameter connectTimeoutMs=700

createRollbackDataFiles

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

mongod --setParameter createRollbackDataFiles=false

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

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

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

disableSplitHorizonIPCheck

バージョン 5.0.0 の新機能。

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

タイプ: ブール値

デフォルト: false

分裂ホライズン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

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

setParameter:
   disableSplitHorizonIPCheck: true

enableFlowControl

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

タイプ: ブール値

デフォルト: true

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

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

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

enableOverrideClusterChainingSetting

バージョン 5.0.2 の新機能。

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

タイプ: ブール値

デフォルト: false

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

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

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

mongod --setParameter enableOverrideClusterChainingSetting=true

flowControlTargetLagSeconds

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

タイプ: 整数

デフォルト: 10

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

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

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

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

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

flowControlWarnThresholdSeconds

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

タイプ: 整数

デフォルト: 10

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

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

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

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

heartBeatFrequencyMs

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

タイプ: 整数

デフォルト: 10000

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

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

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

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

mongod --setParameter heartBeatFrequencyMs=700

initialSyncIndexBuildMemoryPercentage

バージョン8.2の新機能。

mongod でのみ利用可能です。

型: double

デフォルト: 10.0

最初の同期中にMongoDB がインデックスビルドに割り当てたシステムメモリの割合。使用されるシステムメモリの量は、initialSyncIndexBuildMemoryMinMB と initialSyncIndexBuildMemoryMaxMB の値によって制限されます。

0.0 から 80.0 までの値を指定できます。

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

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

例、mongodインスタンスの initialSyncIndexBuildMemoryPercentage を 40% に設定するには、次のようにします。

mongod --setParameter initialSyncIndexBuildMemoryPercentage=40

initialSyncIndexBuildMemoryMaxMB

バージョン8.2の新機能。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 16384

MongoDB が最初の同期中にインデックス構築に使用できるシステムメモリの最大量（メガバイト単位）。

50 から 10000000 までの値を指定できます。

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

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

例、mongodインスタンスの initialSyncIndexBuildMemoryMaxMB を 20000 MB に設定するには、次の操作を実行します。

mongod --setParameter initialSyncIndexBuildMemoryMaxMB=20000

initialSyncIndexBuildMemoryMinMB

バージョン8.2の新機能。

mongod でのみ利用可能です。

タイプ : 整数

デフォルト: 200

MongoDB が最初の同期中にインデックス構築に使用できるシステムメモリの最小量（メガバイト単位）。

50 から 10000000 までの値を指定できます。

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

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

例、mongodインスタンスの initialSyncIndexBuildMemoryMinMB を 60 MB に設定するには、次の操作を実行します。

mongod --setParameter initialSyncIndexBuildMemoryMinMB=60

initialSyncMethod

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: string

デフォルト: logical

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

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

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

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

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

initialSyncSourceReadPreference

mongod でのみ利用可能です。

タイプ: string

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

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

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

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

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

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

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

initialSyncTransientErrorRetryPeriodSeconds

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

タイプ: 整数

デフォルト: 86400

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

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

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

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

logicalSessionRefreshMillis

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

タイプ: 整数

デフォルト: 300000（5 分）

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

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

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

mongod --setParameter logicalSessionRefreshMillis=600000

maxAcceptableLogicalClockDriftSecs

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

タイプ: 整数

デフォルト：31536000（1年）

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

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

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

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

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxNumSyncSourceChangesPerHour

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

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 3

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

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

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

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

maxSessions

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

タイプ: 整数

デフォルト: 1000000

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

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

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

mongod --setParameter maxSessions=1000

mirrorReads

mongod でのみ利用可能です。

型: ドキュメント

デフォルト: { 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 とは異なります。

targetedMirroring

キャッシュウォーミングの対象となるノードを設定するフィールドが含まれています。ターゲットミラーリングの詳細については、ターゲットを絞ったミラーリングされた読み取りを参照してください。

次のフィールドが含まれます:

`tag`	デフォルトは空の `BSONObj` です。ミラーリングの対象となるノードをターゲットにするために使用できるレプリカセットタグ。次の構文を使用して、ターゲットミラーリング用にノードを構成できます。 `tag: { "<tag1>": "<string1>" }` 入力できるタグは 1 つだけです。これらのタグを持つ同じレプリカセット内のすべてのノードが対象となります。
`samplingRate`	型: float 範囲: `0.0` から `1.0`（この値を含む）対象を絞った読み取りが 1 つまたは複数のホストにミラーリングされるレート。レートが `0.0` の場合は読み取りはミラーリングされないことを意味し、レートが `1.0` の場合はすべての読み取りがミラーリングされます。`samplingRate` のデフォルトは `0.01` ですが、`tag`フィールドのデフォルトは空であるため、`targetedMirroring` 機能はデフォルトでオフになっています。
`maxTimeMS`	タイプ: int ミラーリングされた読み取りがタイムアウトするまでの最大時間（ミリ秒単位）。`maxTimeMS` の最小値は `0` です。デフォルトは `1000` です。

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

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

mirrorReadsMaxConnPoolSize

バージョン8.2の新機能。

タイプ: int

デフォルト: 4

ミラーリングプール内の最大接続数を制御します。このパラメータは、一般的な読み取りと対象を絞ったミラーリングされた読み取りの両方に影響します。mirrorReadsMaxConnPoolSize の最小値は 1 です。

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

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

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

oplogFetcherUsesExhaust

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

oplogInitialFindMaxSeconds

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 60

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

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

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

periodicNoopIntervalSecs

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

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

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

注意

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

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

mongod --setParameter periodicNoopIntervalSecs=1

replBatchLimitBytes

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

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

replicaSetMonitorProtocol

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

型: string

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

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

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

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

mongod --setParameter replicaSetMonitorProtocol='sdam'

replWriterMinThreadCount

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 0

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

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

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

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

replWriterThreadCount

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 16

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

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

Tip

replWriterMinThreadCount

rollbackTimeLimitSecs

mongod でのみ利用可能です。

型: 64 ビット整数

デフォルト: 86400（1 日）

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

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

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

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

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

TransactionRecordMinimumLifetimeMinutes

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30

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

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

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

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

localLogicalSessionTimeoutMinutes

waitForSecondaryBeforeNoopWriteMS

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

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

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

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

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

mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

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

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

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

analyzeShardKeyCharacteristicsDefaultSampleSize

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10000000

analyzeShardKey を実行するときに sampleRate と sampleSize が設定されていない場合、シャードキー特性メトリクスを計算するときにサンプリングするドキュメントの数を指定します。0 より大きくする必要があります。

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

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

次の例では、スタートアップ時にanalyzeShardKeyCharacteristicsDefaultSampleSize に 10000 を設定します。

mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

analyzeShardKeyMonotonicityCorrelationCoefficientThreshold

バージョン 7.0 で追加。

mongod でのみ利用可能です。

型: double

デフォルト: 0.7

シャードキーが挿入順で単調に変化しているかを判断するために使用される RecordId 相関係数のしきい値を指定します。0 より大きく、1 以下である必要があります。

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

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

次の例では、スタートアップ時にanalyzeShardKeyMonotonicityCorrelationCoefficientThreshold に 1 を設定します。

mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

analyzeShardKeyNumMostCommonValues

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 5

返却する最も一般的なシャードキー値の数を指定します。コレクションに含まれる一意のシャードキーの数がこの値より少ない場合、analyzeShardKeyNumMostCommonValues はその最も一般的な値の数を返します。0 より大きく、1000 以下である必要があります。

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

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

次の例では、スタートアップ時にanalyzeShardKeyNumMostCommonValues に 3 を設定します。

mongod --setParameter analyzeShardKeyNumMostCommonValues=3

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

analyzeShardKeyNumRanges

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 100

シャードキー範囲のホットネス（アクセス頻度）を計算するときに、シャードキースペースを分割する範囲の数を指定します。0 より大きく、10000 以下である必要があります。

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

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

次の例では、スタートアップ時にanalyzeShardKeyNumRanges に 50 を設定します。

mongod --setParameter analyzeShardKeyNumRanges=50

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

analyzeShardKeyNumSamplesPerRange

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 10

シャードキーの範囲ごとにサンプルするドキュメントの数。 0 より大きく、10000 以下の値である必要があります。

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

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

次の例では、スタートアップ時にanalyzeShardKeyNumSamplesPerRange に 50 を設定します。

mongod --setParameter analyzeShardKeyNumSamplesPerRange=50

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

autoMergerIntervalSecs

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 3600

AutoMerger が有効な場合、自動マージのラウンド間隔（秒単位）を指定します。デフォルト値は 3600 秒（1 時間）です。

autoMergerIntervalSecs は、コンフィギュレーションサーバーでのみ設定できます。

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

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

次の例では、起動時に autoMergerIntervalSecs を 7200 秒（2 時間）に設定します。

mongod --setParameter autoMergerIntervalSecs=7200

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

autoMergerThrottlingMS

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 15000

AutoMerger が有効な場合、同じコレクションで AutoMerger によって開始されるマージ間の最小時間（ミリ秒単位）を指定します。

autoMergerThrottlingMS は、コンフィギュレーションサーバーでのみ設定できます。

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

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

次の例では、起動時に autoMergerThrottlingMS を 60000 ミリ秒（1 分）に設定します。

mongod --setParameter autoMergerThrottlingMS=60000

実行中に、setParameter コマンドを使用してパラメーターを設定または変更できます。

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

balancerMigrationsThrottlingMs

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

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 1000

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

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

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

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

mongod --setParameter balancerMigrationsThrottlingMs=2000

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

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

catalogCacheCollectionMaxEntries

バージョン 8.1 の新機能（8.0.10、7.0.22 以降でも利用可能）

タイプ: 整数

デフォルト: 10000

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

コレクションのカタログキャッシュで許可されるエントリの最大数。

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

catalogCacheDatabaseMaxEntries

バージョン 8.1 の新機能（8.0.10、7.0.22 以降でも利用可能）

タイプ: 整数

デフォルト: 10000

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

データベースのカタログキャッシュで許可されるエントリの最大数。

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

chunkDefragmentationThrottlingMS

バージョン 5.3 で追加。

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

タイプ: 整数

デフォルト: 0

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

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

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

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

mongod --setParameter chunkDefragmentationThrottlingMS=10

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

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

disableResumableRangeDeleter

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

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

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

重要

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

MongoDB 8.2 以降では、スタートアップと実行時の両方で disableResumableRangeDeleter を設定できます。

スタートアップ時に disableResumableRangeDeleter を設定するには、次のコマンドを使用します。

mongod --setParameter disableResumableRangeDeleter=false

実行時に disableResumableRangeDeleter を設定するには、次のコマンドを使用します。

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

enableFinerGrainedCatalogCacheRefresh

注意

8.0 で非推奨

MongoDB 8.0 以降では、パラメータは非推奨となり、変更やエラーは発生しません。

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

タイプ: ブール値

デフォルト: true

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

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

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

Tip

enableShardedIndexConsistencyCheck

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

mongod --setParameter enableShardedIndexConsistencyCheck=false

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

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

Tip

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

findChunksOnConfigTimeoutMS

バージョン 5.0 で追加

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

タイプ: 非負整数

デフォルト: 900000

chunksでの検索操作のタイムアウト時間（ミリ秒）。

クラスターに多数のチャンクがあり、チャンクのロードがエラー ExceededTimeLimit で失敗する場合は、次のようにパラメーターの値を増やしてください。

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

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

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

loadRoutingTableOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

maxCatchUpPercentageBeforeBlockingWrites

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

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

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

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

MongoDB 7.1（および 7.0.1）以降では、実行時にパラメータを設定できます。

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

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

MongoDB 7.1（および 7.0.1）以降では、次のように setParameter コマンドを使用して実行時にパラメーターを設定できます。

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

Tip

ライブ移行プロトコル

maxTimeMSForHedgedReads: 重要
MongoDB 8.1 以降では、ヘッジされた読み取りは削除され、このパラメーターは効果がありません。

metadataRefreshInTransactionMaxWaitBehindCritSecMS

非推奨

注意

MongoDB 8.1 以降では、古い metadataRefreshInTransactionMaxWaitBehindCritSecMS パラメータの名前が metadataRefreshInTransactionMaxWaitMS に変更されます。パラメータ名として metadataRefreshInTransactionMaxWaitBehindCritSecMS を引き続き使用できますが、これは非推奨であり、今後のMongoDBリリースで削除される予定です。

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

バージョン8.1で変更。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 500

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

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

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

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

警告

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

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

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

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

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

metadataRefreshInTransactionMaxWaitMS

バージョン8.1で変更。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 500

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

注意

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

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

警告

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

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

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

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

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

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

mongosShutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

mongos でのみ利用可能です。

タイプ: 整数

デフォルト: 15000

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

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

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

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

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

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

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

opportunisticSecondaryTargeting: 重要
MongoDB 8.1 以降では、ヘッジされた読み取りは削除され、このパラメーターは効果がありません。

orphanCleanupDelaySecs

バージョン8.2で変更。

mongod でのみ利用可能です。

デフォルト: 3600（60 分）

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

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

8.2 以降、シャードセカンダリで進行中のクエリの動作は terminateSecondaryReadsOnOrphanCleanup によって決定されます。

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

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

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

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

mongod --setParameter orphanCleanupDelaySecs=1200

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

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

Tip

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

persistedChunkCacheUpdateMaxBatchSize

バージョン 7.2 の新機能（および 7.1.1、 7.0.4、 6.0.13、 5.0.25）

mongod でのみ利用可能です。

型: 整数

デフォルト: 1000

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

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

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

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

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

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

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

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

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

queryAnalysisSampleExpirationSecs

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 7 * 24 * 3600

サンプリングされたクエリドキュメントが TTL モニターによって削除されるまで存在する時間（秒単位）。0 より大きくする必要があります。

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

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

次の例では、mongod インスタンスの起動時に queryAnalysisSampleExpirationSecs を 691200（8 * 24 * 3600）に設定します。

mongod --setParameter queryAnalysisSampleExpirationSecs=691200

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

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

queryAnalysisSamplerConfigurationRefreshSecs

バージョン 7.0 で追加。

バージョン 7.0.1 で変更。

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

タイプ: 整数

デフォルト: 10

サンプラー（mongos または mongod）がクエリアナライザのサンプリングレートをリフレッシュする間隔。

configureQueryAnalyzer コマンドで構成されたサンプリングレートは、通過するトラフィックに基づいて、シャーディングされたクラスターの mongos インスタンス、またはレプリカセットの mongod インスタンスに分割されます。mongos または mongod のサンプリングレート割り当てを、通過するトラフィックに対してより応答性を高くするには、この値を小さくします。

デフォルト値を使用することをお勧めします。

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

MongoDB 7.0.1 以降では、実行時に queryAnalysisSamplerConfigurationRefreshSecs を設定できます。

次の例では、mongod インスタンスの起動時に queryAnalysisSamplerConfigurationRefreshSecs を 60 秒に設定します。

mongod --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

次の例では、mongos インスタンスの起動時に queryAnalysisSamplerConfigurationRefreshSecs を 60 秒に設定します。

mongos --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

値を 30 秒に設定するには、次のコマンドを実行します。

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

queryAnalysisWriterIntervalSecs

バージョン 7.0 で追加。

バージョン 7.0.1 で変更。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 90

サンプリングされたクエリがディスクに書き込まれる間隔（秒単位）。

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

MongoDB 7.0.1 以降では、実行時に queryAnalysisWriterIntervalSecs を設定できます。

次の例では、mongod インスタンスの起動時に queryAnalysisWriterIntervalSecs を 60 秒に設定します。

mongod --setParameter queryAnalysisWriterIntervalSecs=60

値を 60 秒に設定するには、次のコマンドを実行します。

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

queryAnalysisWriterMaxBatchSize

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 100000

一度にディスクに書き込むサンプリングされたクエリの最大数。0 より大きく、100000 以下にする必要があります。

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

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

次の例では、mongod スタートアップのインスタンスで queryAnalysisWriterMaxBatchSize を 1000 に設定します。

mongod --setParameter queryAnalysisWriterMaxBatchSize=1000

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

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

queryAnalysisWriterMaxMemoryUsageBytes

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 100 * 1024 * 1024

クエリサンプリングライターが使用できるメモリの最大量（バイト単位)。制限に到達すると、バッファがフラッシュされるまで、新しいクエリと差分はすべてサンプリングから破棄されます。0 より大きくする必要があります。

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

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

次の例では、mongod スタートアップのインスタンスで queryAnalysisWriterMaxMemoryUsageBytes を 10000000 に設定します。

mongod --setParameter queryAnalysisWriterMaxMemoryUsageBytes=10000000

rangeDeleterBatchDelayMS

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 20

範囲移行のクリーンアップ段階で、次の削除バッチまでに待機する時間（ミリ秒単位）。

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

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

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

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

mongod --setParameter rangeDeleterBatchDelayMS=200

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

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

Tip

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

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

rangeDeleterBatchSize

mongod でのみ利用可能です。

タイプ: 非負整数

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

範囲移行のクリーンアップ段階で削除する各バッチの最大ドキュメント数。

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

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

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

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

mongod --setParameter rangeDeleterBatchSize=32

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

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

Tip

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

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

readHedgingMode: 重要
MongoDB 8.1 以降では、ヘッジされた読み取りは削除され、このパラメーターは効果がありません。

routingTableCacheChunkBucketSize

バージョン 7.0.1 の新機能。

バージョン 7.2 で変更。

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

タイプ: 整数

デフォルト: 500

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

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

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

mongod --setParameter routingTableCacheChunkBucketSize=250

shardedIndexConsistencyCheckIntervalMS

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600000

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

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

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

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

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

ShardingTaskExecutorPoolHostTimeoutMS

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

型: 整数

デフォルト: 300000（5 分）

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

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

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

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

ShardingTaskExecutorPoolMaxConnecting

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

型: 整数

デフォルト: 2

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

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

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

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

ShardingTaskExecutorPoolMaxSize

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

型: 整数

デフォルト: 2 ⁶⁴ - 1

各 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 で追加。

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

型: 整数

デフォルト: -1

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

設定値:

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

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolMaxSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolMinSize

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

型: 整数

デフォルト: 1

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

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

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

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

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

Tip

ShardingTaskExecutorPoolMaxSize
warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolMinSizeForConfigServers

バージョン 6.0 で追加。

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

型: 整数

デフォルト: -1

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

設定値:

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

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolMinSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolRefreshRequirementMS

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

型: 整数

デフォルト: 60000（1 分）

プール内のアイドル接続をハートビートするまでにmongosが待機する最大時間。プールが最小サイズを超えると、更新中にアイドル接続が破棄される可能性があります。

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

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

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

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

mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

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

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

ShardingTaskExecutorPoolRefreshTimeoutMS

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

型: 整数

デフォルト: 20000（20 秒）

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

shutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 15000

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

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

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

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

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

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

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

skipShardingConfigurationChecks

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

true の場合、シャードノードまたはコンフィギュレーションサーバーノードをスタンドアロンとして起動してメンテナンス操作を行うことができます。このパラメーターは、--configsvr または --shardsvr オプションと相互に排他的です。

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

mongod --setParameter skipShardingConfigurationChecks=true

重要

メンテナンスが完了したら、mongodを再起動するときにskipShardingConfigurationChecksパラメーターを削除します。

taskExecutorPoolSize

mongos でのみ利用可能です。

型: 整数

デフォルト: 1

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

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

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

taskExecutorPoolSizeのデフォルト値は1です。

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

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

mongos --setParameter taskExecutorPoolSize=6

Tip

ShardingTaskExecutorPoolMaxSize
ShardingTaskExecutorPoolMinSize

terminateSecondaryReadsOnOrphanCleanup

mongod でのみ利用可能です。

バージョン8.2の新機能。

タイプ: ブール値

デフォルト: true

セカンダリノードで実行されている長時間実行されている読み取り操作を、チャンク移行後の孤立したドキュメントの削除前に自動的に終了するかどうかを制御します。

シャーディングされたクラスターでは、チャンクがソースシャードから宛先シャードに正常に移行されても、 MongoDB は移行されたドキュメントをソースシャードからすぐに削除しません。代わりに、ソースシャードのプライマリは、移行されたチャンクの名前空間に関連する進行中の読み取りが完了するまで待機し、その後、orphanCleanupDelaySecs によって制御される追加の期間（デフォルト: 1 時間）を待機します。この追加の遅延により、孤立したドキュメントがソースシャードから削除される前に、実行時間が長いセカンダリ読み取りを終了できます。

孤立したドキュメントがソースシャードから削除された後、terminateSecondaryReadsOnOrphanCleanup が true に設定されていない限り、チャンク移行の前に開始されたセカンダリノードで実行中進行中の読み取りでは、エラーが返されることなくドキュメントが自動的に欠落する可能性があります。

terminateSecondaryReadsOnOrphanCleanup が true に設定されている場合、チャンク移行のコミット前に開始されたセカンダリノードでの読み取り操作は、孤立したドキュメントがセカンダリノードから削除される前に自動的に終了されます。これにより、移行中に移動されたドキュメントが暗黙的に欠落するというセカンダリ読み取りが長時間実行されるのを防ぎます。

false に設定されている場合、孤立したドキュメントが削除された後でも、セカンダリノードでの読み取り操作は実行され続けます。操作では、エラーを返さずにドキュメントが暗黙的に欠落することがあります。これは、8.2 より前のバージョンのMongoDB の動作と一致します。

注意

この動作は、チャンク移行がコミットする前に開始される読み取り操作にのみ影響します。クエリ、集計、複数の名前空間にまたがる操作など、セカンダリ上のすべての読み取り操作に適用されます。

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

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

エラー応答

terminateSecondaryReadsOnOrphanCleanup によって読み取り操作が終了すると、 MongoDB は次のエラーを返します。

{
  code: 175, 
  name: QueryPlanKilled, 
  categories: [CursorInvalidatedError], 
  errmsg: "Read has been terminated due to orphan range cleanup"
}

このエラーは設計上再試行することはできません。これらのエラーの処理の詳細については、シャーディングされたクラスターで実行されているセカンダリ読み取りが長時間実行されているを参照してください。

warmMinConnectionsInShardingTaskExecutorPoolOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

Tip

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

mongos でのみ利用可能です。

型: 整数

デフォルト: 2000（2 秒）

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

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

Tip

warmMinConnectionsInShardingTaskExecutorPoolOnStartup
ShardingTaskExecutorPoolMinSize

ヘルスマネージャーパラメータ

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

ストレージパラメータ

enableAutoCompaction

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

バージョン8.1.0の新機能。

タイプ: ブール値

デフォルト: false

インスタンスが自動でバックグラウンド圧縮を実行するかどうかを指定します。

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

次の例では、インスタンスで自動バックグラウンド圧縮を有効にします。

mongod --setParameter "enableAutoCompaction=true"

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 で追加

mongod でのみ利用可能です。

デフォルト: 300

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

バージョン 7.0 で変更。

mongod でのみ利用可能です。

タイプ: 整数

ストレージエンジンに許可された同時読み取りトランザクション（読み取りチケット）の最大数を指定します。

注意

バージョン 7.0 以降、MongoDB はチケット数を動的に調整して、パフォーマンスを最適化します（最大値は 128）。

この値を変更すると、パフォーマンスの問題やエラーが発生する可能性があります。動的な同時ストレージエンジントランザクションアルゴリズムを無効にするのがクラスターにとって最適かどうかを判断するには、MongoDB サポートにお問い合わせください。

MongoDB 7.0 以降では、このパラメーターはすべてのストレージエンジンで使用できます。以前のバージョンでは、このパラメーターは WiredTiger storage engine でのみ使用できます。

Tip

queues.execution

storageEngineConcurrentWriteTransactions

バージョン 7.0 で変更。

mongod でのみ利用可能です。

タイプ: 整数

WiredTigerストレージエンジンに許可される同時書込みトランザクションの最大数を指定します。

注意

バージョン 7.0 以降、MongoDB はチケット数を動的に調整して、パフォーマンスを最適化します（最大値は 128）。

Tip

queues.execution

syncdelay

mongod でのみ利用可能です。

デフォルト: 60

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

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

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

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

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

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

Tip

temporarilyUnavailableBackoffBaseMs

mongod でのみ利用可能です。

デフォルト: 1000

キャッシュの負荷によりロールバックされた書き込み操作を再試行するまでの初期遅延を指定します。

まれに、キャッシュの負荷により書込み (write) が失敗する場合があります。このような状況が発生すると、MongoDB では、TemporarilyUnavailable エラーを発行し、スロークエリログとフルタイム診断データ取得（FTDC）の 2 か所で temporarilyUnavailableErrors　カウンターの値を増加させます。

マルチドキュメントトランザクション内の個々の操作では、TemporarilyUnavailable エラーは返されません。

temporarilyUnavailableBackoffBaseMs } パラメータとtemporarilyUnavailableMaxRetriesパラメータを変更して、書込み再試行プロパティを調整します。

このパラメーターは以下を受け入れます。

値	説明
`integer >= 0`	デフォルトは 1 秒。再試行間の初期遅延。この値は、再試行のたびに最大 55 秒まで増加します。値を大きくすると、次回の再試行までにキャッシュ負荷が軽減される可能性が高くなります。再試行回数を設定するには、`temporarilyUnavailableMaxRetries` を使用します。

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

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

新しい値を設定するには、db.adminCommand() を使用します。

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

バージョン 6.1.0 の新機能。

temporarilyUnavailableMaxRetries

mongod でのみ利用可能です。

デフォルト: 10

キャッシュの負荷により書き込み操作がロールバックされた場合の最大再試行回数を指定します。

マルチドキュメントトランザクション内の個々の操作では、TemporarilyUnavailable エラーは返されません。

temporarilyUnavailableBackoffBaseMs } パラメータとtemporarilyUnavailableMaxRetriesパラメータを変更して、書込み再試行プロパティを調整します。

このパラメーターは以下を受け入れます。

値	説明
`integer >= 0`	最大再試行回数。再試行間の遅延が増加します。バックオフ時間を設定するには、`temporarilyUnavailableBackoffBaseMs` を使用します。

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

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

新しい値を設定するには、db.adminCommand() を使用します。

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

バージョン 6.1.0 の新機能。

upsertMaxRetryAttemptsOnDuplicateKeyError

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

バージョン8.1.0の新機能。

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

タイプ : 整数

デフォルト: 100

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

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

重要

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

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

mongod --setParameter "upsertMaxRetryAttemptsOnDuplicateKeyError=50"

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

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

WiredTiger パラメータ

wiredTigerConcurrentReadTransactions

mongod でのみ利用可能です。

タイプ: 整数

ストレージエンジンに許可された同時読み取りトランザクション（読み取りチケット）の最大数を指定します。

注意

バージョン 7.0 以降、MongoDB はチケット数を動的に調整して、パフォーマンスを最適化します（最大値は 128）。

バージョン 6.0 での変更。

wiredTigerConcurrentReadTransactions パラメーターは storageEngineConcurrentReadTransactions に名前が変更されました。

wiredTigerConcurrentWriteTransactions

mongod でのみ利用可能です。

タイプ: 整数

WiredTigerストレージエンジンに許可される同時書込みトランザクションの最大数を指定します。

注意

バージョン 7.0 以降、MongoDB はチケット数を動的に調整して、パフォーマンスを最適化します（最大値は 128）。

バージョン 6.0 での変更。

wiredTigerConcurrentWriteTransactions パラメーターは storageEngineConcurrentWriteTransactions に名前が変更されました。

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

wiredTigerSessionMax

バージョン8.1の新機能。

型 : 32 ビット整数

デフォルト：33000

mongod でのみ利用可能です。

WiredTigerによって許可されるセッションの最大数。

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

利用可能なすべてのWiredTiger構成オプションについては、WiredTiger のドキュメントを参照してください。

監査パラメータ

auditAuthorizationSuccess

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

タイプ: ブール値

デフォルト: false

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

authCheck アクションの承認成功の監査を有効にします。

auditAuthorizationSuccessがfalseの場合、監査システムはauthCheckの承認の失敗のみを記録します。

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

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

承認成功の監査を有効にするには、次のコマンドを発行します。

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

auditAuthorizationSuccessを有効にすると、承認の失敗のみをログに記録する場合よりもパフォーマンスが低下します。

ランタイム監査構成が有効になっている場合、auditAuthorizationSuccessパラメーターはmongodまたはmongos構成ファイルに表示されません。パラメーターが存在する場合、サーバーは起動に失敗します。

Tip

getParameter

auditConfigPollingFrequencySecs

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

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 300

シャーディングされたクラスターには、クラスターの監査構成設定を維持するサーバーが存在する場合があります。構成されていないサーバーが現在の監査生成についてコンフィギュレーションサーバーをポーリングする間隔を秒単位で設定します。返されたこの値が以前の既知の値と異なる場合、開始ノードは現在の構成をリクエストし、その内部状態をアップデートします。

注意

デフォルト値の 300 秒を使用すると、非 config ノードではauditConfigクラスターパラメータを設定してから最大 5 分かかることがあります。

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

auditEncryptionHeaderMetadataFile

バージョン 6.0 で追加。

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

型: string

注意

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

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

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

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

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

auditEncryptKeyWithKMIPGet

バージョン 6.0 で追加。

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

タイプ: ブール値

デフォルト: false

注意

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

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

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

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

mongod --setParameter auditEncryptKeyWithKMIPGet=true

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

AbortExpiredTransactionsSessionCheckoutTimeout

バージョン 8.1 の新機能: （8.0.13 でも利用可能）

mongod でのみ利用可能です。

タイプ: 整数

デフォルト : 100 ミリ秒

セッションは、データベース操作を実行するためにセッションプールからチェックアウトされます。

AbortExpiredTransactionsSessionCheckoutTimeout は、期限切れのトランザクションを終了しようとするときにチェックアウトするセッションの最大数（ミリ秒）を設定します。

期限切れのトランザクションが正常に終了すると、 MongoDB はmetrics.abortExpiredTransactions.successfulKills を増やします。セッションのチェックアウト時にタイムアウトしたためトランザクションが正常に終了しなかった場合、 MongoDB はmetrics.abortExpiredTransactions.timedOutKillsを増分します。

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

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

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

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

このパラメータは、のスタートアップ時に設定することもできます。（例: ）。

mongod --setParameter AbortExpiredTransactionsSessionCheckoutTimeout=120

coordinateCommitReturnImmediatelyAfterPersistingDecision

バージョン 5.0 で追加

バージョン 6.1 で更新

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

falseに設定すると、シャードトランザクションの調整役は、結果をクライアントに返す前に、参加しているすべてのシャードがマルチドキュメントトランザクションをコミットまたはキャンセルするかどうかの決定を確認するまで待機します。
trueに設定すると、シャードトランザクションの調整役は、要求されたトランザクションの書込み保証（ write concern ）で永続的な決定が行われるとすぐに、マルチドキュメントトランザクションをコミットする決定をクライアントに返します。
クライアントが "majority" 未満の書込み保証 (write concern) をリクエストした場合、決定がクライアントに返された後にコミットがロールバックされる可能性があります。
トランザクションには「書込みの読み取り」整合性がない場合があります。つまり、読み取り操作では、その前の書込み操作の結果が表示されない場合があります。これは、次の場合に発生する可能性があります。
- トランザクションは複数のシャードに書込み (write) しなければなりません。
- 読み取りと以前の書込み (write) は、異なるセッションで行われます。
因果整合性は、同じセッション内で発生する読み取りと書き込みの因果関係のみを保証します。

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

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

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

mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

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

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

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.2 の新機能。

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

スロットベースの実行パラメーター

planCacheSize

バージョン 6.3 で追加。

mongod でのみ利用可能です。

型: string

デフォルト: 5%

注意

planCacheSize パラメーターは MongoDB の以前のバージョンにも存在していましたが、バージョン 6.3 まではプランキャッシュには影響がありませんでした。

プランキャッシュのサイズをスロットベースのクエリ実行エンジンのみに設定します。

planCacheSize値は次のいずれかに設定できます。

プランキャッシュに割り当てるシステムの合計物理メモリの割合。たとえば、"8.5%"。
MB または GB のいずれかのプランキャッシュに割り当てる正確なデータ量。たとえば、"100MB" や "1GB"など。

プランキャッシュサイズを増やすと、クエリプランナーにキャッシュされたプランキャッシュクエリシェイプが増えます。これによりクエリのパフォーマンスは向上しますが、メモリ使用量が増加します。

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

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

次のスタートアップコマンドでは、planCacheSizeを80メガバイトに設定します。

mongod --setParameter planCacheSize="80MB"

MongoDB Shell 内で、setParameter コマンドを使用することもできます。

db.adminCommand( { setParameter: 1, planCacheSize: "80MB" } )

戻る

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

MongoDB クラスターパラメーター

注意

Synopsis

パラメーター

認証パラメータ

注意

エンタープライズ機能

注意

Tip

注意

注意

Tip

Tip

oidcIdentityProviders フィールド

注意

注意

注意

注意

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

注意

重要

Tip

Tip

Tip

Tip

Tip

Tip

重要

注意

一般的なパラメータ

注意

Tip

警告

警告

警告

注意

警告

注意

注意

重要

Tip

Tip

Tip

重要

注意

注意

ログ パラメータ

Tip

警告

Tip

注意

エンタープライズ機能

Tip

Tip

診断パラメータ

注意

警告

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

警告

テスト目的のみ

注意

Tip

Tip

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

重要

注意

8.0 で非推奨

Tip

Tip

Tip

重要

注意

警告

注意

警告

重要

Tip

Tip

Tip

重要

Tip

ログパラメータ

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

ヘルスマネージャーパラメータ

`progressMonitor` フィールド

ストレージパラメータ

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