Docs Menu
Docs Home
/
MongoDBマニュアル
/ / /

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

項目一覧

  • 構成ファイル
  • ファイル形式
  • 構成ファイルを使用
  • 中心的オプション
  • systemLog オプション
  • processManagement オプション
  • net オプション
  • security オプション
  • setParameter オプション
  • storage オプション
  • operationProfiling オプション
  • replication オプション
  • sharding オプション
  • auditLog オプション
  • snmp オプション
  • mongos -only オプション
  • Windows サービス オプション
  • 削除済み MMAPv1 オプション

次のページでは、 MongoDB 5.0で使用できる構成オプションについて説明します。 他のバージョンの MongoDB の構成ファイルのオプションについては、該当するバージョンの MongoDB マニュアルを参照してください。

注意

MongoDB Atlas を使用して、MongoDB のクラウドへの配置を管理している場合は、構成ファイルの作成は不要です。MongoDB Atlas 配置設定の構成方法については、追加設定の構成」を参照してください。

構成ファイル オプションを使用するだけでなく、MongoDB バイナリのデフォルト構成ではオペレーティング システムの環境変数も使用されます。

起動時に構成ファイルを使用して、 mongodおよびmongosインスタンスを構成できます。 構成ファイルには、 mongodmongosコマンドライン オプションと同等の設定が含まれています。 「自己管理型構成ファイルの設定とコマンドライン オプションのマッピング 」を参照してください。

構成ファイルを使用すると、特に大規模な配置の場合、mongod オプションと mongos オプションの管理が容易になります。構成ファイルにコメントを追加して、サーバーの設定を説明することもできます。

  • Linux の yumapt、macOS の brew などのパッケージ マネージャーを使用して、または Windows の MSI インストーラーを使用して、MongoDB をインストールした場合、インストールの一部としてデフォルトの構成ファイルが提供されています。

    プラットフォーム
    方式
    構成ファイル
    Linux
    aptyumまたは、zypper パッケージ マネージャー
    /etc/mongod.conf
    MacOS
    brew パッケージ マネージャー
    Windows
    MSI インストーラー
    <install directory>\bin\mongod.cfg
  • ダウンロードした TGZ または ZIP ファイルを使用して MongoDB をインストールした場合、独自の構成ファイルを作成する必要があります。基本的な例の構成から始めることが推奨されます。

MongoDB の構成ファイルでは YAML 形式 [1] が使用されます。

次のサンプル構成ファイルには、ローカル構成に合わせて調整できるいくつかの mongod 設定が含まれています。

注意

YAML はインデント用のタブ文字をサポートしていません。代わりにスペースを使用します。

systemLog:
destination: file
path: "/var/log/mongodb/mongod.log"
logAppend: true
storage:
journal:
enabled: true
processManagement:
fork: true
net:
bindIp: 127.0.0.1
port: 27017
setParameter:
enableLocalhostAuthBypass: false
...

公式 MongoDB パッケージに含まれる Linux パッケージ init スクリプトは、systemLog.pathstorage.dbPath、および processManagement.fork の特定の値に依存します。デフォルトの構成ファイルでこれらの設定を変更すると、mongod が起動しない可能性があります。

[1] YAML は JSON のスーパーセットです。

注意

MongoDB は、構成ファイルの展開ディレクティブを使用して外部から取得された値をロードすることをサポートしています。 展開ディレクティブを使用すると、特定の構成ファイル オプションの値をロードしたり、構成ファイル全体をロードしたりできます。

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

展開ディレクティブ
説明

ユーザーが、構成ファイル オプションの外部ソースまたは完全な構成ファイルとして REST エンドポイントを指定できるようにします。

構成ファイルに__rest 展開が含まれている場合、Linux/macOS では、構成ファイルへの読み取りアクセスは、mongod / mongos プロセスを実行しているユーザーのみに制限する必要があります。

ユーザーが構成ファイル オプションの外部ソースまたは完全な構成ファイルとして、shell またはターミナルコマンドを指定できるようにします。

構成ファイルに __exec 展開が含まれている場合、Linux/macOS では、構成ファイルへの書き込み (write) アクセスは、mongod / mongos プロセスを実行しているユーザーのみに制限する必要があります。

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

構成ファイルを使用して mongod または mongos を構成するには、次の例のように、--config オプションまたは -f オプションを使用して構成ファイルを指定します。

たとえば、次の例では mongod --config <configuration file> mongos --config <configuration file> が使用されています。

mongod --config /etc/mongod.conf
mongos --config /etc/mongos.conf

次のように、-f エイリアスを使用して構成ファイルを指定することもできます。

mongod -f /etc/mongod.conf
mongos -f /etc/mongos.conf

パッケージからインストールし、システムの init スクリプトを使用して MongoDB を起動した場合は、すでに構成ファイルが使用されています。

構成ファイルで展開ディレクティブを使用している場合は、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:
verbosity: <int>
quiet: <boolean>
traceAllExceptions: <boolean>
syslogFacility: <string>
path: <string>
logAppend: <boolean>
logRotate: <string>
destination: <string>
timeStampFormat: <string>
component:
accessControl:
verbosity: <int>
command:
verbosity: <int>
# COMMENT additional component verbosity settings omitted for brevity
systemLog.verbosity

タイプ: 整数

デフォルト: 0

コンポーネントのデフォルトのログ メッセージの冗長レベルです。冗長レベルは、MongoDB が出力する情報メッセージとデバッグ メッセージの量を決定します。[2]

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

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

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

名前付きコンポーネントに別の冗長レベルを使用するには、コンポーネントの冗長設定を使用します。 たとえば、 systemLog.component.accessControl.verbosityを使用して、 ACCESSコンポーネントのみに冗長レベルを設定します。

特定のコンポーネントの冗長設定については、「systemLog.component.<name>.verbosity 設定」を参照してください。

ログの冗長レベルを設定するさまざまな方法については、「ログの冗長レベルの構成」を参照してください。

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

タイプ: ブール値

デフォルト: false

出力量を制限するクワイエットモードで mongos または mongod を実行します。

systemLog.quiet は、特定の接続中に問題の追跡が非常に困難になる可能性があるため、実稼働システムには推奨されません

systemLog.traceAllExceptions

タイプ: ブール値

デフォルト: false

デバッグ用に詳細情報を出力します。サポート関連のトラブルシューティングのための追加ログに使用します。

systemLog.syslogFacility

: string

デフォルト: user

メッセージを syslog に記録するときに使用するファシリティ レベルです。指定する値は、使用しているオペレーティング システムの syslog の実装でサポートされている必要があります。このオプションを使用するには、systemLog.destinationsyslog に設定する必要があります。

systemLog.path

: string

mongod または mongos が標準出力やホストの syslog ではなく、すべての診断ログ情報を送信すべきログファイルのパス。MongoDB は指定したパスにログファイルを作成します。

Linux パッケージ初期化スクリプトでは、 systemLog.pathがデフォルトから変更されることは想定されていません。 Linux パッケージを使用してsystemLog.pathを変更する場合は、独自の初期化スクリプトを使用し、組み込みスクリプトを無効にする必要があります。

systemLog.logAppend

タイプ: ブール値

デフォルト: false

trueの場合、インスタンスの再起動時にmongosまたはmongodによって既存のログファイルの末尾に新しいエントリが追加されます。 このオプションを指定しない場合、 mongodまたはmongosは既存のログをバックアップして新しいファイルを作成します。

systemLog.logRotate

: string

デフォルト: rename

サーバー ログや監査ログをローテーションするときの logRotate コマンドの動作を決定します。rename または reopen を指定します。

  • rename は、ログファイルの名前を変更します。

  • reopen は、一般的な Linux/Unix ログのローテーション動作に従って、ログファイルを閉じてから再度開きます。Linux/Unix logrotate ユーティリティを使用する場合は、ログの損失を防ぐために reopen を使用してください。

    reopenを指定する場合は、 systemLog.logAppendtrueに設定する必要があります。

systemLog.destination

: string

MongoDB がすべてのログ出力を送信する宛先です。file または syslog を指定します。file を指定する場合は、systemLog.path も指定する必要があります。

systemLog.destinationを指定しない場合、MongoDB はすべてのログ出力を標準出力に送信します。

警告

syslog デーモンでは、MongoDB がメッセージを発行したときではなく、メッセージをログに記録する際にタイムスタンプを生成します。これにより、特にシステムの負荷が高い場合に、ログエントリのタイムスタンプに誤りが生じる可能性があります。タイムスタンプが正確になるように、実稼働システムでは file オプションを使用することをお勧めします。

systemLog.timeStampFormat

: string

Default: iso8601-local

ログ メッセージのタイムスタンプの時間形式。次のいずれかの値を指定。

説明
iso8601-utc
ISO-8601 形式のUTC(Coordinated Universal Time、協定世界時)でタイムスタンプを表示します。たとえば、UNIXエポック開始時のニューヨークの場合、以下のようになります。 1970-01-01T00:00:00.000Z
iso8601-local
タイムスタンプを ISO-8601 形式のローカルタイムで表示します。たとえば、UNIXエポック開始時のニューヨークの場合、以下のようになります。 1969-12-31T19:00:00.000-05:00

注意

systemLog.timeStampFormat での ctime のサポートは終了しました。ctime 形式の日付の例は、Wed Dec 31 18:17:54.811 です。

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>

注意

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

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.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.transaction.verbosity

タイプ: 整数

デフォルト: 0

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

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

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

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

systemLog.component.write.verbosity

タイプ: 整数

デフォルト: 0

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

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

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

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

processManagement:
fork: <boolean>
pidFilePath: <string>
timeZoneInfo: <string>
processManagement.fork

タイプ: ブール値

デフォルト: false

デーモン モードを有効にして、mongos または mongod プロセスをバックグラウンドで実行します。デフォルトでは、mongos または mongod は、デーモンとして実行されません。mongos または mongod をデーモンとして使用するには、processManagement.fork を設定するか、デーモン化プロセスを取り扱う制御プロセス(例: systemd)を使用します。

processManagement.forkオプションは Windows ではサポートされていません。

Linux パッケージ初期化スクリプトでは、 processManagement.forkがデフォルトから変更されることは想定されていません。 Linux パッケージを使用してprocessManagement.forkを変更する場合は、独自の初期化スクリプトを使用し、組み込みスクリプトを無効にする必要があります。

processManagement.pidFilePath

: string

mongos プロセスまたは mongod プロセスのプロセス ID(PID)を保存するファイルの場所を指定します。mongod プロセスまたは mongos プロセスを実行中のユーザーは、このパスに書込む (write) ことができる必要があります。processManagement.pidFilePath オプションが指定されていない場合、プロセスは PID ファイルを作成しません。このオプションは通常、processManagement.fork の設定と組み合わせて使用した場合にのみ役立ちます。

注意

Linux

Linux では、PID ファイルの管理は通常、ディストリビューションの初期化システムによって行われます。通常、 /etc/init.dディレクトリ内のサービス ファイル、またはsystemctlに登録された systemd ユニット ファイルが使用されます。 これらの初期化システムのいずれも使用していない場合にのみ、 processManagement.pidFilePathオプションを使用してください。 詳細については、ご利用中のオペレーティング システム用のインストール ガイドを参照してください。

注意

MacOS

macOS では、PID ファイル管理は通常brewによって処理されます。 macOS システムでbrewを使用していない場合にのみ、 processManagement.pidFilePathオプションを使用してください。 詳細については、ご利用中のオペレーティング システム用のインストール ガイドを参照してください。

processManagement.timeZoneInfo

: string

タイムゾーン データベースをロードするフルパス。 このオプションが指定されていない場合、MongoDB は組み込みのタイムゾーンデータベースを使用します。

Linux パッケージと macOS パッケージに含まれる構成ファイルでは、タイムゾーン データベース パスがデフォルトで /usr/share/zoneinfo に設定されています。

組み込みのタイム ゾーン データベースは、 Olson および IANA のタイムゾーンデータベースのコピーです。タイム ゾーン データベースは MongoDB のリリース時にアップデートされますが、タイム ゾーン データベースと MongoDB のリリース サイクルは異なります。タイム ゾーン データベースの最新リリースは、当社の ダウンロードサイト から入手できます。

警告

MongoDB はサードパーティの timelib を使用します ライブラリ。タイムゾーン間の正確な変換を提供します。最近の更新により、 timelibは MongoDB の古いバージョンで不正確なタイムゾーン変換を作成する可能性があります。

5.0 より前のバージョンの MongoDB でタイムゾーン データベースに明示的にリンクするには、タイムゾーン データベース をダウンロードし、timeZoneInfo パラメーターを使用します。

バージョン 5.0 で変更: MongoDB は、net.serviceExecutor構成オプションとそれに対応する --serviceExecutor コマンドライン オプションを削除します。

net:
port: <int>
bindIp: <string>
bindIpAll: <boolean>
maxIncomingConnections: <int>
wireObjectCheck: <boolean>
ipv6: <boolean>
unixDomainSocket:
enabled: <boolean>
pathPrefix: <string>
filePermissions: <int>
tls:
certificateSelector: <string>
clusterCertificateSelector: <string>
mode: <string>
certificateKeyFile: <string>
certificateKeyFilePassword: <string>
clusterFile: <string>
clusterPassword: <string>
CAFile: <string>
clusterCAFile: <string>
CRLFile: <string>
allowConnectionsWithoutCertificates: <boolean>
allowInvalidCertificates: <boolean>
allowInvalidHostnames: <boolean>
disabledProtocols: <string>
FIPSMode: <boolean>
logVersions: <string>
compression:
compressors: <string>
net.port

タイプ: 整数

デフォルト:

MongoDB インスタンスがクライアント接続を待機するTCP ポート。

バージョン5.0.22での変更: net.portオプションは、 0から65535までの範囲の値を受け入れます。 ポートを0に設定すると、 mongosまたはmongodはオペレーティング システムによって割り当てられた任意のポートを使用するように構成されます。

net.bindIp

: string

デフォルト: localhost

mongos または mongod がクライアント接続を待機するべきホスト名、IP アドレス、Unix ドメイン ソケットの完全パス。mongos または mongod を任意のインターフェースにバインドできます。複数のアドレスにバインドするには、カンマで区切った値のリストを入力します。

localhost,/tmp/mongod.sock

IPv4 アドレスと IPv6 アドレスの両方、 IPv4 アドレスまたは IPv6 アドレスのいずれかに解決するホスト名が指定できます。

localhost, 2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513

注意

IPv6 アドレス、または IPv6 アドレスに解決するホスト名を net.bindIp に指定する場合、IPv6 サポートを有効にするには、mongos または mongodnet.ipv6 : true に設定して開始する必要があります。 net.bindIp に IPv6 アドレスを指定しても、IPv6 サポートは有効になりません。

link-local IPv6 アドレスfe80::/10)を指定する場合、ゾーン インデックスをそのアドレス(fe80::<address>%<adapter-name>)に追加する必要があります。

localhost,fe80::a00:27ff:fee0:1fcf%enp0s3

重要

IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。

分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。

警告

非ローカルホスト(例: (一般にアクセス可能な)IP アドレスを使用して、クラスターを不正アクセスから保護していることを確認します。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。

IP バインディングの詳細については、「自己管理型配置の IP バインディング」ドキュメントを参照してください。

すべての IPv4 アドレスにバインドするには、「0.0.0.0」と入力します。

すべての IPv4 と IPv6 アドレスにバインドするには、::,0.0.0.0 またはアスタリスク"*" を入力します(アスタリスクは YAML エイリアス ノード と区別するために引用符で囲みます)。 )。または、 net.bindIpAll設定を使用します。

注意

  • net.bindIpnet.bindIpAllは相互に排他的です。 つまり、どちらか一方を指定できますが、両方を指定することはできません。

  • コマンドライン オプション --bind_ip は、構成ファイルの設定 net.bindIp を上書きします。

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

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

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

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

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

net.bindIpAll

タイプ: ブール値

デフォルト: false

true の場合、 mongosまたはmongodインスタンスはすべての IPv 4アドレス(つまり 0.0.0.0 )。 mongosまたはmongodnet.ipv6 : trueで始まる場合、 net.bindIpAllはすべての IPv 6アドレス(つまり :: )。

mongos または mongod では、net.ipv6 : true に設定して開始された場合にのみ IPv6 がサポートされます。net.bindIpAll のみを指定しても、IPv6 のサポートは有効になりません。

警告

非ローカルホスト(例: (一般にアクセス可能な)IP アドレスを使用して、クラスターを不正アクセスから保護していることを確認します。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。

IP バインディングの詳細については、「自己管理型配置の IP バインディング」ドキュメントを参照してください。

あるいは、net.bindIp::,0.0.0.0 またはアスタリスク "*" に設定し(アスタリスクは YAML エイリアス ノードと区別するために引用符で囲みます)、すべての IP アドレスにバインドします。

注意

net.bindIpnet.bindIpAllは相互に排他的です。 両方のオプションを指定すると、 mongosまたはmongodはエラーをスローして終了します。

net.maxIncomingConnections

タイプ: 整数

Default (Windows): 1,000,000
Default (Linux): (RLIMIT_NOFILE) * 0.8

mongos または mongod が受け入れる同時接続の最大数です。この設定は、オペレーティング システムで設定されている最大接続追跡しきい値よりも高い場合は効果がありません。

このオプションに、あまりにも低い値は割り当てないでください。通常のアプリケーション操作中にエラーが発生する可能性があります。

これは、クライアントで接続を複数作成して、それらを閉じるのではなくタイムアウトさせる場合、特に mongos にとって有用です。

この場合、maxIncomingConnections を、クライアントが作成する接続の最大数、または接続プールの最大サイズよりも少し高い値に設定します。

この設定により、mongos が個々のシャードで接続スパイクが発生するのを防ぎます。このようなスパイクが発生すると、シャーディングされたクラスターの操作とメモリ割り当てが中断されることがあります。

net.wireObjectCheck

タイプ: ブール値

デフォルト: true

true の場合、mongod インスタンスや mongos インスタンスでは、クライアントからのリクエストを受け取るとすぐにすべてのリクエストを検証し、クライアントが MongoDB データベースに不正な BSON を挿入するのを防ぎます。

サブドキュメントのネストが深いオブジェクトの場合、net.wireObjectCheck はパフォーマンスにわずかな影響を与える可能性があります。

net.ipv6

タイプ: ブール値

デフォルト: false

IPv6 のサポートを有効にするには、net.ipv6true に設定します。mongos および mongod では、デフォルトで IPv6 のサポートは無効です。

net.ipv6 を設定しても、mongos および mongod がローカル IPv6 アドレスまたはインターフェースをリッスンするように指示しませんmongos および mongod を IPv6 インターフェースでリッスンするように設定するには、次のいずれかを行う必要があります。

  • IPv 6アドレスに解決される 1 つ以上の IPv 6アドレスまたはホスト名を使用してnet.bindIpを構成するか、あるいは

  • net.bindIpAlltrue に設定します。

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

タイプ: ブール値

デフォルト: true

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

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

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

  • net.unixDomainSocket.enabled とは false

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

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

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

公式の .debからインストールされたmongosmongodパッケージと .rpmパッケージであれば、 bind_ip 構成がデフォルトで127.0.0.1 に設定されています。

net.unixDomainSocket.pathPrefix

: string

デフォルト: /tmp

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

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

net.unixDomainSocket.filePermissions

タイプ: int

デフォルト: 0700

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

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

注意

tlsオプションは、前のsslオプションと同じ機能を提供します。

net:
tls:
mode: <string>
certificateKeyFile: <string>
certificateKeyFilePassword: <string>
certificateSelector: <string>
clusterCertificateSelector: <string>
clusterFile: <string>
clusterPassword: <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 認証を使用する場合、--tlsCertificateSelector を使用しない限り、--tlsCAFile または tls.CAFile を指定する必要があります。

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

net.tls.certificateKeyFile

: string

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

macOS または Windows では、net.tls.certificateSelector 設定を使用して、PEM キー ファイルの代わりに、オペレーティング システムのセキュリティで保護されている証明書ストアからの証明書を指定できます。certificateKeyFilenet.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 の詳細については、「mongodmongos のTLS/SSL 設定」および「クライアントの 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 の詳細については、「mongodmongos のTLS/SSL 設定」および「クライアントの TLS/SSL 設定」を参照してください。

net.tls.certificateSelector

: string

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

net.tls.certificateKeyFilenet.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または--tlsCertificateSelectorthumbprintに設定している場合、 rotateCertificatesコマンドまたはdb.rotateCertificates() shell メソッドは使用できません。

net.tls.clusterCertificateSelector

: string

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

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

net.tls.clusterFilenet.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 証明書が含まれている必要があります。

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

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 認証を使用する場合、--tlsCertificateSelector を使用しない限り、--tlsCAFile または tls.CAFile を指定する必要があります。

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

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

重要

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

net.tls.clusterPassword

: string

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

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

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

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

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

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

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 の詳細については、「mongodmongos のTLS/SSL 設定」および「クライアントの 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 ハンドシェイクの各部分を検証するために、異なる認証局を使用することができます。

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

net.tls.allowConnectionsWithoutCertificates

タイプ: ブール値

デフォルト: false

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

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

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

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

net.tls.allowInvalidCertificates

タイプ: ブール値

デフォルト: false

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

注意

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

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

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

net.tls.allowInvalidHostnames

タイプ: ブール値

デフォルト: false

net.tls.allowInvalidHostnamestrueの場合、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_0TLS1_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

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

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

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

net:
compression:
compressors: <string>
net.compression.compressors

Default: snappy,zstd,zlib

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

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

  • mongosh

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

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

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

重要

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

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

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

security:
keyFile: <string>
clusterAuthMode: <string>
authorization: <string>
transitionToAuth: <boolean>
javascriptEnabled: <boolean>
redactClientLogData: <boolean>
clusterIpSourceAllowlist:
- <string>
sasl:
hostName: <string>
serviceName: <string>
saslauthdSocketPath: <string>
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>
ldap:
servers: <string>
bind:
method: <string>
saslMechanisms: <string>
queryUser: <string>
queryPassword: <string | array>
useOSDefaults: <boolean>
transportSecurity: <string>
timeoutMS: <int>
userToDNMapping: <string>
authz:
queryTemplate: <string>
validateLDAPServerConfig: <boolean>
security.keyFile

: string

MongoDB インスタンスが シャーディングされたクラスターまたはレプリカセット内で相互に認証するために使用する共有シークレットを保存するキー ファイルへのパスです。 keyFilesecurity.authorization } を意味します。 詳細については、「自己管理型内部認証とメンバーシップ認証」を参照してください。

内部メンバーシップ認証用のキーファイルでは、キーファイル内に複数のキーを含めるために YAML 形式が使用されます。YAML 形式は次のいずれかを受け入れます。

  • 1 つのキー文字列(以前のバージョンと同じ)

  • キー文字列のシーケンス

YAML 形式は、テキストファイル形式を使用する既存の単一のキー キーファイルと互換性があります。

security.clusterAuthMode

: string

デフォルト: keyFile

クラスター認証に使用される認証モードです。内部 x.509 認証を使用する場合は、ここで指定します。このオプションには、次のいずれかの値を指定できます。

説明
keyFile
認証にはキーファイルを使用します。キーファイルのみを受け付けます。
sendKeyFile
ローリングアップグレードを目的としたものです。認証のためにキーファイルを送信しますが、キーファイルと x.509 証明書の両方を受け入れることができます。
sendX509
ローリングアップグレードを目的としたものです。認証のために x.509 証明書を送信しますが、 x.509 証明書とキーファイルの両方を受け入れることができます。
x509
推奨。認証のために x.509 証明書を送信し、x.509 証明書のみを受け入れます。

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

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

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

security.authorization

: string

デフォルト: disabled

データベースリソースや操作に対する各ユーザーのアクセスを管理するために、ロールベース アクセス制御 (RBAC) を有効または無効にします。

このオプションは次のいずれかに設定します。

説明
enabled
ユーザーは、権限が付与されているデータベース リソースとアクションにのみアクセスできます。
disabled
ユーザーは任意のデータベースにアクセスして任意のアクションを実行することができます。

詳細については、「自己管理型配置のロールベースのアクセス制御」を参照してください。

security.authorization設定はmongodでのみ使用できます。

security.transitionToAuth

タイプ: ブール値

デフォルト: false

mongod または mongos が配置内の他の mongod インスタンスおよび mongos インスタンスとの間で、認証済みの接続および非認証の接続の受け入れと作成を許可します。これは、レプリカセットやシャーディングされたクラスターを、認証なしの構成から内部認証へ段階的に移行するために使用されます。security.keyFile などの内部認証メカニズムを指定する必要があります。

たとえば、キーファイル内部認証に使用する場合、mongodmongos では、一致するキーファイルを使用して、配置にある任意の mongodmongos との認証された接続を作成します。セキュリティ メカニズムが一致しない場合、mongodmongos では代わりに非認証の接続を利用します。

security.transitionToAuth を使用して実行されている mongod または mongos では、ユーザー アクセス制御は強制されません。ユーザーは、アクセス制御チェックなしで配置に接続し、読み取り操作、書込み操作、および管理操作を実行できます。

注意

mongod または mongos が、内部認証で実行され、かつ security.transitionToAuth がない場合、クライアントはユーザー アクセス制御を使用して接続する必要があります。クライアントを更新して、適切なユーザーを使用して mongod または mongos に接続し再起動する前に、mongod または mongossecurity.transitionToAuth がない状態で接続する必要があります。

security.javascriptEnabled

タイプ: ブール値

デフォルト: true

サーバー側でのJavaScript の実行を有効または無効にします無効にすると、$where クエリ演算子、mapReduce コマンド、$accumulator$function など、サーバー側で JavaScript コードの実行を行う操作はできません。

このような操作をしない場合は、サーバー側のスクリプトを無効にします。

security.javascriptEnabledmongodmongosの両方で使用できます。 以前のバージョンでは、この設定はmongodでのみ利用可能です。

security.redactClientLogData

タイプ: ブール値

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

security.redactClientLogData を使用して実行されている mongod または mongos は、ログに記録される前にログ イベントに付随するすべてのメッセージを編集します。これにより、mongod または mongos がデータベースに保存されている潜在的に機密性の高いデータを診断ログに書込むことを防ぎます。エラー コードやオペレーション コード、行番号、ソース ファイル名などのメタデータは、引き続きログに表示されます。

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

たとえば、MongoDB の配置では、個人を特定できる情報(PII)が 1 つ以上のコレクションに保存される場合があります。mongod または mongos は、CRUD 操作やシャーディングメタデータなどに関連するイベントをログに記録します。mongod または mongos は、これらのログ操作の一環として PII を公開する可能性があります。security.redactClientLogData とともに実行される mongod または mongos は、ログに出力される前にこれらのイベントに付随するメッセージをすべて除き、効果的に PII を排除します。

とともに実行されているmongos security.redactClientLogDataまたはmongod の診断は、ログ イベントに関連するデータが不足しているため、より困難になる可能性があります。がログ出力に与える影響の例については、 security.redactClientLogDataプロセス ログ のマニュアル ページを参照してください。

稼働中の mongodmongos でも、 setParameterredactClientLogData パラメーターとともに使用して、この設定を構成できます。

security.clusterIpSourceAllowlist

タイプ: list

バージョン 5.0 で追加

バージョン 5.2 で変更

IP アドレス/CIDR(クラスレス ドメイン間ルーティング)のリスト範囲に対して、mongod はレプリカセットの他のノードおよび、シャーディングされたクラスターの一部である場合は、mongos インスタンスからの認証リクエストを検証します。mongod は、発信元 IP がリストに明示的に含まれているか、またはリスト内の CIDR 範囲に属していることを確認します。IP アドレスが存在しない場合、サーバーは mongod または mongos を認証しません。

security.clusterIpSourceAllowlist は、認証なしで開始された mongod には影響しません。

MongoDB 5.2以降では、setParameter を使用して実行中のmongodまたはmongossecurity.clusterIpSourceAllowlistを構成できます

この例では、ランタイム時に security.clusterIpSourceAllowlist を更新して、IP アドレス "1.1.1.1/24""2.2.2.2/16"、および "3.3.3.3" を含めます。

db.adminCommand( {
setParameter: 1,
"clusterIpSourceAllowlist": ["1.1.1.1/24", "2.2.2.2/16", "3.3.3.3"]
} );

この例では、ランタイム時に security.clusterIpSourceAllowlist を更新してすべての IP アドレスを除外します。

db.adminCommand( {
setParameter: 1,
"clusterIpSourceAllowlist": null
} );

security.clusterIpSourceAllowlist は、認証なしで開始された mongod には影響しません。

security.clusterIpSourceAllowlist には、各IPv4/6 アドレスまたはクラスレス ドメイン間ルーティング(CIDR)の範囲を、YAML リストとして指定する必要があります。

security:
clusterIpSourceAllowlist:
- 192.0.2.0/24
- 127.0.0.1
- ::1

重要

クラスター コンポーネント間の正常な通信を確保するために、security.clusterIpSourceAllowlist には、IP アドレス、または各レプリカセットのノードもしくは配置内にある mongos を含む CIDR 範囲が含まれていることを確認してください。

security.clusterIpSourceWhitelist

タイプ: list

バージョン 5.0 では非推奨: 代わりに、security.clusterIpSourceAllowlist使用してください。

IP アドレス/CIDR( クラスレス ドメイン間ルーティング )のリスト )の範囲に基づき、mongod はレプリカセットの他のノードおよび、シャーディングされたクラスターの一部である場合は、mongos インスタンスからの認証リクエストを検証します。mongodは、元 IP がリストに明示的に含まれているか、 または リスト内の CIDR 範囲に属していることを確認します。 IP アドレスが存在しない場合、サーバーはmongodまたはmongosを認証しません。

認証なしで開始された security.clusterIpSourceWhitelist は、mongod には影響しません。

security.clusterIpSourceWhitelist には、各IPv4/6 アドレスまたはクラスレス ドメイン間ルーティング(CIDR)の範囲を、YAML リストとして指定する必要があります。

security:
clusterIpSourceWhitelist:
- 192.0.2.0/24
- 127.0.0.1
- ::1

重要

クラスター コンポーネント間の正常な通信を確保するために、security.clusterIpSourceWhitelist に、IP アドレス、または各レプリカセットのノードもしくは配置内にある mongos の IP アドレスを含む CIDR 範囲が含まれていることを確認してください。

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.enableEncryptiontrueである必要があります。

注意

エンタープライズ機能

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

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

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 が存在する場合、mongodCN との一致は試行しません。

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 設定も指定する必要があります。

注意

macOS または Windows では、PEM キー ファイルの代わりにオペレーティング システムのセキュア ストアからの証明書を使用できます。 詳しくはsecurity.kmip.clientCertificateSelectorを参照してください。

注意

エンタープライズ機能

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

security.kmip.clientCertificatePassword

: string

クライアント証明書を復号化するためのパスワード(security.kmip.clientCertificateFile)で、MongoDB を KMIP サーバーに認証するために使用されます。証明書が暗号化されている場合にのみ、オプションを使用してください。

注意

エンタープライズ機能

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

security.kmip.clientCertificateSelector

: string

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

security.kmip.clientCertificateFilesecurity.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 サーバーへの安全なクライアント接続を検証するために使用されます。

注意

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.activateKeystrue で、KMIP サーバーに既存のキーがある場合、最初にキーをアクティブ化する必要があります。そうしないと、mongod ノードの起動に失敗します。

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

security.kmip.keyStatePollingSeconds

タイプ: int

デフォルト: 900 秒

バージョン 5.3 で追加。

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

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

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:
servers: <string>
bind:
method: <string>
saslMechanisms: <string>
queryUser: <string>
queryPassword: <string | array>
useOSDefaults: <boolean>
transportSecurity: <string>
timeoutMS: <int>
userToDNMapping: <string>
authz:
queryTemplate: <string>
validateLDAPServerConfig: <boolean>
security.ldap.servers

: string

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

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

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

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

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

security.ldap.bind.queryUser

: string

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

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

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

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

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

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

注意

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

security.ldap.bind.queryPassword

: string または array

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

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

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

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

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

注意

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

security.ldap.bind.useOSDefaults

タイプ: ブール値

デフォルト: false

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

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

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

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

security.ldap.bind.method

: string

デフォルト: simple

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

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

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

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

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

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

security.ldap.bind.saslMechanisms

: string

デフォルト: DIGEST-MD5

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

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

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

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

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

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

注意

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

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

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

security.ldap.transportSecurity

: string

デフォルト: tls

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

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

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

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

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

警告

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

security.ldap.timeoutMS

タイプ: int

デフォルト: 10000

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

mongodmongos で LDAP サーバーからリクエストへの応答があるまで待機する時間(ミリ秒単位)。

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

この設定は、稼働中の mongodmongos でも 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正規表現に一致する認証名を RFC 4515と RFC 4516に従ってエンコードされた 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 のいずれかを使用する必要があります。同じ文書で両方を指定することはできません

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

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

また、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 サーバーに対してユーザーを認証または承認しようとする際に、ユーザー名を変換しません。

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

security.ldap.authz.queryTemplate

: string

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

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

注意

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

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

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

クエリ 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 を使用してユーザーを認証することはできません。

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

注意

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

security.ldap.validateLDAPServerConfig

タイプ: ブール値

デフォルト: true

MongoDB Enterprise で利用可能です。

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

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

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

setParameter

MongoDB パラメータまたは自己管理型配置の MongoDB Server パラメータ で説明されているパラメータを設定します

パラメーターを YAML 構成ファイルに設定するには、次の形式を使用します。

setParameter:
<parameter1>: <value1>
<parameter2>: <value2>

たとえば、構成ファイルで enableLocalhostAuthBypass を指定するには、次のようにします。

setParameter:
enableLocalhostAuthBypass: false
setParameter.ldapUserCacheInvalidationInterval

タイプ: int

デフォルト: 30

自己管理型配置で LDAPmongod 認証 を使用する サーバーで使用します。

mongod が外部ユーザー キャッシュをフラッシュする間隔(秒単位)。mongod が外部ユーザー キャッシュをフラッシュした後、LDAP 承認ユーザーが次に操作を発行したときに、MongoDB は LDAP サーバーから認証データを再取得します。

指定する値を増やすと、mongod が LDAP サーバーと同期する間隔が長くなりますが、LDAP サーバーの負荷は軽減されます。逆に、指定する値を減らすと、 mongod が LDAP サーバーと同期する間隔は短くなりますが、LDAP サーバーの負荷が増大します。

setParameter:
ldapUserCacheInvalidationInterval: <int>

バージョン 4.4 での変更:

  • MongoDB では、 storage.indexBuildRetryオプションと対応する--noIndexBuildRetryコマンドライン オプションが削除されます。

  • MongoDB はstorage.wiredTiger.engineConfig.maxCacheOverflowFileSizeGBオプションを廃止します。 オプションは MongoDB 4.4 以降では効果がありません。

storage:
dbPath: <string>
journal:
enabled: <boolean>
commitIntervalMs: <num>
directoryPerDB: <boolean>
syncPeriodSecs: <int>
engine: <string>
wiredTiger:
engineConfig:
cacheSizeGB: <number>
journalCompressor: <string>
directoryForIndexes: <boolean>
maxCacheOverflowFileSizeGB: <number>
collectionConfig:
blockCompressor: <string>
indexConfig:
prefixCompression: <boolean>
inMemory:
engineConfig:
inMemorySizeGB: <number>
oplogMinRetentionHours: <double>
storage.dbPath

: string

デフォルト:

  • /data/db Linux と macOS の場合

  • \data\db Windows の場合

mongod インスタンスによってデータが保存されるディレクトリ。

storage.dbPath設定はmongodでのみ使用できます。

注意

構成ファイル

パッケージ マネージャーのインストールに含まれるデフォルトの mongod.conf 構成ファイルでは、 storage.dbPath に対し、プラットフォーム固有の次のデフォルト値が使用されます。

プラットフォーム
パッケージ マネージャー
default storage.dbPath
RHEL / CentOS と Amazon
yum
/var/lib/mongo
SUSE
zypper
/var/lib/mongo
Ubuntu と Debian
apt
/var/lib/mongodb
MacOS
brew
/usr/local/var/mongodb

Linux パッケージ初期化スクリプトでは、 storage.dbPathがデフォルトから変更されることは想定されていません。 Linux パッケージを使用してstorage.dbPathを変更する場合は、独自の初期化スクリプトを使用し、組み込みスクリプトを無効にする必要があります。

storage.journal.enabled

タイプ: ブール値

デフォルト: 64 ビット システムではtrue 、32 ビット システムではfalse

データファイルが有効で回復可能な状態に保たれるように、耐久性ジャーナルを有効または無効にします。 このオプションは、 storage.dbPath設定を指定した場合にのみ適用されます。 mongodはデフォルトでジャーナリングを有効にします。

storage.journal.enabled設定はmongodでのみ使用できます。

インメモリ ストレージエンジンを使用する mongod インスタンスでは使用できません。

WiredTiger ストレージ エンジンを使用するレプリカセット メンバーに対して、 --nojournalオプションまたはstorage.journal.enabled: falseを指定することはできません。

storage.journal.commitIntervalMs

タイプ: 数値

デフォルト: 100

mongod プロセスがジャーナリング操作間に許容する最大時間(ミリ秒単位)。値は 1 から 500 ミリ秒の範囲で指定できます。値を小さくすると、ジャーナリングの耐久性は向上しますが、ディスクのパフォーマンスは低下します。

WiredTiger では、デフォルトのジャーナル コミット間隔は100ミリ秒です。 さらに、 j:trueを含む、または意味する書込み (write) によって、ジャーナルが即座に同期されます。 同期の頻度に影響する詳細またはその他の条件については、「ジャーナリング プロセス 」を参照してください。

storage.journal.commitIntervalMs設定はmongodでのみ使用できます。

インメモリ ストレージエンジンを使用する mongod インスタンスでは使用できません。

storage.directoryPerDB

タイプ: ブール値

デフォルト: false

true の場合、MongoDB は各データベースのデータを保存するために個別のディレクトリを使用します。ディレクトリは、storage.dbPath ディレクトリの下にあり、各サブディレクトリ名はデータベース名に対応しています。

storage.directoryPerDB設定はmongodでのみ使用できます。

インメモリ ストレージエンジンを使用する mongod インスタンスでは使用できません。

MongoDB 5.0以降 、 storage.directoryPerDBが有効になっている場合にデータベース内の最終コレクションを削除すると(またはデータベース自体を削除すると)、そのデータベースの新しく空になったサブディレクトリが削除されます。

既存の配置の storage.directoryPerDB オプションを変更する方法は以下の通りです。

  • スタンドアロン インスタンスの場合:

    1. mongodump既存のmongod インスタンスで を使用してバックアップを生成します。

    2. mongod インスタンスを停止します。

    3. storage.directoryPerDB値を追加し、新しいデータディレクトリ構成する

    4. mongod インスタンスを再起動します。

    5. mongorestoreを使用して新しいデータディレクトリを作成します。

  • レプリカセットの場合:

    1. セカンダリ ノードを停止します。

    2. storage.directoryPerDB 値を追加し、そしてセカンダリ ノードに新しいデータ ディレクトリを設定します。

    3. そのセカンダリを再起動します。

    4. 最初の同期を使用して新しいデータディレクトリを作成します。

    5. 残りのセカンダリも同じ方法で更新します。

    6. プライマリを降格させ、降格させたノードを同様に更新します。

storage.syncPeriodSecs

タイプ: 数値

デフォルト: 60

MongoDB がデータをデータファイルにフラッシュするまでにかかる時間です。

この値は本番システムでは設定しないでください。ほとんどすべての状況において、デフォルト設定を使用するべきです。

mongodプロセスはデータをジャーナルにすばやく書込み、データファイルには遅延して書き込みます。 storage.syncPeriodSecsジャーナリングには影響しませんが、 storage.syncPeriodSecs0に設定されていると、ジャーナルにより利用可能なディスクスペースが最終的にすべて消費されます。

storage.syncPeriodSecs設定はmongodでのみ使用できます。

インメモリ ストレージエンジンを使用する mongod インスタンスでは使用できません。

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

storage.engine

デフォルト: wiredTiger

mongod データベースのストレージエンジン。使用可能な値は次のとおりです。

説明
wiredTiger
inMemory

自己管理型配置の インメモリ ストレージ エンジン を指定します。

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

storage.engine で指定されたもの以外のストレージエンジンによって生成されたデータファイルを含む storage.dbPath を使用して mongod を起動しようとすると、mongod は起動を拒否します。

storage.oplogMinRetentionHours

: double

oplog エントリーを保持する最小時間数を指定します。10 進数値は時間単位を表します。 たとえば、 1.5の値は 1 時間と 30 分を表します。

値は 0 以上である必要があります。値が 0 の場合、構成された最大 oplog サイズを維持するために、mongod は最も古いエントリから oplog を切り詰める必要があることを示します。

デフォルトは 0 です。

oplogMinRetentionHours で起動された mongod は、次の場合にのみ oplog エントリを削除します。

  • oplog が設定された最大 oplog サイズに達し、かつ

  • oplog エントリーは、ホスト システム クロックに基づいて構成された時間数よりも以前のものです。

oplog 保持期間が最小に設定されている場合、 mongod は次のように動作します。

  • oplog は、設定された時間数だけ oplog エントリーを保持できるように、制約なしに拡張されます。そのため、書き込みが大量で保存期間が長い組み合わせにした場合は、システム ディスク容量が減少または枯渇する可能性があります。

  • oplog が最大サイズを超えた場合、oplog が最大サイズに戻ったり最大サイズが小さく設定されたりしても、mongod はそのディスク領域を保持し続けることがあります。「oplog サイズを縮小してもディスク領域は即座に解放されない」を参照してください。

  • mongod は、oplog エントリの保持を強制するときに、システム ウォール クロックと oplog エントリ作成ウォール クロック タイムを比較します。クラスター コンポーネント間でのクロックのズレにより、予期しない oplog 保持動作が発生する可能性があります。クラスター ノード間のクロック同期の詳細については、「クロック同期」を参照してください。

mongod を開始した後に oplog の最小保持期間を変更するには、replSetResizeOplog を使用します。replSetResizeOplog の使用により、mongod プロセスを再起動せずに oplog のサイズを動的に変更できます。replSetResizeOplog を使用して行った変更を再起動後も保持するには、oplogMinRetentionHours の値を更新してください。

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

: float

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

値の範囲は 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 内部キャッシュ サイズがデフォルト値より大きくならないようにしてください。

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

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

注意

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

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

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

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

storage.wiredTiger.engineConfig.journalCompressor

デフォルト: snappy

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

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

storage.wiredTiger.engineConfig.directoryForIndexes

タイプ: ブール値

デフォルト: false

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

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

storage.wiredTiger.engineConfig.zstdCompressionLevel

タイプ: 整数

デフォルト: 6

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

値の範囲は 1 から 22 までです。

zstdCompressionLevel に指定する値が大きいほど、適用される圧縮率も高くなります。

blockCompressorzstdに設定されている場合にのみ適用されます。

MongoDB 5.0 以降で利用可能

storage.wiredTiger.collectionConfig.blockCompressor

デフォルト: snappy

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

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

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:
engineConfig:
inMemorySizeGB: <number>
storage.inMemory.engineConfig.inMemorySizeGB

: float

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

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

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

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

注意

エンタープライズ機能

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

operationProfiling:
mode: <string>
slowOpThresholdMs: <int>
slowOpSampleRate: <double>
filter: <string>
operationProfiling.mode

: string

デフォルト: off

どの操作をプロファイリングするべきかを指定します。次のプロファイラー レベルが利用可能です。

レベル
説明
off
プロファイラーはオフになっており、データは収集されません。これはデフォルトのプロファイラー レベルです。
slowOp
プロファイラーは、 slowms の値よりも時間がかかる操作のデータを収集します。
all
プロファイラーは、すべての操作のデータを収集します。

警告

プロファイリングにより、パフォーマンスが低下し、暗号化されていないクエリ データがシステム ログに公開されることがあります。プロファイラーを本番環境に設定して有効にする前に、パフォーマンスとセキュリティへの影響を慎重に検討してください。

パフォーマンス低下の可能性の詳細については、「プロファイラーのオーバーヘッド」を参照してください。

operationProfiling.slowOpThresholdMs

タイプ: 整数

デフォルト: 100

低速操作時間のしきい値(ミリ秒単位)。操作が実行される時間がこのしきい値より長いと、低速とみなされます。

logLevel 0に設定されている場合、MongoDBslowOpSampleRate で決定されたレートで 低速 操作を診断ログに記録します

logLevel 設定を引き上げると、レイテンシに関係なく、すべての操作が診断ログに表示されます。ただし、セカンダリによる低速の oplog エントリ メッセージのログ記録は除きます。セカンダリでは、低速の oplog エントリのみがログに記録されます。logLevel を引き上げても、すべての oplog エントリがログに記録されるわけではありません。

この設定は、mongod および mongos で使用できます。

  • mongod インスタンスの場合、この設定は診断ログと(有効になっている場合)プロファイラーの両方に影響します。

  • mongos インスタンスの場合、この設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos では利用できないためです。

operationProfiling.slowOpSampleRate

: double

デフォルト: 1.0

プロファイリングまたはログに記録する必要がある低速操作の割合。 operationProfiling.slowOpSampleRateは0から1までの値を受け入れます。

slowOpSampleRate 設定は、mongodmongos で使用できます。

  • mongod インスタンスの場合、この設定は診断ログと(有効になっている場合)プロファイラーの両方に影響します。

  • mongos インスタンスの場合、この設定は診断ログにのみ影響し、プロファイラーには影響しません。プロファイリングは mongos では使用できないためです。

operationProfiling.filter

タイプ: クエリ ドキュメントの文字列表現

どの操作をプロファイリングしてログ記録するかを制御するフィルター式。

filterが設定されている場合、 slowOpThresholdMsslowOpSampleRateはプロファイリングおよび低速クエリ ログ行には使用されません。

構成ファイルでプロファイル フィルターを設定すると、そのフィルターは配置にあるデータベースすべてに適用されます。特定のデータベースにプロファイル フィルターを設定するには、db.setProfilingLevel() メソッドを使用します。

このオプションでは、次の形式のクエリ ドキュメントの文字列表現を取ります。

{ <field1>: <expression1>, ... }

<field> は、プロファイラー出力の任意のフィールドになります。<expression>クエリ条件式です。

構成ファイルでプロファイリング フィルターを指定するには、以下の手順を実行する必要があります。

  • フィルター ドキュメントを一重引用符で囲み、ドキュメントを文字列として渡します。

  • YAML 形式の構成ファイルを使用します。

たとえば、次の filter では、2 秒以上かかる query 操作をログ記録するようプロファイラーに設定します。

operationProfiling:
mode: all
filter: '{ op: "query", millis: { $gt: 2000 } }'
replication:
oplogSizeMB: <int>
replSetName: <string>
enableMajorityReadConcern: <boolean>
replication.oplogSizeMB

タイプ: 整数

oplogの最大サイズ(メガバイト単位)。 oplogSizeMB設定では、ディスク上のサイズではなく、oplog の非圧縮サイズが構成されます。

注意

oplog は、majority commit point が削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。

mongod プロセスのデフォルト設定では、使用可能な最大容量に基づいて oplog が作成されます。64 ビット システムの場合、oplog は通常、使用可能なディスク容量の 5% を占めます。

mongod が初めて oplog を作成した後は、replication.oplogSizeMB オプションを変更しても oplog のサイズには影響しません。mongod の起動後に最大 oplog サイズを変更するには、replSetResizeOplog を使用します。replSetResizeOplog の使用により、mongod プロセスを再起動せずに oplog のサイズを動的に変更できます。replSetResizeOplog を使用して行った変更を再起動後も保持するには、oplogSizeMB の値を更新します。

詳細については、oplog サイズを参照してください。

replication.oplogSizeMB設定はmongodでのみ使用できます。

replication.replSetName

: string

mongod が属するレプリカセットの名前。レプリカセット内のすべてのホストは同じセット名を持つ必要があります。

アプリケーションが複数のレプリカセットに接続する場合、それぞれのセットには異なる名前を付ける必要があります。一部のドライバーは、レプリカセットの名前で接続をグループ化します。

replication.replSetName設定はmongodでのみ使用できます。

replication.replSetName は、storage.indexBuildRetry と組み合わせて使用することはできません。

WiredTiger storage engine の場合、 storage.journal.enabled: falsereplication.replSetNameと組み合わせて使用することはできません。

replication.enableMajorityReadConcern

デフォルト: true

"majority" 読み取り保証 (read concern) のサポートを設定します。

MongoDB 5.0以降では、enableMajorityReadConcern は変更されず、常に true に設定されます。--enableMajorityReadConcern オプションを使用して、過半数 の読み取り保証 (read concern) をサポートしないストレージエンジンを起動しようとすると失敗し、エラー メッセージが返されます。

MongoDB の以前のバージョンでは、enableMajorityReadConcern は構成可能でした。

警告

3 ノードのプライマリセカンダリアービタ(PSA)アーキテクチャを使用している場合は、次の点を考慮してください。

sharding:
clusterRole: <string>
archiveMovedChunks: <boolean>
sharding.clusterRole

: string

シャーディングされたクラスターでの mongod インスタンスのロール。この設定を次のいずれかに設定します。

説明
configsvr

このインスタンスをコンフィギュレーションサーバーとして起動します。インスタンスは、デフォルトではポート 27019 で起動します。

MongoDB インスタンスを clusterRole configsvr として構成する場合は、replSetName も指定する必要があります。

shardsvr

このインスタンスをシャードとして起動します。インスタンスは、デフォルトではポート 27018 で起動します。

MongoDB インスタンスを clusterRole shardsvr として構成する場合は、replSetName も指定する必要があります。

注意

sharding.clusterRole を設定するには、 mongod インスタンスがレプリケーションを使用して実行されている必要があります。インスタンスをレプリカセット ノードとして配置するには、replSetName 設定を使用してレプリカセットの名前を指定します。

sharding.clusterRole設定はmongodでのみ使用できます。

sharding.archiveMovedChunks

タイプ: ブール値

デフォルト: false

チャンクの移行中、シャードはシャードから移行されたドキュメントを保存しません。

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

auditLog:
destination: <string>
format: <string>
path: <string>
filter: <string>
auditLog.destination

: string

設定すると、auditLog.destination によって監査が有効になり、mongos または mongod がすべての監査イベントを送信する場所を指定します。

auditLog.destination には次のいずれかの値を指定できます。

説明
syslog

監査イベントを JSON 形式で syslog に出力します。Windows では使用できません。監査メッセージの syslog 重大度レベルは info で、機能レベルは user です。

syslog メッセージの制限により、監査メッセージが切り捨てられる可能性があります。監査システムは、切り捨てを検出することも、切り捨て時にエラーを発生させることもありません。

console
監査イベントを JSON 形式で stdout に出力します。
file
監査イベントを、auditLog.format で指定された形式で、 auditLog.pathで指定されたファイルに出力します

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

auditLog.filter

タイプ: ドキュメントの文字列表現

監査システムが記録する操作の種類を制限するフィルター。このオプションでは、次の形式のクエリ ドキュメントの文字列表現を取ります。

{ <field1>: <expression1>, ... }

<field>は、監査フィールド内の任意のフィールドparam ドキュメントで返されるフィールドを含む)にすることができます。<expression>クエリ条件式です。

監査フィルターを指定するには、フィルター ドキュメントを一重引用符で囲み、ドキュメントを文字列として渡します。

構成ファイルで監査フィルターを指定するには、YAML 形式の構成ファイルを使用する必要があります。

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

auditLog.format

: string

destinationfile であった場合の監査用出力ファイルの形式です。auditLog.format オプションには、次のいずれかの値を指定できます。

説明
JSON
監査イベントを JSON 形式で auditLog.path で指定されたファイルに出力します。
BSON
監査イベントを BSON バイナリ形式で、 auditLog.pathで指定されたファイルに出力します。

監査イベントを JSON 形式のファイルに出力すると、BSON 形式のファイルに出力するよりもサーバーのパフォーマンスが低下します。

注意

MongoDB EnterpriseおよびMongoDB Atlasでのみ利用可能です。

auditLog.path

: string

destination の値が file の場合の監査用の出力ファイル。auditLog.path オプションには、完全パス名または相対パス名のいずれかを指定できます。

auditLog.runtimeConfiguration

タイプ: ブール値

監査フィルターと AuditAuthorizationSuccess 変数のランタイム構成をノードで許可するかどうかを指定します。true の場合、ノードはオンライン監査フィルター マネジメントに参加できます。

注意

macOS 上の MongoDB Enterprise には、 SERVER-29352 により SNMP のサポートが含まれていませ ん 。

snmp:
disabled: <boolean>
subagent: <boolean>
master: <boolean>
snmp.disabled

タイプ: ブール値

デフォルト: false

mongodへの SNMP アクセスを無効にします。 オプションはsnmp.subagentおよびsnmp.masterと互換性がありません。

SNMP アクセスを無効にするには、 をtrueに設定します。

snmp.disabled設定はmongodでのみ使用できます。

snmp.subagent

タイプ: ブール値

snmp.subagenttrueの場合、SNMP はサブエージェントとして実行されます。 オプションは、 snmp.disabledtrueに設定することと互換性がありません。

snmp.subagent設定はmongodでのみ使用できます。

snmp.master

タイプ: ブール値

snmp.mastertrueの場合、SNMP はマスターとして実行されます。 オプションは、 snmp.disabledtrueに設定することと互換性がありません。

snmp.master設定はmongodでのみ使用できます。

replication:
localPingThresholdMs: <int>
sharding:
configDB: <string>
replication.localPingThresholdMs

タイプ: 整数

デフォルト: 15

mongos でクライアントからの読み取り操作を渡すセカンダリ レプリカセット ノードの決定に使用される ping 時間(ミリ秒単位)。デフォルト値の 15 は、すべてのクライアントドライバーのデフォルト値に対応します。

mongosセカンダリ ノードへの読み取りの許可のリクエストを受信すると、 mongos は次のようになります。

  • ping 時間が最も短いセットのノードを検索します。

  • レプリカセット ノードのリストを作成します。これはセットの最も近い適切なノードから、ping 時間 15 ミリ秒以内です。

    replication.localPingThresholdMs オプションに値を指定すると、mongos は、この値で許容されるレイテンシ内のレプリカ ノードのリストを構築します。

  • このリストからランダムに読み取るノードを選択します。

replication.localPingThresholdMs 設定によって比較されるノードの ping 時間は、最大 10 秒間隔で計算した直近の ping 時間の移動平均です。その結果、 mongos が平均を再計算するまでに、一部のクエリは閾値を超えるノードに到達する可能性があります。

詳細については、 読み込み設定 (read preference) ドキュメントの「レプリカセットの読み込み設定」セクションを参照してください。

sharding.configDB

: string

シャーディングされたクラスター構成サーバー

シャーディングされたクラスターのコンフィギュレーションサーバーはレプリカセットとして配置されます。レプリカセット コンフィギュレーションサーバーでは、WiredTiger ストレージエンジンを実行する必要があります。

コンフィギュレーションサーバー レプリカセット名と、コンフィギュレーションサーバー レプリカセットの少なくとも 1 つのノードのホスト名とポートを指定します。

sharding:
configDB: <configReplSetName>/cfg1.example.net:27019, cfg2.example.net:27019,...

シャーディングされたクラスターの mongos インスタンスで指定するコンフィギュレーションサーバー レプリカセット名は同じにする必要がありますが、レプリカセットのノードのホスト名とポートにはそれぞれ異なった指定ができます。

processManagement:
windowsService:
serviceName: <string>
displayName: <string>
description: <string>
serviceUser: <string>
servicePassword: <string>
processManagement.windowsService.serviceName

: string

デフォルト: MongoDB

Windows サービスとして実行中の mongos または mongod のサービス名。この名前を net start <name> 操作およびnet stop <name> 操作で使用します。

processManagement.windowsService.serviceNameは、 --installまたは--removeオプションのいずれかと組み合わせて使用する必要があります。

processManagement.windowsService.displayName

: string

デフォルト: MongoDB

サービス管理アプリケーションで表示される MongoDB の名前。

processManagement.windowsService.description

: string

デフォルト: MongoDB Server

mongos または mongod のサービスの説明を実行します。

processManagement.windowsService.description--install オプションと組み合わせて使用する必要があります。

説明にスペースを含む場合は、その説明を引用符で囲む必要があります。

processManagement.windowsService.serviceUser

: string

特定のユーザーのコンテキストでの mongos サービスまたは mongodサービス。このユーザーには「サービスとしてログオンする」権限が必要です。

processManagement.windowsService.serviceUser--install オプションと組み合わせて使用する必要があります。

processManagement.windowsService.servicePassword

: string

processManagement.windowsService.serviceUser オプションで実行する場合の mongos または mongod<user> のパスワード。

processManagement.windowsService.servicePassword--install オプションと組み合わせて使用する必要があります。

MongoDB で非推奨の MMAPv1 ストレージエンジンと MMAPv1 固有の構成オプションが削除されました。

削除された構成ファイルの設定
削除されたコマンドライン オプション
storage.mmapv1.journal.commitIntervalMs
storage.mmapv1.journal.debugFlags
mongod --journalOptions
storage.mmapv1.nsSize
mongod --nssize
storage.mmapv1.preallocDataFiles
mongod --noprealloc
storage.mmapv1.quota.enforced
mongod --quota
storage.mmapv1.quota.maxFilesPerDB
mongod --quotaFiles
storage.mmapv1.smallFiles
mongod --smallfiles
storage.repairPath
mongod --repairpath
replication.secondaryIndexPrefetch
mongod --replIndexPrefetch

MongoDBの以前のバージョンについては、レガシードキュメントを参照してください。

戻る

mongod プロセスの管理