mongos インスタンス

中心的オプション

--help, -h

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

--version

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

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

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

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

--configExpand <none|rest|exec>

デフォルト: なし

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

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

値	説明
none	デフォルト。mongos は展開ディレクティブを展開しません。構成ファイルの設定で展開ディレクティブが使用されている場合、mongosは起動に失敗します。
rest	mongos は、構成ファイルを解析するときに __rest 展開ディレクティブを展開します。
exec	mongos は、構成ファイルを解析するときに __exec 展開ディレクティブを展開します。

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

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

--verbose, -v

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

--quiet

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

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

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

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

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

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

--port <port>

デフォルト: 27017

mongos インスタンスがクライアント接続をリッスンする TCP ポートです。

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

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

デフォルト: localhost

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

以下に例を挙げます。 localhost,/tmp/mongod.sock

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

以下に例を挙げます。 localhost,2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513

注意

IPv6 アドレス、または IPv アドレスに解決するホスト名を6 --bind_ipmongos--ipv6に指定する場合、IPv6 のサポートを有効にするには、 を で開始する必要があります。6 に--bind_ip IPv アドレスを指定しても、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」と入力します。

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

注意

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

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

--bind_ip_all

指定されている場合、mongos インスタンスはすべての IPv4 アドレス（つまり0.0.0.0 ）にバインドされます。 がmongos --ipv6で始まる場合、 もすべての--bind_ip_all IPv6 アドレス（:: ）にバインドされます。

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

警告

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

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

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

注意

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

--listenBacklog <number>

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

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

警告

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

重要

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

listenBacklogパラメーターのデフォルト値は、ターゲットシステムに依存します。Linux では、MongoDB は/proc/sys/net/core/somaxconnを使用します。その他のすべてのターゲットシステムでは、MongoDB はコンパイル時定数SOMAXCONNを使用します。

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

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

--maxConns <number>

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

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

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

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

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

--logpath <path>

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

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

--syslog

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

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

警告

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

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

...  ACCESS   [repl writer worker 5] Unsupported modification to roles collection ...

--syslogFacility <string>

デフォルト: user

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

--logappend

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

--logRotate <string>

デフォルト: rename

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

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

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

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

--redactClientLogData

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

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

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

例、 MongoDBデプロイでは、個人を特定できる情報（PII）が 1 つ以上のコレクションに保存される場合があります。 は、mongos CRUD操作 やシャーディングメタデータなどのイベントをログに記録します。これらのログ操作の一環として PII を公開する可能性があります。 とともに実行中mongos --redactClientLogDataは、これらのイベントに付随するメッセージをログに書き込む前にすべてのメッセージを削除するため、PII が削除されます。

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

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

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

注意

タイムスタンプ形式は ctime をサポートしなくなりました。ctime 形式の日付の例は、Wed Dec 31 18:17:54.811 です。

--pidfilepath <path>

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

注意

Linux

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

注意

MacOS

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

--keyFile <file>

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

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

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

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

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

--setParameter <options>

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

--noscripting

スクリプト エンジンを無効にします。無効にすると、$where クエリ演算子、mapReduce コマンド、$accumulator、$function など、JavaScript コードをサーバーサイドで実行する操作は使用できません。

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

--nounixsocket

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

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

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

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

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

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

--unixSocketPrefix <path>

デフォルト: /tmp

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

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

• net.unixDomainSocket.enabled とは false

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

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

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

--filePermissions <path>

デフォルト: 0700

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

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

--fork

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

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

--forkオプションを使用するには、次のいずれかのログ出力でmongos のログ出力を構成する必要があります。

• --logpath

• --syslog

--transitionToAuth

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

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

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

注意

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

--networkMessageCompressors <string>

Default: snappy,zstd,zlib

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

• シャーディングされたクラスターの他のノード

• mongosh

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

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

• Snappy

• zlib

• zstd

mongod インスタンスと mongos インスタンスはどちらもデフォルトで snappy,zstd,zlib コンプレッサーに設定され、順序は同じです。

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

重要

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

複数のコンプレッサーを指定する場合、通信イニシエーターだけでなく、コンプレッサーをリストする順序も重要になります。例、 が次のネットワークmongosh コンプレッサーzlib,snappy mongodsnappy,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
mongos --timeZoneInfo timezonedb-2017b/

警告

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

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

--outputConfig

mongosYAML 形式の インスタンスの構成オプションをstdout mongosに出力し、 インスタンスを終了します。自己管理型MongoDBの外部構成値--outputConfig を使用する構成オプションの場合、 はそれらのオプションの解決された値を返します。

警告

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

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

• 解決された展開ディレクティブ値を含む構成ファイルを出力する

• 自己管理型コマンドライン オプションを YAML に変換する

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

--configdb <replicasetName>/<config1>,<config2>...

シャーディングされたクラスターの構成サーバーを指定します。

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

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

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

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

--localThreshold

デフォルト: 15

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

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

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

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

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

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

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

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

TLS のオプション

--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 証明書ストアを使用します。

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsCertificateKeyFile <filename>

注意

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

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

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsCertificateKeyFilePassword <value>

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

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの 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 証明書ストアを使用します。

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsClusterFile <filename>

注意

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

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

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

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsClusterPassword <value>

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

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsCAFile <filename>

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsClusterCAFile <filename>

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

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

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

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

--tlsCAFileが設定されている必要があります。

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsCertificateSelector <parameter>=<value>

注意

の代替としてWindowsと macOS--tlsCertificateKeyFile で利用できます。

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

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

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

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

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

注意

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

--tlsClusterCertificateSelector <parameter>=<value>

注意

の代替としてWindowsと macOS--tlsClusterFile で利用できます。

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

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

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

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

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

--tlsCRLFile <filename>

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

注意

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsAllowConnectionsWithoutCertificates

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

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

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsAllowInvalidCertificates

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

注意

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

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの TLS/SSL 構成 を参照してください。

--tlsAllowInvalidHostnames

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

TLS と MongoDB の詳細については、TLS/SSL 暗号化用 MongoDB インスタンスの構成 および クライアントの 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）。

• 認識できないプロトコルを指定すると、サーバーは起動しません。

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

MongoDB1.0 1.1は、システムで TLS + が利用可能な場合、TLS の使用を無効にします。無効になっている TLS1.0 を有効にするには、none から--tlsDisabledProtocols を指定します。

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

Tip

プロトコルを許可しない

--tlsFIPSMode

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

MongoDB8.3 以降では、SCRAM-SHA-1 またはauthenticationMechanisms mongod --tlsFIPSModeも指定しながら、 にmongos --tlsFIPSMode を指定することはできません。

--tlsFIPSMode も指定しているときに authenticationMechanisms に SCRAM-SHA-1 を指定しようとすると、サーバーはエラーをスローし、次のようなメッセージをログに記録します。

SCRAM-SHA-1 is not allowed in FIPS mode.

注意

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

監査のオプション

--auditCompressionMode

バージョン5.3の新機能。

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

このオプションは、次のいずれかの値に設定できます。

値	説明
zstd	監査ログを圧縮するには、zstd アルゴリズムを使用します。
none （デフォルト）	監査ログを圧縮しないでください。

注意

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

--auditDestination

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

--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）キーの一意の識別子を指定します。

このオプションと--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の新機能。

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

注意

キーが保護されていないため、このオプションはテスト目的でのみ使用してください。キーを保護するには、 と外部のKey Management Interoperability Protocol--auditEncryptionKeyUID (KMIP)サーバーを使用します。

両方のオプションを同時に使用することはできません。

注意

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

型: string

デフォルト: mongo

バージョン8.0の新機能。

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

値	説明
mongo	ログは、MongoDB によって設計された形式で書き込まれます。 ログメッセージの例については、「mongo スキーマ監査メッセージ」を参照してください。
OCSF	ログは OCSF 形式で書かれています。このオプションは、ログプロセッサと互換性のある標準化された形式でログを提供します。 ログメッセージの例については、「OCSF スキーマ監査メッセージ」を参照してください。

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

--slowms <integer>

デフォルト: 100

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

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

logLevel を高く設定すると、待ち時間に関係なく、すべての操作が診断ログに表示されます。

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

--slowOpSampleRate <double>

デフォルト: 1.0

ログに記録されるべき 低速--slowOpSampleRate 操作の割合です。0 1は、 から までの値を受け入れます。

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

LDAP 認証および承認のオプション

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

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

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

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

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

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

--ldapValidateLDAPServerConfig <boolean>

MongoDB Enterprise で利用可能です。

mongosインスタンスがスタートアップの一部としてLDAP server(s) の可用性を確認するかどうかを決定するフラグです。

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

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

--ldapQueryUser <string>

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

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

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

• LDAP 承認を使用している

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

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

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

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

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

注意

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

--ldapQueryPassword <string>

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

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

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

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

注意

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

--ldapBindWithOSDefaults <bool>

デフォルト: false

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

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

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

• LDAP 承認を使用している

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

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

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

--ldapBindMethod <string>

デフォルト: simple

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

は--ldapQueryUser を使用してmongos--ldapQueryPassword LDAPサーバーに認証します。 LDAPサーバーに接続するには、 と とともに を使用します。

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

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

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

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

--ldapBindSaslMechanisms <string>

デフォルト: DIGEST-MD5

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

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

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

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

Linux

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

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

Windows

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

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

注意

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

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

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

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

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

--ldapTransportSecurity <string>

デフォルト: tls

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

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

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

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

--ldapTransportSecurityをnone mongosに設定すると、 と LDAPサーバーの間で TLS/SSL が無効になります。

警告

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

--ldapTimeoutMS <int>

デフォルト: 10000

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

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

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

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

--ldapRetryCount <int>

バージョン6.1の新機能。

デフォルト: 0

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

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

--ldapUserToDNMapping <string>

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

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

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

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

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

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

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

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

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

注意

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

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

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

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

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

MongoDB5.0 以降、マッピング ドキュメントの代わりに、--ldapUserToDNMapping は空の文字列"" または空の配列[ ] を受け入れます。空の 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)" です。mongos は LDAP サーバーに対してこのクエリを実行し、結果として "cn=bob,ou=dba,dc=example,dc=com" を返します。

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

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

追加オプション

--ipv6

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

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

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

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