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 mongod
com 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 mongos
configuraçã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 configDB
sequência, que deve ser idêntica em todos os mongos
processos. 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.