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

項目一覧

Synopsis

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

Synopsis

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

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

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

パラメーター

認証パラメータ

authenticationMechanisms

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

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

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

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

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

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

awsSTSRetryCount

バージョン7.0の変更：（6.0.7および5.0.18以降でも開始）

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

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

タイプ: 整数

デフォルト: 2

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

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

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

mongod --setParameter awsSTSRetryCount=15

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

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

clusterAuthMode

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

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

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

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

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

enableLocalhostAuthBypass

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

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

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

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

KeysRotationIntervalSec

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

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

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

ldapForceMultiThreadMode

デフォルト: false

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

注意

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

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

Tip

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

ldapQueryPassword

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

型: string

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

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

ldapQueryUser

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

型: string

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

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

ldapRetryCount

バージョン 6.1 で追加。

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

タイプ: 整数

デフォルト: 0

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

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

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

mongod --ldapRetryCount=3

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

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

ldapUserCacheInvalidationInterval

バージョン 5.2 で変更。

mongod でのみ利用可能です。

注意

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

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

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

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

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

デフォルトは 30 秒です。

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

ldapUseConnectionPool

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

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

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

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

ldapConnectionPoolUseLatencyForHostPriority

デフォルト: true

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

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

ldapConnectionPoolMinimumConnectionsPerHost

デフォルト: 1

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

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

ldapConnectionPoolMaximumConnectionsPerHost

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

デフォルト: 2147483647

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

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

ldapConnectionPoolMaximumConnectionsInProgressPerHost

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

デフォルト: 2

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

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

ldapConnectionPoolHostRefreshIntervalMillis

デフォルト: 60000

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

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

ldapConnectionPoolIdleHostTimeoutSecs

デフォルト: 300

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

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

ldapShouldRefreshUserCacheEntries

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

maxValidateMemoryUsageMB

バージョン 5.0 で追加

デフォルト: 200

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

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

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

oidcIdentityProviders

バージョン 7.0 で追加。

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

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

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

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

重要

より低い FCV7.0 を使用している場合は、authorizationClaim clientIdフィールドとフィールドが必要です。
フィールドと useAuthorizationClaimsupportsHumanFlowsフィールドは FCV を使用した配置でのみ使用できます。7.0

配置で使用される FCV を見つけるには、「 FeatureCompatibilityVersion の取得」を参照してください。

oidcIdentityProviders フィールド

フィールド

必要性

タイプ

説明

issuer

必須

string

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

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

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

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（デフォルト）が設定されている場合に必須です。

重要: 未満の FCV7.0 を使用する場合は、clientId が必要です。

audience

必須

string

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

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

requestScopes

任意

array[ string ]

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

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.0.5の新機能。

重要: useAuthorizationClaim は FCV 7.0 の配置でのみ使用できます。

authorizationClaim

条件付き

string

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

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

重要: 未満の FCV7.0 を使用する場合は、authorizationClaim が必要です。

logClaims

任意

array[ string ]

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

JWKSPollSecs

任意

integer

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

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

supportsHumanFlows

任意

ブール値

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

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

デフォルト: true 。

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

重要: supportsHumanFlows は FCV 7.0 の配置でのみ使用できます。

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

ocspEnabled

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

デフォルト: true

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

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

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

mongod --setParameter ocspEnabled=false ...

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

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

Tip

ocspValidationRefreshPeriodSecs

Linuxで利用できます。

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

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

mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ...

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

Tip

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

ocspEnabled
tlsOCSPStaplingTimeoutSecs
tlsOCSPVerifyTimeoutSecs

opensslCipherConfig

Linux でのみ利用可能です。

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

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

注意

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

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

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

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

opensslCipherSuiteConfig

バージョン 5.0 で追加

Linux でのみ利用可能です。

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

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

注意

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

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

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

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

opensslDiffieHellmanParameters

Linux でのみ利用可能です。

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

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

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

注意

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

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

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

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

saslauthdPath

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

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

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

Tip

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

tlsMode

tlsMode

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

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

preferTLS
requireTLS

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

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

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

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

Tip

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

sslMode

tlsClusterAuthX509Override

バージョン 7.0 で追加。

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

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

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

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

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

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

tlsOCSPStaplingTimeoutSecs

Linuxで利用できます。

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

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

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

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

mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

Tip

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

ocspEnabled
ocspValidationRefreshPeriodSecs
tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

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

デフォルト: 5

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

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

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

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

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Tip

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

ocspEnabled
ocspValidationRefreshPeriodSecs
tlsOCSPStaplingTimeoutSecs

tlsUseSystemCA

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

重要

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

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

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

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

mongod --setParameter tlsUseSystemCA=true

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

tlsWithholdClientCertificate

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

デフォルト: 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値を含む新しい証明書に、証明書のローリングアップデートを行うことができます。 x のローリングアップデートを参照してください。自己管理型クラスター上の新しい識別名を含む509証明書

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

tlsX509ExpirationWarningThresholdDays

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

デフォルト : 30

が x を表示した場合、 mongod / mongosは接続時に警告を記録します。 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設定を使用します

authFailedDelayMs

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

デフォルト: 0

注意

エンタープライズ機能

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

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

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

allowRolesFromX509Certificates

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

デフォルト: true

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

このパラメーターは、スタートアップ時にのみ使用できます。パラメーターを設定するには、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
  }
)

httpVerboseLogging

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

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

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

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

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

mongos --setParameter httpVerboseLogging=true

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

connPoolMaxConnsPerHost

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

デフォルト: 200

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

注意

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

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

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

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

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

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

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

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

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

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

connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes

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

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

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

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

mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

cursorTimeoutMillis

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

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

maxNumActiveUserIndexBuilds

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 3

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

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

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

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

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

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

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

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

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

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

notablescan

mongod でのみ利用可能です。

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

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

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

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

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

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

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

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

注意

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

ttlMonitorEnabled

mongod でのみ利用可能です。

デフォルト: true

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

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

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

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

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

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

mongod --setParameter ttlMonitorEnabled=false

重要

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

tcpFastOpenServer

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

デフォルト: true

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

Windows

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

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

MacOS

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

Linux

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

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

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

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

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

Tip

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

RFC7413.

tcpFastOpenClient

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

デフォルト: true

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

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

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

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

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

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

Tip

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

RFC7413.

tcpFastOpenQueueSize

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

デフォルト: 1024

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

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

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

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

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

Tip

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

disableJavaScriptJIT

mongod でのみ利用可能です。

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

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

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

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

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

注意

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

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

mongod --setParameter disableJavaScriptJIT=false

indexMaxNumGeneratedKeysPerDocument

バージョン 5.3 で追加。

デフォルト: 100000

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

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

maxIndexBuildMemoryUsageMegabytes

デフォルト: 200

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

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

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

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

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

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

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

Tip

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

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

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

reportOpWriteConcernCountersInServerStatus

デフォルト: false

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

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

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

watchdogPeriodSeconds

mongod でのみ利用可能です。

タイプ: 整数

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

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

--dbpath ディレクトリ
--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 が有効になっていない場合、実行時に設定するとエラーが発生します。

tcmallocAggressiveMemoryDecommit

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

デフォルト: 0

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

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

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

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

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

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

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

tcmallocReleaseRate

デフォルト: 1.0

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

注意

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

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

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

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

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

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

mongod --setParameter "tcmallocReleaseRate=5.0"

fassertOnLockTimeoutForStepUpDown

バージョン 5.3 で追加。

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

デフォルト: 15 秒

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

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

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

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

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

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

ログパラメータ

logLevel

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

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

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

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

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

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

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

Tip

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

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

logComponentVerbosity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

maxLogSizeKB

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

型: 非負整数

デフォルト: 10

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

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

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

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

警告

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

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

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

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

mongod --setParameter maxLogSizeKB=20

profileOperationResourceConsumptionMetrics

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

操作でリソース消費メトリクスを収集し、低速クエリログで報告するかどうかを決定するフラグ。プロファイリングを有効にすると、これらのメトリクスも含まれます。

true に設定されている場合、冗長度が executionStats 以上のときに explain コマンドの実行により operationMetrics が返されます。

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

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

traceExceptions

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

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

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

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

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

Tip

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

systemLog.traceAllExceptions

suppressNoTLSPeerCertificateWarning

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

タイプ: ブール値

デフォルト: false

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

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

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

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

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

診断パラメータ

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

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

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

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

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

注意

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

diagnosticDataCollectionEnabled

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

タイプ: ブール値

デフォルト: true

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

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

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

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

mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionDirectoryPath

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 の両方で使用できます。

タイプ: 整数

デフォルト: 200

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

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

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

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

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

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

diagnosticDataCollectionFileSizeMB

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

タイプ: 整数

デフォルト: 10

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

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

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

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

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

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

diagnosticDataCollectionPeriodMillis

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

タイプ: 整数

デフォルト: 1000

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

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

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

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

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

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

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

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

enableOverrideClusterChainingSetting

バージョン 5.0.2 の新機能。

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

タイプ: ブール値

デフォルト: false

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

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

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

mongod --setParameter enableOverrideClusterChainingSetting=true

logicalSessionRefreshMillis

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

タイプ: 整数

デフォルト: 300000（5 分）

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

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

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

mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes

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

タイプ: 整数

デフォルト: 30

警告

テスト目的のみ

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

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

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

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

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

mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs

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

タイプ: 整数

デフォルト：31536000（1年）

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

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

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

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

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions

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

タイプ: 整数

デフォルト: 1000000

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

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

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

mongod --setParameter maxSessions=1000

oplogBatchDelayMillis

バージョン 6.0 で追加。

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

タイプ: 整数

デフォルト: 0

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

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

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

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

mongod --setParameter oplogBatchDelayMillis=20

periodicNoopIntervalSecs

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

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

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

注意

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

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

mongod --setParameter periodicNoopIntervalSecs=1

storeFindAndModifyImagesInSideCollection

バージョン 5.0 で追加

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

タイプ: ブール値

デフォルト: true

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

storeFindAndModifyImagesInSideCollectionがの場合:

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

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

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

注意

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

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

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

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

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

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

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

TransactionRecordMinimumLifetimeMinutes

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 30

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

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

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

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

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

localLogicalSessionTimeoutMinutes

enableFlowControl

タイプ: ブール値

デフォルト: true

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

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

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

注意

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

flowControlTargetLagSeconds

タイプ: 整数

デフォルト: 10

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

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

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

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

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

flowControlWarnThresholdSeconds

タイプ: 整数

デフォルト: 10

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

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

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

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

initialSyncTransientErrorRetryPeriodSeconds

タイプ: 整数

デフォルト: 86400

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

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

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

initialSyncSourceReadPreference

mongod でのみ利用可能です。

タイプ: string

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

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

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

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

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

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

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

initialSyncMethod

バージョン 5.2 で追加。

mongod でのみ利用可能です。

タイプ: string

デフォルト: logical

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

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

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

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

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

maxNumSyncSourceChangesPerHour

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 3

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

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

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

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

oplogFetcherUsesExhaust

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

oplogInitialFindMaxSeconds

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 60

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

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

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

replWriterThreadCount

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 16

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

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

Tip

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

replWriterMinThreadCount

replWriterMinThreadCount

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 0

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

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

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

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

rollbackTimeLimitSecs

型: 64 ビット整数

デフォルト: 86400（1 日）

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

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

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

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

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

waitForSecondaryBeforeNoopWriteMS

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

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

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

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

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

mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

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

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

createRollbackDataFiles

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

mongod --setParameter createRollbackDataFiles=false

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

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

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

replBatchLimitBytes

Default: 104857600 (100MB)

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

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

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

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

次の例では、oplog アプリケーションのバッチサイズを制限するために、 replBatchLimitBytesを64 MB に設定しています。

mongod --setParameter replBatchLimitBytes=67108864

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

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

mirrorReads

mongod でのみ利用可能です。

型: ドキュメント

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

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

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

フィールド

説明

samplingRate

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

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

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

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

デフォルト値は 0.01 です。

maxTimeMS

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

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

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

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

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

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

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

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

setParameter:
   mirrorReads: '{samplingRate: 0.10}'

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

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

allowMultipleArbiters

バージョン 5.3 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

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

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

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

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

mongod --setParameter allowMultipleArbiters=true

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

analyzeShardKeyCharacteristicsDefaultSampleSize

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10000000

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

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

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

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

mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

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

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

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

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

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

chunkDefragmentationThrottlingMS

バージョン 5.3 で追加。

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

タイプ: 整数

デフォルト: 0

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

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

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

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

mongod --setParameter chunkDefragmentationThrottlingMS=10

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

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

chunkMigrationConcurrency

MongoDB 7.0、6.3、6.0.6（および 5.0.15）以降で利用できます。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 1

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

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

最大値は 500 です。

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

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

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

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

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

mongod --setParameter chunkMigrationConcurrency=5

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

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

コレクションバランシングを構成するには、「configureCollectionBalancing」を参照してください。

シャーディングされたコレクションのデフラグについて詳しくは、「シャーディングされたコレクションのデフラグ」をご覧ください。

disableResumableRangeDeleter

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

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

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

重要

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

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

mongod --setParameter disableResumableRangeDeleter=false

enableShardedIndexConsistencyCheck

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

mongod --setParameter enableShardedIndexConsistencyCheck=false

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

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

Tip

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

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

opportunisticSecondaryTargeting

バージョン 6.1.0 の新機能。

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: false

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

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

注意

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

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

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

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

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600000

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

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

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

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

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

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

enableFinerGrainedCatalogCacheRefresh

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

タイプ: ブール値

デフォルト: true

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

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

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

Tip

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

maxTimeMSForHedgedReads

mongos でのみ利用可能です。

タイプ: 整数

デフォルト: 150

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

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

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

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

mongos --setParameter maxTimeMSForHedgedReads=200

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

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

Tip

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

maxCatchUpPercentageBeforeBlockingWrites

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 10

moveChunk および 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

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

ライブ移行プロトコル

metadataRefreshInTransactionMaxWaitBehindCritSecMS

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

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 500

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

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

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

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

警告

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

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

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

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

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

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
To set the value to 60 seconds, run the following:

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

queryAnalysisWriterMaxMemoryUsageBytes

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 100 * 1024 * 1024

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

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

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

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

mongod --setParameter queryAnalysisWriterMaxMemoryUsageBytes=10000000

queryAnalysisWriterMaxBatchSize

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 100000

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

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

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

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

mongod --setParameter queryAnalysisWriterMaxBatchSize=1000

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

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

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

readHedgingMode

mongos でのみ利用可能です。

型: string

デフォルト: オン

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

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

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

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

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

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

mongos --setParameter readHedgingMode=off

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

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

Tip

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

routingTableCacheChunkBucketSize

バージョン 7.0.1 の新機能。

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

タイプ: 整数

デフォルト: 500

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

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

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

mongod --setParameter routingTableCacheChunkBucketSize=250

shutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 15000

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

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

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

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

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

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

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

mongosShutdownTimeoutMillisForSignaledShutdown

バージョン 5.0 で追加

mongos でのみ利用可能です。

タイプ: 整数

デフォルト: 15000

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

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

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

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

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

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

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

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

taskExecutorPoolSize

mongos でのみ利用可能です。

型: 整数

デフォルト: 1

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

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

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

Linux で MongoDB 6.2以降を実行中の場合、taskExecutorPoolSizeをデフォルト値の1から変更することはできません。Windows または macOS で MongoDB を実行中の場合は、このパラメーターを変更できます。

taskExecutorPoolSizeのデフォルト値は1です。

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

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

mongos --setParameter taskExecutorPoolSize=6

Tip

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

ShardingTaskExecutorPoolMaxSize
ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup

mongos でのみ利用可能です。

タイプ: ブール値

デフォルト: true

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

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

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

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

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

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

migrateCloneInsertionBatchDelayMS

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 0

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

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

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

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

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

mongod --setParameter migrateCloneInsertionBatchDelayMS=200

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

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

migrateCloneInsertionBatchSize

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 0

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

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

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

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

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

mongod --setParameter migrateCloneInsertionBatchSize=100

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

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

orphanCleanupDelaySecs

mongod でのみ利用可能です。

デフォルト: 900（15 分）

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

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

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

注意

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

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

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

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

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

mongod --setParameter orphanCleanupDelaySecs=1200

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

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

Tip

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

persistedChunkCacheUpdateMaxBatchSize

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

mongod でのみ利用可能です。

型: 整数

デフォルト: 1000

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

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

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

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

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

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

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

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

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

rangeDeleterBatchDelayMS

mongod でのみ利用可能です。

タイプ: 非負整数

デフォルト: 20

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

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

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

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

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

mongod --setParameter rangeDeleterBatchDelayMS=200

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

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

Tip

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

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

rangeDeleterBatchSize

mongod でのみ利用可能です。

タイプ: 非負整数

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

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

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

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

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

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

mongod --setParameter rangeDeleterBatchSize=32

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

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

Tip

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

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

rangeDeleterHighPriority

バージョン 7.0 で追加。

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

true の場合、ユーザーの操作よりも孤立したドキュメントのクリーンアップを優先します。デフォルトでは、孤立したドキュメントのクリーンアップよりもユーザーの操作を優先するように、false に設定されています。

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

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

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

mongod --setParameter rangeDeleterHighPriority=true

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

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

skipShardingConfigurationChecks

mongod でのみ利用可能です。

タイプ: ブール値

デフォルト: false

true の場合、シャードノードまたはコンフィギュレーションサーバーノードをスタンドアロンとして起動してメンテナンス操作を行うことができます。このパラメーターは、--configsvr または --shardsvr オプションと相互に排他的です。

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

mongod --setParameter skipShardingConfigurationChecks=true

重要

メンテナンスが完了したら、mongodを再起動するときにskipShardingConfigurationChecksパラメーターを削除します。

findChunksOnConfigTimeoutMS

バージョン 5.0 で追加

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

タイプ: 非負整数

デフォルト: 900000

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

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

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

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

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

ヘルスマネージャーパラメータ

activeFaultDurationSecs

mongos でのみ利用可能です。

型: ドキュメント

ヘルスマネージャーの概要に障害が発生してから、mongos がクラスターから排除されるまでの待機時間（秒単位）です。

障害が検出され、ヘルスマネージャーが critical に構成されている場合、サーバーは指定された間隔だけ待機してから、クラスターから mongos を削除します。

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

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

たとえば、障害からクラッシュまでの期間を 5 分に設定するには、起動時に次のコマンドを発行します。

mongos --setParameter activeFaultDurationSecs=300

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

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの activeFaultDurationSecs を設定します。

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

mongos でのみ利用可能です。

型: ドキュメントの配列

このパラメータを使用して、ヘルスマネージャーの強度レベルを設定します。

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

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

healthMonitoringIntensities はドキュメントの配列 values を受け取ります。values の各ドキュメントは 2 個のフィールドを取ります。

type、ヘルスマネージャーファセット
intensity、強度レベル

ヘルスマネージャー

Facet	ヘルスオブザーバーがチェックする内容
`configServer`	コンフィギュレーションサーバーに対する接続に関連するクラスターの健全性の問題。
`dns`	DNS の可用性と機能に関連するクラスターの健全性の問題。
`ldap`	LDAP の可用性と機能に関するクラスターの健全性の問題。

強度レベル

強度レベル	説明
`critical`	このファセットのヘルスマネージャーは有効になっており、エラーが発生した場合に障害のあるmongosをクラスターから移動する機能があります。ヘルスマネージャーは、 `activeFaultDurationSecs`で指定された時間待機してから、 mongosを自動的に停止してクラスターから移動します。
`non-critical`	このファセットのヘルスマネージャーは有効になっており、エラーをログに記録しますが、エラーが発生した場合、mongos はクラスター内に残ります。
`off`	このファセットのヘルスマネージャーは無効です。mongos は、このファセットでヘルスチェックを実行しません。これは、デフォルトの強度レベルです。

たとえば、dns ヘルスマネージャーファセットを強度レベル critical に設定するには、スタートアップ時に以下を実行します。

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

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

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの healthMonitoringIntensities を設定します。

setParameter:
   healthMonitoringIntensities: "{ values:[ { type:\"dns\", intensity: \"critical\"} ] }"

healthMonitoringIntervals

mongos でのみ利用可能です。

型: ドキュメントの配列

このヘルスマネージャーの実行頻度（ミリ秒単位）です。

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

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

healthMonitoringIntervals はドキュメントの配列 values を受け取ります。values の各ドキュメントは 2 個のフィールドを取ります。

type、ヘルスマネージャーファセット
interval、実行の間隔（ミリ秒単位）

ヘルスマネージャー

Facet	ヘルスオブザーバーがチェックする内容
`configServer`	コンフィギュレーションサーバーに対する接続に関連するクラスターの健全性の問題。
`dns`	DNS の可用性と機能に関連するクラスターの健全性の問題。
`ldap`	LDAP の可用性と機能に関するクラスターの健全性の問題。

たとえば、30 秒ごとにヘルスチェックを実行するように ldap ヘルスマネージャーファセットを設定するには、スタートアップ時に次のコマンドを発行します。

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

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

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの healthMonitoringIntervals を設定します。

setParameter:
   healthMonitoringIntervals: "{ values: [{type: \"ldap\", interval: 200}] }"

progressMonitor

mongos でのみ利用可能です。

型: ドキュメント

プログレスモニターは、ヘルスマネージャーのチェックが停止したり、応答しなくなったりしないよう確認するためのテストを実行します。プログレスモニターは、interval で指定された間隔でこれらのテストを実行します。ヘルスチェックが開始されたが、deadline で指定されたタイムアウト内に完了しない場合、プログレスモニターは mongos を停止し、クラスターから削除します。

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

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

`progressMonitor` フィールド

フィールド	説明	単位
`interval`	ヘルスマネジャーが、停止したり、応答しなくなったりしないよう確認する頻度。	ミリ秒
`deadline`	ヘルスマネージャーのチェックが進行していない場合に、mongos を自動的に失敗させるまでの中断時間。	秒

interval を 1000 ミリ秒に設定し、deadline を 300 秒に設定するには、スタートアップ時に次のコマンドを発行します。

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

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

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

setParameter で設定されたパラメーターは再起動後に永続することはありません。詳細については、「setParameter ページ」を参照してください。

この設定を永続的にするには、次の例のように setParameter オプションを使用して mongos コンフィギュレーションファイルの progressMonitor を設定します。

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

ストレージパラメータ

honorSystemUmask

mongod でのみ利用可能です。

デフォルト: false

honorSystemUmaskがtrueに設定されている場合、MongoDB によって作成された新しいファイルには、ユーザーのumask設定に従って権限が付与されます。 processUmaskhonorSystemUmaskがに設定されている場合、true を設定することはできません。

honorSystemUmaskがfalseに設定されている場合、MongoDB によって作成される新しいファイルの権限は600に設定され、読み取りと書込みの権限が所有者のみに付与されます。新しいディレクトリの権限は700に設定されています。 processUmaskを使用して、MongoDB によって作成されたすべての新しいファイルに対するグループや他のユーザーのデフォルト権限を上書きできます。

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

mongod --setParameter honorSystemUmask=true

注意

honorSystemUmask は、Windows システムでは使用できません。

journalCommitInterval

mongod でのみ利用可能です。

ジャーナルコミット間のミリ秒数（ms）を表す 1 から500 までの整数を指定します。

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

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

journalCommitIntervalを200ミリ秒に設定する次の例を考えてみます。

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

Tip

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

storage.journal.commitIntervalMs

minSnapshotHistoryWindowInSeconds

バージョン 5.0 で追加

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 でのみ利用可能です。

タイプ: 整数

デフォルト: 128

MongoDB 7.0 以降では、このパラメーターはすべてのストレージエンジンで使用できます。以前のバージョンでは、このパラメーターは WiredTiger storage engine でのみ使用できます。

storage engine に許可された同時読み取りトランザクション（読み取りチケット）の最大数を指定します。

デフォルト値を使用すると、MongoDB はチケット数を動的に調整して最大値 128 でパフォーマンスを最適化します。

MongoDB 7.0 以降では、storageEngineConcurrentReadTransactions をデフォルト以外の値に設定すると、同時 storage engine トランザクション数を動的に調整するアルゴリズムが無効になります。

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

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

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

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

Tip

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

wiredTiger.concurrentTransactions

storageEngineConcurrentWriteTransactions

バージョン 7.0 で変更。

mongod でのみ利用可能です。

タイプ: 整数

WiredTiger storage engine に許可された同時書込みトランザクション (write transaction) の最大数を指定します。

デフォルトでは、MongoDB は storageEngineConcurrentWriteTransactions を次のどちらか大きい値に設定します。

MongoDB を実行しているマシンのコア数
4

デフォルト値を使用すると、MongoDB はチケット数を動的に調整して最大値 128 でパフォーマンスを最適化します。

MongoDB 7.0 以降では、storageEngineConcurrentWriteTransactions をデフォルト以外の値に設定すると、同時 storage engine トランザクション数を動的に調整するアルゴリズムが無効になります。

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

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

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

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

Tip

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

wiredTiger.concurrentTransactions

syncdelay

mongod でのみ利用可能です。

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

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

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

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

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

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

Tip

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

temporarilyUnavailableBackoffBaseMs

mongod でのみ利用可能です。

キャッシュの負荷によりロールバックされた書き込み操作を再試行するまでの初期遅延を指定します。

まれに、キャッシュの負荷により書込み (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 でのみ利用可能です。

キャッシュの負荷により書き込み操作がロールバックされた場合の最大再試行回数を指定します。

マルチドキュメントトランザクション内の個々の操作では、TemporarilyUnavailable エラーは返されません。

temporarilyUnavailableBackoffBaseMs } パラメータとtemporarilyUnavailableMaxRetriesパラメータを変更して、書込み再試行プロパティを調整します。

このパラメーターは以下を受け入れます。

値	説明
`integer >= 0`	デフォルトは 10。最大再試行回数。再試行間の遅延が増加します。バックオフ時間を設定するには、`temporarilyUnavailableBackoffBaseMs`を使用します。

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

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

新しい値を設定するには、db.adminCommand() を使用します。

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

バージョン 6.1.0 の新機能。

WiredTiger パラメータ

wiredTigerConcurrentReadTransactions

バージョン 7.0 で変更。

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 128

storage engine に許可された同時読み取りトランザクション（読み取りチケット）の最大数を指定します。

デフォルト値を使用すると、MongoDB はチケット数を動的に調整して最大値 128 でパフォーマンスを最適化します。

MongoDB 7.0 以降では、wiredTigerConcurrentReadTransactions をデフォルト以外の値に設定すると、同時 storage engine トランザクション数を動的に調整するアルゴリズムが無効になります。

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

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

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

Tip

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

wiredTiger.concurrentTransactions

wiredTigerConcurrentWriteTransactions

バージョン 7.0 で変更。

mongod でのみ利用可能です。

タイプ: 整数

WiredTiger storage engine に許可された同時書込みトランザクション (write transaction) の最大数を指定します。

デフォルトでは、MongoDB は wiredTigerConcurrentWriteTransactions を次のどちらか大きい値に設定します。

MongoDB を実行しているマシンのコア数
4

デフォルト値を使用すると、MongoDB はチケット数を動的に調整して最大値 128 でパフォーマンスを最適化します。

MongoDB 7.0 以降では、wiredTigerConcurrentWriteTransactions をデフォルト以外の値に設定すると、同時 storage engine トランザクション数を動的に調整するアルゴリズムが無効になります。

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

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

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

Tip

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

wiredTiger.concurrentTransactions

wiredTigerEngineRuntimeConfig

mongod でのみ利用可能です。

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

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

警告

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

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

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

wiredTigerFileHandleCloseIdleTime

mongod でのみ利用可能です。

タイプ: 整数

デフォルト: 600

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

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

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

以下に例を挙げます。

mongod --setParameter wiredTigerFileHandleCloseIdleTime=100000

利用可能なすべての WiredTiger 構成オプションについては、WiredTiger のドキュメントを参照してください。

監査パラメータ

auditAuthorizationSuccess

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

バージョン 5.0 で追加

タイプ: 整数

デフォルト: 300

シャーディングされたクラスターには、クラスターの監査構成設定を維持するサーバーが存在する場合があります。構成されていないサーバーが現在の監査生成についてコンフィギュレーションサーバーをポーリングする間隔を秒単位で設定します。返されたこの値が以前の既知の値と異なる場合、開始ノードは現在の構成をリクエストし、その内部状態をアップデートします。

注意

デフォルト値の 300 秒を使用すると、非 config ノードは setAuditConfig コマンドから最大 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

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

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

戻る

サーバーパラメータ

バックアップ方法

Synopsis

パラメーター

認証パラメータ

注意

Tip

注意

注意

重要

oidcIdentityProviders フィールド

Tip

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

Tip

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

注意

注意

注意

注意

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

注意

重要

Tip

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

Tip

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

Tip

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

Tip

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

Tip

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

Tip

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

重要

注意

注意

エンタープライズ機能

一般的なパラメータ

注意

Tip

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

警告

注意

重要

Tip

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

Tip

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

Tip

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

注意

Tip

注意

注意

注意

ログ パラメータ

Tip

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

警告

Tip

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

注意

エンタープライズ機能

Tip

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

Tip

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

診断パラメータ

注意

警告

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

警告

テスト目的のみ

注意

注意

Tip

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

注意

Tip

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

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

ログパラメータ

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

ヘルスマネージャーパラメータ

`progressMonitor` フィールド

ストレージパラメータ

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