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

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

Primeiro, um autônomo mongodcom a porta padrão, caminho, configurações de diário - este seria o tipo de configuração usado para testes locais, com alguns extras, então mostre 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 marcado ( wireObjectCheck: false) na produção, mas para uma carga em massa de dados para fins de teste, isso acelerará um pouco e é um risco mínimo em tal 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 loopback (já que essa é a única ligação especificada), portanto, cuidado

Agora, vamos ver um arquivo de configuração de amostra para um membro típico do conjunto de réplicas de produção com autenticação habilitada 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, existem declarações explícitas de padrões e configurações implícitas (a porta está implícita em clusterRole, por exemplo), geralmente isso é recomendado para evitar confusão
• A vinculação de IP agora é apenas o endereço IP externo, portanto, a comunicação no IP de loopback agora falhará, mas a replicação pode funcionar para hosts remotos
• O oplog é padronizado para 5% de espaço livre, por isso é comum em grandes volumes ser mais conservador e definir explicitamente o tamanho alocado

Em seguida, uma mongosconfiguração de exemplo:

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 as remoções que não se aplicam ao mongos(já que ele não armazena dados) e a adição da configDBstring, 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 geralmente pode ser uma boa ideia para clusters maiores.

Completando 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"

Finalmente, o MongoDB 3.0 (ainda não lançado no momento da redação deste artigo) 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 padrão) método de compactação ágil (observação: alterado do original por causa de SERVER-16266 e adicionado amostra 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 um bônus final, mostrei como vincular vários endereços IP usando uma lista, neste caso um IP externo e o IP de loopback.