Образцы файлов конфигурации YAML для MongoDB?

В документации по параметрам конфигурации MongoDB перечислены все доступные параметры, которые можно указать, но есть ли у кого-нибудь набор полностью сформированных примеров файлов конфигурации в формате YAML для экземпляров MongoDB в различных ролях?

Набор примеров для общих ролей будет очень полезной отправной точкой для тех, кто начинает с нуля или хочет протестировать с последним форматом файла конфигурации.

Вот несколько примеров конфигураций 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

Некоторые примечания по этому конфигу:

• Как правило, вы не хотите, чтобы объект check ( 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-шлейфу теперь будет прерываться, но репликация может работать на удаленные хосты.
• По умолчанию для оплога установлено 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 и (быстро по умолчанию) методом сжатия (примечание: изменено по сравнению с оригинальным из-за 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-адрес обратной связи.