Docs Menu
Docs Home
/ /
設定とメンテナンス
Docs Home
/ /
管理
/
設定とメンテナンス
Docs Home
/
データベース マニュアル
/
自己管理型配置
/
管理
/
設定とメンテナンス

自己管理型配置のためのランタイムデータベース構成

コマンドライン インターフェースおよび構成ファイル インターフェースは、MongoDB 管理者にデータベース システムの操作を制御するための多数のオプションと設定を提供します。このドキュメントでは、一般的な設定の概要と、一般的なユースケースにおけるベストプラクティスの例を示します。

どちらのインターフェースも同じオプションと設定のコレクションにアクセスできますが、このドキュメントでは主に構成ファイル インターフェイスを使用します。

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

    プラットフォーム
    方式
    構成ファイル

    Linux

    apt、yumまたは、zypper パッケージ マネージャー

    /etc/mongod.conf

    MacOS

    brew パッケージ マネージャー

    /usr/local/etc/mongod.conf （Intel プロセッサ上）、または

    /opt/homebrew/etc/mongod.conf （ Apple Silicon プロセッサ）

    Windows

    MSI インストーラー

    <install directory>\bin\mongod.cfg

  • ダウンロードしたTGZまたはZIPファイルを使用してMongoDB をインストールした場合は、独自の構成ファイルを作成する必要があります。 基本的な例の構成から始めることが推奨されます。

Linux または macOS 上の MongoDB のパッケージ インストールでは、このデフォルトの構成ファイルを使用する初期化スクリプトも提供されます。この初期化スクリプトは、次の方法でこれらのプラットフォーム上で mongod を起動するために使用できます。

  • systemd init システム（systemctl コマンド）を使用する Linux システムの場合:

    sudo systemctl start mongod

  • SystemV init init システム（service コマンド）を使用する Linux システムの場合:

    sudo service mongod start

  • macOS で、brew パッケージ マネージャーを使用する場合:

    brew services start mongodb-community@6.0

MongoDB をTGZまたはZIPファイルを使用してインストールした場合は、独自の構成ファイルを作成する必要があります。 基本的な例構成については、このドキュメントの後半に記載されています。 構成ファイルを作成したら、 に または--config-f mongodオプションのいずれかを使用して、この構成ファイルで MongoDB インスタンスを起動できます。たとえば、Linux の場合は次のようになります。

mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf

データベース インスタンスの構成を制御するには、システム上の mongod.conf ファイルの値を変更します。

データベースの構成

次の基本構成を検討します。

processManagement:
   fork: true
net:
   bindIp: localhost
   port: 27017
storage:
   dbPath: /var/lib/mongo
systemLog:
   destination: file
   path: "/var/log/mongodb/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true

ほとんどのスタンドアロン サーバーの場合、これが十分な基本構成です。これにより、いくつかの前提が作られますが、次の説明で考えてみます。

  • fork は true です。これにより mongod のデーモン モードが有効になり、MongoDB を現在のセッションからデタッチし（すなわち「フォーク」)、データベースを従来のサーバーとして運用できます。

  • bindIp は localhost です。これによりサーバーは localhost IP のリクエストのみをリッスンするよう強制されます。システム ネットワーク フィルタリング（すなわち「ファイアウォール」）から提供されるアクセス制御を使って、アプリケーションレベルのシステムがアクセスできるセキュアなインターフェースにのみバインドします。

  • port は 27017 です。これはデータベース インスタンスのデフォルトの MongoDB ポートです。MongoDB は任意のポートにバインドできます。また、ネットワーク フィルタリング ツールを使用して、ポートに基づいてアクセスをフィルタリングすることもできます。

    注意

    UNIX のようなシステムでは、1024 未満のポートにプロセスをアタッチするにはスーパーユーザー権限が必要です。

  • quiet は true です。これにより、出力/ログファイル内の最も重要なエントリを除くすべてが無効になるため、実稼働システムには推奨されません。このオプションを設定する場合、setParameter を使用してこの設定を変更できます。

  • dbPath は /var/lib/mongo です。これは、MongoDB がデータファイルを保存する場所を規定します。

    yum や apt などのパッケージ マネージャーを使用して Linux に MongoDB をインストールした場合、MongoDB インストールで提供される /etc/mongod.conf ファイルによって、Linux ディストリビューションに応じて次のデフォルトの dbPath が設定されます。

    プラットフォーム
    パッケージ マネージャー
    default 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

    mongod を実行するユーザー アカウントには、このディレクトリへの読み取りアクセス権および書込みアクセス権が必要です。

  • systemLog.path は /var/log/mongodb/mongod.log です。これは mongod が出力を書き込む場所です。この値を設定しない場合、mongod はすべての出力を標準出力に書き込みます（例: stdout）。

  • logAppend は true です。これにより、サーバーの起動操作後に mongod が既存のログファイルを上書きしないことが保証されます。

  • storage.journal.enabledはtrueであり、これによりジャーナリングが有効になります。 ジャーナリングにより、単一インスタンスの書込み耐久性が確保されます。 mongodの 64 ビット ビルドでは、デフォルトでジャーナリングが有効になります。 したがって、この設定は冗長な設定になる可能性があります。

デフォルト構成と考慮すると、これらの一部は冗長な値と考えられますが、多くの状況において、構成を明確に示すことで、システム全体の理解しやすさが向上します。

セキュリティに関する考慮事項

次の構成オプションは、mongod インスタンスへのアクセスを制限するのに役立ちます。

net:
   bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
security:
   authorization: enabled
net.bindIp

この例では、bindIp オプションに 4 つの値を指定します。

  • localhost、localhost インターフェイス

  • 10.8.0.10、通常、ローカル ネットワークおよび VPN インターフェースに使用される プライベート IP アドレス

  • 192.168.4.24、通常、ローカル ネットワークで使用されるプライベート ネットワーク インターフェース

  • /tmp/mongod.sock、Unix ドメイン ソケット パス

本番環境の MongoDB インスタンスは、複数のデータベース サーバーからアクセスできる必要があるため、アプリケーション サーバーからアクセス可能な複数のインターフェースに MongoDB をバインドすることが重要です。同時に、これらのインターフェースは、ネットワーク レイヤーで制御および保護されているインターフェースに限定することが重要です。

security.authorization
このオプションを true に設定すると、MongoDB 内の承認システムが有効になります。有効にした場合、初めてユーザー認証情報を作成するには、localhost インターフェース経由で接続してログインする必要があります。

Tip

セキュリティ

レプリケーションとシャーディングの構成

レプリケーション構成

レプリカセットの構成は簡単で、必要なのはreplSetNameがセットのすべてのノード間で一貫した値を持っているだけです。次の点を考慮してください。

replication:
   replSetName: set0

セットにはわかりやすい名前を使用します。 構成が完了したら、 mongoshを使用してレプリカセットにホストを追加します。

Tip

レプリカセットの再構成

キーファイルを使用してレプリカセットの認証を有効にするには、次の keyFile オプション を追加します [1]。

security:
   keyFile: /srv/mongodb/keyfile

keyFile を設定すると認証が有効になり、レプリカセット ノードが相互に認証するときに使用するキーファイルが指定されます。

Tip

レプリカセットを使用した認証の構成については、「レプリカセットのセキュリティ」セクションを参照してください。

MongoDB でのレプリケーションと一般的なレプリカセット構成の詳細については、レプリケーションのドキュメントを参照してください。

[1] シャーディングされたクラスターとレプリカセットでは、キーファイルの代わりに X.509 を使用してメンバーシップを検証できます。詳細については、「X.509」を参照してください。

シャーディング構成

シャーディングには、コンフィギュレーションサーバーとシャードに対して異なる mongod 構成を持つ mongod インスタンスが必要です。コンフィギュレーションサーバーはクラスターのメタデータを保存し、シャードはデータを保存します。

コンフィギュレーションサーバーの mongod インスタンスを構成するには、構成ファイルで、sharding.clusterRole 設定に configsvr を指定します。

注意

コンフィギュレーションサーバーは レプリカセット として配置する必要があります。

 sharding:
    clusterRole: configsvr
 net:
    bindIp: 10.8.0.12
    port: 27001
replication:
    replSetName: csRS

コンフィギュレーションサーバーをレプリカセットとして展開するには、コンフィギュレーションサーバーにより WiredTiger ストレージ エンジンが実行されている必要があります。Initiate レプリカセットを作成し、ノードを追加します。

シャード mongod インスタンスを構成するには、sharding.clusterRole 設定に shardsvr を指定し、レプリカセットとして実行している場合は、レプリカセット名を指定します。

sharding:
   clusterRole: shardsvr
replication:
   replSetName: shardA

レプリカセットとして実行している場合、シャード レプリカセットを initiate し、ノードを追加します。

ルーター（つまり、mongos）には、次の設定で少なくとも 1 つの mongos プロセスを構成します。

sharding:
   configDB: csRS/10.8.0.12:27001

レプリカセット名の後にカンマ区切りのリスト形式でホスト名とポートを指定することで、コンフィギュレーションサーバー レプリカセットの追加ノードを指定できます。

Tip

シャーディングとクラスター構成の詳細については、マニュアルの「シャーディング」セクションを参照してください。

同じシステム上で複数のデータベース インスタンスの実行

多くの場合、1 つのシステム上で mongod の複数のインスタンスを実行することは推奨されません。一部のタイプの配置 [2] やテストの目的では、1 つのシステム上で複数の mongod を実行する必要がある場合があります。

このような場合は、インスタンスごとに基本構成を使用しますが、次の構成値を考慮してください。

storage:
   dbPath: /var/lib/mongo/db0/
processManagement:
   pidFilePath: /var/lib/mongo/db0.pid

dbPath 値は、mongod インスタンスのデータディレクトリのロケーションを制御します。各データベースに、別個かつ適切にラベル付けされたデータディレクトリがあることを確認してください。pidFilePath は、mongod プロセスがプロセス ID（PID）ファイルを配置する場所を制御します。これは特定の mongod ファイルを追跡するため、これらのプロセスを簡単に開始および停止できるように、ファイルが一意であり、適切にラベル付けされていることが重要です。

これらのプロセスを制御するには、必要に応じて追加の init スクリプトを作成したり、既存の MongoDB 構成と init スクリプトを調整したりします。

[2] SSD またはその他の高性能ディスクを備えたシングルテナント システムでは、複数の mongod インスタンスに対して許容可能なパフォーマンス レベルが提供される場合があります。さらに、ワーキングセットが小さい複数のデータベースが 1 つのシステム上で許容できる程度に機能する場合もあります。

診断の構成

次の構成オプションは、診断目的でさまざまな mongod の動作を制御します。

  • operationProfiling.mode は、データベースプロファイラー レベルを設定します。プロファイラー自体がパフォーマンスに影響する可能性があるため、プロファイラーはデフォルトではアクティブになっていません。この設定がオンになっていない場合、クエリはプロファイリングされません。

  • operationProfiling.slowOpThresholdMs configures the threshold which determines whether a query is "slow" for the purpose of the logging system and the profiler. The default value is 100 milliseconds. Set to a lower value if the logging system and the database profiler do not return useful results or set to a higher value to only log the longest running queries.

    replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:

    プロファイラーは遅い oplog エントリをキャプチャしません。

  • systemLog.verbosity は、mongod がログに書込むログ出力の量を制御します。通常のログ レベルに反映されない問題が発生している場合にのみ、このオプションを使用してください。

    systemLog.component.<name>.verbosity設定を使用して、特定のコンポーネントの冗長レベルを指定することもできます。 利用可能なコンポーネントについては、 component verbosity settingsを参照してください。

詳細については、「データベースプロファイラー」と「MongoDB のパフォーマンス」も参照してください。

戻る

設定とメンテナンス

次へ

最新のパッチ リリースへのアップグレード

項目一覧