自己管理型構成ファイルのオプション

外部ソースの値

次の展開ディレクティブが利用可能です。

完全なドキュメントについては、「自己管理型配置の 外部ソースの構成ファイルの値 」を参照してください。

展開ディレクティブと --configExpand

構成ファイルで展開ディレクティブを使用している場合は、mongod または mongos を起動するときに、--configExpand オプションを含める必要があります。以下がその例です。

mongod --config /etc/mongod.conf  --configExpand "rest,exec"
mongos --config /etc/mongos.conf  --configExpand "rest,exec"

構成ファイルに展開ディレクティブが含まれている場合、--configExpand のオプションでそのディレクティブを指定せずに mongod / mongos を起動すると、mongod / mongos は起動に失敗します。

完全なドキュメントについては、「自己管理型配置の 外部ソースの構成ファイルの値 」を参照してください。

systemLog.component オプション

systemLog:
   component:
      accessControl:
         verbosity: <int>
      command:
         verbosity: <int>
      # COMMENT some component verbosity settings omitted for brevity
      replication:
         verbosity: <int>
         election:
            verbosity: <int>
         heartbeats:
            verbosity: <int>
         initialSync:
            verbosity: <int>
         rollback:
            verbosity: <int>
      storage:
         verbosity: <int>
         journal:
            verbosity: <int>
         recovery:
            verbosity: <int>
      write:
         verbosity: <int>

systemLog.component.assert.verbosity

タイプ: 整数

デフォルト: 0

MongoDB において、ユーザー操作で発生したアサーションに対するログメッセージの冗長レベル。通常、アサーションは操作がエラーを返したときにトリガーされます。ASSERT コンポーネントをご覧ください。

systemLog.component.accessControl.verbosity

タイプ: 整数

デフォルト: 0

アクセス制御に関連したコンポーネントのログ メッセージの冗長レベル。「ACCESS コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.command.verbosity

タイプ: 整数

デフォルト: 0

コマンドに関連したコンポーネントのログ メッセージの冗長レベル。「COMMAND コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.control.verbosity

タイプ: 整数

デフォルト: 0

制御操作に関連したコンポーネントのログ メッセージの詳細レベル。「CONTROL コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.ftdc.verbosity

タイプ: 整数

デフォルト: 0

診断データ収集操作に関連したコンポーネントのログ メッセージの詳細レベル。「FTDC コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.geo.verbosity

タイプ: 整数

デフォルト: 0

地理空間解析操作に関連したコンポーネントのログ メッセージの詳細レベル。「GEO コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.index.verbosity

タイプ: 整数

デフォルト: 0

インデックス操作に関連したコンポーネントのログ メッセージの詳細レベル。「INDEX コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.network.verbosity

タイプ: 整数

デフォルト: 0

ネットワーク操作に関連したコンポーネントのログ メッセージの詳細レベル。「NETWORK コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.query.verbosity

タイプ: 整数

デフォルト: 0

クエリ操作に関連したコンポーネントのログ メッセージの詳細レベル。「QUERY コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.query.rejected.verbosity

タイプ: 整数

デフォルト: 0

バージョン8.0の新機能。

拒否されたクエリ操作に関連したコンポーネントのログ メッセージの冗長レベル。詳細については、REJECTED コンポーネントを参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.queryStats.verbosity

タイプ: 整数

デフォルト: 0

$queryStatsの呼び出しに関連するコンポーネントのログ メッセージの冗長レベル。 QUERYSTATSコンポーネントを参照してください。

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

• 0 は、デフォルトのログ冗長レベルであり、情報メッセージのみが含まれます。 このレベルでは、 $queryStats呼び出しはログに記録されません。

• 1 から2に増やすと、冗長レベルが上がり、 algorithmが"hmac-sha-256"である$queryStats呼び出しが含まれるようになります。 すべての HMAC キーは編集されます。

• 3 から5への冗長レベルは、 algorithmが"hmac-sha-256"である$queryStats呼び出しとそれに対応する結果を含めるようにします。 各結果は独自のエントリであり、string "we finished"を含む最終エントリがあります。

systemLog.component.replication.verbosity

タイプ: 整数

デフォルト: 0

レプリケーションに関連したコンポーネントのログ メッセージの冗長レベル。「REPL コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.replication.election.verbosity

タイプ: 整数

デフォルト: 0

選挙に関連したコンポーネントのログ メッセージの冗長レベル。「ELECTION コンポーネント」を参照。

systemLog.component.replication.election.verbosity が設定されていない場合、systemLog.component.replication.verbosity レベルは選挙コンポーネントにも適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.replication.heartbeats.verbosity

タイプ: 整数

デフォルト: 0

ハートビートに関連したコンポーネントのログ メッセージの冗長レベル。「REPL_HB コンポーネント」を参照。

systemLog.component.replication.heartbeats.verbosityが設定されていない場合は、ハートビート コンポーネントにsystemLog.component.replication.verbosityレベルも適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.replication.initialSync.verbosity

タイプ: 整数

デフォルト: 0

initialSync に関連したコンポーネントのログ メッセージの冗長レベル。「INITSYNC コンポーネント」を参照。

systemLog.component.replication.initialSync.verbosityが設定されていない場合は、 systemLog.component.replication.verbosityレベルも initialSync コンポーネントに適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.replication.rollback.verbosity

タイプ: 整数

デフォルト: 0

ロールバックに関連したコンポーネントのログ メッセージの冗長レベル。「ROLLBACK コンポーネント」を参照。

systemLog.component.replication.rollback.verbosity が設定されていない場合は、systemLog.component.replication.verbosity レベルはロールバック コンポーネントにも適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.sharding.verbosity

タイプ: 整数

デフォルト: 0

シャーディングに関連したコンポーネントのログ メッセージの冗長レベル。「SHARDING コンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.verbosity

タイプ: 整数

デフォルト: 0

ストレージに関連したコンポーネントのログ メッセージの冗長レベル。「STORAGE コンポーネント」を参照。

systemLog.component.storage.journal.verbosityが設定されていない場合は、 systemLog.component.storage.verbosityレベルもジャーナリング コンポーネントに適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.journal.verbosity

タイプ: 整数

デフォルト: 0

ジャーナリングに関連したコンポーネントのログ メッセージの冗長レベル。「JOURNAL コンポーネント」を参照。

systemLog.component.storage.journal.verbosityが設定されていない場合、ジャーナリング コンポーネントは親ストレージ コンポーネントと同じ冗長レベルになります。つまり、設定されている場合はsystemLog.component.storage.verbosityレベル、またはデフォルトの冗長レベルのいずれかです。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.recovery.verbosity

タイプ: 整数

デフォルト: 0

リカバリに関連したコンポーネントのログメッセージの冗長レベル。「RECOVERY コンポーネント」を参照。

systemLog.component.storage.recovery.verbosity が設定されていない場合は、systemLog.component.storage.verbosity レベルもリカバリ コンポーネントに適用されます。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンに関連したコンポーネントのログ メッセージの冗長レベル。「WTコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtBackup.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されたバックアップ操作に関連したコンポーネントのログ メッセージの詳細レベル。「WTBACKUPコンポーネント」を参照。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtCheckpoint.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるチェックポイント操作に関連するコンポーネントのログ メッセージの冗長度。「WTCHKPTコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtCompact.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行される圧縮操作に関連するコンポーネントのログ メッセージの冗長度。「WTCMPCTコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtEviction.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるエビクション操作に関連するコンポーネントのログ メッセージの冗長度。「WTEVICTコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtHS.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行される履歴保存操作に関連するコンポーネントのログ メッセージの冗長度。「WTHSコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtRecovery.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるリカバリ操作に関連するコンポーネントのログ メッセージの冗長度。「WTRECOVコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtRTS.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行される安定状態へのロールバック（RTS）操作に関連するコンポーネントのログ メッセージの冗長度。「WTRTSコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtSalvage.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるサルベージ操作に関連するコンポーネントのログ メッセージの冗長度。「WTSLVGコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtTimestamp.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって使用されるタイムスタンプに関連するコンポーネントのログ メッセージの冗長度。「WTTSコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtTransaction.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるトランザクション操作に関連するコンポーネントのログ メッセージの冗長度。「WTTXNコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtVerify.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行される検証操作に関連するコンポーネントのログ メッセージの冗長度。「WTVRFYコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.storage.wt.wtWriteLog.verbosity

タイプ: 整数

デフォルト: -1

バージョン 5.3 で追加。

WiredTiger ストレージエンジンによって実行されるログ書き込み (write) 操作に関連するコンポーネントのログ メッセージの冗長度。「WTWRTLOGコンポーネント」を参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.transaction.verbosity

タイプ: 整数

デフォルト: 0

トランザクションに関連するコンポーネントのログ メッセージの冗長レベル。TXN コンポーネントを参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

systemLog.component.write.verbosity

タイプ: 整数

デフォルト: 0

書き込み (write) 操作に関連するコンポーネントのログ メッセージの冗長レベル。WRITE コンポーネントを参照してください。

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

• 0 は MongoDB のデフォルトのログ冗長レベルであり、情報メッセージが含まれます。

• 1 冗長レベルを5 まで上げることによって、デバッグ メッセージを含めることができます。

net.unixDomainSocket オプション

net:
   unixDomainSocket:
      enabled: <boolean>
      pathPrefix: <string>
      filePermissions: <int>

net.unixDomainSocket.enabled

タイプ: ブール値

デフォルト: true

UNIX ドメイン ソケットでのリスニングを有効または無効にします。 net.unixDomainSocket.enabledは Unix ベースのシステムにのみ適用されます。

net.unixDomainSocket.enabled が true の場合、mongos または mongod が UNIX ソケットでリッスンします。

次のいずれかが true でない限り、mongos プロセスや mongod プロセスは常に UNIX ソケットで待機します。

• net.unixDomainSocket.enabled とは false

• --nounixsocket が設定されています。コマンドライン オプションは構成ファイルの設定よりも優先されます。

• net.bindIp が設定されていない

• net.bindIpはlocalhostまたはそれに関連付けられた IP アドレスを指定しません

公式の Install MongoDB Community Edition on Debian および Install MongoDB Community Edition on Red Hat or CentOS パッケージからインストールされた mongos または mongod では、デフォルトで bind_ip 設定が 127.0.0.1 に設定されています。

net.unixDomainSocket.pathPrefix

型: string

デフォルト: /tmp

UNIX ソケットのパス。net.unixDomainSocket.pathPrefix は Unix ベースのシステムにのみ適用されます。

このオプションに値がない場合、mongos プロセスや mongod プロセスでは、プレフィックスとして /tmp のソケットを作成します。MongoDB は、次のいずれかに該当しない限り、UNIX ソケットを作成して待機します。

• net.unixDomainSocket.enabled とは false

• --nounixsocket が設定されている

• net.bindIp が設定されていない

• net.bindIpはlocalhostまたはそれに関連付けられた IP アドレスを指定しません

net.unixDomainSocket.filePermissions

タイプ: int

デフォルト: 0700

UNIX ドメイン ソケット ファイルのパーミッションを設定します。

net.unixDomainSocket.filePermissions は Unix ベースのシステムにのみ適用されます。

net.tls オプション

net:
   tls:
      mode: <string>
      certificateKeyFile: <string>
      certificateKeyFilePassword: <string>
      certificateSelector: <string>
      clusterCertificateSelector: <string>
      clusterFile: <string>
      clusterPassword: <string>
      clusterAuthX509:
        attributes: <string>
        extensionValue: <string>
      CAFile: <string>
      clusterCAFile: <string>
      CRLFile: <string>
      allowConnectionsWithoutCertificates: <boolean>
      allowInvalidCertificates: <boolean>
      allowInvalidHostnames: <boolean>
      disabledProtocols: <string>
      FIPSMode: <boolean>
      logVersions: <string>

net.tls.mode

型: string

すべてのネットワーク接続に使用される TLS を有効にします。net.tls.mode 設定の引数は次のいずれかになります。

値	説明
disabled	サーバーは TLS を使用しません。
allowTLS	サーバー間の接続では TLS は使用されません。着信接続の場合、サーバーでは TLS と非 TLS のいずれも受け付けます。
preferTLS	サーバー間の接続では TLS が使用されます。着信接続の場合、サーバーでは TLS と非 TLS のいずれも受け付けます。
requireTLS	サーバーは TLS 暗号化接続のみを使用し、受け入れます。

--tlsCAFile または tls.CAFile が指定されておらず、X.509 認証を使用していない場合は、tlsUseSystemCA パラメータをtrue に設定する必要があります。これにより、MongoDB は TLS 対応サーバーに接続する際にシステム全体の CA 証明書ストアを使用します。

X.509 認証を使用する場合、 を使用しない限り、--tlsCAFile またはtls.CAFile --tlsCertificateSelectorを指定する必要があります。

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

net.tls.certificateKeyFile

型: string

TLS 証明書とキーの両方を含む .pem ファイル。

macOS または Windows では、net.tls.certificateSelector 設定を使用して、PEM キー ファイルの代わりに、オペレーティング システムのセキュリティで保護されている証明書ストアからの証明書を指定できます。certificateKeyFile と net.tls.certificateSelector は相互に排他的です。指定できるのは 1 つだけです。

• Linux および BSD では、TLS が有効になっている場合、net.tls.certificateKeyFile を指定する必要があります。

• Windows または macOS では、TLS が有効になっている場合、net.tls.certificateKeyFile または net.tls.certificateSelector のいずれかを指定する必要があります。

  重要

  Windows の場合のみ、MongoDB では暗号化された PEM ファイルをサポートしていません。暗号化された PEM ファイルがあると、mongod の起動は失敗します。Windows の TLS で使用する証明書を安全に保存してアクセスするには、net.tls.certificateSelector を使用します。

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

net.tls.certificateKeyFilePassword

型: string

証明書鍵ファイルの複合化用パスワード（ certificateKeyFile ）。 証明書キー ファイルが暗号化されている場合にのみ、 net.tls.certificateKeyFilePasswordオプションを使用します。 いずれの場合も、 mongosまたはmongodはすべてのログとレポート出力からパスワードを削除します。

Linux/BSD で net.tls.certificateKeyFilePassword オプションを指定しない場合、PEM ファイル内の秘密キーが暗号化されていると、MongoDB はパスフレーズの入力を要求します。

詳細については、「 TLS/SSL 証明書のパスフレーズ 」を参照してください。

macOS で PEM ファイル内の秘密キーが暗号化されている場合、 net.tls.certificateKeyFilePasswordオプションを明示的に指定する必要があります。 あるいは、PEM キー ファイルの代わりに、セキュア システム ストア（ net.tls.certificateSelectorを参照）から証明書を取得して使用するか、暗号化されていない PEM ファイルを使用することもできます。

Windows では、MongoDB は暗号化された証明書をサポートしていません。暗号化された PEM ファイルに遭遇すると、mongod は失敗します。代わりに、net.tls.certificateSelector を使用してください。

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

net.tls.certificateSelector

型: string

TLS/SSL に使用する証明書をオペレーティング システムの証明書ストアから選択するための証明書プロパティを指定します。net.tls.certificateKeyFile の代替として Windows および macOS で利用できます。

net.tls.certificateKeyFile と net.tls.certificateSelector のオプションは相互に排他的です。指定できるのは 1 つだけです。

net.tls.certificateSelector では、<property>=<value> 形式の引数が受け入れられます。プロパティは次のいずれか 1 つになります。

プロパティ	値の型	説明
subject	ASCII 文字列	証明書のサブジェクト名またはコモンネーム
thumbprint	hex 文字列	SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。 thumbprint は、fingerprint と呼ばれることもあります。

システムの SSL 証明書ストアを使用する場合、 OCSP（オンライン証明書ステータス プロトコル）を使用して証明書の失効状態を検証します。

mongodは、指定された TLS 証明書の完全な証明書チェーンを検証するために必要な CA 証明書をオペレーティング システムのセキュリティで保護された証明書ストアで検索します。 具体的には、安全な証明書ストアには、TLS 証明書への完全な証明書チェーンを構築するために必要なルート CA 証明書と中間 CA 証明書が含まれている必要があります。

警告

net.tls.certificateSelectorおよび/またはnet.tls.clusterCertificateSelector を使用する場合、ルートおよび中間 CA 証明書を指定するために、 net.tls.clusterFileまたはnet.tls.CAFile を使用することは 推奨され ません 。

たとえば、TLS 証明書が単一のルート CA 証明書によって署名されている場合、セキュア証明書ストアには当該ルート CA 証明書が含まれている必要があります。TLS 証明書が中間 CA 証明書によって署名されている場合、セキュア証明書ストアには中間 CA 証明書とルート CA 証明書が含まれている必要があります。

注意

net.tls.certificateSelectorまたは--tlsCertificateSelectorをthumbprintに設定している場合、 rotateCertificatesコマンドまたはdb.rotateCertificates() shell メソッドは使用できません。

net.tls.clusterCertificateSelector

型: string

内部 X.509 メンバーシップ認証に使用するために、オペレーティング システムのセキュリティで保護された証明書ストアから一致する証明書を選択するための証明書プロパティを指定します。

net.tls.clusterFile の代替として、Windows および macOS で利用可能です。

net.tls.clusterFile と net.tls.clusterCertificateSelector のオプションは相互に排他的です。指定できるのは 1 つだけです。

net.tls.clusterCertificateSelector では、<property>=<value> 形式の引数が受け入れられます。プロパティは次のいずれか 1 つになります。

プロパティ	値の型	説明
subject	ASCII 文字列	証明書のサブジェクト名またはコモンネーム
thumbprint	hex 文字列	SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。 thumbprint は、fingerprint と呼ばれることもあります。

mongodは、指定されたクラスター証明書の完全な証明書チェーンを検証するために必要な CA 証明書をオペレーティング システムのセキュリティで保護された証明書ストアで検索します。 具体的には、安全な証明書ストアには、クラスター証明書への完全な証明書チェーンを構築するために必要なルート CA 証明書と中間 CA 証明書が含まれている必要があります。

警告

net.tls.certificateSelector および/または net.tls.clusterCertificateSelector を使用する場合、ルートおよび中間 CA 証明書を指定するために、net.tls.CAFile または net.tls.clusterCAFile を使用することは推奨されません。

たとえば、クラスター証明書が単一のルート CA 証明書によって署名されている場合、セキュア証明書ストアには当該ルート CA 証明書が含まれている必要があります。クラスター証明書が中間 CA 証明書によって署名されている場合、セキュア証明書ストアには中間 CA 証明書とルート CA 証明書が含まれている必要があります。

mongodmongosX.509 証明書が30 mongod/mongosホスト システム時間から 日以内に期限切れになる場合、 / は接続時に警告を記録します。

net.tls.clusterFile

型: string

クラスターまたはレプリカ セットのメンバーシップ認証のための X.509 証明書キー ファイルを含む .pem ファイル。

macOS または Windows では、PEM 鍵ファイルの代わりに、net.tls.clusterCertificateSelector オプションを使用してオペレーティング システムの安全な証明書ストアから証明書を指定できます。net.tls.clusterFile オプションと net.tls.clusterCertificateSelector オプションは相互に排他的です。指定できるのは 1 つだけです。

net.tls.clusterFile が内部クラスター認証用の .pem ファイルまたは代替の net.tls.clusterCertificateSelector を指定しない場合、クラスターは certificateKeyFile 設定で指定された .pem ファイルまたは net.tls.certificateSelector によって返された証明書を使用します。

X.509 認証を使用する場合、 を使用しない限り、--tlsCAFile またはtls.CAFile --tlsCertificateSelectorを指定する必要があります。

mongodmongosX.509 証明書が30 mongod/mongosホスト システム時間から 日以内に期限切れになる場合、 / は接続時に警告を記録します。

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

重要

Windows の場合のみ、MongoDB では暗号化された PEM ファイルをサポートしていません。暗号化された PEM ファイルがあると、mongod の起動は失敗します。Windows のメンバーシップ認証で使用する証明書を安全に保存してアクセスするには、net.tls.clusterCertificateSelector を使用します。

net.tls.clusterPassword

型: string

で指定された X.509 --sslClusterFile証明書キーファイルの復号化パスワード。証明書キーファイルが暗号化されている場合にのみ、net.tls.clusterPassword オプションを使用します。いずれの場合も、mongos またはmongod はすべてのログとレポート出力からパスワードを削除します。

Linux/BSD で net.tls.clusterPassword オプションを指定しない場合、x.509 ファイル内の秘密キーが暗号化されていると、MongoDB はパスフレーズの入力を要求します。

詳細については、「 TLS/SSL 証明書のパスフレーズ 」を参照してください。

macOS で x.509 ファイル内の秘密キーが暗号化されている場合は、net.tls.clusterPassword オプションを明示的に指定する必要があります。あるいは、クラスター PEM ファイルの代わりに、セキュア システム ストア（net.tls.clusterCertificateSelector を参照）から証明書を取得して使用するか、暗号化されていない PEM ファイルを使用することもできます。

Windows では、MongoDB は暗号化された証明書をサポートしていません。 暗号化された PEM ファイルがあると、 mongodは処理に失敗します。 net.tls.clusterCertificateSelectorを使用します。

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

net.tls.clusterAuthX509

バージョン 7.0 で追加。

net:
   tls:
     clusterAuthX509:
       attributes: <string>
       extensionValue: <string>

net.tls.clusterAuthX509.attributes

型: string

バージョン 7.0 で追加。

証明書サブジェクト名にクラスター ノードが含まれていることがサーバーで予期されている X.509DN（Distinguished Name、識別名）属性と値のセットを指定します。こうすると、DC、O、OU の値を含まない証明書を使用してクラスター ノードを認証できるようになります。

attributes が設定されている場合、MongoDB は識別名を使用して証明書を照合し、拡張値を無視します。

net.tls.clusterAuthX509.extensionValue

型: string

バージョン 7.0 で追加。

MongoDBクラスター メンバーシップ拡張 OID、1.3.6.1.4.1.34601.2.1.2 に対応する拡張値を指定します。サーバーでは、クラスター ノードの証明書にこの拡張機能が含まれていることが想定されています。こうすると、DC、O、OU の値を含まない証明書を使用してクラスター ノードを認証できるようになります。

extensionValue を設定すると、 MongoDB は証明書拡張値を使用して証明書を照合し、識別名（DN）を無視します。

OID 1.3.6.1.4.1.34601.2.1.2 を使用して証明書を作成する場合は、次のガイドラインを考慮してください。

• 拡張値は 128 バイト未満にしてください。

• 拡張機能の内部値として単一の UTF8string を使用します。 mongod は他の string タイプを受け入れません。

• OpenSSL を使用する場合は、UTF8string をエンコードするため、ASN.1 タイプを明示的に指定する必要があります。（例: ）。

  • コマンドラインで、-addext: 1.3.6.1.4.1.34601.2.1.2=ASN1:UTF8String:<your-value> を指定します。

  • OpenSSL 構成ファイルで、1.3.6.1.4.1.34601.2.1.2 = ASN1:UTF8String:<your-value> と指定します。

  警告

  ASN1:UTF8String:を省略すると、OpenSSL は別のエンコーディングまたは未加工の oct を選択する可能性があり、mongod は「Unsupported tags」または「Unknown DER」タグで拒否します。

net.tls.CAFile

型: string

証明機関からのルート証明書チェーンを含む .pem ファイル。相対パスまたは絶対パスを使用して .pem ファイルのファイル名を指定します。

Windows と macOS のみ

net.tls.certificateSelectorおよび/またはnet.tls.clusterCertificateSelector を使用する場合、ルート CA 証明書と中間 CA 証明書の指定には net.tls.CAFile を使用しません。net.tls.certificateSelectorおよび/またはnet.tls.clusterCertificateSelector証明書の完全な信頼チェーンの検証に必要なすべての CA 証明書は、安全な証明書ストアに保存します。

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

net.tls.clusterCAFile

型: string

接続を確立するクライアントによって提示された証明書を検証するために使用される証明機関からのルート証明書チェーンを含む.pemファイル。 相対パスまたは絶対パスを使用して、 .pemファイルのファイル名を指定します。 net.tls.clusterCAFileにはnet.tls.CAFileが設定されている必要があります。

net.tls.clusterCAFile で、接続を確立するクライアントからの証明書を検証するための.pemファイルが指定されない場合、クラスターでは net.tls.CAFile オプションで指定された.pemファイルが使用されます。

net.tls.clusterCAFile クライアントからサーバー、サーバーからクライアントへのTLS ハンドシェイクの各部分を検証するために、異なる認証局を使用することができます。

4.0 以降、macOS または Windows では、PEM キー ファイルの代わりに、オペレーティング システムのセキュア ストアからの証明書を使用できます。net.tls.clusterCertificateSelector 参照してください。セキュア ストアを使用する場合は、net.tls.clusterCAFile を指定する必要はありませんが、指定することもできます。

Windows と macOS のみ

net.tls.certificateSelectorおよび/またはnet.tls.clusterCertificateSelector を使用する場合、ルート CA 証明書と中間 CA 証明書の指定には net.tls.clusterCAFile を使用しません。net.tls.certificateSelectorおよび/またはnet.tls.clusterCertificateSelector証明書の完全な信頼チェーンの検証に必要なすべての CA 証明書は、安全な証明書ストアに保存します。

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

net.tls.CRLFile

型: string

証明書失効リストを含む .pem ファイル。相対パスまたは絶対パスを使用して .pem ファイルのファイル名を指定します。

注意

• macOS では、net.tls.CRLFile は指定できません。代わりに、システム SSL 証明書ストアを使用できます。これは、OCSP（オンライン証明書ステータス プロトコル）を使用して証明書の失効ステータスを検証するものです。システム SSL 証明書ストアを使用するには、net.tls.certificateSelector を参照してください。

• 証明書の失効を確認するために、MongoDB は CRL ファイルを指定するか、システム SSL 証明書ストアを使用する代わりに、デフォルトで OCSP（Online Certificate Status Protocol、オンライン証明書ステータス プロトコル）を使用しenables 。

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

net.tls.allowConnectionsWithoutCertificates

タイプ: ブール値

デフォルト: false

false の場合、すべてのクライアントがクライアント TLS 証明書を提供する必要があります。true の場合、クライアントはクライアント証明書を提供する必要はありませんが、mongod または mongos によって TLS/SSL 接続が暗号化されます。

クライアントがクライアント証明書を提供する場合、net.tls.allowConnectionsWithoutCertificates に設定した値に関係なく、mongos または mongod は、CAFile で指定されたルート証明書チェーン、または tlsUseSystemCA が true の場合はシステム CA ストアを使用して証明書の検証を実行し、無効な証明書を持つクライアントを拒否します。

mongos または mongod に証明書を提示しない、または提示できないクライアントを含む混合配置がある場合は、net.tls.allowConnectionsWithoutCertificates オプションを使用します。

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

net.tls.allowInvalidCertificates

タイプ: ブール値

デフォルト: false

クラスター内の他のサーバーの TLS 証明書の検証チェックを有効または無効にし、無効な証明書を使用して接続できるようにします。

注意

X.509 認証を使用するときに --tlsAllowInvalidCertificates または tls.allowInvalidCertificates: true を指定した場合、無効な証明書は TLS 接続を確立するには十分ですが、認証には不十分です。

net.tls.allowInvalidCertificates設定を使用すると、MongoDB では無効な証明書の使用に関する警告がログに記録されます。

TLS とMongoDB の詳細については、「 自己管理型配置および自己管理型内部認証とメンバーシップ認証で TLS/SSL 用に とmongod mongosを構成する 」を参照してください。

net.tls.allowInvalidHostnames

タイプ: ブール値

デフォルト: false

net.tls.allowInvalidHostnamesがtrueの場合、MongoDB は TLS 証明書のホスト名の検証を無効にします。 これにより、証明書のホスト名が指定されたホスト名と一致しない場合でも、 mongodまたはmongosはクラスター内の他の MongoDB インスタンスに接続できます。

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

net.tls.disabledProtocols

型: string

TLS によって実行されている MongoDB サーバーで、1 つ以上の特定のプロトコルを使用する着信接続を受け付けないようにします。複数のプロトコルを指定するには、カンマで区切ったプロトコルのリストを使用しますが、このカンマの後にはスペースを入れないでください。プロトコル名の前にスペースがあると、認識されないプロトコルと解釈されるため、サーバーは起動しません。

net.tls.disabledProtocols は、TLS1_0 プロトコル、TLS1_1 プロトコル、TLS1_2 プロトコル、および TLS1_3 プロトコルを認識します。

• macOS では、TLS1_1 を無効にして、TLS1_0 と TLS1_2 の両方を有効のままにすることはできません。他の 2 つのうち少なくとも 1 つを無効にする必要があります（例: TLS1_0,TLS1_1）。

• 複数のプロトコルを一覧表示するには、カンマの後にスペースを入れずに、カンマで区切ったプロトコルのリストとして指定します。たとえば、TLS1_0,TLS1_1 と指定します。

• 認識されないプロトコルを指定したり、カンマの後にスペースを入れたりすると、サーバーが起動しなくなります。

• 指定の無効なプロトコルは、デフォルトの無効なプロトコルを上書きします。

MongoDB は、システムで TLS 1.1 + が利用可能な場合、TLS 1.0の使用を無効にします。 TLS 1.0を有効にするには、 noneからnet.tls.disabledProtocolsを指定します。

レプリカセットとシャーディングされたクラスターのノード間では、少なくとも 1 つのプロトコルが共通している必要があります。

Tip

プロトコルを許可しない

net.tls.FIPSMode

タイプ: ブール値

デフォルト: false

mongos または mongod の TLS ライブラリの FIPS モードの使用を有効または無効にします。net.tls.FIPSMode オプションを使用するには、システムに FIPS 準拠のライブラリが必要です。

注意

FIPS に準拠した TLS/SSL は MongoDB Enterprise でのみ利用できます。詳細については「MongoDB を FIPS 用に構成する」を参照してください。

net.tls.logVersions

型: string

mongos や mongod に対し、クライアントが指定の TLS バージョンを使用して接続した場合にメッセージをログに記録するよう指示します。

TLS バージョンを 1 つ指定するか、複数の TLS バージョンのカンマ区切りリストを指定します。

例

クライアントが TLS 1.2または TLS 1.3を使用して接続したときにメッセージをログに記録するよう、 mongosまたはmongodに指示するには、 net.tls.logVersionsを"TLS1_2,TLS1_3"に設定します。

net.compression オプション

net:
   compression:
      compressors: <string>

net.compression.compressors

Default: snappy,zstd,zlib

このような mongod インスタンスや mongosインスタンスと以下の間の通信に使用するデフォルトのコンプレッサーを指定します。

• 配置の他のノード（インスタンスがレプリカセットまたはシャーディングされたクラスターの一部である場合）

• mongosh

• OP_COMPRESSED メッセージ形式をサポートするドライバー

MongoDB では、以下のコンプレッサーをサポートしています。

• Snappy

• zlib

• zstd

ネットワーク圧縮を無効にするには、値を disabled に設定します。

重要

両者がネットワーク圧縮を有効にしている場合、メッセージは圧縮されます。そうでなければ、この両者間のメッセージは非圧縮となります。

複数のコンプレッサーを指定する場合、通信イニシエーターだけでなく、コンプレッサーをリストする順序も重要になります。たとえば、mongosh が次のネットワーク コンプレッサー zlib,snappy を指定し、mongod が snappy,zlib を指定する場合、mongosh と mongod の間のメッセージは zlib を使用します。

両者に共通のコンプレッサーが 1 つもなければ、両者間のメッセージは圧縮されません。例えば、mongosh ではネットワーク コンプレッサーとして zlib が指定され、mongod ではsnappy が指定されている場合、mongosh と mongodの間のメッセージは圧縮されません。

キー管理構成オプション

security:
   enableEncryption: <boolean>
   encryptionCipherMode: <string>
   encryptionKeyFile: <string>
   kmip:
      keyIdentifier: <string>
      rotateMasterKey: <boolean>
      serverName: <string>
      port: <string>
      clientCertificateFile: <string>
      clientCertificatePassword: <string>
      clientCertificateSelector: <string>
      serverCAFile: <string>
      connectRetries: <int>
      connectTimeoutMS: <int>
      activateKeys: <boolean>
      keyStatePollingSeconds: <int>

security.enableEncryption

タイプ: ブール値

デフォルト: false

WiredTiger ストレージエンジンの暗号化を有効にします。暗号化キーと構成を渡すには、true に設定する必要があります。

注意

エンタープライズ機能

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

security.encryptionCipherMode

型: string

デフォルト: AES256-CBC

保管時の暗号化に使用するモードです。

モード	説明
AES256-CBC	暗号ブロック チェーン モードの 256 ビット AES（Advanced Encryption Standard）
AES256-GCM	ガロア カウンタ モードの 256 ビットAES Linuxでのみ利用可能です。 Windows 上の MongoDB Enterprise では、保管時の暗号化のブロック暗号として AES256-GCM をサポートしなくなりました。この使用は、Linux でのみサポートされています。

注意

エンタープライズ機能

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

security.encryptionKeyFile

型: string

KMIP以外の プロセスで鍵を管理する場合のローカル鍵ファイルへのパスです。 KMIP 以外のプロセスでキーを管理する場合にのみ設定します。 データがすでに KMIP を使用して暗号化されている場合には、MongoDB はエラーをスローします。

security.enableEncryptionがtrueである必要があります。

注意

エンタープライズ機能

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

security.kmip.keyIdentifier

型: string

KMIP サーバー内の既存のキーに対する一意の KMIP 識別子です。この識別子を指定することで、識別子に関連付けられたキーをシステム キーとして使用できます。この設定は、mongod インスタンスの暗号化を初めて有効にするときにのみ使用できます。security.enableEncryption が true である必要があります。

未指定の場合、MongoDB は KMIP サーバーにシステムキーとして使う新しいキーの作成を要求します。

KMIP サーバーが指定された識別子を持つキーを見つけられない場合、またはデータがすでにキーで暗号化されている場合、MongoDB でエラーが発生します。

注意

エンタープライズ機能

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

security.kmip.rotateMasterKey

タイプ: ブール値

デフォルト: false

true の場合、マスター キーをローテーションし、内部キーストアを再暗号化します。

注意

エンタープライズ機能

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

Tip

KMIP マスター キーのローテーション

security.kmip.serverName

型: string

接続先の KMIP サーバーのホスト名または IP アドレスです。security.enableEncryption が true である必要があります。

複数の KMIP サーバーをカンマ区切りのリスト（例: server1.example.com,server2.example.com ）として指定できます。mongod では起動時に、リストされている順序で各サーバーへの接続確立が試みられ、正常に接続を確立できた最初のサーバーが選択されます。KMIP サーバーが選択されるのは、起動時のみです。

mongod では、起動時に KMIP サーバーへの接続を検証します。

--kmipServerName に指定するサーバー名は、KMIP サーバーで提示する証明書のサブジェクト代替名 SAN またはコモンネーム CN のいずれかと一致する必要があります。SAN はシステム名または IP アドレスにすることができます。

SAN が存在する場合、mongod は CN との一致は試行しません。

KMIP サーバーのホスト名や IP アドレスが SAN とも CN とも一致しない場合、mongod は起動しません。

MongoDB 4.2 以降、SAN の比較を行なう際に、MongoDB は DNS 名または IP アドレスの比較をサポートします。以前のバージョンでは、 MongoDB は DNS 名の比較のみをサポートしていました。

注意

エンタープライズ機能

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

security.kmip.port

型: string

デフォルト: 5696

KMIP サーバーとの通信に使用されるポート番号です。security.kmip.serverName が必要です。security.enableEncryption が true である必要があります。

security.kmip.serverName で複数の KMIP サーバーを指定する場合、mongod は、提供されているすべての KMIP サーバーに対して security.kmip.port で指定されたポートを使用します。

注意

エンタープライズ機能

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

security.kmip.clientCertificateFile

型: string

KMIP サーバーに対して MongoDB を認証するために使用される .pem ファイルへのパスです。指定された .pem ファイルには、TLS/SSL 証明書とキーの両方が含まれている必要があります。

この設定を使用するには、security.kmip.serverName 設定も指定する必要があります。

重要

Windows で KMIP サーバーを使用して暗号化を有効にすると、 security.kmip.clientCertificateFileと KMIP サーバーにより TLS 1.2が強制されます。

Windows で KMIP を使用して保管時の暗号化を有効にするには、次の条件を満たす必要があります。

• クライアント証明書を Windows 証明書ストアにインポートします。

• security.kmip.clientCertificateSelectorオプションを使用します。

注意

エンタープライズ機能

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

security.kmip.clientCertificatePassword

型: string

KMIPサーバーに接続するクライアント証明書の秘密キーを復号化するためのパスワードです。 このオプションはMongoDB をKMIPサーバーに認証するため、 を指定する必要があります。--kmipClientCertificateFile

注意

エンタープライズ機能

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

security.kmip.clientCertificateSelector

型: string

バージョン5.0の新機能: security.kmip.clientCertificateFileの代替として Windows および macOS で利用できます。

security.kmip.clientCertificateFile と security.kmip.clientCertificateSelector のオプションは相互に排他的です。指定できるのは 1 つだけです。

MongoDB が KMIP サーバーに認証するために、オペレーティング システムの証明書ストアから一致する証明書を選択するための証明書プロパティを指定します。

security.kmip.clientCertificateSelector では、<property>=<value> 形式の引数が受け入れられます。プロパティは次のいずれか 1 つになります。

プロパティ	値の型	説明
subject	ASCII 文字列	証明書のサブジェクト名またはコモンネーム
thumbprint	hex 文字列	SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。 thumbprint は、fingerprint と呼ばれることもあります。

注意

エンタープライズ機能

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

security.kmip.serverCAFile

型: string

CA ファイルへのパス。KMIP サーバーへの安全なクライアント接続を検証するために使用されます。

注意

4.0 以降、macOS または Windows では、PEM キー ファイルの代わりに、オペレーティング システムのセキュア ストアからの証明書を使用できます。security.kmip.clientCertificateSelector 参照してください。セキュア ストアを使用する場合は、security.kmip.serverCAFile を指定する必要はありませんが、指定することもできます。

注意

エンタープライズ機能

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

security.kmip.connectRetries

タイプ: int

デフォルト: 0

KMIP サーバーに対する初期接続を再試行する回数です。 connectTimeoutMSと併用することで、 mongodが再試行を行うまでの待機時間を管理できます。

注意

エンタープライズ機能

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

security.kmip.connectTimeoutMS

タイプ: int

デフォルト: 5000

KMIP サーバーからの応答を待つ際のタイムアウト（ミリ秒）です。connectRetries 設定が指定されている場合、mongod は再試行ごとに connectTimeoutMS で指定された値まで待機します。

値は 1000 以上である必要があります。

注意

エンタープライズ機能

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

security.kmip.activateKeys

タイプ: ブール値

デフォルト: true

バージョン 5.3 で追加。

新しく作成された KMIP キーを作成時にすべてアクティブ化し、その後、当該キーがアクティブな状態であるかどうかを定期的にチェックします。

security.kmip.activateKeys が true で、KMIP サーバーに既存のキーがある場合、最初にキーをアクティブ化する必要があります。そうしないと、mongod ノードの起動に失敗します。

mongod によって使用されているキーが非アクティブ状態に移行すると、kmipActivateKeys が false でない限り、mongod ノードはシャットダウンします。アクティブなキーがあることを確認するには、security.kmip.rotateMasterKey を使用して KMIP マスター キーをローテーションします。

security.kmip.keyStatePollingSeconds

タイプ: int

デフォルト: 900 秒

バージョン 5.3 で追加。

mongod が KMIP サーバーでアクティブなキーをポーリングする頻度（秒単位）。

ポーリングを無効にするには、値を -1 に設定します。

security.kmip.useLegacyProtocol

タイプ: ブール値

デフォルト: false

バージョン 7.0 の新機能: （および 6.0.6）

true の場合、mongod では、デフォルトのバージョンではなく、KMIP プロトコル バージョン 1.0 または 1.1 が使用されます。デフォルトの KMIP プロトコルはバージョン 1.2 です。

KMIP バージョン 1.0 または 1.1 で監査ログ暗号化を使用するには、スタートアップ時に auditEncryptKeyWithKMIPGet を指定する必要があります。

KMIP プロトコルのバージョン 1.0 または 1.1 を使用するには、ローカル値を置き換えて、次のようなエントリを mongod 構成ファイルに追加します。

security:
  enableEncryption: true
  kmip:
    serverName: "mdbhost.somecompany.com"
    serverCAFile: "security/libs/trusted-ca.pem"
    clientCertificateFile: "security/libs/trusted-client.pem"
    useLegacyProtocol: true

security.sasl オプション

security:
   sasl:
      hostName: <string>
      serviceName: <string>
      saslauthdSocketPath: <string>

security.sasl.hostName

型: string

SASL および Kerberos 認証を構成するための完全修飾サーバー ドメイン名。SASL ホスト名は、SASL および Kerberos のの構成でのみホスト名を上書きします。

security.sasl.serviceName

型: string

SASL を使用するサービスの登録名。このオプションを指定すると、インスタンスごとに Kerberos プリンシパル名のデフォルトの Kerberos サービス名コンポーネントを上書きできます。指定しない場合、デフォルト値は mongodb です。

MongoDB では、このオプションが設定できるのは起動時のみです。この設定を setParameter で変更することはできません。

このオプションは MongoDB Enterprise でのみ使用できます。

重要

ドライバーが代替サービス名をサポートしていることを確認してください。新しいmongosh やその他の MongoDB ツールに接続するには、serviceName を参照し、gssapiServiceName オプションを確認してください。

security.sasl.saslauthdSocketPath

型: string

saslauthd の UNIX ドメインソケットファイルへのパス。

security.ldap オプション

security:
   ldap:
      servers: <string>
      bind:
         method: <string>
         saslMechanisms: <string>
         queryUser: <string>
         queryPassword: <string | array>
         useOSDefaults: <boolean>
      transportSecurity: <string>
      timeoutMS: <int>
      retryCount: <int>
      userToDNMapping: <string>
      authz:
         queryTemplate: <string>
      validateLDAPServerConfig: <boolean>

security.ldap.servers

型: string

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

mongod や mongos がユーザーを認証したり、指定されたデータベースでユーザーが実行する権限を決定するための LDAP サーバー。指定された LDAP サーバーに複製されたインスタンスがある場合、複製サーバーごとのホストとポートをカンマ区切りのリストで指定できます。

LDAP インフラストラクチャが LDAPディレクトリを複数の LDAP サーバーに分割する場合は、1 つ の LDAPサーバーまたはその複製されたインスタンスのいずれかをsecurity.ldap.servers に指定します。MongoDB は、RFC 4511 4.1.10 で定義されている以下の LDAP 紹介をサポートしています。インフラストラクチャ内のすべての LDAPサーバーを一覧表示するために、security.ldap.servers は使用しないでください。

LDAP サーバーの前にsrv:とsrv_raw:を付けることができます。

接続stringで "srv:<DNS_NAME>" が指定されている場合、 mongodは Active Directory をサポートする SRV に "_ldap._tcp.gc._msdcs.<DNS_NAME>" が存在することを確認します。 見つからない場合、 mongodは SRV に"_ldap._tcp.<DNS_NAME>"が存在することを確認します。 SRV レコードが見つからない場合、 mongodは代わりに"srv_raw:<DNS_NAME>"を使用するように警告します。

接続stringで "srv_raw:<DNS_NAME>" が指定されている場合、 mongodは "<DNS NAME>" の SRV レコード検索を実行します。

この設定は、稼働中の mongod や mongos でも setParameterを使用して構成できます。

設定されていない場合、 mongod や mongos では LDAP 認証や承認ができません。

security.ldap.bind.queryUser

型: string

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

LDAP サーバーへの接続またはクエリ実行時に mongod または mongos がバインドする ID。

次のいずれかに当てはまる場合にのみ必要です。

• LDAP 承認を使用している

• security.ldap.userToDNMapping には LDAP クエリを使用します。

• LDAP サーバーが匿名バインドを許可していない

queryPassword ではqueryUserを使用する必要があります

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

この設定は、稼働中の mongod や mongos でも setParameterを使用して構成できます。

注意

Windows MongoDB 配置では、useOSDefaultsqueryUserqueryPassword と の代わりに使用できます。queryUserとuseOSDefaultsの両方を同時に指定することはできません。

security.ldap.bind.queryPassword

型: string または array

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

queryUserを使用するときに LDAP サーバーにバインドするために使用されるパスワード。 queryUser ではqueryPasswordを使用する必要があります

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

この設定は、実行中の mongod や mongos でも setParameterを使用して行うことができます。

ldapQueryPassword setParameter コマンドは、文字列または文字列の配列のいずれかを受け付けます。ldapQueryPassword が配列に設定されている場合、MongoDB は成功するまで各パスワードを順番に試行します。パスワード配列を使用して、LDAP アカウントのパスワードをダウンタイムなしでロールオーバーします。

注意

Windows MongoDB 配置では、useOSDefaultsqueryUserqueryPassword と の代わりに使用できます。queryPasswordとuseOSDefaultsの両方を同時に指定することはできません。

security.ldap.bind.useOSDefaults

タイプ: ブール値

デフォルト: false

Windows プラットフォームの MongoDB Enterprise でのみ利用可能です。

mongod や mongos が LDAP サーバーに接続する際の認証やバインドに Windows のログイン認証情報を使用できるようにします。

次の場合にのみ必要です。

• LDAP 承認を使用している

• username transformation には LDAP クエリを使用します。

• LDAP サーバーが匿名バインドを許可していない

useOSDefaultsqueryUserと を置き換えるには、queryPassword を使用します。

security.ldap.bind.method

型: string

デフォルト: simple

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

メソッドmongodまたはmongosは を使用して LDAP サーバーに認証します。 LDAP サーバーに接続するには、 queryUserとqueryPasswordとともに使用します。

method は次の値をサポートします。

• simple - mongod や mongos でシンプル認証を使用します。

• sasl - mongod や mongos で認証に SASL プロトコルを使用します

saslを指定した場合は、 security.ldap.bind.saslMechanismsを使用して使用可能な SASL メカニズムを構成できます。 mongodまたはmongosはデフォルトでDIGEST-MD5メカニズムを使用します。

security.ldap.bind.saslMechanisms

型: string

デフォルト: DIGEST-MD5

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

SASL メカニズムのカンマ区切りリストは、mongod または mongos が LDAP サーバーに認証する時に使用できます。mongod や mongos と、LDAP サーバーは、少なくとも 1 つのメカニズムで一致している必要があります。mongod または mongos は、ホスト マシンにインストールされている SASL メカニズム ライブラリをランタイムで動的に読み込みます。

選択した SASL メカニズムに該当するライブラリを、mongod または mongos のホストおよびリモート LDAP サーバー ホストの両方にインストールして構成してください。オペレーティング システムには、特定の SASL ライブラリがデフォルトで含まれている場合があります。インストールと構成のガイダンスについては、各 SASL メカニズムに関連するドキュメントを参照してください。

自己管理型配置で Kerberos 認証で使用するためにGSSAPI SASL メカニズムを使用する場合は、 mongodまたはmongosホスト マシンで次の点を確認します。

Linux

• KRB5_CLIENT_KTNAME 環境変数は、ホスト マシン用のクライアントLinuxキータブ ファイルの名前に解決されます。Kerberos 環境変数の詳細については、 Kerberos のドキュメント を参照してください。

• クライアント キータブには、LDAP サーバーに接続して LDAP クエリを実行する際に使用する mongod や mongos のユーザー プリンシパルが含まれています。

Windows

Active Directoryサーバーに接続する場合、 Windows Kerberos構成により、ユーザーがシステムにログオンした際に Ticket-Granting-Ticket が自動生成されます。useOSDefaults を true に設定すると、mongod または mongos が Active Directoryサーバーに接続してクエリを実行する際に、生成された認証情報を使用できるようになります。

このオプションを使用するには method をsasl に設定します。

注意

全 SASL メカニズムを網羅したリストについては、IANA のリスト を参照してください。サービスと互換性のある SASL メカニズムを特定するには、LDAP または Active Directory サービスのドキュメントを参照してください。

MongoDB は SASL メカニズム ライブラリのソースではなく、MongoDB ドキュメントも特定の SASL メカニズムのインストールや設定をするための決定的な情報源ではありません。ドキュメントとサポートについては、SASL メカニズム ライブラリのベンダーまたは管理者に問い合わせてください。

SASLの詳細については、次のリソースを参照してください。

• Linuxの場合は、 Cyrus SASL のドキュメント を参照してください。

• Windowsの場合は、Windows SASL ドキュメントを参照してください。

security.ldap.transportSecurity

型: string

デフォルト: tls

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

デフォルトでは、mongod や mongos は、LDAP サーバーに対して TLS/SSL で保護された接続を確立します。

Linux配置の場合、/etc/openldap/ldap.confファイルで適切な TLS オプションを構成する必要があります。オペレーティング システムのパッケージマネージャーは、libldap 依存関係を介して、 MongoDB Enterpriseインストールの一部としてこのファイルを作成します。詳しくは、ldap.conf OpenLDAP ドキュメント の TLS Options のドキュメントを参照してください。

Windows 配置の場合、LDAP サーバー CA 証明書を Windows 証明書管理ツールに追加する必要があります。ツールの正確な名前と機能は、オペレーティング システムのバージョンによって異なる場合があります。証明書管理の詳細については、ご使用の Windows バージョンのドキュメントを参照してください。

またはmongos と transportSecuritynonemongodLDAP サーバー間の TLS/SSL を無効にするには、 を に設定します。

警告

transportSecurityをnoneに設定すると、 mongodまたはmongosと LDAP サーバー間でプレーンテキスト情報と、場合によっては認証情報が送信されます。

security.ldap.timeoutMS

タイプ: int

デフォルト: 10000

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

mongod や mongos で LDAP サーバーからリクエストへの応答があるまで待機する時間（ミリ秒単位）。

timeoutMSの値を増やすと、障害の原因が接続タイムアウトである場合、MongoDB サーバーと LDAP サーバー間の接続が失敗しなくなる可能性があります。 timeoutMSの値を小さくすると、MongoDB が LDAP サーバーからの応答を待機する時間が短縮されます。

この設定は、稼働中の mongod や mongos でも setParameterを使用して構成できます。

security.ldap.retryCount

バージョン 6.1 で追加。

タイプ: int

デフォルト: 0

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

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

この設定は、稼働中の mongod や mongos でも setParameterを使用して構成できます。

security.ldap.userToDNMapping

型: string

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

認証用にmongodまたはmongosに指定されたユーザー名を LDAP 識別名（DN）にマッピングします。 次のシナリオではユーザー名を LDAP DN に変換するためにuserToDNMappingを使用する必要がある場合があります。

• LDAP のシンプル バインドにより LDAP 認証を実行し、ユーザーが MongoDB に対し、完全な LDAP 識別名ではないユーザー名で認証されます。

• 識別名を必要とする LDAP authorization query template を使用します。

• さまざまな認証メカニズム（例: x.509、kerberos）を使用して Mongo DB に認証するクライアントのユーザー名を、承認用の完全な LDAP 識別名に変換します。

userToDNMapping は、順序付けられたドキュメントの配列を表す引用符で囲まれた JSON 文字列を要求しています。各ドキュメントには、正規表現の match と受信ユーザー名の変換に使用される substitution または ldapQuery のテンプレートが含まれています。

配列内の各ドキュメントの形式は次のとおりです。

{
  match: "<regex>"
  substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}

フィールド	説明	例
match	指定されたユーザー名と照合するための ECMAScript 形式の正規表現（regex）です。かっこで囲まれた各セクションは、substitution または ldapQuery で使用される正規表現キャプチャ グループを表します。	"(.+)ENGINEERING" "(.+)DBA"
substitution	match 正規表現に一致する認証名を LDAP DN に変換する LDAP識別名（DN）形式のテンプレート。中括弧で囲まれた各数値は、 正規表現を通じて認証ユーザー名から抽出された、対応する正規表現キャプチャmatch グループに置き換えられます。 置換の結果は、 RFC 4514 に準拠した、エスケープされた文字列である必要があります。	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	match 正規表現に一致する認証名を RFC4515 と RFC4516 に従ってエンコードされた LDAP クエリ URI に挿入する LDAP クエリ形式のテンプレート。中括弧で囲まれた各数値は、 式を通じて認証ユーザー名から抽出された、対応する正規表現キャプチャmatch グループに置き換えられます。mongod または mongos は LDAPサーバーに対してクエリを実行し、認証されたユーザーの LDAP DN を検索します。mongod または mongos では、変換を成功させるために返された結果が 1 つだけ必要になるか、mongod または mongos はこの変換をスキップします。	"ou=engineering,dc=example, dc=com??one?(user={0})"

注意

RFC4514、 RFC4515、 RFC4516、または LDAP クエリの説明は、 MongoDBドキュメントの範囲外です。RFC を直接確認するか、希望する LDAPリソースを使用してください。

配列内の各ドキュメントに対して、substitution または ldapQuery のいずれかを使用する必要があります。同じ文書で両方を指定することはできません。

認証や承認を実行する際、mongod や mongos では配列にあるドキュメントを指定の順序で処理し、認証ユーザー名を match フィルターと照合します。一致が見つかったら、mongod や mongos で変換を適用し、その出力を使用してユーザーを認証します。mongod または mongos では、配列内の残りのドキュメントをチェックしません。

特定のドキュメントが指定の認証名と一致しない場合でも、mongod や mongos ではドキュメントのリストで他に一致するところがないか引き続き検索します。どのドキュメントにも一致するところが見つからない場合、またはドキュメントの記載内容の変換が失敗した場合、mongod や mongos はエラーを返します。

また、LDAP サーバーとのネットワーク接続や認証に失敗して変換の 1 つを評価できない場合にも、 mongodまたはmongosはエラーを返します。 mongodまたはmongosは接続リクエストを拒否し、配列内の残りのドキュメントをチェックしません。

MongoDB 5.0 以降、マッピング ドキュメントの代わりにuserToDNMappingは空のstring "" または空の配列 [ ] を受け入れます。 空の string または空の配列をuserToDNMappingに指定すると、MongoDB は認証されたユーザー名を LDAP DN としてマッピングします。 以前は、空のマッピング ドキュメントを提供するとマッピングが失敗していました。

例

次に示すのは、2 つの変換ドキュメントです。1 番目のドキュメントは @ENGINEERING で終わる文字列に一致し、サフィックスの前にあるものはすべて正規表現のキャプチャ グループに格納します。2 番目のドキュメントは @DBA で終わる文字列に一致し、サフィックスの前にあるものはすべて正規表現のキャプチャ グループに格納します。

重要

配列は文字列として userToDNMapping へ渡す必要があります。

"[
   {
      match: "(.+)@ENGINEERING.EXAMPLE.COM",
      substitution: "cn={0},ou=engineering,dc=example,dc=com"
   },
   {
      match: "(.+)@DBA.EXAMPLE.COM",
      ldapQuery: "ou=dba,dc=example,dc=com??one?(user={0})"
   }
]"

ユーザー名 alice@ENGINEERING.EXAMPLE.COM のユーザーが最初のドキュメントと一致します。正規表現キャプチャ グループ {0} は文字列 alice に対応します。結果の出力は DN "cn=alice,ou=engineering,dc=example,dc=com" です。

ユーザー名が bob@DBA.EXAMPLE.COM のユーザーは 2 番目のドキュメントに一致します。正規表現のキャプチャ グループ {0} は文字列 bob に対応します。結果としての出力は、LDAP クエリ "ou=dba,dc=example,dc=com??one?(user=bob)" です。mongod または mongos では、このクエリを LDAP サーバーに対して実行し、その結果 "cn=bob,ou=dba,dc=example,dc=com" を返します。

userToDNMappingが設定されていない場合、 mongodまたはmongosは、LDAP サーバーに対してユーザーを認証または承認しようとする際に、ユーザー名を変換しません。

この設定は、実行中の mongod や mongos でも setParameter データベース コマンドを使用して構成できます。

security.ldap.authz.queryTemplate

型: string

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

RFC4515 と RFC4516 に準拠して形式された相対的 LDAP クエリURL で、認証されたユーザーが属する LDAP グループを取得するために mongod が実行します。クエリは、security.ldap.servers で指定されたホストに対して相対的です。

注意

パフォーマンスを向上させるには、MongoDB 認可に使用される LDAP グループを専用の組織単位（ OU ）に配置することを検討してください。

URL では、次の置換トークンが使用できます。

置換トークン	説明
{USER}	認証されたユーザー名を置き換えるか、 が指定されている場合はtransformed userToDNMappingユーザー名を置き換えます。
{PROVIDED_USER}	認証または LDAP transformation の前に、指定されたユーザー名を置き換えます。

クエリ URL を作成する際は、LDAP パラメーターの順序が次の RFC4516 に準拠しているようにします。

[ dn  [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

クエリに属性が含まれている場合、mongod は、このエンティティがメンバーである識別名のリストがクエリで取得されるものと想定します。

クエリに属性が含まれていない場合、mongod では、ユーザーがメンバーであるエンティティすべてがクエリで取得されるものと想定します。

クエリによって返される LDAP 識別名ごとに、mongod では認証されているユーザーに対し admin データベースの対応するロールを割り当てます。admin データベースでのロールが識別名と完全に一致する場合、mongod ではそのロールに割り当てられているロールと権限をユーザーに付与します。ロール作成の詳細については、db.createRole() メソッドを参照してください。

例

この LDAP クエリは、LDAP ユーザー オブジェクトの memberOf 属性にリストされているすべてのグループを返します。

"{USER}?memberOf?base"

LDAP 構成に、ユーザー スキーマの一部として memberOf 属性が含まれていない場合、グループ メンバーシップのレポート作成用に別の属性がある場合、属性を通じてグループ メンバーシップを追跡していない場合があります。クエリは、独自の LDAP 設定に基づいて設定します。

設定されていない場合、mongod は LDAP を使用してユーザーを認証することはできません。

データベースコマンドを使用して実行中中の mongodsetParameterの パラメータの値を変更することはできますが、実行中に有効または無効にすることはできません。ldapAuthzQueryTemplateこの設定を有効にするには、スタートアップ時に構成ファイルで security.ldap.authz.queryTemplate を構成する必要があります。

注意

RFC4515、RFC4516、または LDAP クエリの説明は、 MongoDBドキュメントの範囲外です。RFC を直接確認するか、希望する LDAPリソースを使用してください。

security.ldap.validateLDAPServerConfig

タイプ: ブール値

デフォルト: true

MongoDB Enterprise で利用可能です。

mongodまたはmongosインスタンスが起動の一部としてLDAP server(s)の可用性をチェックするかどうかを決定するフラグです。

• true の場合、mongod インスタンスや mongos インスタンスでは可用性チェックを実行し、LDAP サーバーが利用可能な場合にのみ起動を続行します。

• false の場合、mongod インスタンスや mongosインスタンスは可用性チェックをスキップします。つまり、LDAP サーバーが利用できない場合でもインスタンスは起動します。

storage.wiredTiger オプション

storage:
   wiredTiger:
      engineConfig:
         cacheSizeGB: <number>
         cacheSizePct: <number>
         journalCompressor: <string>
         directoryForIndexes: <boolean>
         maxCacheOverflowFileSizeGB: <number>
      collectionConfig:
         blockCompressor: <string>
      indexConfig:
         prefixCompression: <boolean>

storage.wiredTiger.engineConfig.cacheSizeGB

型: float

WiredTiger がすべてのデータに使用する内部キャッシュの最大サイズを定義します。インデックス構築が消費するメモリ（maxIndexBuildMemoryUsageMegabytes を参照）は、 WiredTigerキャッシュメモリとは別です。

WiredTiger の内部キャッシュサイズをデフォルト値より大きくしないようにしてください。ユースケースでその必要がある場合は、 を使用して、使用可能なメモリの最大storage.wiredTiger.engineConfig.cacheSizePct 80% のパーセンテージを指定できます。値の範囲は 0.25 GBから 10000 GBです。

デフォルトの WiredTiger 内部キャッシュ サイズは、次のいずれか大きい方です。

• （RAM-1 GB）の50%、または

• 256 MB.

たとえば、合計が4 GB の RAM を備えたシステムでは、WiredTiger キャッシュは1.5 GB の RAM を使用します（ 0.5 * (4 GB - 1 GB) = 1.5 GB ）。 逆に、合計が1.25のシステムでは GBのRAM WiredTigerは 256 MB をWiredTigerキャッシュに割り当てます。これはRAMの合計の半分以上で 1 ギガバイト（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）を引いた値であるためです。

注意

コンテナで実行している場合など、場合によっては、データベースのメモリが制約され、システムメモリの合計よりも少なくなることがあります。このような場合、システム メモリの合計ではなく、このメモリ上限が、使用可能な最大 RAM として使用されます。

メモリ制限を確認するには、hostInfo.system.memLimitMB を参照してください。

WiredTiger を使用する MongoDB では WiredTiger 内部キャッシュとファイルシステム キャッシュの両方を利用します。

ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

注意

storage.wiredTiger.engineConfig.cacheSizeGBは WiredTiger の内部キャッシュのサイズを制限します。 オペレーティング システムは、使用可能な空きメモリをファイルシステム キャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。 さらに、オペレーティング システムは、空き RAM を使用して、ファイル システム ブロックとファイル システム キャッシュをバッファリングします。

RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュ サイズを減らす必要がある場合があります。

デフォルトのWiredTiger内部キャッシュサイズの値は、マシンごとに 1 つの mongod インスタンスがあることを前提としています。1 台のマシンに複数のMongoDBインスタンスが存在する場合は、設定値を減らして他の mongod インスタンスに対応できるようにしてください。

システムで使用可能なすべての RAM にアクセス でき ない mongodコンテナ（たとえば、lxc cgroups、storage.wiredTiger.engineConfig.cacheSizeGB 、Docker など）で を実行する場合は、 を 値に設定する必要がありますコンテナで使用可能な RAM の量よりも小さい。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。 詳しくはmemLimitMBを参照してください。

storage.wiredTiger.engineConfig.cacheSizeGB または storage.wiredTiger.engineConfig.cacheSizePct のいずれか 1 つだけを提供できます。

storage.wiredTiger.engineConfig.cacheSizePct

型: float

キャッシュに割り当てるメモリの最大量を物理RAMの割合で定義します。インデックス構築が消費するメモリ（maxIndexBuildMemoryUsageMegabytes を参照）は、 WiredTigerキャッシュメモリとは別です。

使用可能なメモリの最大 80% の割合を指定できます。値の範囲は 0.25 GBから 10000 GBです。

デフォルトの WiredTiger 内部キャッシュ サイズは、次のいずれか大きい方です。

• （RAM-1 GB）の50%、または

• 256 MB.

たとえば、合計が4 GB の RAM を備えたシステムでは、WiredTiger キャッシュは1.5 GB の RAM を使用します（ 0.5 * (4 GB - 1 GB) = 1.5 GB ）。 逆に、合計が1.25のシステムでは GBのRAM WiredTigerは 256 MB をWiredTigerキャッシュに割り当てます。これはRAMの合計の半分以上で 1 ギガバイト（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）を引いた値であるためです。

注意

コンテナで実行している場合など、場合によっては、データベースのメモリが制約され、システムメモリの合計よりも少なくなることがあります。このような場合、システム メモリの合計ではなく、このメモリ上限が、使用可能な最大 RAM として使用されます。

メモリ制限を確認するには、hostInfo.system.memLimitMB を参照してください。

WiredTiger を使用する MongoDB では WiredTiger 内部キャッシュとファイルシステム キャッシュの両方を利用します。

ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

注意

storage.wiredTiger.engineConfig.cacheSizePctは WiredTiger の内部キャッシュのサイズを制限します。 オペレーティング システムは、使用可能な空きメモリをファイルシステム キャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。 さらに、オペレーティング システムは、空き RAM を使用して、ファイル システム ブロックとファイル システム キャッシュをバッファリングします。

RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュ サイズを減らす必要がある場合があります。

デフォルトのWiredTiger内部キャッシュサイズの値は、マシンごとに 1 つの mongod インスタンスがあることを前提としています。1 台のマシンに複数のMongoDBインスタンスが存在する場合は、設定値を減らして他の mongod インスタンスに対応できるようにしてください。

システムで使用可能なすべての RAM にアクセス でき ない mongodコンテナ（たとえば、lxc cgroups、storage.wiredTiger.engineConfig.cacheSizePct 、Docker など）で を実行する場合は、 を 値に設定する必要がありますコンテナで使用可能な RAM の量よりも小さい。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。 詳しくはmemLimitMBを参照してください。

storage.wiredTiger.engineConfig.cacheSizePct または storage.wiredTiger.engineConfig.cacheSizeGB のいずれか 1 つだけを提供できます。

storage.wiredTiger.engineConfig.journalCompressor

デフォルト: snappy

WiredTiger ジャーナリング データを圧縮するのに使用する圧縮タイプを指定します。

利用可能なコンプレッサーは次のとおりです。

• none

• Snappy

• zlib

• zstd

storage.wiredTiger.engineConfig.directoryForIndexes

タイプ: ブール値

デフォルト: false

storage.wiredTiger.engineConfig.directoryForIndexesがtrueの場合、 mongodはインデックスとコレクションをデータの下の個別のサブディレクトリに保存します（つまり storage.dbPath ）ディレクトリ。 具体的には、 mongodはインデックスをindexという名前のサブディレクトリに保存し、コレクション データをcollectionという名前のサブディレクトリに保存します。

シンボリックリンクを使用すると、インデックスに別のロケーションを指定することができます。具体的には、mongod インスタンスが実行されていない場合に、index サブディレクトリを目的のロケーションに移動し、index という名前のシンボリック リンクを新しい目的地のデータディレクトリの下に作成します。

storage.wiredTiger.engineConfig.zstdCompressionLevel

タイプ: 整数

デフォルト: 6

バージョン 5.0 で追加

バージョン8.2で変更

zstd コンプレッサーを使用する際に適用される圧縮レベルを指定します。

値の範囲は -7 から 22 です。

正の値は圧縮レベルを指定します。zstdCompressionLevel の値が大きいほど圧縮比率は高くなりますが、圧縮と解凍速度は遅くなりコスト。

負の値を指定すると、圧縮比率がコスト、圧縮および解凍の速度が速くなります。

0 の値を指定すると、zstd の内部デフォルト圧縮レベル 3 が使用されます。これはMongoDBのデフォルトの 6 とは異なります。

blockCompressor または journalCompressor（あるいは両方）が zstd に設定されている場合にのみ適用されます。

重要

MongoDBの以前のバージョンにダウングレードする場合は、storage.wiredTiger.engineConfig.zstdCompressionLevel の設定がそのバージョンでサポートされている範囲に構成されていることを確認してください。例、 MongoDB 8.0 は 1 から 22 の範囲をサポートしています。

storage.wiredTiger.collectionConfig.blockCompressor

デフォルト: snappy

コレクション データのデフォルトの圧縮率を指定します。これは、コレクションを作成する際、コレクションごとに上書きできます。

利用可能なコンプレッサーは次のとおりです。

• none

• Snappy

• zlib

• zstd

storage.wiredTiger.collectionConfig.blockCompressor は作成されたすべてのコレクションに影響します。既存の MongoDB の配置で storage.wiredTiger.collectionConfig.blockCompressor の値を変更すると、すべての新しいコレクションで指定されたコンプレッサーが使用されます。既存のコレクションは、作成時に指定されたコンプレッサー、またはその時点でのデフォルトのコンプレッサーを引き続き使用します。

storage.wiredTiger.indexConfig.prefixCompression

デフォルト: true

インデックスデータの接頭辞圧縮を有効または無効にします。

truestorage.wiredTiger.indexConfig.prefixCompressionインデックス データの 接頭辞圧縮 を有効にするにはfalse に指定し、インデックス データの接頭辞圧縮を無効にするには を指定します。

storage.wiredTiger.indexConfig.prefixCompressionの設定は作成されたすべてのインデックスに影響します。 既存の MongoDB デプロイでstorage.wiredTiger.indexConfig.prefixCompressionの値を変更すると、すべての新しいインデックスで接頭辞圧縮が使用されます。 既存のインデックスは影響を受けません。

storage.inmemory オプション

storage:
   inMemory:
      engineConfig:
         inMemorySizeGB: <number>

storage.inMemory.engineConfig.inMemorySizeGB

型: float

デフォルト: 物理 RAM の50% から 1GB を引いた値

値の範囲は 256 MB から 10 TB までで、float にすることができます。

インメモリ ストレージエンジン データ（インデックス、mongod がレプリカセットの一部である場合の oplog、レプリカセット、シャーディングされたクラスターのメタデータなど）に割り当てるメモリの最大量。

デフォルトで、インメモリ ストレージエンジンは物理 RAM の 50% から 1 GB を引いた量を使用します。

注意

エンタープライズ機能

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