web-dev-qa-db-ja.com

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

MongoDB構成オプションのドキュメント は、指定可能なすべての使用可能なオプションを一覧表示していますが、さまざまな役割のMongoDBインスタンス用に完全に形成されたYAML形式の設定ファイルのセットを持っている人はいますか？

一般的な役割の一連の例は、ゼロから始める場合、または最新の構成ファイル形式でテストする場合に非常に役立つ開始点になります。

mongodb
33
Adam C

[〜＃〜] yaml [〜＃〜] Linux用の設定（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 config：

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です。

47
Adam C