MongoDBのサンプルYAML構成ファイル？

MongoDBの構成オプションのドキュメントのリストを指定することができますが、誰でもYAMLはさまざまなロールでのMongoDBインスタンスの設定ファイルをフォーマットされた完全に形成された例のセットを持っていない、すべての利用可能なオプション？

一般的なロールのサンプルセットは、ゼロから始める場合や、最新の構成ファイル形式でテストする場合に非常に便利な出発点になります。

Linux のYAML構成のいくつかの例を示します（Windowsのパスとオプションは少し異なります）。いくつかのデフォルトと一般的に使用される設定を本質的に明示的に設定します。

最初に、mongodデフォルトのポート、パス、ジャーナル設定を備えたスタンドアロン-これはローカルテストに使用される構成のタイプであり、いくつかの追加機能があるため、一般的なスタイルを示します。

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/data/db/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 127.0.0.1
    port: 27017
    wireObjectCheck : false
    unixDomainSocket: 
        enabled : true

この設定に関するいくつかの注意：

• 通常wireObjectCheck: false、実稼働環境ではオブジェクトをオフ（）にしたくないのですが、テスト目的で大量のデータをロードする場合は、物事が少しスピードアップし、そのような環境では最小限のリスクです
• これは、レプリカセットのすべてのメンバーがループバックIPアドレス上にない限り（これが指定された唯一のバインディングであるため）、レプリケーションでは機能しません。

次に、認証が有効であり、シャードクラスターの一部として実行されている典型的な実稼働レプリカセットメンバーのサンプル構成ファイルを見てみましょう。

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: 192.0.2.1
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

この構成に関する注意事項：

• 繰り返しますが、デフォルトと暗黙の設定の明示的な宣言があります（たとえば、ポートはclusterRoleによって暗黙的に指定されます）。通常、混乱を避けるためにこれが推奨されます。
• IPバインディングは外部IPアドレスのみであるため、ループバックIPでの通信は失敗しますが、リモートホストへの複製は機能します
• oplogのデフォルトは空き領域の5％であるため、大規模なボリュームではより保守的で、割り当てられたサイズを明示的に設定するのが一般的です

次に、サンプル構成mongos：

sharding:
    configDB: "config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
    autoSplit: true
systemLog:
    destination: file
    path: "/var/log/mongos.log"
processManagement:
    fork: true
net:
    port: 27017
    bindIp: 192.0.2.2
    maxIncomingConnections: 5000
security:
    keyFile: "/data/key/mongos.key"
    authorization: "enabled"

ここで必要な変更は、mongos（データを保存しないため）に適用されない削除configDBと、すべてのmongosプロセスで同一でなければならない文字列の追加のみです。例として最大接続数の設定を追加しましたが、これは必須ではありませんが、大規模なクラスターの場合には良いアイデアです。

分割されたクラスターを完成させるために、サンプルの構成サーバーがあります。これは、実際にはレプリカセットメンバーのサブセットであり、若干の変更が加えられています。

storage:
    dbPath: "/data/db"
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 192.0.2.3
    port: 27019
security:
    keyFile: "/data/key/config.key"
    authorization: "enabled"
sharding:
    clusterRole: "configsvr"

最後に、MongoDB 3.0（この記事の執筆時点ではまだリリースされていません）では、特に新しいストレージエンジンの導入により、いくつかの新しいオプションが導入されます。したがって、同じレプリカセットメンバーを構成する方法の例を次に示しますが、今回はWiredTigerストレージエンジンと（デフォルトの）snappy圧縮方法を使用します（注：SERVER-16266のために元のものから変更され、サンプルが追加されましたengineConfig）。

storage:
    dbPath: "/data/db"
    engine: "wiredTiger"
    wiredTiger:
        engineConfig: 
            cacheSizeGB: 8
        collectionConfig: 
            blockCompressor: snappy        
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: "192.0.2.1,127.0.0.1"
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

最後のボーナスとして、リスト（この場合は外部IPとループバックIP）を使用して複数のIPアドレスをバインドする方法を示しました。