Arquivos de configuração YAML de amostra para MongoDB?

A documentação das opções de configuração do MongoDB lista todas as opções disponíveis que podem ser especificadas, mas alguém tem um conjunto de arquivos de configuração formatados em YAML de exemplo totalmente formados para instâncias do MongoDB em várias funções?

Um conjunto de exemplos para as funções comuns seria um ponto de partida muito útil para quem começa do zero ou procura testar com o formato de arquivo de configuração mais recente.

Aqui estão vários exemplos de configurações de YAML para Linux (caminhos e opções do Windows são um pouco diferentes), essencialmente definindo explicitamente alguns padrões e configurações usadas com freqüência.

Primeiro, um autônomo mongodcom a porta padrão, caminho, configurações de diário - esse seria o tipo de configuração usada para testes locais, com alguns extras para mostrar o estilo geral:

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

Algumas notas sobre esta configuração:

• Geralmente, você não deseja que o objeto seja desativado ( wireObjectCheck: false) na produção, mas, para uma carga em massa de dados para fins de teste, isso agiliza um pouco as coisas e representa um risco mínimo nesse ambiente.
• Isso não funcionaria para replicação, a menos que todos os membros do conjunto de réplicas estivessem no endereço IP de auto-retorno (como essa é a única ligação especificada), portanto, tenha cuidado

Agora, vejamos um exemplo de arquivo de configuração para um membro típico do conjunto de réplicas de produção com a autenticação ativada e em execução como parte de um cluster fragmentado:

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"

Algumas notas sobre esta configuração:

• Novamente, há declarações explícitas de padrões e configurações implícitas (porta é implícita por clusterRole, por exemplo), geralmente isso é recomendado para evitar confusão
• A ligação IP agora é apenas o endereço IP externo; portanto, a comunicação no IP de loopback agora falhará, mas a replicação pode funcionar em hosts remotos.
• O oplog assume como padrão 5% de espaço livre, portanto, é comum em grandes volumes ser mais conservador e definir explicitamente o tamanho alocado

Em seguida, uma mongosconfiguração de amostra :

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"

As únicas alterações necessárias aqui são remoções que não se aplicam ao mongos(já que ele não armazena dados) e a adição da configDBsequência, que deve ser idêntica em todos os mongosprocessos. Adicionei a configuração de conexões máximas como exemplo, não é necessária, mas muitas vezes pode ser uma boa ideia para clusters maiores.

Para arredondar o cluster fragmentado, temos um servidor de configuração de amostra, que é realmente um subconjunto do membro do conjunto de réplicas com algumas pequenas alterações:

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"

Por fim, o MongoDB 3.0 (ainda não lançado no momento da redação deste documento) apresentará várias novas opções, especialmente com a introdução dos novos mecanismos de armazenamento. Portanto, aqui está um exemplo de como configurar o mesmo membro do conjunto de réplicas, mas desta vez com o mecanismo de armazenamento WiredTiger e o método de compressão rápida (padrão) (observação: alterado do original por causa do SERVER-16266 e amostra adicionada 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"

Como uma adição final de bônus, mostrei como vincular vários endereços IP usando uma lista, neste caso um IP externo e o IP de loopback.