Menu Docs
Página inicial do Docs
/ /

Opções de arquivo de configuração autogerenciado

As opções de arquivo de configuração nesta página se aplicam ao MongoDB 8.0. Para opções em outras versões, consulte a versão apropriada do Manual do MongoDB.

Observação

Se você estiver utilizando o MongoDB Atlas para gerenciar suas implantações MongoDB na nuvem, você não precisará criar um arquivo de configuração. Para aprender como configurar as configurações para sua implantação do MongoDB Atlas, consulte Configurar Configurações Adicionais.

Os binários do MongoDB também leem variáveis de ambiente do sistema operacional.

Você pode configurar as instâncias mongod e mongos na inicialização usando um arquivo de configuração. O arquivo de configuração contém configurações que são equivalentes às opções de linha de comando mongod e mongos. Consulte Mapeamento de opções de linha de comando e configuração autogerenciada.

Você também pode adicionar comentários ao arquivo de configuração para explicar as configurações do servidor.

  • 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 (on processadores Apple M1)

    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.

Os arquivos de configuração do MongoDB usam o formato YAML [1].

O seguinte arquivo de configuração de amostra inclui várias configurações do mongod:

Observação

O YAML não suporta caracteres de tabulação para indentação: em vez disso, use espaços.

systemLog:
destination: file
path: "/var/log/mongodb/mongod.log"
logAppend: true
processManagement:
fork: true
net:
bindIp: 127.0.0.1
port: 27017
setParameter:
enableLocalhostAuthBypass: false
...

Os scripts de inicialização do pacote Linux incluídos nos pacotes oficiais do MongoDB dependem de valores específicos para systemLog.path, storage.dbPath e processManagement.fork ou variável de ambiente do sistema MONGODB_CONFIG_OVERRIDE_NOFORK. Se você modificar essas configurações no arquivo de configuração padrão, mongod pode não iniciar.

[1] YAML é um superconjunto de JSON.

Observação

O MongoDB suporta o uso de diretivas de expansão em arquivos de configuração para carregar valores de origem externa. As diretivas de expansão podem carregar valores para opções específicas do arquivo de configuração ou carregar todo o arquivo de configuração.

As seguintes diretivas de expansão estão disponíveis:

Diretiva de expansão
Descrição

Permite que os usuários especifiquem um endpoint REST como fonte externa para as opções do arquivo de configuração ou o arquivo de configuração completo.

Se o arquivo de configuração incluir a expansão __rest, no Linux/macOS, o acesso de leitura ao arquivo de configuração deverá ser limitado apenas ao usuário que estiver executando o processo mongod / mongos apenas.

Permite que os usuários especifiquem um comando shell ou terminal como a origem externa para opções de arquivo de configuração ou o arquivo de configuração completo.

Se o arquivo de configuração incluir a expansão __exec, no Linux/macOS, o acesso de gravação ao arquivo de configuração deverá ser limitado apenas ao usuário que estiver executando o processo mongod / mongos apenas.

Para obter a documentação completa, consulte Valores de configuração externa para MongoDB autogerenciado.

Para configurar mongod ou mongos usando um arquivo de configuração, especifique o arquivo de configuração com a opção --config ou a opção -f, como nos exemplos a seguir:

mongod --config /etc/mongod.conf
mongos --config /etc/mongos.conf

Você também pode usar o alias -f:

mongod -f /etc/mongod.conf
mongos -f /etc/mongos.conf

Se você instalou a partir de um pacote e iniciou o MongoDB usando o script de inicialização do sistema, já está usando um arquivo de configuração.

Se você estiver utilizando diretivas de expansão no arquivo de configuração, você deverá incluir a opção --configExpand ao iniciar o mongod ou mongos. Por exemplo:

mongod --config /etc/mongod.conf --configExpand "rest,exec"
mongos --config /etc/mongos.conf --configExpand "rest,exec"

Se o arquivo de configuração incluir uma diretiva de expansão e você iniciar o mongod / mongos sem especificar esta diretiva na opção --configExpand, o mongod / mongos falhará ao iniciar.

systemLog:
verbosity: <int>
quiet: <boolean>
traceAllExceptions: <boolean>
syslogFacility: <string>
path: <string>
logAppend: <boolean>
logRotate: <string>
destination: <string>
timeStampFormat: <string>
component:
accessControl:
verbosity: <int>
command:
verbosity: <int>
# COMMENT additional component verbosity settings omitted for brevity
systemLog.verbosity

Tipo: inteiro

Padrão: 0

O nível de detalhamento da mensagem de log padrão para componentes. O nível de verbosidade determina a quantidade de mensagens informativas e de depuração que o MongoDB emite. [2]

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

Para usar um nível de verbosidade diferente para um componente nomeado, use a configuração de verbosidade do componente. Por exemplo, use o systemLog.component.accessControl.verbosity para definir o nível de verbosidade específico dos componentes ACCESS.

Consulte as configurações do systemLog.component.<name>.verbosity para configurações de verbosidade de componente específicas.

Para ver várias maneiras de definir o nível de verbosidade do registro, consulte Configurar níveis de verbosidade do registro.

[2] A partir da versão 4.2, o MongoDB inclui o nível de verbosidade de depuração (1-5) nas mensagens de registro. Por exemplo, se o nível de verbosidade for 2, o MongoDB registrará D2. Em versões anteriores, as mensagens de registro do MongoDB especificavam somente D para o nível de depuração.
systemLog.quiet

Tipo: booleano

Padrão: false

Execute mongos ou mongod em um modo silencioso que tente limitar a quantidade de saída.

systemLog.quiet não é recomendado para sistemas de produção, pois pode dificultar muito o rastreamento de problemas durante conexões específicas.

systemLog.traceAllExceptions

Tipo: booleano

Padrão: false

Imprima informações verbais para depuração. Use para registro adicional para solução de problemas relacionados ao suporte.

systemLog.syslogFacility

Tipo: string

Usuário padrão

O nível da instalação utilizado ao registrar mensagens no syslog. O valor especificado deve ser aceito pela implementação de syslog do seu sistema operacional. Para usar essa opção, você deve configurar systemLog.destination como syslog.

systemLog.path

Tipo: string

O caminho do arquivo de log para o qual mongod ou mongos deve enviar todas as informações de registro de diagnóstico, em vez da saída padrão ou do syslog do hospedar. O MongoDB cria o arquivo de log no caminho especificado.

Os scripts de inicialização do pacote Linux não esperam que systemLog.path mude dos padrões. Se você usar os pacotes Linux e alterar systemLog.path, deverá usar seus próprios scripts de inicialização e desabilitar os scripts integrados.

systemLog.logAppend

Tipo: booleano

Padrão: false

Quando true, mongos ou mongod acrescenta novas entradas ao final do arquivo de log existente quando a instância é reiniciada. Sem essa opção, mongod ou mongos fará backup do log existente e criará um novo arquivo.

systemLog.logRotate

Tipo: string

Padrão: renomear

Determina o comportamento do comando logRotate ao girar o log do servidor e/ou o log de auditoria. Especifique rename ou reopen:

  • rename renomeia o arquivo de log.

  • reopen fecha e reabre o arquivo de log seguindo o comportamento típico de rotação de registro Linux/Unix. Utilize o reopen ao usar o utilitário de rotação de registro Linux/Unix para evitar perda de registro.

    Se você especificar reopen, também deverá configurar systemLog.logAppend como true.

systemLog.destination

Tipo: string

O destino para o qual o MongoDB envia toda a saída de log. Especifique file ou syslog. Se você especificar file, você também deverá especificar systemLog.path.

Se você não especificar systemLog.destination, o MongoDB enviará todos os resultados de log para saída padrão.

Aviso

O daemon syslog gera carimbos de data/hora quando registra uma mensagem, não quando o MongoDB emite a mensagem. Isso pode levar a carimbos de data/hora enganosos para entradas de log, especialmente quando o sistema está sob carga pesada. Recomendamos usar a opção file para sistemas de produção para garantir carimbos de data/hora precisos.

systemLog.timeStampFormat

Tipo: string

Default: iso8601-local

O formato de hora para carimbos de data/hora em mensagens de registro. Especifique um dos valores a seguir:

Valor
Descrição

iso8601-utc

Exibe carimbos de data/hora em Tempo Universal Coordenado (UTC) no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1970-01-01T00:00:00.000Z

iso8601-local

Exibe carimbos de data e hora na hora local no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1969-12-31T19:00:00.000-05:00

Observação

O formato de carimbo de data/hora ctime não é mais aceito. Um exemplo de data formatada ctime é: Wed Dec 31 18:17:54.811.

systemLog:
component:
accessControl:
verbosity: <int>
command:
verbosity: <int>
# COMMENT some component verbosity settings omitted for brevity
replication:
verbosity: <int>
election:
verbosity: <int>
heartbeats:
verbosity: <int>
initialSync:
verbosity: <int>
rollback:
verbosity: <int>
storage:
verbosity: <int>
journal:
verbosity: <int>
recovery:
verbosity: <int>
write:
verbosity: <int>

Observação

A partir da versão 4.2, o MongoDB inclui o nível de verbosidade de depuração (1-5) nas mensagens de registro. Por exemplo, se o nível de verbosidade for 2, o MongoDB registrará D2. Em versões anteriores, as mensagens de registro do MongoDB especificavam somente D para o nível de depuração.

systemLog.component.assert.verbosity

Tipo: inteiro

Padrão: 0

O nível de detalhamento da mensagem de log para asserções encontradas em operações de usuário no MongoDB. Normalmente, uma asserção é acionada quando uma operação retorna um erro. Consulte componentes do ASSERT.

systemLog.component.accessControl.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de log para componentes relacionados ao controle de acesso. Consulte componentes do ACCESS.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.command.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados a comandos. Consulte COMMAND componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.control.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de controle. Consulte CONTROL componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.ftdc.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de log para componentes relacionados às operações de coleta de dados de diagnóstico. Consulte componentes do FTDC.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.geo.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de log para componentes relacionados às operações de análise geoespacial. Consulte GEO componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.index.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de indexação. Consulte componentes do INDEX.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.network.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de rede. Consulte NETWORK componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.query.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de consulta. Consulte QUERY componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.query.rejected.verbosity

Tipo: inteiro

Padrão: 0

Novidades na versão 8.0.

O nível de detalhamento da mensagem de log para componentes relacionados a operações de consulta rejeitadas. Para obter detalhes, consulte o componente REJECTED.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.queryStats.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados a invocações de $queryStats. Consulte componentes QUERYSTATS.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão e inclui apenas mensagens informativas . Não há chamadas $queryStats registradas neste nível.

  • 1 para 2 aumenta o nível de verbosidade para incluir chamadas $queryStats onde algorithm é "hmac-sha-256". Todas as chaves HMAC são redigidas.

  • 3 para 5 aumenta o nível de detalhamento para incluir chamadas $queryStats onde algorithm é "hmac-sha-256", e os resultados correspondentes. Cada resultado é sua própria entrada e há uma entrada final com a string "we finished".

systemLog.component.replication.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à replicação. Consulte REPL componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.replication.election.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à eleição. Consulte ELECTION componentes.

Se systemLog.component.replication.election.verbosity não estiver definido, o nível systemLog.component.replication.verbosity também se aplicará aos componentes de eleição.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.replication.heartbeats.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados a batidas cardíacas. Consulte REPL_HB componentes.

Se systemLog.component.replication.heartbeats.verbosity não estiver definido, o nível systemLog.component.replication.verbosity também se aplicará aos componentes de batimentos cardíacos.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.replication.initialSync.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados ao initialSync. Veja os componentes INITSYNC.

Se systemLog.component.replication.initialSync.verbosity estiver desmarcado, o nível systemLog.component.replication.verbosity também se aplicará aos componentes do initialSync.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.replication.rollback.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à reversão. Consulte componentes do ROLLBACK.

Se systemLog.component.replication.rollback.verbosity estiver desmarcado, o nível de systemLog.component.replication.verbosity também se aplica aos componentes de rollback.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.sharding.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados ao sharding. Consulte SHARDING componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados ao armazenamento. Consulte componentes do STORAGE.

Se systemLog.component.storage.journal.verbosity não estiver definido, o nível systemLog.component.storage.verbosity também se aplicará aos componentes de registro no diário.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.journal.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à diário. Consulte componentes do JOURNAL.

Se systemLog.component.storage.journal.verbosity não estiver configurado, os componentes de registro no diário terão o mesmo nível de detalhamento que os componentes de armazenamento pai: isto é, o nível do systemLog.component.storage.verbosity se configurado ou o nível de detalhamento padrão.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.recovery.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à recuperação. Consulte componentes do RECOVERY.

Se systemLog.component.storage.recovery.verbosity não estiver definido, o nível systemLog.component.storage.verbosity também se aplicará aos componentes de recuperação.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O nível de verbosidade da mensagem de log para componentes relacionados ao mecanismo de armazenamento WiredTiger. Consulte componentes do WT.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtBackup.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O nível de detalhamento da mensagem de log para componentes relacionados a operações de backup executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTBACKUP.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtCheckpoint.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de ponto de verificação executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTCHKPT.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtCompact.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados às operações de compactação realizadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTCMPCT.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtEviction.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de despejo realizadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTEVICT.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtHS.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de armazenamento de histórico executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTHS.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtRecovery.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de recuperação executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTRECOV.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtRTS.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de rollback para estável (RTS) executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTRTS.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtSalvage.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados às operações de recuperação realizadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTSLVG.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtTimestamp.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a logs de data e hora usados pelo mecanismo de armazenamento do WiredTiger. Consulte componentes do WTTS.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtTransaction.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados às operações de transação realizadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTTXN.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtVerify.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de registro para componentes relacionados a operações de verificação realizadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTVRFY.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.storage.wt.wtWriteLog.verbosity

Tipo: inteiro

Padrão: -1

Novidades na versão 5.3.

O detalhamento da mensagem de log para componentes relacionados a operações de gravação de log executadas pelo mecanismo de armazenamento WiredTiger. Consulte componentes do WTWRTLOG.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.transaction.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados à transação. Consulte TXN componentes.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

systemLog.component.write.verbosity

Tipo: inteiro

Padrão: 0

O nível de verbosidade da mensagem de registro para componentes relacionados às operações de gravação. Consulte componentes do WRITE.

O nível de verbosidade pode variar de 0 a 5:

  • 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

  • 1 para 5 aumenta o nível de detalhamento para incluir mensagens de Depuração.

processManagement:
fork: <boolean>
pidFilePath: <string>
timeZoneInfo: <string>
processManagement.fork

Tipo: booleano

Padrão: false

Ative um modo daemon que execute o processo mongos ou mongod em segundo plano. Por padrão, mongos ou mongod não é executado como um daemon. Para usar mongos ou mongod como um daemon, defina processManagement.fork ou use um processo de controle que lide com o processo de daemonização (por exemplo, systemd).

A opção processManagement.fork não é aceita no Windows.

Os scripts de inicialização do pacote Linux não esperam que processManagement.fork mude dos padrões. Se você usar os pacotes Linux e alterar processManagement.fork, deverá usar seus próprios scripts de inicialização e desabilitar os scripts integrados.

Observação

Alternativamente, você pode configurar a variável de ambiente do MONGODB_CONFIG_OVERRIDE_NOFORK em seu sistema para true para executar o processo do mongos ou mongod no segundo plano. Se você definir a variável de ambiente, ela substituirá a configuração de processManagement.fork.

processManagement.pidFilePath

Tipo: string

Especifica uma localização de arquivo para armazenar o ID de processo (PID) do processo mongos ou mongod. O usuário que executa o processo mongod ou mongos deve ser capaz de gravar nesse caminho. Se a opção processManagement.pidFilePath não for especificada, o processo não criará um arquivo PID. Em geral, essa opção só é útil em combinação com a configuração processManagement.fork.

Observação

Linux

No Linux, o gerenciamento de arquivos PID geralmente é de responsabilidade do sistema de inicialização da sua distribuição: geralmente, um arquivo de serviço no diretório /etc/init.d ou um arquivo de unidade systemd registrado em systemctl. Só use a opção processManagement.pidFilePath se não estiver usando um desses sistemas de inicialização. Para obter mais informações, consulte o respectivo Guia de instalação do seu sistema operacional.

Observação

macOS

No macOS, o gerenciamento de arquivos PID geralmente é tratado por brew. Use somente a opção processManagement.pidFilePath se você não estiver usando brew no seu sistema macOS. Para obter mais informações, consulte o respectivo Guia de Instalação do seu sistema operacional.

processManagement.timeZoneInfo

Tipo: string

O caminho completo a partir do qual carregar o banco de dados de fuso horário. Se esta opção não for fornecida, o MongoDB usará seu banco de dados de fuso horário integrado.

O arquivo de configuração incluído com pacotes Linux e macOS define o caminho do banco de dados de fuso horário para /usr/share/zoneinfo por padrão.

O banco de dados de fuso horário embutido é uma cópia do banco de dados de fuso horário Olson/IANA. Ele é atualizado junto com as versões do MongoDB, mas o ciclo de lançamento da zona de fuso horário é diferente do ciclo de lançamento do MongoDB. A versão mais recente do banco de dados de fuso horário está disponível em nosso site de download.

Aviso

O MongoDB usa a biblioteca timelib de terceiros para fornecer conversões precisas entre fusos horários. Devido a uma atualização recente, o timelib pode criar conversões de zona horário imprecisas em versões mais antigas do MongoDB.

Para vincular explicitamente ao banco de dados de fuso horário em versões do MongoDB anteriores à 5.0, baixe o banco de dados de fusos horários. e use o parâmetro timeZoneInfo .

Alterado na versão 5,0: MongoDB remove a opção de configuração do net.serviceExecutor e a opção correspondente de linha de comando do --serviceExecutor.

net:
port: <int>
bindIp: <string>
bindIpAll: <boolean>
maxIncomingConnections: <int>
wireObjectCheck: <boolean>
ipv6: <boolean>
unixDomainSocket:
enabled: <boolean>
pathPrefix: <string>
filePermissions: <int>
tls:
certificateSelector: <string>
clusterCertificateSelector: <string>
mode: <string>
certificateKeyFile: <string>
certificateKeyFilePassword: <string>
clusterFile: <string>
clusterPassword: <string>
CAFile: <string>
clusterCAFile: <string>
clusterAuthX509:
attributes: <string>
extensionValue: <string>
CRLFile: <string>
allowConnectionsWithoutCertificates: <boolean>
allowInvalidCertificates: <boolean>
allowInvalidHostnames: <boolean>
disabledProtocols: <string>
FIPSMode: <boolean>
logVersions: <string>
compression:
compressors: <string>
net.port

Tipo: inteiro

Padrão:

  • 27017 para mongod (se não for um membro do shard ou um membro do servidor de configuração) ou instância do mongos

  • 27018 se mongod for um shard member

  • 27019 se mongod for um nó de servidor de configuração

A porta TCP na qual a instância do MongoDB escuta conexão de cliente.

A opção net.port aceita um intervalo de valores entre 0 e 65535. Configurar a porta para 0 configura mongos ou mongod para utilizar uma porta arbitrária atribuída pelo sistema operacional.

net.bindIp

Tipo: string

Padrão: localhost

Os nomes de host e/ou endereços IP e/ou caminhos completos de soquete de domínio Unix nos quais mongos ou mongod devem escutar as conexões do cliente. Você pode anexar mongos ou mongod a qualquer interface. Para vincular a vários endereços, insira uma lista de valores separados por vírgula.

Exemplo

localhost,/tmp/mongod.sock

Você pode especificar endereços IPv4 e IPv6 ou nomes de host que resolvem para um endereço IPv4 ou IPv6.

Exemplo

localhost, 2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513

Observação

Se estiver especificando um endereço IPv6 ou um nome de host que resolva para um endereço IPv6 para net.bindIp, é preciso executar o mongos ou mongod com net.ipv6 : true para habilitar o suporte a IPv6 . Especificar um endereço IPv6 para net.bindIp não habilita o compatibilidade com IPv6.

Se especificar um endereço IPv6 local de link (fe80::/10), você deverá acrescentar o índice da zona para esse endereço (ou seja, fe80::<address>%<adapter-name>).

Exemplo

localhost,fe80::a00:27ff:fee0:1fcf%enp0s3

Importante

Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.

Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.

Aviso

Antes de vincular sua instância a um endereço IP acessível publicamente, você deve proteger seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte Lista de verificação de segurança para implantações autogerenciadas. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.

Para obter mais informações sobre vinculação de IP, consulte a documentação de vinculação de IP em implantações autogerenciadas.

Para vincular a todos os endereços IPv4, digite 0.0.0.0.

Para se vincular a todos os endereços IPv4 e IPv6, digite ::,0.0.0.0 ou um asterisco "*" (coloque o asterisco entre aspas para diferenciá-lo dos nós de alias YAML). Como alternativa, use a configuração net.bindIpAll.

Observação

  • net.bindIp e net.bindIpAll são mutuamente exclusivos. Ou seja, você pode especificar um ou outro, mas não ambos.

  • A opção de linha de comando --bind_ip substitui a configuração do arquivo de configuração net.bindIp.

Para configurar nós de cluster para DNS de horizonte dividido, use nomes de host em vez de endereços IP.

Começando no MongoDB v5,0, replSetInitiate e replSetReconfig rejeitam configurações que usam endereços IP em vez de nomes de host.

Use disableSplitHorizonIPCheck para modificar nós que não podem ser atualizados para usar nomes de host. O parâmetro se aplica somente aos comandos de configuração.

mongod e mongos não dependem de disableSplitHorizonIPCheck para validação na inicialização. As instâncias legadas de mongod e mongos que usam endereços IP em vez de nomes de hospedar podem ser iniciadas após uma atualização.

As instâncias configuradas com endereços IP registram um aviso para usar nomes de host em vez de endereços IP.

net.bindIpAll

Tipo: booleano

Padrão: false

Se for verdadeiro, a instância mongos ou mongod se vinculará a todos os endereços IPv4 (ou seja, 0.0.0.0). Se mongos ou mongod começar com net.ipv6 : true, net.bindIpAll também se vinculará a todos os endereços IPv6 (ou seja, ::).

mongos ou mongod só oferece suporte a IPv6 se iniciado com net.ipv6 : true. Especificar net.bindIpAll por si só não habilita o suporte a IPv6.

Aviso

Antes de vincular sua instância a um endereço IP acessível publicamente, você deve proteger seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte Lista de verificação de segurança para implantações autogerenciadas. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.

Para obter mais informações sobre vinculação de IP, consulte a documentação Vinculação de IP.

Como alternativa, defina net.bindIp como ::,0.0.0.0 ou como um asterisco "*" (coloque o asterisco entre aspas para diferenciá-lo dos nós do alias YAML) para vincular-se a todos os endereços IP.

Observação

net.bindIp e net.bindIpAll são mutuamente exclusivos. Especificar ambas as opções faz com que mongos ou mongod gere um erro e encerre.

net.maxIncomingConnections

Tipo: inteiro

Alterado na versão 8.1: (e 8.0.16, 7.0.31)

Default (Windows): 1,000,000
Default (Linux): (RLIMIT_NOFILE / 2) * 0.8

Observação

No Linux, net.maxIncomingConnections deve ser menor ou igual ao valor de (RLIMIT_NOFILE / 2) * 0.8. Se você tentar definir um valor maior, o MongoDB usará automaticamente o padrão.

O número máximo de conexões simultâneas que mongos ou mongod aceita. Esta configuração não terá efeito se for maior do que o limite máximo de rastreamento de conexão configurado pelo sistema operacional.

Não atribua um valor muito baixo a essa opção ou poderá encontrar erros durante a operação normal do aplicativo.

Isso é particularmente útil para um mongos se você tiver um cliente que cria várias conexões e permite que elas atinjam o tempo limite em vez de fechá-las.

Neste caso, defina maxIncomingConnections como um valor um pouco maior que o número máximo de conexões que o cliente cria ou o tamanho máximo do pool de conexões.

Essa configuração impede que mongos cause picos de conexão nos fragmentos individuais. Picos como esses podem interromper a operação e a alocação de memória do cluster fragmentado.

net.wireObjectCheck

Tipo: booleano

Padrão: true

Quando true, a instância mongod ou mongos valida todas as solicitações dos clientes no recebimento para evitar que os clientes insiram BSON malformado ou inválido em um banco de dados do MongoDB.

Para objetos com um alto grau de aninhamento de subdocumentos, o net.wireObjectCheck pode ter um pequeno impacto no desempenho.

net.ipv6

Tipo: booleano

Padrão: false

Defina net.ipv6 como true para ativar o suporte IPv6. mongos/mongod desativa o suporte a IPv6 por padrão.

A configuração net.ipv6 não direciona o mongos/mongod para escutar em nenhum endereço ou interface IPv6 local. Para configurar o mongos/mongod para escutar em uma interface IPv6, você tem as seguintes opções:

  • Configure net.bindIp com um ou mais endereços IPv6 ou nomes de host que resolvam para endereços IPv6, ou

  • Defina net.bindIpAll como true.

net:
unixDomainSocket:
enabled: <boolean>
pathPrefix: <string>
filePermissions: <int>
net.unixDomainSocket.enabled

Tipo: booleano

Padrão: true

Ative ou desative a escuta no soquete de domínio UNIX. net.unixDomainSocket.enabled aplica-se apenas a sistemas baseados em Unix.

Quando net.unixDomainSocket.enabled é true, o mongos ou mongod escuta o soquete UNIX.

O processo mongos ou mongod sempre escuta no soquete UNIX, a menos que uma das seguintes opções seja verdadeira:

  • net.unixDomainSocket.enabled é false

  • --nounixsocket está definido. A opção da linha de comando tem precedência sobre a configuração do arquivo de configuração.

  • net.bindIp não está definido

  • net.bindIp não especifica localhost ou seu endereço IP associado

mongos ou mongod instalados a partir dos pacotes oficiais Debian e Red Hat ou CentOS têm a configuração bind_ip definida como 127.0.0.1 por padrão.

net.unixDomainSocket.pathPrefix

Tipo: string

Padrão: /tmp

O caminho para o soquete UNIX. net.unixDomainSocket.pathPrefix aplica-se apenas a sistemas baseados em Unix.

Se esta opção não tiver nenhum valor, o processo mongos ou mongod cria um soquete com /tmp como prefixo. O MongoDB cria e escuta em um soquete UNIX, a menos que um dos seguintes seja verdadeiro:

  • net.unixDomainSocket.enabled é false

  • --nounixsocket está definido

  • net.bindIp não está definido

  • net.bindIp não especifica localhost ou seu endereço IP associado

net.unixDomainSocket.filePermissions

Tipo: int

Padrão: 0700

Define a permissão para o arquivo de soquete de domínio UNIX.

net.unixDomainSocket.filePermissions aplica-se apenas a sistemas baseados em Unix.

Observação

As opções tls oferecem funcionalidade idêntica às opções ssl anteriores.

net:
tls:
mode: <string>
certificateKeyFile: <string>
certificateKeyFilePassword: <string>
certificateSelector: <string>
clusterCertificateSelector: <string>
clusterFile: <string>
clusterPassword: <string>
clusterAuthX509:
attributes: <string>
extensionValue: <string>
CAFile: <string>
clusterCAFile: <string>
CRLFile: <string>
allowConnectionsWithoutCertificates: <boolean>
allowInvalidCertificates: <boolean>
allowInvalidHostnames: <boolean>
disabledProtocols: <string>
FIPSMode: <boolean>
logVersions: <string>
net.tls.mode

Tipo: string

Ativa o TLS usado para todas as conexões de rede. O argumento para a configuração net.tls.mode pode ser um dos seguintes:

Valor
Descrição

disabled

O servidor não usa TLS.

allowTLS

As conexões entre servidores não usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.

preferTLS

As conexões entre servidores usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.

requireTLS

O servidor usa e aceita apenas conexões criptografadas TLS.

Se --tlsCAFile ou tls.CAFile não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados de CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Se estiver usando a autenticação X.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando --tlsCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateKeyFile

Tipo: string

O arquivo .pem que contém o certificado e a chave TLS.

No macOS ou no Windows, você pode usar a configuração net.tls.certificateSelector para especificar um certificado do armazenamento de certificados seguro do sistema operacional em vez de um arquivo de chave PEM. certificateKeyFile e net.tls.certificateSelector são mutuamente exclusivos. Você só pode especificar um.

  • No Linux/BSD, você deve especificar net.tls.certificateKeyFile quando o TLS estiver habilitado.

  • No Windows ou macOS, você deve especificar net.tls.certificateKeyFile ou net.tls.certificateSelector quando o TLS estiver habilitado.

    Importante

    Para Windows apenas, o MongoDB não suporta arquivos PEM criptografados. O mongod não iniciará se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com TLS no Windows, use net.tls.certificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateKeyFilePassword

Tipo: string

A senha para descriptografar o arquivo da chave de certificado (ou seja, certificateKeyFile). Utilize a opção net.tls.certificateKeyFilePassword somente se o arquivo da chave de certificado for criptografado. Em todos os casos, o mongos ou mongod elimina a senha de todos os registros e relatórios.

No Linux/BSD, se a chave privada no arquivo PEM estiver criptografada e você não especificar a opção net.tls.certificateKeyFilePassword, o MongoDB solicitará uma senha.

Para obter mais informações, consulte a página Frase-senha do certificado TLS/SSL.

No macOS, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção net.tls.certificateKeyFilePassword. Como alternativa, você pode usar um certificado do armazenamento de sistema seguro (consulte net.tls.certificateSelector) em vez de um arquivo de chave PEM ou usar um arquivo PEM não criptografado.

No Windows, o MongoDB não oferece suporte a certificados criptografados. mongod falha se encontrar um arquivo PEM criptografado. Em vez disso, use net.tls.certificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.certificateSelector

Tipo: string

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para usar para TLS/SSL. Disponível no Windows e macOS como alternativa para net.tls.certificateKeyFile.

net.tls.certificateKeyFile e as opções net.tls.certificateSelector são mutuamente exclusivas. Você só pode especificar uma.

net.tls.certificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade
Tipo de valor
Descrição

subject

string ASCII

Nome do assunto ou nome comum no certificado

thumbprint

string hexadecimal

Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.

O thumbprint às vezes é denominado fingerprint.

Ao usar o armazenamento de certificados SSL do sistema, o OCSP (Online Certificate Status Protocol) é usado para validar o status de revogação dos certificados.

O mongod pesquisa no armazenamento seguro de certificados do sistema operacional os certificados CA necessários para validar a sequência completa de certificados do certificado TLS especificado. Especificamente, o armazenamento de certificados seguro deve conter a CA raiz e quaisquer certificados de CA intermediários necessários para construir a sequência completa de certificados para o certificado TLS.

Aviso

Se você usar net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não recomendamos o uso de net.tls.CAFile ou net.tls.clusterFile para especificar o certificado CA raiz e intermediário

Por exemplo, se o certificado TLS tiver sido assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado TLS foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

Observação

Você não pode usar o comando rotateCertificates nem o método de shell db.rotateCertificates() ao usar net.tls.certificateSelector ou --tlsCertificateSelector configurado como thumbprint

net.tls.clusterCertificateSelector

Tipo: string

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento seguro de certificados do sistema operacional para usar para autenticação de assinatura x.509 interna.

Disponível no Windows e macOS como alternativa para net.tls.clusterFile.

net.tls.clusterFile e as opções net.tls.clusterCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

net.tls.clusterCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade
Tipo de valor
Descrição

subject

string ASCII

Nome do assunto ou nome comum no certificado

thumbprint

string hexadecimal

Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.

O thumbprint às vezes é denominado fingerprint.

O mongod busca no armazenamento seguro de certificados do sistema operacional os certificados CA necessários para validar a sequência completa de certificados do certificado de cluster especificado. Especificamente, o armazenamento de certificados seguro deve conter CA raiz e quaisquer certificados CA intermediários necessários para construir a sequência completa de certificados para o certificado de cluster.

Aviso

Se você usar net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não recomendamos o uso de net.tls.CAFile ou net.tls.clusterCAFile para especificar o certificado CA raiz e intermediário.

Por exemplo, se o certificado de cluster tiver sido assinado com um único certificado CA raiz, o armazenamento de certificados seguro deverá conter esse certificado CA raiz. Se o certificado de cluster foi assinado com um certificado CA intermediário, o armazenamento de certificados seguro deverá conter o certificado CA intermediário e o certificado CA raiz.

O mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias do horário do sistema host mongod/mongos.

net.tls.clusterFile

Tipo: string

O arquivo .pem que contém o arquivo de chave de certificado x.509 para autenticação de associação para o cluster ou conjunto de réplicas.

No macOS ou no Windows, você pode usar a opção net.tls.clusterCertificateSelector para especificar um certificado do armazenamento de certificados seguro do sistema operacional em vez de um arquivo de chave PEM. As opções net.tls.clusterFile e net.tls.clusterCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Se net.tls.clusterFile não especificar o arquivo .pem para autenticação de cluster interno ou a alternativa net.tls.clusterCertificateSelector, o cluster utilizará o arquivo .pem especificado na configuração certificateKeyFile ou o certificado retornado pelo net.tls.certificateSelector.

Se estiver usando a autenticação X.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando --tlsCertificateSelector.

O mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias do horário do sistema host mongod/mongos.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

Importante

Para Windows apenas, o MongoDB não suporta arquivos PEM criptografados. O mongod falha ao iniciar se encontrar um arquivo PEM criptografado. Para armazenar e acessar com segurança um certificado para uso com autenticação de associação no Windows, use net.tls.clusterCertificateSelector.

net.tls.clusterPassword

Tipo: string

A senha para descriptografar o arquivo de chave de certificado X.509 especificado com --sslClusterFile. Utilize a opção net.tls.clusterPassword somente se o arquivo da chave de certificado for criptografado. Em todos os casos, mongos ou mongod edita a senha de todos os resultados de emissão de relatório e registro.

No Linux/BSD, se a chave privada no arquivo X.509 estiver criptografada e você não especificar a opção net.tls.clusterPassword, o MongoDB solicitará uma senha.

Para obter mais informações, consulte ssl-certificate-password.

No macOS, se a chave privada no arquivo X.509 estiver criptografada, você deverá especificar explicitamente a opção net.tls.clusterPassword. Como alternativa, você pode usar um certificado do armazenar seguro do sistema (consulte net.tls.clusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

No Windows, o MongoDB não oferece suporte a certificados criptografados. O mongod falha se encontrar um arquivo PEM criptografado. Use net.tls.clusterCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.clusterAuthX509

Novidades na versão 7.0.

net:
tls:
clusterAuthX509:
attributes: <string>
extensionValue: <string>
net.tls.clusterAuthX509.attributes

Tipo: string

Novidades na versão 7.0.

Especifica um conjunto de atributos e valores de nome distinto (DN) X.509 que o servidor espera que os nós dos membros do cluster contenham em seus nomes de assunto de certificado. Isso permite que você utilize certificados que não contêm valores DC, O e OU para autenticar membros do cluster.

Quando attributes é definido, o MongoDB corresponde aos certificados usando o DN e ignora os valores de extensão.

net.tls.clusterAuthX509.extensionValue

Tipo: string

Novidades na versão 7.0.

Especifica um valor de extensão que corresponde à extensão de associação de cluster do MongoDB OID, 1.3.6.1.4.1.34601.2.1.2. O servidor espera que os nós do cluster contenham essa extensão em seus certificados. Isso permite que você utilize certificados que não contêm valores DC, O e OU para autenticar nós do cluster.

Ao definir extensionValue, o MongoDB faz a correspondência de certificados usando valores de extensão de certificado e ignora o DN (Nome Distinto).

Ao criar um certificado com OID 1.3.6.1.4.1.34601.2.1.2, considere as seguintes diretrizes:

  • Mantenha o valor da extensão abaixo de 128 bytes.

  • Use uma única string UTF8como valor interno da extensão. mongod não aceita outros tipos de string.

  • Se você usar OpenSSL, deverá especificar explicitamente o tipo ASN.1 , para que ele codifique uma string8UTF. Por exemplo:

    • Na linha de comando, especifique -addext: 1.3.6.1.4.1.34601.2.1.2=ASN1:UTF8String:<your-value>.

    • Em um arquivo de configuração OpenSSL, especifique 1.3.6.1.4.1.34601.2.1.2 = ASN1:UTF8String:<your-value>.

    Aviso

    Se você omitir ASN1:UTF8String:, o OpenSSL poderá escolher uma codificação ou octets brutos diferente, que mongod rejeita com uma tag "Unsupported tag" ou "Unknown DER".

net.tls.CAFile

Tipo: string

O arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Somente Windows/macOS
Se estiver usando net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não use net.tls.CAFile para especificar os certificados CA raiz e intermediários. Armazene todos os certificados CA necessários para validar toda a sequência de confiança dos certificados net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.clusterCAFile

Tipo: string

O arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação usada para validar o certificado apresentado por um cliente que estabelece uma conexão. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos. net.tls.clusterCAFile exige que net.tls.CAFile seja definido.

Se net.tls.clusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente que está estabelecendo uma conexão, o cluster utilizará o arquivo .pem especificado na opção net.tls.CAFile.

net.tls.clusterCAFile permite que você use autoridades de certificação separadas para verificar as partes cliente-servidor e servidor-cliente do handshake TLS.

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenar seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte net.tls.clusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o net.tls.clusterCAFile.

Somente Windows/macOS
Se estiver usando net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector, não use net.tls.clusterCAFile para especificar os certificados CA raiz e intermediários. Armazene todos os certificados CA necessários para validar toda a sequência de confiança dos certificados net.tls.certificateSelector e/ou net.tls.clusterCertificateSelector no armazenamento seguro de certificados.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.CRLFile

Tipo: string

O arquivo .pem que contém a lista de revogação de certificado. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Observação

  • Você não pode especificar net.tls.CRLFile no macOS. Em vez disso, você pode usar o armazenamento de certificados SSL do sistema, que usa OCSP (online Certificate Status protocolo) para validar o status de revogação dos certificados. Consulte net.tls.certificateSelector para usar o armazenamento de certificados SSL do sistema.

  • Para verificar a revogação de certificados, o MongoDB enables o uso do OCSP (Protocolo de Status de Certificado Online, Online Certificate Status Protocol na língua inglesa) por padrão, como alternativa à especificação de um arquivo CRL ou ao uso do armazenamento de certificados SSL do sistema.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.allowConnectionsWithoutCertificates

Tipo: booleano

Padrão: false

Se false, todos os clientes devem fornecer certificados TLS de cliente. Se true, os clientes não precisam fornecer certificados de cliente, mas mongod ou mongos criptografam a conexão TLS/SSL.

Se um cliente fornecer um certificado de cliente, independentemente do valor definido para net.tls.allowConnectionsWithoutCertificates, mongos ou mongod executará a validação do certificado usando a cadeia de certificados raiz especificada pelo CAFile, ou o armazenamento de CA do sistema, se tlsUseSystemCA estiver true, e rejeitará clientes com certificados inválidos.

Utilize a opção net.tls.allowConnectionsWithoutCertificates se você tiver uma implantação mista que inclui clientes que não apresentam ou não podem apresentar certificados para o mongos ou mongod.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

net.tls.allowInvalidCertificates

Tipo: booleano

Padrão: false

Habilite ou desabilite as verificações de validação de certificados TLS em outros servidores no cluster e permita o uso de certificados inválidos para conexão.

Observação

Se você especificar --tlsAllowInvalidCertificates ou tls.allowInvalidCertificates: true ao usar a autenticação X.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação.

Ao usar a configuração net.tls.allowInvalidCertificates, o MongoDB registra um aviso sobre o uso do certificado inválido.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Autenticação interna/Autenticação de associação autogerenciada.

net.tls.allowInvalidHostnames

Tipo: booleano

Padrão: false

Quando net.tls.allowInvalidHostnames é true, o MongoDB desabilita a validação dos nomes de host em certificados TLS. Isso permite que mongod ou mongos se conectem a outras instâncias do MongoDB no cluster, mesmo que o nome do host de seus certificados não corresponda ao nome do host especificado.

Para obter mais informações sobre TLS e MongoDB, consulte configure-mongod-mongos-for-tls-ssl.

net.tls.disabledProtocols

Tipo: string

Impede que um servidor MongoDB em execução com TLS aceite conexões recebidas que usam um protocolo ou protocolos específicos. Para especificar vários protocolos, use uma lista separada por vírgula de protocolos, mas não use espaços após as vírgulas. Se você incluir um espaço antes do nome de um protocolo, o servidor o interpretará como um protocolo não reconhecido e não iniciará.

net.tls.disabledProtocols reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e TLS1_3.

  • No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você deve desativar pelo menos um dos outros dois, por exemplo, TLS1_0,TLS1_1.

  • Para listar vários protocolos, especifique como uma lista separada por vírgula de protocolos sem espaços após as vírgulas. Por exemplo TLS1_0,TLS1_1.

  • Especificar um protocolo não reconhecido ou incluir um espaço após uma vírgula impede que o servidor seja iniciado.

  • Os protocolos desabilitados especificados substituem qualquer protocolo padrão desabilitado.

O MongoDB desabilita o uso do TLS 1.0 se o TLS 1.1+ estiver disponível no sistema. Para habilitar o TLS 1.0, especifique none para net.tls.disabledProtocols.

Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.

Dica

net.tls.FIPSMode

Tipo: booleano

Padrão: false

Habilite ou desabilite o uso do modo FIPS da biblioteca TLS para o mongos ou mongod. Seu sistema deve ter uma biblioteca compatível com FIPS para utilizar a opção net.tls.FIPSMode.

Observação

O TLS/SSL compatível com FIPS está disponível apenas no MongoDB Enterprise. Consulte Configurar MongoDB para FIPS para obter mais informações.

net.tls.logVersions

Tipo: string

Instrui mongos ou mongod a fazer log de uma mensagem quando um cliente se conecta usando uma versão TLS especificada.

Especifique uma única versão do TLS ou uma lista separada por vírgula de várias versões do TLS.

Exemplo

Para instruir mongos ou mongod a registrar uma mensagem quando um cliente se conectar usando TLS 1.2 ou TLS 1.3, defina net.tls.logVersions como "TLS1_2,TLS1_3".

net:
compression:
compressors: <string>
net.compression.compressors

Default: snappy,zstd,zlib

Especifica os compressores padrão a serem usados na comunicação entre essa instância mongod ou mongos e:

  • outros membros do sistema se a instância fizer parte de um conjunto de réplicas ou de um cluster fragmentado

  • mongosh

  • drivers que suportam o formato de mensagem OP_COMPRESSED .

MongoDB é compatível com os seguintes compactadores:

Para desativar a compactação de rede, defina o valor como disabled.

Importante

As mensagens são compactadas quando ambas as partes habilitam a compactação de rede. Caso contrário, as mensagens entre as partes serão descompactadas.

Se você especificar vários compressores, a ordem em que você lista os compressores é importante, bem como o iniciador de comunicação. Por exemplo, se mongosh especificar os seguintes compressores de rede zlib,snappy e mongod especificar snappy,zlib, as mensagens entre mongosh e mongod usarão zlib.

Se as partes não compartilharem pelo menos um compressor comum, as mensagens entre as partes serão descompactadas. Por exemplo, se mongosh especificar o compressor de rede zlib e mongod especificar snappy, as mensagens entre mongosh e mongod não serão compactadas.

security:
keyFile: <string>
clusterAuthMode: <string>
authorization: <string>
transitionToAuth: <boolean>
javascriptEnabled: <boolean>
redactClientLogData: <boolean>
clusterIpSourceAllowlist:
- <string>
sasl:
hostName: <string>
serviceName: <string>
saslauthdSocketPath: <string>
enableEncryption: <boolean>
encryptionCipherMode: <string>
encryptionKeyFile: <string>
kmip:
keyIdentifier: <string>
rotateMasterKey: <boolean>
serverName: <string>
port: <string>
clientCertificateFile: <string>
clientCertificatePassword: <string>
clientCertificateSelector: <string>
serverCAFile: <string>
connectRetries: <int>
connectTimeoutMS: <int>
ldap:
servers: <string>
bind:
method: <string>
saslMechanisms: <string>
queryUser: <string>
queryPassword: <string | array>
useOSDefaults: <boolean>
transportSecurity: <string>
timeoutMS: <int>
userToDNMapping: <string>
authz:
queryTemplate: <string>
validateLDAPServerConfig: <boolean>
security.keyFile

Tipo: string

O caminho para um arquivo de chave que armazena o segredo compartilhado que as instâncias do MongoDB usam para autenticar umas às outras em um cluster fragmentado ou conjunto de réplicas. keyFile implica security.authorization. Consulte Autenticação interna/de associação autogerenciada para obter mais informações.

Os arquivos de chaves para autenticação de associação interna usam o formato YAML para permitir várias chaves em um só arquivo. O formato YAML aceita:

  • Uma única string de chave (igual às versões anteriores)

  • Uma sequência de strings de chave

O formato YAML é compatível com os arquivos-chave de chave única existentes que usam o formato de arquivo de texto.

security.clusterAuthMode

Tipo: string

Padrão: keyFile

O modo de autenticação usado para autenticação de cluster. Se você usar a autenticação X.509 interna, especifique aqui. Esta opção pode ter um dos seguintes valores:

Valor
Descrição

keyFile

Use um arquivo-chave para autenticação. Aceite apenas arquivos-chave.

sendKeyFile

Para fins de atualização contínua. Envie um arquivo-chave para autenticação, mas pode aceitar arquivos-chave e certificados X.509.

sendX509

Para fins de atualização contínua. Envie o certificado X.509 para autenticação, mas pode aceitar arquivos-chave e certificados X.509.

x509

Recomendado. Envie o certificado X.509 para autenticação e aceite apenas certificados X.509.

Se --tlsCAFile ou tls.CAFile não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados de CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Se estiver usando a autenticação X.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando --tlsCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar instâncias do MongoDB para criptografia TLS/SSL e Configuração TLS/SSL para clientes .

security.authorization

Tipo: string

Padrão: desabilitado

Habilite ou desabilite o RBAC (Controle de Acesso Baseado em Função) para controlar o acesso de cada usuário a recursos e operações de banco de dados.

Defina esta opção como uma das seguintes:

Valor
Descrição

enabled

Um usuário pode acessar somente os recursos e ações do banco de dados para os quais receberam privilégios.

disabled

Um usuário pode acessar qualquer banco de dados e executar qualquer ação.

Consulte Controle de acesso baseado em funções em implantações autogerenciadas para obter mais informações.

A configuração security.authorization está disponível somente para mongod.

security.transitionToAuth

Tipo: booleano

Padrão: false

Permite que o mongod ou mongos aceite e crie conexões autenticadas e não autenticadas de e para outras instâncias mongod e mongos na implantação. Usado para realizar a transição contínua de conjuntos de réplicas ou clusters fragmentados de uma configuração sem autenticação para autenticação interna. Requer a especificação de um mecanismo de autenticação interna, como security.keyFile.

Por exemplo, se usar keyfiles para autenticação interna, o mongod ou mongos cria uma conexão autenticada com qualquer mongod ou mongos na implantação usando um keyfile correspondente. Se os mecanismos de segurança não corresponderem, o mongod ou mongos utilizará uma conexão não autenticada.

Um mongod ou mongos em execução com security.transitionToAuth não impõe controles de acesso de usuário. Os usuários podem se conectar à sua implantação sem nenhuma verificação de controle de acesso e realizar operações administrativas, de leitura e gravar.

Observação

Um mongod ou mongos executando com autenticação interna e sem security.transitionToAuth exige que os clientes se conectem usando controles de acesso de usuário. Atualize os clientes para conectar ao mongod ou mongos usando o usuário apropriado antes de reiniciar o mongod ou mongos sem security.transitionToAuth.

security.javascriptEnabled

Tipo: booleano

Padrão: true

Importante

JavaScript do lado do servidor obsoleto

A partir do MongoDB 8.0, as funções JavaScript do lado do servidor ($accumulator, $function, $where) estão obsoletas. O MongoDB registra um aviso quando você executa essas funções.

O Map-reduce foi descontinuado a partir do MongoDB 5.0.

Habilita ou desabilita execução JavaScript do lado do servidor. Quando desativado, você não pode usar operações que executam código JavaScript no lado do servidor, como o operador de consulta $where, o comando mapReduce, $accumulator e $function.

Se você não usar essas operações, desabilite os scripts do lado do servidor.

security.javascriptEnabled está disponível para mongod e mongos. Nas versões anteriores, a configuração só está disponível para mongod.

security.redactClientLogData

Tipo: booleano

Disponível apenas no MongoDB Enterprise.

Um mongod ou mongos em execução com security.redactClientLogData redige qualquer mensagem que acompanhe determinado evento de log antes do log. Isso impede que o mongod ou mongos grave dados potencialmente confidenciais armazenados no banco de dados no log de diagnóstico. Metadados como códigos de erro ou operação, números de linha e nomes de arquivos de origem ainda são visíveis nos logs.

Use security.redactClientLogData em conjunto com a criptografia em descanso e TLS/SSL (criptografia de transporte) para auxiliar na conformidade com os requisitos regulatórios.

Por exemplo, uma implantação MongoDB pode armazenar Informações de Identificação Pessoal (PII) em uma ou mais coleções. O mongod ou mongos registra eventos como aqueles relacionados a operações CRUD, sharding de metadados etc. É possível que o mongod ou mongos exponha PII como parte dessas operações de registro. Um mongod ou mongos em execução com security.redactClientLogData remove qualquer mensagem que acompanhe esses eventos antes de ser enviada para o log, removendo efetivamente as PII.

O diagnóstico em um mongod ou mongos em execução com security.redactClientLogData pode ser mais difícil devido à falta de dados relacionados a um evento de log. Consulte a página do manual de log de processos para ver um exemplo do efeito de security.redactClientLogData na saída de log.

Em um mongod ou mongos em execução, use setParameter com o parâmetro redactClientLogData para configurar essa configuração.

security.clusterIpSourceAllowlist

Tipo: lista

Novidades na versão 5.0.

Alterado na versão 5.2.

Uma lista de endereços IP/CIDR (Roteamento entre Domínios sem Classe) faixas em relação aos quais o mongod valida solicitações de autenticação de outros nós do conjunto de réplicas e, se parte de um cluster, as instâncias de mongos. O mongod verifica se o IP de origem está explicitamente na lista ou pertence a uma faixa CIDR na lista. Se o endereço IP não estiver presente, o servidor não autenticará o mongod ou mongos.

security.clusterIpSourceAllowlist não tem efeito sobre um mongod iniciado sem autenticação.

A partir do MongoDB 5.2, você pode configurar security.clusterIpSourceAllowlist em um mongod ou mongos em execução usando setParameter.

Este exemplo atualiza security.clusterIpSourceAllowlist durante o tempo de execução para incluir os endereços IP "1.1.1.1/24", "2.2.2.2/16" e "3.3.3.3".

db.adminCommand( {
setParameter: 1,
"clusterIpSourceAllowlist": ["1.1.1.1/24", "2.2.2.2/16", "3.3.3.3"]
} );

Este exemplo atualiza security.clusterIpSourceAllowlist durante o tempo de execução para excluir todos os endereços IP:

db.adminCommand( {
setParameter: 1,
"clusterIpSourceAllowlist": null
} );

security.clusterIpSourceAllowlist não tem efeito sobre um mongod iniciado sem autenticação.

security.clusterIpSourceAllowlist requer a especificação de cada endereço IPv4/6 ou intervalo de CIDR (Classless Inter-Domain Routing) como uma lista YAML:

security:
clusterIpSourceAllowlist:
- 192.0.2.0/24
- 127.0.0.1
- ::1

Importante

Certifique-se de que security.clusterIpSourceAllowlist inclua o endereço IP ou faixas CIDR que incluam o endereço IP de cada membro do conjunto de réplicas ou mongos na implantação para garantir uma comunicação saudável entre os componentes do cluster.

security:
enableEncryption: <boolean>
encryptionCipherMode: <string>
encryptionKeyFile: <string>
kmip:
keyIdentifier: <string>
rotateMasterKey: <boolean>
serverName: <string>
port: <int>
clientCertificateFile: <string>
clientCertificatePassword: <string>
clientCertificateSelector: <string>
serverCAFile: <string>
connectRetries: <int>
connectTimeoutMS: <int>
activateKeys: <boolean>
keyStatePollingSeconds: <int>
useLegacyProtocol: <boolean>
security.enableEncryption

Tipo: booleano

Padrão: false

Habilita a criptografia para o mecanismo de armazenamento WiredTiger. Você deve definir como true para transmitir chaves e configurações de criptografia.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.encryptionCipherMode

Tipo: string

Padrão: AES256-CBC

O modo de cifra a ser usado para encryption at rest:

Modo
Descrição

AES256-CBC

Padrão de criptografia avançada de 256 bits no modo de sequenciamento de blocos de cifra

AES256-GCM

Padrão de criptografia avançada de 256 bits no modo Galois/Counter

Disponível apenas no Linux.

O MongoDB Enterprise no Windows não é mais compatível com o AES256-GCM como uma cifra de bloco para criptografia em repouso. Esse uso é compatível apenas com Linux.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.encryptionKeyFile

Tipo: string

O caminho para o arquivo-chave local ao gerenciar chaves por meio de um processo diferente do KMIP. Definido apenas ao gerenciar chaves por meio de um processo diferente do KMIP. Se os dados já estiverem criptografados usando KMIP, o MongoDB gerará um erro.

Exige que security.enableEncryption seja true.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.keyIdentifier

Tipo: string

Identificador KMIP exclusivo para uma chave existente no servidor KMIP. Inclua para usar a chave associada ao identificador como chave do sistema. Você só pode usar a configuração na primeira vez em que habilitar a criptografia para a instância mongod. Exige que security.enableEncryption seja verdadeiro.

Se não for especificada, o MongoDB solicita que o servidor KMIP crie uma chave nova para utilizar como chave do sistema.

Se o servidor KMIP não conseguir localizar uma chave com o identificador especificado ou se os dados já estiverem criptografados com uma chave, o MongoDB lançará um erro.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.rotateMasterKey

Tipo: booleano

Padrão: false

Se for verdade, gire a chave mestra e criptografe novamente o keystore interno.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.serverName

Tipo: string

Nome do host ou endereço IP do servidor KMIP ao qual se conectar. Requer que security.enableEncryption seja verdadeiro.

Você pode especificar vários servidores KMIP como uma lista separada por vírgulas, como por exemplo server1.example.com,server2.example.com. Na inicialização, o mongod tenta estabelecer uma conexão com cada servidor na ordem listada e seleciona o primeiro servidor com o qual pode estabelecer uma conexão com êxito. A seleção do servidor KMIP ocorre apenas na inicialização.

mongod verifica a conexão com o servidor KMIP na inicialização.

O nome do servidor especificado no security.kmip.serverName deve corresponder ao nome alternativo do assunto SAN ou ao Nome Comum CN no certificado apresentado pelo servidor KMIP. SAN pode ser um nome de sistema ou um endereço IP.

Se SAN estiver presente, mongod não tentará corresponder a CN.

Se o nome do host ou o endereço IP do servidor KMIP não corresponder a SAN ou CN, mongod não será iniciado.

A partir do MongoDB 4.2, ao realizar a comparação de SAN, o MongoDB oferece suporte à comparação de nomes DNS ou endereços IP. Nas versões anteriores, o MongoDB suporta apenas comparações de nomes DNS.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.port

Tipo: int

Padrão: 5696

Número da porta a ser usada para comunicação com o servidor KMIP. Requer security.kmip.serverName. Exige que security.enableEncryption seja verdadeiro.

Se especificar vários servidores KMIP com security.kmip.serverName, o mongod usará a porta especificada com security.kmip.port para todos os servidores KMIP fornecidos.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificateFile

Tipo: string

Caminho para o arquivo .pem usado para autenticar o MongoDB no servidor KMIP. O arquivo .pem especificado deve conter o certificado e a chave TLS/SSL.

Para utilizar esta configuração, você também deve especificar a configuração do security.kmip.serverName.

Importante

Habilitar a criptografia usando um servidor KMIP no Windows falha ao usar security.kmip.clientCertificateFile e o servidor KMIP impõe TLS 1.2.

Para habilitar a encryption at rest com KMIP no Windows, você deve:

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificatePassword

Tipo: string

A senha para descriptografar a chave privada do certificado do cliente que se conecta ao servidor KMIP . Essa opção autentica o MongoDB no servidor KMIP e exige que você forneça --kmipClientCertificateFile um.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.clientCertificateSelector

Tipo: string

Novo na versão 5.0: Disponível no Windows e macOS como alternativa ao security.kmip.clientCertificateFile.

security.kmip.clientCertificateFile e as opções security.kmip.clientCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para autenticar o MongoDB no servidor KMIP.

security.kmip.clientCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade
Tipo de valor
Descrição

subject

string ASCII

Nome do assunto ou nome comum no certificado

thumbprint

string hexadecimal

Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.

O thumbprint às vezes é denominado fingerprint.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.serverCAFile

Tipo: string

Caminho para o arquivo CA. Usado para validar a conexão segura do cliente com o servidor KMIP.

Observação

A partir de 4.0, no macOS ou no Windows, você pode usar um certificado do armazenar seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte security.kmip.clientCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o security.kmip.serverCAFile.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.connectRetries

Tipo: int

Padrão: 0

Quantas vezes tentar novamente a conexão inicial com o servidor KMIP. Use junto com connectTimeoutMS para controlar quanto tempo o mongod espera por uma resposta entre cada nova tentativa.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.connectTimeoutMS

Tipo: int

Padrão: 5000

Tempo limite em milissegundos para aguardar uma resposta do servidor KMIP. Se a configuração connectRetries for especificada, o mongod aguardará até o valor especificado com connectTimeoutMS para cada nova tentativa.

O valor deve ser 1000 ou superior.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

security.kmip.activateKeys

Tipo: booleano

Padrão: true

Novidades na versão 5.3.

Ativa todas as chaves KMIP recém-criadas na criação e, em seguida, verifica periodicamente se essas chaves estão em estado ativo.

Quando security.kmip.activateKeys é true e você tem chaves existentes em um servidor KMIP, a chave deve ser ativada primeiro ou o nó mongod falha ao iniciar.

Se a chave usada pelo mongod transitar para um estado inativo, o nó mongod será encerrado, a menos que kmipActivateKeys seja falso. Para garantir que você tenha uma chave ativa, gire a chave mestra KMIP usando security.kmip.rotateMasterKey.

security.kmip.keyStatePollingSeconds

Tipo: int

Padrão: 900 segundos

Novidades na versão 5.3.

Frequência em segundos em que o mongod pesquisa o servidor KMIP em busca de chaves ativas.

Para desabilitar a pesquisa, defina o valor como -1.

security.kmip.useLegacyProtocol

Tipo: booleano

Padrão: false

Novidades na versão 7,0: (e 6,0,6)

Quando true, mongod usa o protocolo KMIP versão 1.0 ou 1.1 em vez da versão padrão. O protocolo KMIP padrão é a versão 1.2.

Para usar a criptografia de registro de auditoria com KMIP versão 1.0 ou 1.1, você deve especificar auditEncryptKeyWithKMIPGet na inicialização.

Para utilizar o protocolo KMIP versão 1.0 ou 1.1, substitua seus valores locais e adicione uma entrada como esta ao seu arquivo de configuração do mongod:

security:
enableEncryption: true
kmip:
serverName: "mdbhost.somecompany.com"
serverCAFile: "security/libs/trusted-ca.pem"
clientCertificateFile: "security/libs/trusted-client.pem"
useLegacyProtocol: true
security:
sasl:
hostName: <string>
serviceName: <string>
saslauthdSocketPath: <string>
security.sasl.hostName

Tipo: string

Um nome de domínio de servidor totalmente qualificado com a finalidade de configurar a autenticação SASL e Kerbero. O nome de host do SASL substitui o nome de host somente para a configuração do SASL e Kerberos.

security.sasl.serviceName

Tipo: string

Nome registrado do serviço usando SASL. Essa opção permite que você substitua o componente padrão do nome de serviço do Kerberos do nome principal do Kerberos, por instância. Se não for especificado, o valor padrão será mongodb.

O MongoDB permite definir essa opção somente na inicialização. O setParameter não pode alterar essa configuração.

Esta opção está disponível apenas no MongoDB Enterprise.

Importante

Certifique-se de que seu driver ofereça suporte a nomes de serviço alternativos. Para que o mongosh e outras ferramentas do MongoDB se conectem ao novo serviceName, consulte a opção gssapiServiceName.

security.sasl.saslauthdSocketPath

Tipo: string

O caminho para o arquivo de soquete do domínio UNIX para saslauthd.

Observação

A partir do MongoDB 8.0, A autenticação e autorização LDAP estão obsoletas. O LDAP está disponível e continuará a operar sem alterações durante a vida útil do MongoDB 8. O LDAP será removido em uma futura versão principal.

Para obter detalhes, consulte Descontinuação do LDAP.

security:
ldap:
servers: <string>
bind:
method: <string>
saslMechanisms: <string>
queryUser: <string>
queryPassword: <string | array>
useOSDefaults: <boolean>
transportSecurity: <string>
timeoutMS: <int>
retryCount: <int>
userToDNMapping: <string>
authz:
queryTemplate: <string>
validateLDAPServerConfig: <boolean>
security.ldap.servers

Tipo: string

Disponível apenas no MongoDB Enterprise.

O servidor LDAP no qual o mongod ou mongos autentica os usuários ou determina quais ações um usuário está autorizado a executar em um determinado banco de dados. Se o servidor LDAP especificado tiver quaisquer instâncias replicadas, você poderá especificar o host e a porta de cada servidor replicado em uma lista delimitada por vírgula.

Se a sua infraestrutura LDAP particionar o diretório LDAP em vários servidores LDAP, especifique um servidor LDAP ou qualquer uma de suas instâncias replicadas para security.ldap.servers. O MongoDB suporta as seguintes referências LDAP, conforme definido em RFC 4511 4.1.10. Não utilize o security.ldap.servers para listar todos os servidores LDAP em sua infraestrutura.

Você pode prefixar servidores LDAP com srv: e srv_raw:.

Se sua connection string especificar "srv:<DNS_NAME>", mongod verificará se "_ldap._tcp.gc._msdcs.<DNS_NAME>" existe para que o SRV seja compatível com o Active Directory. Se não encontrado, mongod verifica se "_ldap._tcp.<DNS_NAME>" existe para SRV. Se não for possível encontrar um registro SRV, mongod avisa para usar "srv_raw:<DNS_NAME>" no lugar.

Se a connection string especificar "srv_raw:<DNS_NAME>", mongod executará uma pesquisa de registro SRV para "<DNS NAME>".

Essa configuração pode ser configurada em um mongod ou mongos em execução usando setParameter.

Se não for definido, mongod ou mongos não poderá usar autenticação ou autorização LDAP.

security.ldap.bind.queryUser

Tipo: string

Disponível apenas no MongoDB Enterprise.

A identidade com a qual mongod ou mongos se liga, ao conectar ou executar queries em um servidor LDAP.

Obrigatório apenas se alguma das seguintes afirmações for verdadeira:

Você deve usar queryUser com queryPassword.

Se não estiver definido, mongod ou mongos não tentará se vincular ao servidor LDAP.

Essa configuração pode ser configurada em um mongod ou mongos em execução usando setParameter.

Observação

As implantações do Windows MongoDB podem utilizar o useOSDefaults ao invés do queryUser e queryPassword. Não é possível especificar queryUser e useOSDefaults ao mesmo tempo.

security.ldap.bind.queryPassword

Tipo: string ou array

Disponível apenas no MongoDB Enterprise.

A senha usada para vincular a um servidor LDAP ao usar queryUser. Você deve usar queryPassword com queryUser.

Se não for definido, mongod ou mongos não tentará se vincular ao servidor LDAP.

Você pode definir essa configuração em um mongod ou mongos em execução usando setParameter.

O comando ldapQueryPassword setParameter aceita uma string ou um array de strings. Se ldapQueryPassword for definido como um array, o MongoDB tentará cada senha na ordem até que uma delas seja bem-sucedida. Use um array de senha para passar a senha da conta LDAP sem tempo de inatividade.

Observação

As implantações do Windows MongoDB podem utilizar o useOSDefaults ao invés do queryUser e queryPassword. Não é possível especificar queryPassword e useOSDefaults ao mesmo tempo.

security.ldap.bind.useOSDefaults

Tipo: booleano

Padrão: false

Disponível no MongoDB Enterprise apenas para a plataforma Windows.

Permite que mongod ou mongos autentiquem ou vinculem, utilizando suas credenciais de login do Windows ao conectar ao servidor LDAP.

Necessário apenas se:

  • Utilizando autorização LDAP.

  • Usando uma query LDAP para username transformation.

  • O servidor LDAP não permite ligações anônimas

Use useOSDefaults para substituir queryUser e queryPassword.

security.ldap.bind.method

Tipo: string

Padrão: simples

Disponível apenas no MongoDB Enterprise.

O método mongod ou mongos utiliza para autenticar em um servidor LDAP. Utilize com queryUser e queryPassword para conectar ao servidor LDAP.

method suporta os seguintes valores:

  • simple - mongod ou mongos usa autenticação simples.

  • sasl - mongod ou mongos usa o protocolo SASL para autenticação

Se você especificar sasl, poderá configurar os mecanismos SASL disponíveis utilizando o security.ldap.bind.saslMechanisms. mongod ou mongos usa como padrão o mecanismo DIGEST-MD5 .

security.ldap.bind.saslMechanisms

Tipo: string

Padrão: DIGEST-MD5

Disponível apenas no MongoDB Enterprise.

Uma lista separada por vírgulas de mecanismos SASL mongod ou mongos pode utilizar ao autenticar para o servidor LDAP. O mongod ou mongos e o servidor LDAP devem concordar com pelo menos um mecanismo. O mongod ou mongos carrega dinamicamente quaisquer bibliotecas de mecanismos SASL instaladas na máquina que hospeda no runtime.

Instale e configure as bibliotecas apropriadas para o(s) mecanismo(s) SASL selecionado(s) no host do mongod ou mongos e no host do servidor LDAP remoto. Seu sistema operacional pode incluir determinadas bibliotecas SASL por padrão. Consulte a documentação associada a cada mecanismo SASL para obter orientação sobre instalação e configuração.

Se estiver usando o mecanismo SASL GSSAPI para uso com a Autenticação Kerberos em Implantações Autogerenciadas, verifique o seguinte para a máquina hospedar mongod ou mongos :

Linux
  • A variável de ambiente KRB5_CLIENT_KTNAME é resolvida para o nome do cliente Linux Keytab Files para a máquina host. Para obter mais informações sobre variáveis de ambiente Kerberos, consulte a documentação do Kerberos.

  • O keytab do cliente inclui um User Principal para o mongod ou mongos usar ao se conectar ao servidor LDAP e executar query LDAP.

Windows
Se estiver conectando a um servidor Active diretório, a configuração do Windows Kerberos gerará automaticamente um Ticket-Granting-Ticket quando o usuário fizer log no sistema. Defina useOSDefaults como true para permitir que mongod ou mongos usem as credenciais geradas ao se conectar ao servidor do Active Directory e executar queries.

Defina method como sasl para usar esta opção.

Observação

Para obter uma lista completa dos mecanismos SASL, consulte a lista da IANA . Consulte a documentação do seu serviço LDAP ou Active Directory para identificar os mecanismos SASL compatíveis com o serviço.

MongoDB não é uma fonte de bibliotecas de mecanismo SASL nem a documentação do MongoDB é uma fonte definitiva para instalação ou configuração de qualquer mecanismo SASL. Para documentação e suporte, consulte o fornecedor ou proprietário da biblioteca do mecanismo SASL.

Para obter mais informações sobre SASL, consulte os seguintes recursos:

security.ldap.transportSecurity

Tipo: string

Padrão: tls

Disponível apenas no MongoDB Enterprise.

Por padrão, o mongod ou mongos cria uma conexão segura TLS/SSL para o servidor LDAP.

Para implantações do Linux, você deve configurar as Opções de TLS apropriadas no arquivo /etc/openldap/ldap.conf. O gerenciador de pacotes do seu sistema operacional cria esse arquivo como parte da instalação do MongoDB Enterprise, por meio da dependência libldap. Consulte a documentação do TLS Options na documentação ldap.conf OpenLDAP para instruções mais completas.

Para o sistema do Windows, você deve adicionar os certificados CA do servidor LDAP à ferramenta de gerenciamento de certificados do Windows. O nome exato e a funcionalidade da ferramenta podem variar dependendo da versão do sistema operacional. Consulte a documentação da sua versão do Windows para obter mais informações sobre o gerenciamento de certificados.

Defina transportSecurity como none para desabilitar TLS/SSL entre mongod ou mongos e o servidor LDAP.

Aviso

Configurar o transportSecurity para none transmite informações de texto simples e possivelmente credenciais entre mongod ou mongos e o servidor LDAP.

security.ldap.timeoutMS

Tipo: int

Padrão: 10000

Disponível apenas no MongoDB Enterprise.

A quantidade de tempo em milésimos de segundo mongod ou mongos deve aguardar a resposta de um servidor LDAP a uma solicitação.

Aumentar o valor de timeoutMS pode evitar a falha de conexão entre o servidor MongoDB e o servidor LDAP, se a origem da falha for um tempo limite de conexão. Diminuir o valor de timeoutMS reduz o tempo que o MongoDB espera por uma resposta do servidor LDAP.

Essa configuração pode ser configurada em um mongod ou mongos em execução usando setParameter.

security.ldap.retryCount

Novidades na versão 6.1.

Tipo: int

Padrão: 0

Disponível apenas no MongoDB Enterprise.

Número de tentativas de operação pelo gerenciador LDAP do servidor após um erro de rede.

Essa configuração pode ser configurada em um mongod ou mongos em execução usando setParameter.

security.ldap.userToDNMapping

Tipo: string

Disponível apenas no MongoDB Enterprise.

Mapeia o nome de usuário fornecido para mongod ou mongos para autenticação para um nome diferenciado (nome diferenciado) LDAP. Talvez seja necessário usar userToDNMapping para transformar um nome de usuário em um nome diferenciado LDAP nos seguintes cenários:

  • Executando autenticação LDAP com ligação LDAP simples, onde os usuários se autenticam no MongoDB com nomes de usuário que não são DNs LDAP completos.

  • Utilizando um LDAP authorization query template que exige um DN.

  • Transformar os nomes de usuário dos clientes que se autenticam no Mongo DB usando diferentes mecanismos de autenticação (por exemplo, x.509, kerberos) em um DN LDAP completo para autorização.

userToDNMapping espera uma JSON-string com aspas que represente uma array ordenada de documentos. Cada documento contém uma expressão regular match e um modelo substitution ou ldapQuery usado para transformar o nome de usuário recebido.

Cada documento na array tem o seguinte formato:

{
match: "<regex>"
substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}
Campo
Descrição
Exemplo

match

Uma expressão regular (regex) formatada pelo ECMAScript para corresponder a um nome de usuário fornecido. Cada seção de parênteses representa um grupo de captura regex utilizado pelo substitution ou ldapQuery.

"(.+)ENGINEERING" "(.+)DBA"

substitution

Um modelo de formatação de nome distinto (DN) LDAP que converte o nome de autenticação correspondente pelo regex match em um DN LDAP. Cada valor numérico entre colchetes é substituído pelo grupo de captura regex extraído do nome de usuário de autenticação por meio da regex match.

O resultado da substituição deve ser um RFC4514 string escapade.

"cn={0},ou=engineering, dc=example,dc=com"

ldapQuery

Um modelo de formatação de query LDAP que insere o nome de autenticação correspondente ao regex match em um URI de query LDAP criptografado respeitando RFC4515 e RFC4516. Cada valor numérico entre colchetes é substituído pelo grupo de captura regex correspondente extraído do nome de usuário de autenticação por meio da expressão match. mongod ou mongos executa a query no servidor LDAP para recuperar o nome diferenciado LDAP do usuário autenticado. mongod ou mongos exige exatamente um resultado retornado para que a transformação seja bem-sucedida, ou mongod ou mongos ignora essa transformação.

"ou=engineering,dc=example, dc=com??one?(user={0})"

Observação

Uma explicação da RFC4514, RFC4515, RFC4516, ou queries LDAP estão fora do escopo da documentação do MongoDB. Revise o RFC diretamente ou use o recurso LDAP da sua preferência.

Para cada documento na array, você deve usar substitution ou ldapQuery. Você não pode especificar ambos no mesmo documento.

Ao executar a autenticação ou autorização, mongod ou mongos passa por cada documento na array na ordem fornecida, verificando o nome de usuário da autenticação no filtro match. Se uma correspondência for localizada, mongod ou mongos aplicará a transformação e utilizará a saída para autenticar o usuário. mongod ou mongos não verifica os documentos restantes na array.

Se o documento fornecido não corresponder ao nome de autenticação fornecido, mongod ou mongos continuará na lista de documentos para encontrar correspondências adicionais. Se nenhuma correspondência for encontrada em nenhum documento ou se a transformação descrita no documento falhar, mongod ou mongos retornará um erro.

mongod ou mongos também retorna um erro se uma das transformações não puder ser avaliada devido a falhas de rede ou de autenticação no servidor LDAP. mongod ou mongos rejeita a solicitação de conexão e não verifica os documentos restantes na array.

A partir do MongoDB 5.0, userToDNMapping aceita uma string vazia "" ou uma array vazia [ ] no lugar de um documento de mapeamento. Se fornecer uma string vazia ou array vazia para userToDNMapping, o MongoDB mapeia o nome de usuário autenticado como nome diferenciado LDAP. Anteriormente, fornecer um documento de mapeamento vazio causaria falha no mapeamento.

Importante

Você deve passar a array para userToDNMapping como uma string.

Exemplo

O seguinte mostra dois documentos de transformação. O primeiro documento coincide com qualquer string que termine em @ENGINEERING, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex. O segundo documento coincide com qualquer string que termine em @DBA, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex.

"[
{
match: "(.+)@ENGINEERING.EXAMPLE.COM",
substitution: "cn={0},ou=engineering,dc=example,dc=com"
},
{
match: "(.+)@DBA.EXAMPLE.COM",
ldapQuery: "ou=dba,dc=example,dc=com??one?(user={0})"
}
]"

Um usuário com o nome de usuário alice@ENGINEERING.EXAMPLE.COM corresponde ao primeiro documento. O grupo de captura regex {0} corresponde à cadeia de caracteres alice. A saída resultante é o DN "cn=alice,ou=engineering,dc=example,dc=com".

Um usuário com o nome de usuário bob@DBA.EXAMPLE.COM corresponde ao segundo documento. O grupo de captura regex {0} corresponde à string bob. A saída resultante é a query LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongod ou mongos executa esta query no servidor LDAP, retornando o resultado "cn=bob,ou=dba,dc=example,dc=com".

Se userToDNMapping não estiver definido, mongod ou mongos não aplicará nenhuma transformação no nome de usuário ao tentar autenticar ou autorizar um usuário no servidor LDAP.

Essa configuração pode ser feita em um mongod ou mongos em execução usando o comando de banco de dados setParameter.

security.ldap.authz.queryTemplate

Tipo: string

Disponível apenas no MongoDB Enterprise.

Um URL de query LDAP relativo formatado em conformidade com a RFC4515 e RFC4516 que o mongod executa para obter os grupos LDAP aos quais o usuário autenticado pertence. A query é relativa ao hospedar ou hospedares especificados em security.ldap.servers.

Observação

Para um melhor desempenho, considere colocar os grupos LDAP usados para autorização do MongoDB em sua própria unidade organizacional (OU).

Na URL, você pode usar os seguintes tokens de substituição:

Token de substituição
Descrição

{USER}

Substitui o nome de usuário autenticado ou o nome de usuário do transformed se um userToDNMapping for especificado.

{PROVIDED_USER}

Substitui o nome de usuário fornecido, ou seja, antes da autenticação ou da transformação LDAP.

Ao construir a URL de query, certifique-se de que a ordem dos parâmetros LDAP respeite RFC4516:

[ dn [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

Se sua query incluir um atributo, mongod pressupõe que a query recupera uma lista dos DNs dos quais essa entidade é nó.

Se a sua query não incluir um atributo, mongod assume que a query recupera todas as entidades das quais o usuário é membro.

Para cada DN LDAP retornado pela query, o mongod atribui ao usuário autorizado um papel correspondente no banco de dados do admin. Se uma função no banco de dados do admin corresponder exatamente ao DN, o mongod concede ao usuário as funções e privilégios atribuídos a esta função. Consulte o método db.createRole() para obter mais informações sobre a criação de funções.

Exemplo

Esta query LDAP retorna quaisquer grupos listados no atributo memberOf do objeto de usuário LDAP.

"{USER}?memberOf?base"

Sua configuração LDAP pode não incluir o atributo memberOf como parte do esquema do usuário, pode possuir um atributo diferente para relatar a associação ao grupo ou pode não controlar a associação ao grupo por meio de atributos. Configure sua query com relação à sua configuração LDAP exclusiva.

Se não for definido, mongod não poderá autorizar usuários usando LDAP.

Embora você possa modificar o valor do parâmetro ldapAuthzQueryTemplate em um mongod em execução usando o comando de banco de dados setParameter, não é possível habilitá-lo ou desabilitá-lo durante o tempo de execução. Para habilitar essa configuração, você deve configurar o security.ldap.authz.queryTemplate em seu arquivo de configuração durante a inicialização.

Observação

Uma explicação da RFC4515, RFC4516 ou queries LDAP estão fora do escopo da documentação do MongoDB. Revise o RFC diretamente ou use o recurso LDAP da sua preferência.

security.ldap.validateLDAPServerConfig

Tipo: booleano

Padrão: true

Disponível no MongoDB Enterprise

Um sinalizador que determina se a instância mongod ou mongos verifica a disponibilidade do LDAP server(s) como parte de sua inicialização:

  • Se true, a instância mongod ou mongos executa a verificação de disponibilidade e só continua a iniciar se o servidor LDAP estiver disponível.

  • Se false, a instância mongod ou mongos ignorará a verificação de disponibilidade; ou seja, a instância será iniciada mesmo se o servidor LDAP não estiver disponível.

setParameter

Definir parâmetro ou parâmetros do MongoDB descritos em Parâmetros do servidor MongoDB para uma implantação autogerenciada

Para definir parâmetros no arquivo de configuração YAML, use o seguinte formato:

setParameter:
<parameter1>: <value1>
<parameter2>: <value2>

Por exemplo, para especificar o enableLocalhostAuthBypass no arquivo de configuração:

setParameter:
enableLocalhostAuthBypass: false
setParameter.ldapUserCacheInvalidationInterval

Tipo: int

Padrão: 30

Para uso com servidores mongod que usam Autorização LDAP em Implantações Autogerenciadas.

O intervalo (em segundos) mongod espera entre as descargas de cache do usuário externo. Depois que o mongod libera o cache do usuário externo, o MongoDB readquire os dados de autorização do servidor LDAP na próxima vez que um usuário autorizado pelo LDAP emitir uma operação.

Aumentar o valor especificado aumenta a quantidade de tempo mongod e o servidor LDAP pode estar fora de sincronização, mas reduz a carga no servidor LDAP. Por outro lado, diminuir o valor especificado diminui o tempo mongod e o servidor LDAP podem estar fora de sincronização enquanto aumenta o volume no servidor LDAP.

setParameter:
ldapUserCacheInvalidationInterval: <int>
setParameter.searchIndexManagementHostAndPort

Tipo: string

Padrão: ""

Pesquise o endereço do host de gerenciamento do índice. Este parâmetro especifica o nome do host ou endereço IP e porta para o servidor de gerenciamento de índice de pesquisa .

Observação

Este parâmetro deve ter o mesmo valor que setParameter.mongotHost.

setParameter:
searchIndexManagementHostAndPort: <hostname|IP:port>

Exemplo

setParameter:
searchIndexManagementHostAndPort: localhost:27028
setParameter.skipAuthenticationToSearchIndexManagementServer

Tipo: booleano

Padrão: false

Sinalizador que determina se a autenticação deve ou não ser ignorada para mongod para conexões do servidor para o servidor de gerenciamento de índices, mesmo que a autenticação esteja ativada em mongod.

Observação

Como prática de segurança recomendada, recomendamos configurar este parâmetro para false.

setParameter:
skipAuthenticationToSearchIndexManagementServer: <true|false>
setParameter.mongotHost

Tipo: string

Padrão: ""

mongot endereço do host. Este parâmetro especifica o nome do host ou o endereço IP e a porta do servidor mongot .

Observação

Este parâmetro deve ter o mesmo valor que setParameter.searchIndexManagementHostAndPort.

setParameter:
mongotHost: <hostname|IP:port>

Exemplo

setParameter:
mongotHost: localhost:27028
setParameter.skipAuthenticationToMongot

Tipo: booleano

Padrão: false

Especifica se o MongoDB ignora a autenticação para conexões do mongod para mongot, mesmo que a autenticação esteja habilitada no mongod.

Observação

Como prática de segurança recomendada, recomendamos deixar esse parâmetro não definido ou defini-lo como false.

setParameter:
skipAuthenticationToMongot: <true|false>
setParameter.useGrpcForSearch

Tipo: booleano

Padrão: false

Especifica se os shards devem ou não se comunicar com mongot usando gRPC.

Observação

Você deve definir este parâmetro como true se estiver usando mongot.

setParameter:
useGrpcForSearch: <true|false>
setParameter.searchTLSMode

Tipo: string

Padrão: globalTLS

Define o modo TLS para conexão mongod a mongot. A definição do valor globalTLS usa a configuração especificada em net.tls.mode, enquanto as outras configurações operam de acordo com seu comportamento usual.

Você pode usar os seguintes valores para este parâmetro:

  • globalTLS

  • disabled

  • allowTLS

  • preferTLS

  • requireTLS

setParameter:
searchTLSMode: <globalTLS|disabled|allowTLS|preferTLS|requireTLS>

Alterado na versão 6.1:

  • O MongoDB sempre permite o registro no diário. Como resultado, o MongoDB remove a opção storage.journal.enabled e as opções de linha de comando --journal e --nojournal correspondentes.

storage:
dbPath: <string>
journal:
commitIntervalMs: <num>
directoryPerDB: <boolean>
syncPeriodSecs: <int>
engine: <string>
wiredTiger:
engineConfig:
cacheSizeGB: <number>
journalCompressor: <string>
directoryForIndexes: <boolean>
maxCacheOverflowFileSizeGB: <number>
collectionConfig:
blockCompressor: <string>
indexConfig:
prefixCompression: <boolean>
inMemory:
engineConfig:
inMemorySizeGB: <number>
oplogMinRetentionHours: <double>
storage.dbPath

Tipo: string

Padrão:

  • /data/db em Linux e macOS

  • \data\db no Windows

O diretório onde a instância do mongod armazena seus dados.

A configuração storage.dbPath está disponível apenas para mongod.

Observação

Arquivos de configuração

O arquivo de configuração padrão de mongod.conf incluído nas instalações do gerenciador de pacotes usa estes valores padrão específicos da plataforma para storage.dbPath.

Plataforma
Gerente de pacotes
Default storage.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

Os scripts de inicialização do pacote Linux não esperam que storage.dbPath mude dos padrões. Se você usar os pacotes Linux e alterar storage.dbPath, deverá usar seus próprios scripts de inicialização e desabilitar os scripts integrados.

storage.journal.commitIntervalMs

Tipo: número

Padrão: 100

A quantidade máxima de tempo, em milésimos de segundo, que o processo mongod permite entre as operações do diário. Os valores podem variar de 1 a 500 milésimos de segundo. Valores mais baixos aumentam a durabilidade do diário, em detrimento do desempenho do disco.

No WiredTiger, o intervalo de confirmação do diário padrão é de 100 milissegundos. Além disso, uma gravação que inclua ou implique j:true causa uma sincronização imediata do diário. Para obter detalhes ou condições adicionais que afetam a frequência da sincronização, consulte Processo de registro no diário.

A configuração storage.journal.commitIntervalMs está disponível apenas para mongod.

Não disponível para instâncias do mongod que usam o mecanismo de armazenamento in-memory.

storage.directoryPerDB

Tipo: booleano

Padrão: false

Quando true, o MongoDB utiliza um diretório separado para armazenar dados para cada banco de dados. Os diretórios estão sob o diretório storage.dbPath e cada nome de subdiretório corresponde ao nome do banco de dados.

A configuração storage.directoryPerDB está disponível apenas para mongod.

Não disponível para instâncias do mongod que usam o mecanismo de armazenamento in-memory.

A partir do MongoDB 5.0, descartar a coleção final em um banco de dados (ou descartar o próprio banco de dados) quando storage.directoryPerDB estiver ativado exclui o subdiretório recém-esvaziado desse banco de dados.

Para alterar a opção storage.directoryPerDB para implantações existentes:

  • Para instâncias standalone:

    1. Utilize o mongodump na instância do mongod existente para gerar uma cópia de segurança.

    2. Pare a instância do mongod.

    3. Adicione o valor storage.directoryPerDB e configure um novo diretório de dados

    4. Reinicie a instância do mongod.

    5. Utilize o mongorestore para preencher o novo diretório de dados.

  • Para conjuntos de réplicas:

    1. Pare um membro secundário.

    2. Adicione o valor storage.directoryPerDB e configure um novo diretório de dados para esse nó secundário.

    3. Reinicie esse secundário.

    4. Utilize sincronização inicial para preencher o novo diretório de dados.

    5. Atualize os secundários restantes da mesma maneira.

    6. Mova para baixo o membro primário e atualize o membro movido para baixo da mesma maneira.

storage.syncPeriodSecs

Tipo: número

Padrão: 60

A quantidade de tempo que pode passar antes que o MongoDB libere dados para os arquivos de dados.

Não defina esse valor em sistemas de produção. Em quase todas as situações, você deve usar a configuração padrão.

O processo do mongod grava dados muito rapidamente no diário e de modo lento nos arquivos de dados. storage.syncPeriodSecs não tem efeito sobre o registro no diário, mas se storage.syncPeriodSecs for definido como 0, o diário acabará consumindo todo o espaço disponível em disco.

A configuração storage.syncPeriodSecs está disponível apenas para mongod.

Não disponível para instâncias do mongod que usam o mecanismo de armazenamento in-memory.

Para fornecer dados duráveis, o WiredTiger usa checkpoints. Para obter mais detalhes, consulte Registro no diário e mecanismo de armazenamento WiredTiger.

storage.engine

Padrão: wiredTiger

O mecanismo de armazenamento para o banco de dados do mongod. Os valores disponíveis incluem:

Valor
Descrição

wiredTiger

inMemory

Para especificar o Mecanismo de armazenamento in-memory para sistemas autogerenciados.

Disponível apenas no MongoDB Enterprise.

Se você tentar iniciar um mongod com um storage.dbPath que contém arquivos de dados produzidos por um mecanismo de armazenamento diferente do especificado por storage.engine, o mongod se recusará a iniciar.

storage.oplogMinRetentionHours

Tipo: double

Especifica o número mínimo de horas para preservar uma entrada de oplog, em que os valores decimais representam as frações de uma hora. Por exemplo, um valor de 1.5 representa uma hora e trinta minutos.

O valor deve ser maior ou igual a 0. Um valor de 0 indica que o mongod deve truncar o oplog começando com as entradas mais antigas para manter o tamanho máximo de oplog configurado.

Padrão é 0.

Um mongod iniciado com oplogMinRetentionHours somente remove uma entrada de oplog se:

  • O oplog atingiu o tamanho máximo de oplog configurado e

  • A entrada do oplog é mais antiga que o número configurado de horas com base no relógio do sistema host.

O mongod tem o seguinte comportamento quando configurado com um período mínimo de retenção de oplog:

  • O oplog pode crescer sem restrições, de modo a reter as entradas do oplog pelo número de horas configurado. Isto pode resultar na redução ou esgotamento do espaço em disco do sistema devido a uma combinação de alto volume escrita e grande período de retenção.

  • Se o oplog crescer além de seu tamanho máximo, o mongod poderá continuar a manter esse espaço em disco, mesmo que o oplog retorne ao seu tamanho máximo ou esteja configurado para um tamanho máximo menor. Consulte reduzir o tamanho do oplog não retorna imediatamente espaço em disco.

  • O mongod compara o relógio do sistema com um relógio de criação de entrada de oplog ao impor a retenção de entrada de oplog. O desvio do relógio entre os componentes do cluster pode resultar em um comportamento inesperado de retenção do oplog. Consulte Sincronização do relógio para obter mais informações sobre a sincronização do relógio entre os membros do cluster.

Para alterar o período mínimo de retenção de oplog após iniciar o mongod, utilize replSetResizeOplog. O replSetResizeOplog permite a você redimensionar o oplog dinamicamente sem reiniciar o processo do mongod. Para manter as alterações feitas usando replSetResizeOplog por meio de uma reinicialização, atualize o valor de oplogMinRetentionHours.

storage:
wiredTiger:
engineConfig:
cacheSizeGB: <number>
cacheSizePct: <number>
journalCompressor: <string>
directoryForIndexes: <boolean>
maxCacheOverflowFileSizeGB: <number>
collectionConfig:
blockCompressor: <string>
indexConfig:
prefixCompression: <boolean>
storage.wiredTiger.engineConfig.cacheSizeGB

Tipo: flutuação

Define o tamanho máximo do cache interno que o WiredTiger utiliza para todos os dados. A memória que uma construção de índice consome (consulte maxIndexBuildMemoryUsageMegabytes) é separada da memória de cache do WiredTiger.

Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão. Se seu caso de uso exigir isso, você pode usar storage.wiredTiger.engineConfig.cacheSizePct para especificar uma porcentagem de até 80% da memória disponível. Os valores podem variar de 0.256GB a 10000GB.

O tamanho do cache interno padrão do WiredTiger é o maior entre:

  • 50% de (RAM - 1GB), ou

  • 0.256 GB.

Por exemplo, em um sistema com um total de 4GB de RAM, o cache WiredTiger utiliza 1.5GB de RAM (0.5 * (4GB - 1GB) = 1.5 GB). Ao fornecer um tamanho de cache específico, certifique-se de que a RAM não exceda os limites de 0.256GB a 10000GB.

Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão. Se seu caso exigir, você pode usar --wiredTigerCacheSizePct para contabilizar as alterações na memória devido à vertical. Você deve especificar uma porcentagem de até 80% da memória disponível. Os valores calculados podem variar de 0.256GB a 10000GB. Por exemplo, em um sistema com 2GB de RAM, o --wiredTigerCacheSizePct não pode ser definido como 10 porque 10% de 2GB é 0.2 GB, que é menor que 0.256GB.

Observação

Em alguns casos, como ao executar em um contêiner configurado para usar menos RAM do que a quantidade de memória provisionada para o host, você deve levar em conta os limites. Talvez seja necessário configurar o cache do WiredTiger com um valor apropriado, pois o WiredTiger pode não levar em conta os limites de memória do contêiner específico em determinados casos.

Para visualizar o memory limit, o valor que o WiredTiger utiliza como a quantidade máxima de RAM disponível utilize o comando hostInfo.

Com o WiredTiger, o MongoDB utiliza o cache interno do WiredTiger e o cache do sistema de arquivos.

Com o cache do sistema de arquivos, o MongoDB usa automaticamente toda a memória livre que não é usada pelo cache do WiredTiger ou por outros processos.

Observação

O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer os blocos do sistema de arquivos e o cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única mongod instância por máquina. Se uma única máquina contiver várias instâncias do MongoDB, diminua a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um contêiner (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizeGB ou storage.wiredTiger.engineConfig.cacheSizePct para um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no contêiner. Consulte memLimitMB.

Você só pode fornecer um entre storage.wiredTiger.engineConfig.cacheSizeGB ou storage.wiredTiger.engineConfig.cacheSizePct.

storage.wiredTiger.engineConfig.cacheSizePct

Tipo: flutuação

Define a quantidade máxima de memória a ser alocada para o cache como uma porcentagem da RAM física. A memória que uma construção de índice consome (consulte maxIndexBuildMemoryUsageMegabytes) é separada da memória cache do WiredTiger.

Você pode especificar uma porcentagem de até 80% da memória disponível. Os valores variam de 0.25 GB a 10000 GB.

O tamanho do cache interno padrão do WiredTiger é o maior entre:

  • 50% de (RAM - 1GB), ou

  • 0.256 GB.

Por exemplo, em um sistema com um total de 4GB de RAM, o cache WiredTiger utiliza 1.5GB de RAM (0.5 * (4GB - 1GB) = 1.5 GB). Ao fornecer um tamanho de cache específico, certifique-se de que a RAM não exceda os limites de 0.256GB a 10000GB.

Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão. Se seu caso exigir, você pode usar --wiredTigerCacheSizePct para contabilizar as alterações na memória devido à vertical. Você deve especificar uma porcentagem de até 80% da memória disponível. Os valores calculados podem variar de 0.256GB a 10000GB. Por exemplo, em um sistema com 2GB de RAM, o --wiredTigerCacheSizePct não pode ser definido como 10 porque 10% de 2GB é 0.2 GB, que é menor que 0.256GB.

Observação

Em alguns casos, como ao executar em um contêiner configurado para usar menos RAM do que a quantidade de memória provisionada para o host, você deve levar em conta os limites. Talvez seja necessário configurar o cache do WiredTiger com um valor apropriado, pois o WiredTiger pode não levar em conta os limites de memória do contêiner específico em determinados casos.

Para visualizar o memory limit, o valor que o WiredTiger utiliza como a quantidade máxima de RAM disponível utilize o comando hostInfo.

Com o WiredTiger, o MongoDB utiliza o cache interno do WiredTiger e o cache do sistema de arquivos.

Com o cache do sistema de arquivos, o MongoDB usa automaticamente toda a memória livre que não é usada pelo cache do WiredTiger ou por outros processos.

Observação

O storage.wiredTiger.engineConfig.cacheSizePct limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer os blocos do sistema de arquivos e o cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única mongod instância por máquina. Se uma única máquina contiver várias instâncias do MongoDB, diminua a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um contêiner (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizePct ou storage.wiredTiger.engineConfig.cacheSizeGB para um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no contêiner. Consulte memLimitMB.

Você só pode fornecer um entre storage.wiredTiger.engineConfig.cacheSizePct ou storage.wiredTiger.engineConfig.cacheSizeGB.

storage.wiredTiger.engineConfig.journalCompressor

Padrão: snappy

Especifica o tipo de compactação a ser usada para compactar os dados do diário do WiredTiger.

Os compactadores disponíveis são:

storage.wiredTiger.engineConfig.directoryForIndexes

Tipo: booleano

Padrão: false

Quando storage.wiredTiger.engineConfig.directoryForIndexes é true, mongod armazena índices e coleções em subdiretórios separados sob os dados (ou seja, storage.dbPath) diretório. Especificamente, o mongod armazena os índices em um subdiretório denominado index e os dados de coleção em um subdiretório denominado collection.

Usando um link simbólico, você pode especificar uma localização diferente para os índices. Especificamente, quando mongod a instância do não estiver em execução, mova o index subdiretório do para o destino e crie um link simbólico denominado index no diretório de dados para o novo destino.

storage.wiredTiger.engineConfig.zstdCompressionLevel

Tipo: inteiro

Padrão: 6

Novidade na versão 5.0

Alterado na versão 8.2

Especifica o nível de compressão aplicado ao utilizar o compressor zstd.

Os valores podem variar de -7 a 22.

Valores positivos especificam o nível de compressão, em que um valor mais alto para zstdCompressionLevel resulta em uma taxa de compressão mais alta ao custo de velocidades de compressão e descompressão mais lentas.

Valores negativos fornecem velocidades de compressão e descompressão mais rápidas ao custo da taxa de compressão.

A especificação de um valor de 0 usa o nível de compactação padrão interno de 3, que difere do padrão do MongoDB de 6.

Aplicável somente quando blockCompressor ou journalCompressor (ou ambos) estiverem definidos como zstd.

Importante

Ao fazer o downgrade para uma versão anterior do MongoDB, certifique-se de que a configuração storage.wiredTiger.engineConfig.zstdCompressionLevel esteja configurada para uma faixa compatível com essa versão. Por exemplo, o MongoDB 8.0 suporta uma faixa de 1 a 22.

storage.wiredTiger.collectionConfig.blockCompressor

Padrão: snappy

Especifica a compactação padrão para dados de collection. Você pode substituir isso por collection ao criar collections.

Os compactadores disponíveis são:

  • none

  • snappy

  • zlib

  • zstd

storage.wiredTiger.collectionConfig.blockCompressor afeta todas as coleções criadas. Se você alterar o valor de storage.wiredTiger.collectionConfig.blockCompressor em uma implantação MongoDB existente, todas as novas coleções utilizarão o compressor especificado. As coleções existentes continuam a usar o compressor especificado quando foram criadas ou o compressor padrão naquele momento.

storage.wiredTiger.indexConfig.prefixCompression

Padrão: true

Habilita ou desabilita a compressão de prefixo para dados de índice.

Especifique true para storage.wiredTiger.indexConfig.prefixCompression para habilitar a compactação de prefixo para dados de índice ou false para desabilitar a compactação de prefixo para dados de índice.

A configuração storage.wiredTiger.indexConfig.prefixCompression afeta todos os índices criados. Se você alterar o valor do storage.wiredTiger.indexConfig.prefixCompression em uma implantação MongoDB existente, todos os novos índices utilizarão compactação de prefixo. Os índices existentes não são afetados.

storage:
inMemory:
engineConfig:
inMemorySizeGB: <number>
storage.inMemory.engineConfig.inMemorySizeGB

Tipo: flutuação

Padrão: 50% de RAM física menos 1 GB

Os valores podem variar de 256 MB a 10 TB e podem ser instáveis.

Quantidade máxima de memória para alocar dados do mecanismo de armazenamento in-memory, incluindo índices, oplog se o mongod fizer parte do conjunto de réplicas, conjunto de réplicas ou metadados de cluster fragmentados, etc.

Por padrão, o mecanismo de armazenamento na memória usa 50% da RAM física menos 1 GB.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

operationProfiling:
mode: <string>
slowOpThresholdMs: <int>
slowOpInProgressThresholdMs: <int>
slowOpSampleRate: <double>
filter: <string>
operationProfiling.mode

Tipo: string

Padrão: off

Especifica quais operações devem ser profiladas. Os seguintes níveis de analisador estão disponíveis:

Nível
Descrição

off

O profiler está desligado e não coleta dados. Este é o nível do profiler padrão. Este nível corresponde ao nível 0 do profiler.

slowOp

O profiler coleta dados para operações que levam mais tempo do que o valor de slowms. Este nível corresponde ao nível 1 do profiler.

all

O profiler coleta dados para todas as operações. Este nível corresponde ao nível 2 do profiler.

Aviso

A análise pode degradar o desempenho e expor dados de query não criptografados no registro do sistema. Considere cuidadosamente quaisquer implicações de desempenho e segurança antes de configurar e habilitar o analisador em um sistema de produção.

Consulte Sobrecarga do criador de perfil para obter mais informações sobre a possível degradação do desempenho.

operationProfiling.slowOpInProgressThresholdMs

Tipo: inteiro

Padrão: 5000

O limite de operation time lento para uma query em andamento, em milissegundos. O MongoDB registra as operações que são executadas por mais tempo que esse limite como queries lentas em andamento. O MongoDB registra uma query como uma query lenta em andamento assim que a operação de query ultrapassa o limite de tempo.

operationProfiling.slowOpThresholdMs

Tipo: inteiro

Padrão: 100

O limite do tempo de operação lenta, em milissegundos. As operações executadas por mais tempo que esse limite são consideradas lentas.

As operações lentas são registradas com base em workingMillis, que é a quantidade de tempo que o MongoDB gasta trabalhando nessa operação. Isso significa que fatores como a espera por bloqueios e o controle de fluxo não afetam o fato de uma operação exceder o limite de operação lenta.

Quando logLevel está definido como 0, o MongoDB registra operações lentas no log de diagnóstico a uma taxa determinada por slowOpSampleRate.

Em configurações logLevel mais altas, todas as operações aparecem no log de diagnóstico, independentemente de sua latência, com a seguinte exceção: o log de mensagens de entrada lentas de oplog pelos secundários. Os secundários registram apenas as entradas lentas do oplog; aumentar o logLevel não registra todas as entradas do oplog.

Esta configuração está disponível para mongod e mongos.

  • Para instâncias mongod, a configuração afeta o log de diagnóstico e, se ativado, o profiler.

  • Para instâncias mongos, a configuração afeta somente o log de diagnóstico e não o profiler, já que o profiler não está disponível em mongos.

operationProfiling.slowOpSampleRate

Tipo: double

Padrão: 1.0

A fração de operações lentas que devem ser analisadas ou registradas. operationProfiling.slowOpSampleRate aceita valores entre 0 e 1, inclusive.

A configuração slowOpSampleRate está disponível para mongod e mongos.

  • Para instâncias mongod, a configuração afeta o log de diagnóstico e, se ativado, o profiler.

  • Para instâncias mongos, a configuração afeta somente o log de diagnóstico e não o profiler, já que o profiler não está disponível em mongos.

operationProfiling.filter

Tipo: representação de string de um documento de consulta

Uma expressão de filtro que controla quais operações são perfiladas e registradas.

Quando filter está definido, slowOpThresholdMs e slowOpSampleRate não são usados para criar perfis e linhas de log de query lenta.

Quando você define um filtro de perfil no arquivo de configuração, o filtro se aplica a todos os bancos de dados na implantação. Para definir um filtro de perfil para um banco de dados específico, use o método db.setProfilingLevel().

A opção usa uma representação de string de um documento de query no formato:

{ <field1>: <expression1>, ... }

O <field> pode ser qualquer campo no resultado do perfil. O <expression> é uma expressão da condição de consulta.

Para especificar um filtro de perfil em um arquivo de configuração, você deve:

  • Coloque o documento de filtro entre aspas simples para passar o documento como uma string.

  • Use o formato YAML do arquivo de configuração.

Por exemplo, o filter a seguir configura o criador de perfil para registrar operações query que demoram mais de 2 segundos:

operationProfiling:
mode: all
filter: '{ op: "query", millis: { $gt: 2000 } }'
replication:
oplogSizeMB: <int>
replSetName: <string>
enableMajorityReadConcern: <boolean>
replication.oplogSizeMB

Tipo: inteiro

O tamanho máximo em megabytes do oplog. A configuração oplogSizeMB define o tamanho descompactado do oplog, não o tamanho no disco.

Observação

O oplog pode ultrapassar seu limite de tamanho configurado para evitar a exclusão do majority commit point.

Por padrão, o processo do mongod cria um oplog baseado na quantidade máxima de espaço disponível. Para sistemas de 64bits, o oplog normalmente representa 5% do espaço disponível em disco.

Assim que o mongod tiver criado o oplog pela primeira vez, alterar a opção replication.oplogSizeMB não afetará o tamanho do oplog. Para alterar o tamanho máximo do oplog após iniciar o mongod, utilize replSetResizeOplog. O replSetResizeOplog permite redimensionar o oplog dinamicamente sem reiniciar o processo do mongod. Para manter as alterações feitas usando replSetResizeOplog por meio de uma reinicialização, atualize o valor de oplogSizeMB.

Consulte Tamanho do Oplog para obter mais informações.

A configuração replication.oplogSizeMB está disponível apenas para mongod.

replication.replSetName

Tipo: string

O nome do conjunto de réplicas do qual o mongod faz parte. Todos os hospedares no conjunto de réplicas devem ter o mesmo nome do conjunto.

Se seu aplicativo se conectar a mais de um conjunto de réplicas, cada conjunto deverá ter um nome distinto. Alguns drivers agrupam conexões de conjunto de réplicas por nome de conjunto de réplicas.

A configuração replication.replSetName está disponível apenas para mongod.

replication.replSetName não pode ser usado em conjunto com storage.indexBuildRetry.

replication.enableMajorityReadConcern

Padrão: true

Configura o suporte para a read concern "majority".

A partir do MongoDB 5.0, enableMajorityReadConcern não pode ser alterado e está sempre definido como true. A tentativa de iniciar um mecanismo de armazenamento que não suporta a read concern de maioria com a opção --enableMajorityReadConcern falha e retorna uma mensagem de erro.

Em versões anteriores do MongoDB, o enableMajorityReadConcern era configurável.

Aviso

Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:

sharding:
clusterRole: <string>
sharding.clusterRole

Tipo: string

O papel que a instância do mongod tem no cluster fragmentado. Defina esta configuração como uma das seguintes:

Valor
Descrição

configsvr

Inicie esta instância como um servidor de configuração. A instância inicia na porta 27019 por padrão.

Ao configurar uma instância MongoDB como clusterRole,configsvr você também deve especificar replSetName um.

shardsvr

Inicie esta instância como um shard. A instância inicia na porta 27018 por padrão.

Ao configurar uma instância do MongoDB como um clusterRole shardsvr, você também deve especificar um replSetName.

Observação

A configuração sharding.clusterRole requer que a instância mongod esteja sendo executada com replicação. Para implantar a instância como um nó do conjunto de réplicas, use a configuração replSetName e especifique o nome do conjunto de réplicas.

A configuração sharding.clusterRole está disponível apenas para mongod.

sharding.archiveMovedChunks

Tipo: booleano

Padrão: falso.

Durante a migração de chunk, um shard não salva documentos migrados do shard.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

auditLog:
destination: <string>
format: <string>
path: <string>
filter: <string>
schema: <string>
auditLog.auditEncryptionKeyIdentifier

Tipo: string

Novidades na versão 6.0.

Especifica o identificador exclusivo da chave KMIP (protocolo de interoperabilidade de gerenciamento de chaves) para criptografia de registro de auditorias.

Você não pode usar esta opção e auditLog.localAuditKeyFile juntos.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

auditLog.compressionMode

Tipo: string

Novidades na versão 5.3.

Especifica o modo de compressão da criptografia de logs de auditoria. Você também deve habilitar a criptografia de logs de auditoria usando auditLog.auditEncryptionKeyIdentifier ou auditLog.localAuditKeyFile.

Você pode definir esta opção para um destes valores:

Valor
Descrição

zstd

Use o algoritmo zstd para comprimir o registro de auditoria.

none (padrão)

Não comprima o registro de auditorias.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

auditLog.destination

Tipo: string

Ao configurar, o auditLog.destination habilita auditar e especifica onde mongos ou mongod envia todos os eventos de auditar.

auditLog.destination pode ter um dos seguintes valores:

Valor
Descrição

syslog

Envie os eventos de auditoria para syslog no formato JSON. Não disponível no Windows. As mensagens de auditoria têm um nível de severidade syslog de info e um nível de facilidade de user.

O limite de mensagens syslog pode resultar no truncamento de mensagens de auditoria. O sistema de auditoria não detecta o truncamento nem erros na sua ocorrência.

console

Envie os eventos de auditoria para stdout no formato JSON.

file

Envie os eventos de auditar para o arquivo especificado em no formato auditLog.path especificado auditLog.format em.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

auditLog.filter

Tipo: representação de string de um documento

O filtro para limitar os tipos de operações dos registros do sistema de auditoria. A opção usa uma representação de string de um documento de query no formato:

{ <field1>: <expression1>, ... }

O <field> pode ser qualquer campo na mensagem para auditar, incluindo os campos retornados no documento de parâmetros. O <expression> é uma expressão da condição de query.

Para especificar um filtro de auditoria, coloque o documento do filtro entre aspas simples para passar o documento como uma string.

Para especificar o filtro de auditoria em um arquivo de configuração, você deve utilizar o formato YAML do arquivo de configuração.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

auditLog.format

Tipo: string

O formato do arquivo de saída para auditar se destination for file. A opção auditLog.format pode ter um dos seguintes valores:

Valor
Descrição

JSON

Envie os eventos para auditar no formato JSON para o arquivo especificado em auditLog.path.

BSON

Envie os eventos de auditoria em formato binário BSON para o arquivo especificado em auditLog.path.

A impressão de eventos de auditoria em um arquivo no formato JSON degrada mais o desempenho do servidor do que a impressão em um arquivo no formato BSON.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

auditLog.localAuditKeyFile

Tipo: string

Novidades na versão 5.3.

Especifica o caminho e o nome do arquivo de uma chave de auditoria local para criptografia do registro de auditoria.

Observação

Use esta opção apenas para testes, pois a chave não está protegida. Para proteger a chave, use auditLog.auditEncryptionKeyIdentifier e um servidor KMIP (protocolo de interoperabilidade de gerenciamento de chaves) externo.

Você não pode usar as duas opções juntas.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

auditLog.path

Tipo: string

O arquivo de saída para auditoria se destination tiver valor de file. A opção auditLog.path pode receber um nome de caminho completo ou um nome de caminho relativo.

auditLog.runtimeConfiguration

Tipo: booleano

Especifica se um nó permite a configuração de tempo de execução dos filtros de auditoria e a variável auditAuthorizationSuccess. Se true, o nó pode participar do Gerenciamento de Filtros de Auditoria Online.

auditLog.schema

Tipo: string

Padrão: mongo

Novidades na versão 8.0.

Especifica o formato usado para logs de auditoria. Você pode especificar um dos seguintes valores para auditLog.schema:

Valor
Descrição

mongo

Os logs são gravados em um formato projetado pelo MongoDB.

Por exemplo, para mensagens de log, consulte Mensagens de auditoria do esquema do mongo.

OCSF

Os logs são escritos no formato OCSF . Esta opção fornece logs em um formato padronizado compatível com processadores de log.

Para ver exemplos de mensagens de log, consulte Mensagens de auditoria de esquema do OCSF.

Para visualizar as opções a serem usadas para configurar mongot o mongod com, consulte Configurar mongot.

replication:
localPingThresholdMs: <int>
sharding:
configDB: <string>
replication.localPingThresholdMs

Tipo: inteiro

Padrão: 15

O tempo de ping, em milissegundos, que mongos usa para determinar quais membros do conjunto de réplicas secundário passarão pelas operações de leitura dos clientes. O valor padrão de 15 corresponde ao valor padrão em todos os drivers do cliente.

Quando mongos recebe uma solicitação que permite leituras para nós secundários, o mongos:

  • Localiza o nó do conjunto com o menor tempo de ping.

  • Constrói uma lista de nós do conjunto de réplicas que esteja dentro de um tempo de ping de 15 milissegundos do nó adequado mais próximo do conjunto.

    Se você especificar um valor para a opção replication.localPingThresholdMs, mongos constrói a lista de nós da réplica que estão dentro da latência permitida por este valor.

  • Seleciona um nó para ler aleatoriamente a partir desta lista.

O tempo de ping usado para um nó comparado pela configuração replication.localPingThresholdMs é uma média móvel de tempos de ping recentes, calculada no máximo a cada 10 segundos. Como resultado, algumas query podem alcançar nós acima do limite até que o mongos recalcule a média.

Consulte a seção Preferência de leitura para conjuntos de réplicas da documentação de preferência de leitura para obter mais informações.

sharding.configDB

Tipo: string

Os servidores de configuração do cluster fragmentado.

Os servidores de configuração para clusters fragmentados são implantados como um conjunto de réplica. Os servidores de configuração do conjunto de réplica devem executar o mecanismo de armazenamento WiredTiger.

Especifique o nome do conjunto de réplicas do servidor de configuração e o nome do host e porta de pelo menos um dos membros do conjunto de réplicas do servidor de configuração.

sharding:
configDB: <configReplSetName>/cfg1.example.net:27019, cfg2.example.net:27019,...

As instâncias do mongos para o cluster fragmentado devem especificar o mesmo nome do conjunto de réplicas do servidor de configuração, mas podem especificar o nome do host e a porta de diferentes nós do conjunto de réplicas.

processManagement:
windowsService:
serviceName: <string>
displayName: <string>
description: <string>
serviceUser: <string>
servicePassword: <string>
processManagement.windowsService.serviceName

Tipo: string

Padrão: MongoDB

O nome do serviço mongos ou mongod quando executado como um serviço do Windows. Use este nome com as operações net start <name> e net stop <name> .

Você deve usar processManagement.windowsService.serviceName em conjunto com a opção --install ou --remove.

processManagement.windowsService.displayName

Tipo: string

Padrão: MongoDB

O nome listado para MongoDB no aplicativo administrativo de serviços.

processManagement.windowsService.description

Tipo: string

Padrão: servidor MongoDB

Execute a descrição de serviço do mongos ou mongod.

Você deve usar processManagement.windowsService.description em conjunto com a opção --install.

Para descrições que contêm espaços, você deve incluir a descrição entre aspas.

processManagement.windowsService.serviceUser

Tipo: string

O serviço mongos ou mongod no contexto de um determinado usuário. Este usuário deve ter privilégios de "Fazer log como um serviço".

Você deve usar processManagement.windowsService.serviceUser em conjunto com a opção --install.

processManagement.windowsService.servicePassword

Tipo: string

A senha do <user> para mongos ou mongod ao executar com a opção processManagement.windowsService.serviceUser.

Você deve usar processManagement.windowsService.servicePassword em conjunto com a opção --install.

O MongoDB removeu o storage engine obsoleto MMAPv1 e as opções de configuração específicas do MMAPv1:

Configuração do arquivo de configuração removida
Opção de linha de comando removida

storage.mmapv1.journal.commitIntervalMs

storage.mmapv1.journal.debugFlags

mongod --journalOptions

storage.mmapv1.nsSize

mongod --nssize

storage.mmapv1.preallocDataFiles

mongod --noprealloc

storage.mmapv1.quota.enforced

mongod --quota

storage.mmapv1.quota.maxFilesPerDB

mongod --quotaFiles

storage.mmapv1.smallFiles

mongod --smallfiles

storage.repairPath

mongod --repairpath

replication.secondaryIndexPrefetch

mongod --replIndexPrefetch

Para versões anteriores do MongoDB, consulte a documentação legado.

Voltar

Gerenciar processos mongod