Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

Configuração de banco de dados em tempo de execução para sistemas autogerenciados

Nesta página

  • Configurar o Banco de Dados
  • Considerações de segurança
  • Configuração de replicação e fragmentação
  • Execute múltiplas instâncias de banco de dados no mesmo sistema
  • Configurações de diagnóstico

As interfaces de linha de comando e arquivo de configuração fornecem aos administradores do MongoDB um grande número de opções e configurações para controlar a operação do sistema de banco de dados. Este documento fornece uma visão geral das configurações comuns e exemplos de configurações de melhores práticas para casos de uso comuns.

Embora ambas as interfaces forneçam acesso à mesma coleta de opções e configurações, este documento usa principalmente a interface do arquivo de configuração.

  • Se você instalou o MongoDB com um gerenciador de pacote como yum ou apt no Linux ou brew no macOS, ou com o instalador MSI no Windows, um arquivo de configuração padrão foi fornecido como parte da sua instalação:

    Plataforma
    Método
    Arquivo de configuração
    Linux
    apt, yum, ou zypper gerenciador de pacotes
    /etc/mongod.conf
    macOS
    brew Gerente de pacotes

    /usr/local/etc/mongod.conf (em processadores Intel), ou

    /opt/homebrew/etc/mongod.conf (em processadores Apple Silicon)

    Windows
    Instalador MSI
    <install directory>\bin\mongod.cfg
  • Se você instalou o MongoDB por meio de um arquivo TGZ ou ZIP baixado, você deve criar seu próprio arquivo de configuração. A configuração básica de exemplo é um bom ponto de partida.

Para instalações de pacotes do MongoDB no Linux ou macOS, um script de inicialização que usa esse arquivo de configuração padrão também é fornecido. Este script de inicialização pode ser utilizado para iniciar o mongod nestas plataformas da seguinte maneira:

  • Em sistemas Linux que utilizam o sistema de inicialização systemd (o comando systemctl):

    sudo systemctl start mongod
  • Em sistemas Linux que utilizam o sistema de entrada SystemV (o comando service):

    sudo service mongod start
  • No macOS, usando o gerenciador de pacotes brew :

    brew services start mongodb-community@6.0

Se você instalou o MongoDB utilizando um arquivo TGZ ou ZIP , você precisará criar seu próprio arquivo de configuração. Um exemplo de configuração básica pode ser encontrado posteriormente neste documento. Após criar um arquivo de configuração, você pode iniciar uma instância MongoDB com este arquivo de configuração utilizando as opções --config ou -f para mongod. Por exemplo, no Linux:

mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf

Modifique os valores no arquivo mongod.conf em seu sistema para controlar a configuração da instância do seu banco de dados.

Considere a seguinte configuração básica:

processManagement:
fork: true
net:
bindIp: localhost
port: 27017
storage:
dbPath: /var/lib/mongo
systemLog:
destination: file
path: "/var/log/mongodb/mongod.log"
logAppend: true
storage:
journal:
enabled: true

Para a maioria dos servidores autônomos, essa é uma configuração básica suficiente. Ele faz várias suposições, mas considere a seguinte explicação:

  • fork é true, que habilita um modo daemon para mongod, que se desvincula (ou seja "forks") o MongoDB da sessão atual e permite que você execute o banco de dados como um servidor convencional.

  • bindIp é localhost, que força o servidor a escutar apenas solicitações no IP localhost. Vincule-se somente a interfaces seguras que os sistemas em nível de aplicativo possam acessar com o controle de acesso fornecido pela filtragem de rede do sistema (ou seja, "firewall").

  • port é 27017, que é a porta MongoDB padrão para instâncias do banco de dados. O MongoDB pode se vincular a qualquer porta. Você também pode filtrar o acesso com base na porta usando ferramentas de filtragem de rede.

    Observação

    Sistemas semelhantes aos UNIX exigem privilégios de superusuário para anexar processos a portas inferiores a 1024.

  • quiet é true. Isso desativa todas as entradas no arquivo de saída/log, exceto as mais críticas, e não é recomendado para sistemas de produção. Se você definir essa opção, poderá usar setParameter para modificar essa configuração durante o tempo de execução.

  • dbPath é /var/lib/mongo, que especifica onde MongoDB armazenará seus arquivos de dados.

    Se você instalou o MongoDB no Linux usando um gerenciador de pacotes, como yum ou apt, o arquivo /etc/mongod.conf fornecido com a instalação do MongoDB define o seguinte padrão dbPath, dependendo da sua distribuição Linux:

    Plataforma
    Gerente de pacotes
    Default dbPath
    RHEL / CentOS e Amazon
    yum
    /var/lib/mongo
    SUSE
    zypper
    /var/lib/mongo
    Ubuntu e Debian
    apt
    /var/lib/mongodb
    macOS
    brew
    /usr/local/var/mongodb

    A conta de usuário em que mongod é executado precisará de acesso de leitura e escrita a esse diretório.

  • systemLog.path é /var/log/mongodb/mongod.log, que é onde mongod escreverá sua saída. Se você não definir esse valor, mongod escreverá todo resultado na saída padrão (por exemplo, stdout.)

  • logAppend é true, o que garante que mongod não sobrescreva um arquivo de log existente após a operação de inicialização do servidor.

  • storage.journal.enabled é true, que habilita o registro no diário. O registro no diário garante a durabilidade de gravação de instância única. As compilações de 64 bits do mongod habilitam o registro no diário por padrão. Assim, essa configuração pode ser redundante.

Dada a configuração padrão, alguns desses valores podem ser redundantes. No entanto, em muitas situações, declarar explicitamente a configuração aumenta a inteligibilidade geral do sistema.

As seguintes opções de configuração são úteis para limitar o acesso a uma instância do mongod :

net:
bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
security:
authorization: enabled
net.bindIp

Este exemplo fornece quatro valores para a opção bindIp:

  • localhost, a interface localhost;

  • 10.8.0.10, um endereço IP privado normalmente usado para redes locais e interfaces VPN;

  • 192.168.4.24, uma interface de rede privada normalmente usada para redes locais; e

  • /tmp/mongod.sock, um caminho de soquete de domínio Unix.

Como as instâncias de produção do MongoDB precisam ser acessíveis a partir de vários servidores de banco de dados, é importante vincular o MongoDB a várias interfaces acessíveis a partir de seus servidores de aplicativos. Ao mesmo tempo, é importante limitar estas interfaces a interfaces controladas e protegidas na camada de rede.

security.authorization
Configurar esta opção para true habilita o sistema de autorização dentro do MongoDB. Se ativado, você precisará fazer login conectando-se pela interface localhost pela primeira vez para criar credenciais de usuário.

Dica

Veja também:

A configuração do conjunto de réplicas é simples e requer apenas que o replSetName tenha um valor consistente entre todos os nós do conjunto. Considere o seguinte:

replication:
replSetName: set0

Use nomes descritivos para conjuntos. Após configurado, utilize o mongosh para adicionar hosts ao conjunto de réplica.

Para habilitar a autenticação para o conjunto de réplicas usando keyfiles, adicione a seguinte opção keyFile [1]:

security:
keyFile: /srv/mongodb/keyfile

Definir keyFile habilita a autenticação e especifica um arquivo de chave para o membro do conjunto de réplicas usar ao se autenticar entre si.

Dica

Veja também:

A seção Segurança do conjunto de réplicas para informações sobre como configurar a autenticação com conjuntos de réplicas.

O documento de replicação para obter mais informações sobre replicação no MongoDB e configuração do conjunto de réplicas em geral.

[1] Os clusters fragmentados e os conjuntos de réplicas podem usar x.509 para verificação de associação em vez de arquivos-chave. Para obter detalhes, consulte x.509.

A fragmentação requer mongod instâncias com configurações mongod diferentes para os servidores de configuração e os fragmentos. Os servidores de configuração armazenam os metadados do agrupamento, enquanto os fragmentos armazenam os dados.

Para configurar o servidor de configuraçãomongod instâncias, no arquivo de configuração, especifique configsvr para a configuração sharding.clusterRole.

Observação

Os servidores de configuração devem ser implantados como um conjunto de réplicas.

sharding:
clusterRole: configsvr
net:
bindIp: 10.8.0.12
port: 27001
replication:
replSetName: csRS

Para implantar servidores de configuração como um conjunto de réplica, os servidores de configuração devem executar o WiredTiger Storage Engine. Initiate o conjunto de réplicas e adicionar membros.

Para configurar as instâncias do fragmento mongod, especifique shardsvr para a configuração do sharding.clusterRole e, se estiver executando como um conjunto de réplica, o nome do conjunto de réplica:

sharding:
clusterRole: shardsvr
replication:
replSetName: shardA

Se executar como um conjunto de réplicas, initiate o conjunto de réplicas de shard e adicione membros.

Para o roteador (ou seja, mongos), configure pelo menos um processo mongos com a seguinte configuração:

sharding:
configDB: csRS/10.8.0.12:27001

Você pode especificar membros adicionais da réplica do servidor de configuração definida especificando nomes de host e portas na forma de uma lista separada por vírgula após o nome do conjunto de réplica.

Dica

Veja também:

A seção Fragmentação do manual para obter mais informações sobre fragmentação e configuração de cluster.

Em muitos casos, executar múltiplas instâncias do mongod em um único sistema não é recomendado. Em alguns tipos de implementações [2] e para fins de teste, talvez seja necessário executar mais de um mongod em um único sistema.

Nesses casos, utilize uma configuração de base para cada instância, mas considere os seguintes valores de configuração:

storage:
dbPath: /var/lib/mongo/db0/
processManagement:
pidFilePath: /var/lib/mongo/db0.pid

O valor dbPath controla a localização do diretório de dados da instância mongod. Garanta que cada banco de dados tenha um diretório de dados distinto e bem rotulado. O pidFilePath controla onde o processo mongod coloca seu arquivo de ID de processo (PID). Como isso rastreia o arquivo mongod específico, é crucial que o arquivo seja exclusivo e bem rotulado para facilitar o início e a interrupção desses processos.

Crie scripts de inicialização adicionais e/ou ajuste a configuração existente do MongoDB e o script de inicialização conforme necessário para controlar esses processos.

[2] Sistemas de inquilino único com SSD ou outros discos de alto desempenho podem fornecer níveis de desempenho aceitáveis para múltiplas instâncias do mongod. Além disso, você pode achar que vários bancos de dados com pequenos conjuntos de trabalho podem funcionar de forma aceitável em um único sistema.

As seguintes opções de configuração controlam vários comportamentos do mongod para fins de diagnóstico:

  • operationProfiling.mode define o nível do analisador do banco de dados. O analisador não está ativo por padrão devido ao possível impacto que pode ter sobre o desempenho. A menos que essa configuração esteja ativada, as queries não serão analisadas.

  • operationProfiling.slowOpThresholdMs configures the threshold which determines whether a query is "slow" for the purpose of the logging system and the profiler. The default value is 100 milliseconds. Set to a lower value if the logging system and the database profiler do not return useful results or set to a higher value to only log the longest running queries.

    Os membros secundários de um conjunto de réplicas agora registram entradas de oplog que demoram mais do que o limite de operação lenta para serem aplicadas. Essas mensagens de atraso no oplog:

    • São registradas para os secundários no diagnostic log.

    • São registradas sob o componente REPL com o texto applied op: <oplog entry> took <num>ms.

    • Não dependem dos níveis de registro (seja no nível do sistema ou do componente)

    • Não dependem do nível de perfil.

    • São afetados por slowOpSampleRate.

    O perfilador não captura entradas de oplog lentas.

  • systemLog.verbosity controla a quantidade de saída de registro que mongod grava no registro. Use essa opção somente se você estiver enfrentando um problema que não é refletido no nível de log normal.

    Você também pode especificar o nível de verbosidade para componentes específicos usando a configuração systemLog.component.<name>.verbosity. Para os componentes disponíveis, consulte component verbosity settings.

Para obter mais informações, consulte também Profiler do Banco de Dados e Desempenho do MongoDB.

Voltar

Configuração e manutenção