Docs Menu
Docs Home
/
MongoDBマニュアル
/
自己管理型配置
/
インストール
/
MongoDB パッケージ コンポーネント

mongod

項目一覧

  • Synopsis
  • 互換性
  • Considerations
  • オプション
  • 中心的オプション
  • LDAP 認証または承認のオプション
  • ストレージのオプション
  • WiredTiger のオプション
  • レプリケーションのオプション
  • シャーディングされたクラスターのオプション
  • TLS のオプション
  • プロファイラーのオプション
  • 監査のオプション
  • inMemory のオプション
  • 暗号化のキー管理のオプション

Synopsis

mongod は MongoDB システムのプライマリ デーモン プロセスです。データ リクエストの処理、データ アクセスの管理、バックグラウンドの管理操作を実行します。

このドキュメントでは、 mongodの全コマンド ライン オプションに関する全体像を説明します。 これらのコマンドライン オプションは、主にテストに役立ちます。一般的な操作の場合、データベースの動作を制御するには構成ファイル オプションを使用します。

Tip

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

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

注意

MongoDB は、TLS 1.1 + が利用可能なシステムで TLS 1.0暗号化のサポートを無効にします。

互換性

次の環境でホストされている配置では mongod が使用されます。

  • MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです

注意

MongoDB Atlas では、すべての MongoDB Atlas 配置の mongod を管理します。

  • MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン

  • MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン

Considerations

  • mongodは、デプロイに関するトラブルシューティングを行う MongoDB エンジニアを支援するために、フルタイム診断データ取得メカニズムを備えています。 このスレッドが失敗すると、元のプロセスが終了します。 特に一般的な障害を回避するには、プロセスを実行しているユーザーに FTDC diagnostic.dataディレクトリを作成する権限があることを確認します。 mongodの場合、このディレクトリはstorage.dbPath内にあります。 mongosの場合は、 systemLog.pathと同じ階層にあります。

オプション

バージョン 6.1 での変更:

  • MongoDB では常にジャーナリングが有効です。その結果、MongoDB は、storage.journal.enabled オプション、および対応する --journal と --nojournal のコマンドライン オプションを削除します。

バージョン 5.2 での変更:

  • MongoDB では --cpu コマンドライン オプションが削除されます。

バージョン 5.0 での変更:

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

中心的オプション

--help, -h

mongod のオプションと使用に関する情報を返します。

--version

mongod のリリース番号を返します。

--config <filename>, -f <filename>

ランタイム設定オプション用の構成ファイルを指定します。 構成ファイルは、 mongodのランタイム構成に推奨される方法です。 オプションは、コマンドラインの設定オプションと同じです。 詳細については、 自己管理型構成ファイルのオプションを参照してください。

構成ファイルでは ASCII エンコードを使用するようにしてください。mongod インスタンスでは、UTF-8 など、非 ASCII エンコードの構成ファイルをサポートしていません。

--configExpand <none|rest|exec>

デフォルト: なし

構成ファイルで展開ディレクティブを使用できるようにします。展開ディレクティブを使用すると、構成ファイル オプションに外部ソースの値を設定できます。

--configExpand では、次の展開ディレクティブをサポートします。

値
説明

none

デフォルト。mongod は展開ディレクティブを展開しません。構成ファイルの設定で展開ディレクティブが使用されている場合、mongodは起動に失敗します。

rest

mongod は、構成ファイルを解析するときに __rest 展開ディレクティブを展開します。

exec

mongod は、構成ファイルを解析するときに __exec 展開ディレクティブを展開します。

複数の展開ディレクティブをカンマ区切りのリスト（例: rest, exec ）として指定できます。 構成ファイルに--configExpandに指定されていない展開ディレクティブが含まれている場合、 mongodはエラーを返し、終了します。

展開ディレクティブの詳細については、構成ファイル用「自己管理型配置の外部ソースの構成ファイルの値」を参照してください。

--verbose, -v

標準出力またはログ ファイルに返される内部レポートの量を増やします。-v の形式でオプションを複数回含めることで、冗長度を高められます（例: -vvvvv）。

注意

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

--quiet

出力量を制限する quiet モードで mongod を実行します。

このオプションにより次の項目が抑制されます。

  • データベース コマンドからの出力

  • レプリケーション アクティビティ

  • 接続を受け付けたイベント

  • 接続を終了したイベント

--port <port>

デフォルト:

  • 27017: mongod がシャード ノードまたはコンフィギュレーションサーバー ノードでない場合

  • 27018 mongod が shard member の場合、

  • 27019 mongod が config server member の場合、

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

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

--bind_ip <hostnames|ipaddresses|Unix domain socket paths>

デフォルト: localhost

mongod がクライアント接続を待ち受けるホスト名、IP アドレス、Unix ドメイン ソケットの完全なパスのすべてまたはいずれか。mongod はどのインターフェースにも接続できます。複数のアドレスにバインドするには、値をカンマで区切ったリストを入力します。

例

localhost,/tmp/mongod.sock

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

例

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

注意

IPv 6アドレス、またはIPv 6アドレスに解決するホスト名を--bind_ipに指定する場合、IPv 6のサポートを有効にするには、 --ipv6でmongodを開始する必要があります。 --bind_ipに IPv 6アドレスを指定しても、IPv 6のサポートは有効になりません。

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」と入力します。

すべての IPv 4と IPv 6アドレスにバインドするには、 ::,0.0.0.0またはアスタリスク"*"を入力します（ファイル名パターン展開を避けるためには、アスタリスクを引用符で囲みます）。 または、 net.bindIpAll設定を使用します。

注意

  • --bind_ip と --bind_ip_all は相互に排他的です。両方のオプションを指定すると、mongod はエラーをスローして終了します。

  • コマンドライン オプション --bind では、構成ファイルの設定 net.bindIp が上書きされます。

--bind_ip_all

指定されている場合、 mongodインスタンスはすべての IPv 4アドレス（つまり 0.0.0.0 ）。 mongodが--ipv6で開始する場合、 --bind_ip_allはすべての IPv 6アドレス（つまり :: ）。

mongod では、 --ipv6で開始された場合のみ IPv 6がサポートされます。 --bind_ip_allのみを指定しても、IPv 6のサポートは有効になりません。

警告

インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。

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

あるいは、 --bind_ipオプションを::,0.0.0.0またはアスタリスク"*"に設定することもできます（ファイル名パターン展開を避けるために、アスタリスクは引用符で囲みます）。

注意

--bind_ip と --bind_ip_all は相互に排他的です。つまり、どちらか一方を指定できますが、両方を指定することはできません。

--clusterIpSourceAllowlist <string>

バージョン 5.0 で追加

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

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

--clusterIpSourceAllowlistは複数のカンマ区切りの IPv4 /6 アドレスまたはクラスレス ドメイン間ルーティング（ CIDR ）の範囲：

mongod --clusterIpSourceAllowlist 192.0.2.0/24,127.0.0.1,::1

重要

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

--clusterIpSourceWhitelist <string>

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

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

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

--clusterIpSourceWhitelistは複数のカンマ区切りの IPv4 /6 アドレスまたはクラスレス ドメイン間ルーティング（ CIDR ）の範囲：

mongod --clusterIpSourceWhitelist 192.0.2.0/24,127.0.0.1,::1

重要

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

--ipv6

IPv6 のサポートを有効にします。mongod ではデフォルトで IPv6 のサポートは無効です。

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

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

  • --bind_ip_all を true に設定します。

--listenBacklog <number>

デフォルト: ターゲット システム SOMAXCONN 定数

listen キューに存在できる接続の最大数です。

警告

このパラメーターを使用する前に、制限事項と構成要件を理解するためにローカル システムのドキュメントを確認してください。

重要

未定義の動作を防ぐには、このパラメーターに 1 とローカルシステムの SOMAXCONN 定数の間の値を指定します。

listenBacklog パラメーターのデフォルト値は、コンパイル時にターゲット システムの SOMAXCONN 定数に設定されます。SOMAXCONN は、listen システム コールの backlog パラメーターに記載されている有効な最大値です。

SOMAXCONN を記号的に解釈するシステムもあれば、数値的に解釈するシステムもあります。実際に適用されるlisten バックログは、SOMAXCONN 定数または --listenBacklog への引数の数値的解釈とは異なる場合があります。また、Linux の net.core.somaxconn などのシステム設定によって制約される場合もあります。

listenBacklog パラメーターにローカルシステムの SOMAXCONN 定数を超える値を渡すと、標準では未定義の動作になります。値が大きいと、自動的に整数に切り捨てられる、無視される、予期しないリソースが消費されるなどの悪影響が生じる可能性があります。

接続スパイクが発生するワークロードを含むシステムでは、ローカル システムが backlog パラメーターに SOMAXCONN 定数よりも高い値を指定できることが経験的にわかっています。listenBacklog パラメーターを高い値に設定すると、強制的にバックオフ状態になる接続の数が減るため、クライアントが確認する操作のレイテンシが短くなる可能性があります。

--maxConns <number>

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

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

--logpath <path>

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

デフォルトでは、MongoDB は既存のログファイルを上書きせず、移動します。ログファイルに追加するには、--logappend オプションを設定します。

--syslog

すべてのログ出力を標準出力やログファイル（--logpath）ではなく、ホストの syslog システムに送信します。

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

警告

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

MongoDB は、 syslogへのログ メッセージにコンポーネントを含めます。

...  ACCESS   [repl writer worker 5] Unsupported modification to roles collection ...
--syslogFacility <string>

デフォルト: user

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

--logappend

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

--logRotate <string>

デフォルト: rename

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

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

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

    reopenを指定する場合は、 --logappendも使用する必要があります。

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

注意

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

--traceExceptions

内部診断のみに使用します。

--pidfilepath <path>

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

注意

Linux

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

注意

MacOS

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

--keyFile <file>

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

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

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

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

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

--setParameter <options>

「 自己管理型配置の MongoDB Server パラメーター 」で説明されている MongoDB パラメーターの 1 つを指定します。 複数のsetParameterフィールドを指定できます。

--nounixsocket

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

次のいずれかが当てはまらない限り、mongod プロセスは常に UNIX ソケットを listen します。

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

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

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

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

--unixSocketPrefix <path>

デフォルト: /tmp

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

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

--filePermissions <path>

デフォルト: 0700

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

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

--fork

mongod プロセスをバックグラウンドで実行するデーモン モードを有効にします。--fork オプションは Windows ではサポートされていません。

デフォルトでは、 mongodはデーモンとして実行されません。 --forkまたは、 upstartやsystemdなど、デーモン化を取り扱う制御プロセスを使用して、 mongodをデーモンとして実行します。

--forkを使用するには、次のいずれかを使用してmongodのログ出力を構成します。

--auth

データベースのリソースと操作に対するユーザーのアクセスを制御する権限を有効にします。認証が有効になっている場合、MongoDB はクライアントのアクセス権を決定するために、すべてのクライアントに対して最初に認証を要求します。

ユーザーを構成するには、mongosh クライアントを使用します。ユーザーが存在しない場合、最初のユーザーを作成するまでローカルホスト インターフェースがデータベースにアクセスできます。

詳細については、「セキュリティ」を参照してください。

--noauth

認証を無効にします。現在はデフォルトです。将来の互換性と明確さのために存在します。

--transitionToAuth

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

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

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

注意

--transitionToAuth を使用せずに内部認証で動作する mongod では、 クライアントによる接続にユーザー アクセス制御を使用する必要があります。--transitionToAuth なしで mongod を再起動する前に、適切なユーザーを使用して mongod に接続するよう、クライアントを更新します。

--sysinfo

診断システム情報を返し、終了します。この情報には、ページ サイズ、物理ページ数、使用可能な物理ページ数が含まれます。

--noscripting

スクリプト エンジンを無効にします。

--notablescan

コレクションスキャンが必要な操作を禁止します。詳細については notablescan を参照してください。

--shutdown

--shutdownオプションにより、mongod プロセスが正常かつ安全に終了します。このオプションを使用して mongod を呼び出す場合は、 --dbpath オプションを直接、または構成ファイルと--config オプションを使用して設定する必要があります。

--shutdown オプションは Linux システムでのみ使用できます。

シャットダウンするその他の方法については、「mongod プロセスの停止」も参照してください。

--redactClientLogData

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

--redactClientLogDataで実行されているmongodは、ログに記録される前に特定のログ イベントに付随するすべてのメッセージをリダクションします。 これにより、データベースに保存されている機密性が高い可能性のあるデータをmongodが診断ログに書き込むことを防止します。 エラー コードや操作 コード、行番号、ソース ファイル名などのメタデータは、引き続きログに表示されます。

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

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

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

実行中のmongodでこの設定を構成するには、setParameter を redactClientLogData パラメーターとともに使用します。

--networkMessageCompressors <string>

Default: snappy,zstd,zlib

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

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

  • mongosh

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

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

注意

mongodインスタンスとmongosインスタンスの両方がデフォルトでsnappy,zstd,zlibコンプレッサーに設定されます。

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

重要

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

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

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

--timeZoneInfo <path>

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

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

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

wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip
unzip timezonedb-latest.zip
mongod --timeZoneInfo timezonedb-2017b/

警告

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

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

Tip

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

processManagement.timeZoneInfo.

--outputConfig

YAML 形式のmongodインスタンスの構成オプションをstdoutに出力し、 mongodインスタンスを終了します。 自己管理型配置に外部ソースの構成ファイルの値 を使用する構成オプションの場合、 --outputConfigはそれらのオプションの解決値を返します。

警告

これには、以前に外部ソースを通して難読化された、設定されたパスワードや秘密が含まれ場合があります。

使用例については、以下を参照してください。

LDAP 認証または承認のオプション

注意

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

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

--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>

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

mongod がユーザーを認証したり、特定のデータベースでユーザーが実行できるアクションを決定したりするための LDAP サーバーです。指定した LDAP サーバーにレプリケーションされたインスタンスがある場合は、各複製サーバーのホストとポートをカンマ区切りのリストで指定できます。

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

この設定は、setParameter を使用して実行中の mongod で設定できます。

設定されていない場合、mongod は LDAP 認証または承認を使用できません。

--ldapValidateLDAPServerConfig <boolean>

MongoDB Enterprise で利用可能です。

mongodインスタンスが起動時にLDAP server(s)の可用性を確認するかどうかを決定するフラグです。

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

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

--ldapQueryUser <string>

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

LDAP サーバーに接続するとき、または LDAP サーバーでクエリを実行するときに、mongod がバインドする ID です。

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

--ldapQueryPassword では--ldapQueryUserを使用する必要があります

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

この設定は、setParameter を使用して実行中の mongod で設定できます。

注意

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

--ldapQueryPassword <string | array>

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

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

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

この設定は実行中のmongodでsetParameterを使用して構成できます。

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

注意

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

--ldapBindWithOSDefaults <bool>

デフォルト: false

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

LDAP サーバーに接続するときに、mongod が Windows のログイン資格情報を使用して認証またはバインドできるようにします。

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

--ldapBindWithOSDefaults--ldapQueryUserと を置き換えるには、--ldapQueryPassword を使用します。

--ldapBindMethod <string>

デフォルト: simple

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

mongodが LDAP サーバーへの認証に使用する方法。 LDAP サーバーに接続するには、 --ldapQueryUserと--ldapQueryPasswordとともに使用します。

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

  • simple - mongod は簡易認証を使用する

  • sasl - mongod は認証に SASL プロトコルを使用する

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

--ldapBindSaslMechanisms <string>

デフォルト: DIGEST-MD5

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

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

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

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

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

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

注意

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

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

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

--ldapTransportSecurity <string>

デフォルト: tls

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

デフォルトでは、mongod はLDAP サーバーへの TLS/SSL で保護された接続を作成します。

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

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

mongod と LDAP サーバー間の TLS/SSL を無効にするには、--ldapTransportSecurity を none に設定します。

警告

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

--ldapTimeoutMS <int>

デフォルト: 10000

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

LDAP サーバーが要求に応答するまで mongod が待機する時間（ミリ秒）です。

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

この設定は、setParameter を使用して実行中の mongod で設定できます。

--ldapRetryCount <int>

バージョン 6.1 で追加。

デフォルト: 0

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

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

--ldapUserToDNMapping <string>

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

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

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

  • DN を必要とする LDAP authorization query template を使用する

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

--ldapUserToDNMapping は、順序付けられたドキュメントの配列を表す引用符で囲まれた 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は LDAP サーバーに対してクエリを実行し、認証されたユーザーの LDAP DN を検索します。 mongodでは変換が成功するために返された結果が 1 つだけ必要になる場合があります。または、 mongodはこの変換をスキップします。

"ou=engineering,dc=example, dc=com??one?(user={0})"

注意

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

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

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

指定されたドキュメントが指定された認証名と一致しない場合、mongod はドキュメントのリストをさらにたどって新たに一致するものを探します。どのドキュメントにも一致するものが見つからない場合、またはドキュメントで説明されている変換が失敗した場合、mongod はエラーを返します。

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

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

例

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

重要

配列を文字列として --ldapUserToDNMapping に渡す必要があります。

"[
   {
      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 は LDAP サーバーに対してこのクエリを実行し、結果として "cn=bob,ou=dba,dc=example,dc=com" を返します。

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

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

--ldapAuthzQueryTemplate <string>

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

RFC 4515 と RFC 4516 に準拠して形式された相対的 LDAP クエリ URL を mongod によって実行することでで、認証されたユーザが所属する LDAP グループを取得します。クエリは、--ldapServers で指定されたホストに対して相対的です。

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

置換トークン
説明

{USER}

認証されたユーザー名を置き換えるか、 が指定されている場合はtransformed username mappingユーザー名を置き換えます。

{PROVIDED_USER}

認証または LDAP transformation の前に、指定されたユーザー名を置き換えます。

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

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

クエリに属性が含まれている場合、mongod はクエリが検索するのはこのエンティティがノードである DN であると想定します。

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

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

例

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

"{USER}?memberOf?base"

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

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

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

注意

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

ストレージのオプション

--storageEngine string

デフォルト: wiredTiger

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

値
説明

wiredTiger

WiredTiger ストレージ エンジン を指定します。

inMemory

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

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

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

--dbpath <path>

デフォルト: Linux と macOS では /data/db、Windows では \data\db

mongod インスタンスがデータをストアするディレクトリです。

MongoDB のパッケージ マネージャー インストールに含まれるデフォルトの構成ファイルを使用する場合、対応する storage.dbPath 設定では別のデフォルトが使用されます。

--dbpath内のファイルは、 --storageEngineで指定されたストレージ エンジンに対応している必要があります。 データファイルが--storageEngineに対応していない場合、 mongodは起動しません。

--directoryperdb

各データベースのデータを保存するには、個別のディレクトリを使用します。 ディレクトリは--dbpathディレクトリの下にあり、各サブディレクトリ名はデータベース名に対応しています。

インメモリ storage engine を使用する mongod インスタンスでは利用できません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--syncdelay <value>

デフォルト: 60

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

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

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

インメモリ storage engine を使用する mongod インスタンスでは利用できません。

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

--upgrade

必要に応じて、--dbpath で指定されたファイルのオンディスク データ 形式を最新バージョンにアップグレードします。

このオプションは、データファイルが古い形式の場合の mongod の操作にのみ影響します。

ほとんどの場合、この値を設定しない方が、アップグレードプロセスを最大限にコントロールできます。アップグレード プロセスの詳細については、MongoDB リリースノートを参照してください。

--repair

mongod インスタンスのすべてのデータベースに対して修復ルーチンを実行します。

MongoDB 5.0 以降:

  • 修復操作では、コレクションを検証して不整合を見つけ、可能であれば修正するため、インデックスの再構築を回避できます。

  • コレクションのデータファイルがサルベージされた場合、または検証ステップで修正できない不整合がコレクションにある場合は、すべてのインデックスが再構築されます。

Tip

ジャーナリングを有効にして実行している場合、サーバーはジャーナル ファイルを使用してデータファイルを自動的にクリーンな状態に復元できるため、修復を実行する必要はほとんどありません。ただし、ディスク レベルのデータ破損から回復する必要がある場合は、修復を実行する必要があるかもしれません。

警告

  • 他に選択肢がない場合にのみ、 mongod --repairを使用してください。 この操作により、修復プロセス中に破損したデータは削除され、保存はされません。

  • レプリカセット ノードに対して--repairを実行しないでください。

  • --repairを使用する前に、 dbpathディレクトリのバックアップ コピーを作成してください。

  • 何らかの理由で修復が完了しなかった場合は、--repair オプションを使用してインスタンスを再起動する必要があります。

--journalCommitInterval <value>

デフォルト: 100

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

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

インメモリ storage engine を使用する mongod インスタンスでは利用できません。

WiredTiger のオプション

--wiredTigerCacheSizeGB <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 キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

注意

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

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

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

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

--wiredTigerJournalCompressor <compressor>

デフォルト: snappy

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

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

--wiredTigerDirectoryForIndexes

--wiredTigerDirectoryForIndexesを使用してmongodを起動すると、 mongodはインデックスとコレクションをデータの下の個別のサブディレクトリに保存します（つまり、 --dbpath ）ディレクトリ。 具体的には、 mongodはインデックスをindexという名前のサブディレクトリに保存し、コレクション データをcollectionという名前のサブディレクトリに保存します。

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

--wiredTigerCollectionBlockCompressor <compressor>

デフォルト: snappy

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

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

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

--wiredTigerIndexPrefixCompression <boolean>

デフォルト: true

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

true--wiredTigerIndexPrefixCompressionインデックス データの 接頭辞圧縮 を有効にするにはfalse に指定し、インデックス データの接頭辞圧縮を無効にするには を指定します。

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

レプリケーションのオプション

--replSet <setname>

レプリケーションを構成します。このセットの引数としてレプリカセット名を指定します。レプリカセット内のすべてのホストは同じセット名を持つ必要があります。

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

--oplogSize <value>

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

注意

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

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

mongod により oplog が初めて作成された後は、--oplogSize オプションを変更しても oplog のサイズには影響しません。mongod を開始した後に oplog の最小保持期間を変更するには、 replSetResizeOplog を使用します。replSetResizeOplog を使用すると、mongod プロセスを再起動せずに oplog のサイズを動的に変更できます。replSetResizeOplog を使用して行った変更を再起動後も保持するには、--oplogSize の値をアップデートします。

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

--oplogMinRetentionHours <value>

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 の値をアップデートします。

--enableMajorityReadConcern

デフォルト: true

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

MongoDB 5.0 以降、--enableMajorityReadConcernは変更できず、常に true に設定されます。MongoDB の以前のバージョンでは、--enableMajorityReadConcern は構成可能でした。

警告

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

シャーディングされたクラスターのオプション

--configsvr

コンフィギュレーションサーバーを起動する場合は必須です。

このmongodインスタンスがシャーディングされたクラスターのコンフィギュレーションサーバーとして機能することを宣言します。 このオプションで実行すると、クライアント（ 他のクラスター コンポーネント）では、 configとadmin以外のデータベースにデータを書込むことができません。 このオプションを使用したmongodのデフォルト ポートは27019であり、デフォルトの--dbpathディレクトリは/data/configdbです（指定されていない場合）。

重要

--configsvr を使用して MongoDB サーバーを起動する場合は、--replSet も指定する必要があります。

非推奨のミラー化された mongod インスタンスをコンフィギュレーションサーバー（SCCC）として使用することはサポートされなくなりました。

レプリカセット コンフィギュレーションサーバー（CSRS）は、WiredTiger ストレージ エンジン を実行する必要があります。

--configsvr オプションはローカル oplog を作成します。

--configsvrでは--shardsvr オプションは使用 しない でください。コンフィギュレーションサーバーはシャードサーバーにすることはできません。

--configsvrskipShardingConfigurationChecksパラメーターとともに使用しないでください。つまり、メンテナンス操作のためにmongodをスタンドアロンとして一時的に起動する場合は、パラメーターskipShardingConfigurationChecksを含め、 --configsvrを除外します。 メンテナンスが完了したら、 skipShardingConfigurationChecksパラメータを削除し、 --configsvrで再起動します。

--shardsvr

シャード サーバーを起動する場合に必要です。

この mongod インスタンスをシャーディングされたクラスター内のシャードとして設定します。これらのインスタンスのデフォルト ポートは 27018 です。

重要

--shardsvr を使用して MongoDB サーバーを起動する場合は、--replSet も指定する必要があります。

--shardsvrskipShardingConfigurationChecksパラメーターとともに使用しないでください。つまり、メンテナンス操作のためにmongodをスタンドアロンとして一時的に起動する場合は、パラメーターskipShardingConfigurationChecksを含め、 --shardsvrを除外します。 メンテナンスが完了したら、 skipShardingConfigurationChecksパラメータを削除し、 --shardsvrで再起動します。

TLS のオプション

Tip

次を参照してください。

MongoDB のサポートの完全なドキュメントについては、 TLS/SSL 用に mongod と mongos を設定してください。

--tlsMode <mode>

すべてのネットワーク接続に使用される TLS を有効にします。--tlsMode オプションの引数には、以下のいずれかを指定できます。

値
説明

disabled

サーバーは TLS を使用しません。

allowTLS

サーバー間の接続では TLS は使用されません。着信接続の場合、サーバーでは TLS と非 TLS のいずれも受け付けます。

preferTLS

サーバー間の接続では TLS が使用されます。着信接続の場合、サーバーでは TLS と非 TLS のいずれも受け付けます。

requireTLS

サーバーは TLS 暗号化接続のみを使用し、受け入れます。

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

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

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

--tlsCertificateKeyFile <filename>

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

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

  • Linux/BSD では、TLS/SSL が有効な場合は--tlsCertificateKeyFileを指定する必要があります。

  • Windows または macOS では、TLS/SSL が有効になっている場合に--tlsCertificateKeyFileまたは--tlsCertificateSelectorのいずれかを指定する必要があります。

    重要

    MongoDB では、Windows に限り、暗号化 PEM ファイルをサポートしません。暗号化された PEM ファイルに遭遇すると、mongod は起動に失敗します。Windows 上で TLS 用の証明書を安全に保存し、使用するには、--tlsCertificateSelectorを使用します。

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

--tlsCertificateKeyFilePassword <value>

証明書鍵ファイル（--tlsCertificateKeyFile）を復号化するためのパスワードを指定します。--tlsCertificateKeyFilePassword オプションは、証明書鍵ファイルが暗号化されている場合にのみ使用します。いずれの場合も、mongod はすべてのログおよびレポート出力からパスワードを削除します。

  • Linux/BSD で --tlsCertificateKeyFilePassword オプションを指定しない場合、PEM ファイル内の秘密キーが暗号化されていると、MongoDB はパスフレーズの入力を要求します。 「TLS/SSL 証明書のパスフレーズ」を参照してください。

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

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

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

--clusterAuthMode <option>

デフォルト: 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 証明書ストアを使用するようになります。

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

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

--tlsClusterFile <filename>

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

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

--tlsClusterFileが内部クラスター認証用の.pemファイルまたは代替の--tlsClusterCertificateSelectorを指定しない場合、クラスターは--tlsCertificateKeyFileオプションで指定された.pemファイルまたは--tlsCertificateSelectorによって返された証明書を使用します。

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

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

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

重要

MongoDB では、Windows に限り、暗号化 PEM ファイルをサポートしません。 暗号化された PEM ファイルに遭遇すると、 mongodは起動に失敗します。 Windows のメンバーシップ認証で使用する証明書を安全に保存してアクセスするには、 --tlsClusterCertificateSelectorを使用します。

--tlsCertificateSelector <parameter>=<value>

注意

--tlsCertificateKeyFile の代替として、Windows および macOS で利用可能です。

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

--tlsCertificateKeyFileオプションと--tlsCertificateSelectorオプションは相互に排他的です。 指定できるのは 1 つだけです。

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

プロパティ
値の型
説明

subject

ASCII 文字列

証明書のサブジェクト名またはコモンネーム

thumbprint

hex 文字列

SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。

thumbprint は、fingerprint と呼ばれることもあります。

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

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

たとえば、TLS/SSL 証明書が単一のルート CA 証明書で署名されている場合、セキュリティで保護された証明書ストアにはそのルート CA 証明書が含まれている必要があります。TLS/SSL 証明書が中間 CA 証明書で署名されている場合、セキュリティで保護された証明書ストアには中間 CA 証明書とルート CA 証明書が含まれている必要があります。

注意

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

--tlsClusterCertificateSelector <parameter>=<value>

注意

--tlsClusterFile の代替として、Windows および macOS で利用可能です。

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

--tlsClusterFile と --tlsClusterCertificateSelector のオプションは相互に排他的です。指定できるのは 1 つだけです。

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

プロパティ
値の型
説明

subject

ASCII 文字列

証明書のサブジェクト名またはコモンネーム

thumbprint

hex 文字列

SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。

thumbprint は、fingerprint と呼ばれることもあります。

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

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

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

--tlsClusterPassword <value>

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

  • Linux/BSD で --tlsClusterPassword オプションを指定しない場合、x.509 ファイル内の秘密キーが暗号化されていると、MongoDB はパスフレーズの入力を要求します。「TLS/SSL 証明書のパスフレーズ」を参照してください。

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

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

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

--tlsCAFile <filename>

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

重要

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

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

Windows と macOS のみ
--tlsCertificateSelectorおよび/または--tlsClusterCertificateSelector を使用する場合、ルート CA 証明書と中間 CA 証明書の指定には --tlsCAFile を使用しません。--tlsCertificateSelectorおよび/または--tlsClusterCertificateSelector証明書の完全な信頼チェーンの検証に必要なすべての CA 証明書は、安全な証明書ストアに保存します。

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

--tlsClusterCAFile <filename>

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

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

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

Windows と macOS のみ
--tlsCertificateSelectorおよび/または--tlsClusterCertificateSelector を使用する場合、ルート CA 証明書と中間 CA 証明書の指定には --tlsClusterCAFile を使用しません。--tlsCertificateSelectorおよび/または--tlsClusterCertificateSelector証明書の完全な信頼チェーンの検証に必要なすべての CA 証明書は、安全な証明書ストアに保存します。

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

--tlsCRLFile <filename>

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

注意

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

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

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

--tlsAllowInvalidCertificates

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

注意

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

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

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

--tlsAllowInvalidHostnames

プロセス間認証のためにレプリカセットまたはシャーディングされたクラスターの他のノードに接続するときに、TLS 証明書内のホスト名の検証を無効にします。これにより、証明書内のホスト名が設定されたホスト名と一致しない場合でも、mongod は他のノードに接続できるようになります。

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

--tlsAllowConnectionsWithoutCertificates

デフォルトでは、サーバーは CA ファイルを使用するよう構成されていない限り、クライアント証明書の検証をバイパスします。CA ファイルが設定されている場合、次のルールが適用されます。

  • 証明書を提供していないクライアントの場合、 mongodまたはmongosは、接続が正常に確立されているという前提で TLS/SSL 接続を暗号化します。

  • 証明書を提示するクライアントの場合、mongod により --tlsCAFile で指定されたルート証明書チェーンを使用して証明書の検証が実行され、無効な証明書を持つクライアントは拒否されます。

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

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

--tlsDisabledProtocols <protocol(s)>

TLS で実行されている MongoDB サーバーが、特定のプロトコルを使用する接続を受け入れることを防ぎます。複数のプロトコルを指定するには、プロトコルをカンマで区切ったリストを使用します。

--tlsDisabledProtocols は、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から--tlsDisabledProtocolsを指定します。

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

Tip

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

プロトコルを許可しない

--tlsFIPSMode

TLS ライブラリの FIPS モードを使用するようにmongodに指示します。 --tlsFIPSModeオプションを使用するには、システムに FIPS 準拠のライブラリが必要です。

注意

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

プロファイラーのオプション

--profile <level>

デフォルト: 0

データベースプロファイラーレベルを設定します。次のプロファイラー レベルを使用できます。

0
プロファイラーはオフになっており、データは収集されません。これはデフォルトのプロファイラー レベルです。
1

プロファイラーは、 slowmsしきい値を超える操作、または指定されたフィルターに一致する操作のデータを収集します。

フィルターが設定されている場合、

  • slowmsおよびsampleRateオプションはプロファイリングには使用されません。

  • プロファイラーは、フィルターに一致する操作のみをキャプチャします。

2
プロファイラーは、すべての操作のデータを収集します。

警告

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

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

--slowms <integer>

デフォルト: 100

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

低速操作は、MongoDB でその操作にかかった時間である workingMillis に基づいてログに記録されます。つまり、ロック待ちやフロー制御などの要因は、操作が低速操作のしきい値を超えるかどうかに影響しません。

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

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

mongodインスタンスの場合、 --slowmsは診断ログと（有効になっている場合）プロファイラーに影響します。

Tip

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

Database Profiler

--slowOpSampleRate <double>

デフォルト: 1.0

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

--slowOpSampleRateは、レプリカセットのセカンダリ ノードによる oplog エントリのログ記録の遅さに影響することはありません。 セカンダリ ノードでは、 --slowOpSampleRateに関係なく、低速操作のしきい値よりも時間がかかるすべての oplog のエントリがログに記録されます。

mongodインスタンスの場合、 --slowOpSampleRateは診断ログと（有効になっている場合）プロファイラーに影響します。

監査のオプション

--auditCompressionMode

バージョン 5.3 で追加。

監査ログの暗号化の圧縮モードを指定します。 また、 --auditEncryptionKeyUIDまたは--auditLocalKeyFileのいずれかを使用して、監査ログの暗号化を有効にする必要があります。

--auditCompressionMode は次のいずれかの値に設定できます。

値
説明

zstd

監査ログを圧縮するには、zstd アルゴリズムを使用します。

none （デフォルト）

監査ログを圧縮しないでください。

注意

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

--auditDestination

監査を有効にし、mongod がすべての監査イベントを送信する場所を指定します。

--auditDestination には次のいずれかの値を指定できます。

値
説明

syslog

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

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

console

監査イベントを JSON 形式で stdout に出力します。

file

監査するイベントを--auditPath --auditFormatで指定された形式で、 で指定されたファイルに出力します。

注意

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

--auditEncryptionKeyUID

バージョン 6.0 で追加。

監査ログの暗号化用に KMIP（Key Management Interoperability Protocol）キーの一意の識別子を指定します。

--auditEncryptionKeyUIDと--auditLocalKeyFileを併用することはできません。

注意

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

--auditFormat

が --auditDestinationである場合の 監査file 用出力ファイルの形式を指定します。--auditFormatオプションには、次のいずれかの値を指定できます。

値
説明

JSON

監査するイベントをJSON形式で--auditPath で指定されたファイルに出力します。

BSON

監査するイベントをBSONバイナリ形式で、--auditPath で指定されたファイルに出力します。

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

注意

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

--auditLocalKeyFile

バージョン 5.3 で追加。

監査ログの暗号化用にローカル監査キー ファイルのパスとファイル名を指定します。

注意

キーが保護されていないため、テストには--auditLocalKeyFileのみを使用してください。 キーを保護するには、 --auditEncryptionKeyUIDと外部の KMIP サーバーを使用します。

--auditLocalKeyFileと--auditEncryptionKeyUIDを併用することはできません。

注意

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

--auditPath

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

注意

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

--auditFilter

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

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

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

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

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

注意

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

--auditSchema

デフォルト: mongo

バージョン8.0の新機能。

監査ログに使用される形式を指定します。--auditSchema には、次のいずれかの値を指定できます。

値
説明

mongo

ログは、MongoDB によって設計された形式で書き込まれます。

ログメッセージの例については、「mongo スキーマ監査メッセージ」を参照してください。

OCSF

ログは OCSF 形式で書き込まれます。このオプションは、ログプロセッサと互換性のある標準化された形式でログを提供します。

ログメッセージの例については、「OCSF スキーマ監査メッセージ」を参照してください。

inMemory のオプション

--inMemorySizeGB <float>

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

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

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

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

注意

エンタープライズ機能

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

暗号化のキー管理のオプション

--enableEncryption

デフォルト: false

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

注意

エンタープライズ機能

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

--encryptionCipherMode <string>

デフォルト: AES256-CBC

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

モード
説明

AES256-CBC

暗号ブロック チェーン モードの 256 ビット AES（Advanced Encryption Standard）

AES256-GCM

ガロア カウンタ モードの 256 ビットAES

Linuxでのみ利用可能です。

Windows 上の MongoDB Enterprise では、保管時の暗号化のブロック暗号として AES256-GCM をサポートしなくなりました。この使用は、Linux でのみサポートされています。

注意

エンタープライズ機能

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

--encryptionKeyFile <string>

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

キーファイルには1つのキーしか入れることができません。キーは 16 文字または 32 文字の文字列です。

--enableEncryption が必要です。

注意

エンタープライズ機能

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

--kmipKeyIdentifier <string>

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

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

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

注意

エンタープライズ機能

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

--kmipRotateMasterKey <boolean>

デフォルト: false

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

注意

エンタープライズ機能

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

Tip

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

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

--kmipServerName <string>

接続先の KMIP サーバーのホスト名または IP アドレスです。--enableEncryption が必要です。

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

KMIP サーバーに接続すると、 mongodは、指定された--kmipServerNameがサブジェクト代替名SAN （またはSANが存在しない場合は、コモンネームCN ）と一致することを確認します。 KMIP サーバー SANが存在する場合、 mongodはCNと一致しません。 ホスト名がSAN （またはCN ）と一致しない場合、 mongodは接続に失敗します。

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

注意

エンタープライズ機能

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

--kmipPort <number>

デフォルト: 5696

KMIP サーバーとの通信に使用するポート番号です。--kmipServerName が必要です。--enableEncryption が必要です。

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

注意

エンタープライズ機能

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

--kmipConnectRetries <number>

デフォルト: 0

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

注意

エンタープライズ機能

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

--kmipConnectTimeoutMS <number>

デフォルト: 5000

KMIP サーバーの応答を待つ際のタイムアウト時間（ミリ秒）です。--kmipConnectRetries 設定が指定されている場合、mongod は各再試行の間に指定された時間だけ待機します。

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

注意

エンタープライズ機能

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

--kmipClientCertificateSelector <string>

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

--kmipClientCertificateFile と --kmipClientCertificateSelector のオプションは相互に排他的です。指定できるのは 1 つだけです。

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

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

プロパティ
値の型
説明

subject

ASCII 文字列

証明書のサブジェクト名またはコモンネーム

thumbprint

hex 文字列

SHA-1 ダイジェストによって公開キーを識別するために使用される、16進数で表現されるバイト シーケンス。

thumbprint は、fingerprint と呼ばれることもあります。

注意

エンタープライズ機能

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

--kmipClientCertificateFile <string>

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

このオプションを使用するには、 --kmipServerNameオプションも指定する必要があります。

重要

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

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

注意

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

注意

エンタープライズ機能

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

--kmipClientCertificatePassword <string>

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

注意

エンタープライズ機能

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

--kmipServerCAFile <string>

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

注意

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

--kmipActivateKeys <boolean>

デフォルト: true

バージョン 5.3 で追加。

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

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

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

--kmipKeyStatePollingSeconds <integer>

デフォルト: 900 秒

バージョン 5.3 で追加。

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

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

--kmipUseLegacyProtocol <boolean>

デフォルト: false

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

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

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

--eseDatabaseKeyRollover

AES256-GCM で暗号化された ストレージ エンジンのデータベース キーをロールオーバーします。

このオプションを使用して mongod インスタンスを起動すると、インスタンスはキーをローテーションして終了します。

注意

エンタープライズ機能

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

戻る

MongoDB パッケージ コンポーネント

次へ

mongos