mongod
Nesta página
- Synopsis
- Compatibilidade
- Considerações
- Opções
- Opções principais
- Opções de autenticação ou autorização LDAP
- Opções de armazenamento
- Opções do WiredTiger
- Opções de replicação
- Opções de cluster fragmentado
- Opções de TLS
- Opções de analisador
- Opções de auditoria
- Opções do inMemory
- Opções de gerenciamento de chave de encriptação
Synopsis
mongod
é o processo daemon principal para o sistema
MongoDB. Ele lida com solicitações de dados, gerencia o acesso a dados e executa
operações de gerenciamento de background.
Este documento fornece uma visão geral completa de todas as opções de linha de comando para mongod
. Essas opções de linha de comando são úteis principalmente para testes: na operação comum, use asopções de arquivo de configuração para controlar o comportamento do seu banco de dados de dados.
Dica
Veja também:
Observação
O MongoDB desabilita o suporte para criptografia TLS 1.0 em sistemas em que o TLS 1.1+ está disponível.
Compatibilidade
Os sistemas hospedados nos seguintes ambientes utilizam o mongod
:
MongoDB Atlas: o serviço totalmente gerenciado para implantações do MongoDB na nuvem
Observação
O MongoDB Atlas gerencia mongod
para todos os sistemas do MongoDB Atlas.
MongoDB Enterprise: a versão autogerenciada e baseada em assinatura do MongoDB
MongoDB Community: uma versão com código disponível, de uso gratuito e autogerenciada do MongoDB
Considerações
mongod
inclui um mecanismo de captura de dados de diagnóstico em tempo integral para auxiliar os engenheiros do MongoDB na solução de problemas de implantações. Se essa thread falhar, ela encerrará o processo de origem. Para evitar as falhas mais comuns, confirme se o usuário que executa o processo tem permissões para criar o diretório FTDCdiagnostic.data
. Paramongod
, o diretório está dentro destorage.dbPath
. Paramongos
, ele é paralelo asystemLog.path
.
Opções
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.
Alterado na versão 5.2:
O MongoDB remove a opção de linha de comando
--cpu
.
Alterado na versão 5.0:
O MongoDB remove a opção de linha de comando
--serviceExecutor
e a opção de configuraçãonet.serviceExecutor
correspondente.
Opções principais
--config <filename>, -f <filename>
Especifica um arquivo de configuração para opções de configuração do tempo de execução. O arquivo de configuração é o método preferido para a configuração de tempo de execução do
mongod
. As opções são equivalentes às opções de configuração da linha de comando. Consulte Opções de arquivo de configuração autogerenciadas para obter mais informações.Certifique-se de que o arquivo de configuração use codificação ASCII. A instância
mongod
não suporta arquivos de configuração com codificação não ASCII, incluindo UTF-8.
--configExpand <none|rest|exec>
Padrão: nenhum
Habilita o uso de diretivas de expansão em arquivos de configuração. As diretivas de expansão permitem que você defina valores de origem externa para opções de arquivo de configuração.
--configExpand
suporta as seguintes diretivas de expansão:ValorDescriçãonone
Padrão.mongod
não expande diretivas de expansão.mongod
falha ao iniciar se alguma configuração do arquivo de configuração usar diretivas de expansão.rest
mongod
expande as diretivas de expansão__rest
ao analisar o arquivo de configuração.exec
mongod
expande as diretivas de expansão__exec
ao analisar o arquivo de configuração.É possível especificar várias diretivas de expansão como uma lista separada por vírgula, por exemplo:
rest, exec
. Se o arquivo de configuração tiver diretivas de expansão não especificadas para--configExpand
, omongod
retornará um erro e encerrará.Consulte Valores de arquivo de configuração de origem externa para implantações autogerenciadas para arquivos de configuração para obter mais informações sobre diretivas de expansão.
--verbose, -v
Aumenta a quantidade de relatórios internos retornados no resultado padrão ou em arquivos de log. Aumente a verbosidade com o formato
-v
incluindo a opção várias vezes, por exemplo:-vvvvv
.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 somenteD
para o nível de depuração.
--quiet
Executa
mongod
em um modo silencioso que tenta limitar a quantidade de resultado.Esta opção suprime:
resultado de comandos do banco de dados
atividade de replicação
eventos aceitos de conexão
eventos fechados de conexão
--port <port>
Padrão:
27017, se
mongod
não for um membro de shard ou um membro do servidor de configuração27018 se
mongod
for umshard member
27019 se
mongod
for umconfig server member
A porta TCP na qual a instância do MongoDB escuta conexão de cliente.
A opção
--port
aceita um intervalo de valores entre0
e65535
. A definição da porta como0
configuramongod
para usar uma porta arbitrária atribuída pelo sistema operacional.
--bind_ip <hostnames|ipaddresses|Unix domain socket paths>
Padrão: localhost
Os nomes de host e/ou endereços IP e/ou caminhos completos de soquete de domínio Unix nos quais
mongod
deve escutar as conexões do cliente. Você pode anexarmongod
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 de link local (
fe80::/10
), você deve anexar o índice de zona para esse endereço (ou sejafe80::<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 evitar a expansão do padrão de nome de arquivo). Como alternativa, use a configuraçãonet.bindIpAll
.Observação
--bind_ip
e--bind_ip_all
são mutuamente exclusivos. Especificar as duas opções faz com quemongod
gere um erro e encerre.A opção de linha de comando
--bind
substitui a definição do arquivo de configuraçãonet.bindIp
.
--bind_ip_all
Se especificado, a instância do
mongod
se liga a todos os endereços IPv4 (ou seja,0.0.0.0
). Semongod
começar com--ipv6
,--bind_ip_all
também se vinculará a todos os endereços IPv6 (ou seja::
).mongod
só oferece suporte a IPv6 se iniciado com--ipv6
. Especificar--bind_ip_all
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 de vinculação de IP em implantações autogerenciadas.
Como alternativa, você pode definir a opção
--bind_ip
como::,0.0.0.0
ou como asterisco"*"
(coloque o asterisco entre aspas para evitar a expansão do padrão de nome de arquivo).Observação
--bind_ip
e--bind_ip_all
são mutuamente exclusivos. Ou seja, você pode especificar um ou outro, mas não ambos.
--clusterIpSourceAllowlist <string>
Novidades na versão 5.0.
Uma lista de endereços IP/CIDR (Roteamento entre Domínios sem Classe) varia 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 fragmentado, as instâncias demongos
. Omongod
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á omongod
oumongos
.--clusterIpSourceAllowlist
não tem efeito sobre ummongod
iniciado sem autenticação.--clusterIpSourceAllowlist
aceita vários endereços IPv4/ separados por6 vírgula ou intervalos de roteamentoentre domínios sem classe (CIDR):mongod --clusterIpSourceAllowlist 192.0.2.0/24,127.0.0.1,::1 Importante
Certifique-se de que
--clusterIpSourceAllowlist
inclua o endereço IP ou faixas CIDR que incluam o endereço IP de cada membro do conjunto de réplicas oumongos
na implantação para garantir uma comunicação saudável entre os componentes do cluster.
--clusterIpSourceWhitelist <string>
Obsoleto na versão 5.0: Em vez disso, use
--clusterIpSourceAllowlist
.Uma lista de endereços IP/CIDR (Roteamento entre Domínios sem Classe) varia 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 fragmentado, as instâncias demongos
. Omongod
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á omongod
oumongos
.--clusterIpSourceWhitelist
não tem efeito sobre ummongod
iniciado sem autenticação.--clusterIpSourceWhitelist
aceita vários endereços IPv4/ separados por6 vírgula ou intervalos de roteamentoentre domínios sem classe (CIDR):mongod --clusterIpSourceWhitelist 192.0.2.0/24,127.0.0.1,::1 Importante
Certifique-se de que
--clusterIpSourceWhitelist
inclua o endereço IP ou faixas CIDR que incluam o endereço IP de cada membro do conjunto de réplicas oumongos
na implantação para garantir uma comunicação saudável entre os componentes do cluster.
--ipv6
Habilita o suporte a IPv6.
mongod
desabilita o suporte a IPv6 por padrão.A configuração do
--ipv6
não direciona omongod
para escutar em nenhum endereço ou interface IPv6 local. Para configurar omongod
para escutar em uma interface IPv6, você tem as seguintes opções:Configure
--bind_ip
com um ou mais endereços IPv6 ou nomes de host que resolvam para endereços IPv6, ouDefinir
--bind_ip_all
comotrue
.
--listenBacklog <number>
Padrão: constante do sistema de destino
SOMAXCONN
O número máximo de conexões que podem existir na fila de escuta .
Aviso
Consulte a documentação do seu sistema local para entender as limitações e os requisitos de configuração antes de usar este parâmetro.
Importante
Para evitar um comportamento indefinido, especifique um valor para esse parâmetro entre
1
e a constanteSOMAXCONN
do sistema local.O valor padrão do parâmetro
listenBacklog
é configurado no tempo de compilação para a constanteSOMAXCONN
do sistema de destino.SOMAXCONN
é o valor máximo válido documentado para o parâmetro backlog da chamada de sistema de escuta.Alguns sistemas podem interpretar
SOMAXCONN
simbolicamente e, outros, numericamente. O backlog de escuta real aplicado na prática pode ser diferente de qualquer interpretação numérica da constanteSOMAXCONN
ou do argumento--listenBacklog
e também pode ser limitado por configurações do sistema, comonet.core.somaxconn
no Linux.Passar um valor para o parâmetro
listenBacklog
que excede a constanteSOMAXCONN
para o sistema local é, de acordo com os padrões, comportamento indefinido. Valores mais altos podem ser silenciosamente truncados, podem ser ignorados, podem causar consumo inesperado de recursos ou ter outras consequências adversas.Em sistemas com volumes de trabalho que exibem picos de conexão, para os quais é empiricamente conhecido que o sistema local pode honrar valores mais altos para o parâmetro backlog do que a constante
SOMAXCONN
, definir o parâmetrolistenBacklog
para um valor mais alto pode reduzir a latência da operação, conforme observado pelo cliente, reduzindo o número de conexões que são forçadas a um estado de backoff.
--maxConns <number>
O número máximo de conexões simultâneas que
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 esta opção para não encontrar erros durante a operação normal do aplicativo.
--logpath <path>
Envia todas as informações de registro de diagnóstico para um arquivo de log em vez de para o resultado padrão ou para o sistema syslog do host. O MongoDB cria o arquivo de log no caminho especificado.
Por padrão, o MongoDB move qualquer arquivo de log existente em vez de substituí-lo. Para anexar ao arquivo de log, defina a opção
--logappend
.
--syslog
Envia toda a saída de log para o sistema syslog do host em vez de para a saída padrão ou para um arquivo de log (
--logpath
).A opção
--syslog
não é aceita no Windows.Aviso
O daemon
syslog
gera logs de data/hora quando registra uma mensagem, não quando o MongoDB envia a mensagem. Isso pode levar a carimbos de data/hora enganosos para entradas de log, especialmente quando o sistema está sobrecarregado. Recomendamos usar a opção--logpath
para sistemas de produção para garantir carimbos de data/hora precisos.O MongoDB inclui o componente em suas mensagens de log para
syslog
.... ACCESS [repl writer worker 5] Unsupported modification to roles collection ...
--syslogFacility <string>
Usuário padrão
Especifica o nível de instalação utilizado ao registrar mensagens para syslog. O valor especificado deve ser suportado pela implementação de syslog do seu sistema operacional. Para utilizar esta opção, você deve habilitar a opção
--syslog
.
--logappend
Acrescenta novas entradas ao final do arquivo de log existente quando a instância
mongod
é reiniciada. Sem esta opção,mongod
faz backup do registro existente e cria um novo arquivo.
--logRotate <string>
Padrão: renomear
Determina o comportamento do comando
logRotate
ao girar o log do servidor e/ou o log de auditoria. Especifiquerename
oureopen
: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 oreopen
ao usar o utilitário de rotação de registro Linux/Unix para evitar perda de registro.Se você especificar
reopen
, também deverá usar--logappend
.
--timeStampFormat <string>
Default: iso8601-local
O formato de hora para carimbos de data/hora em mensagens de registro. Especifique um dos valores a seguir:
ValorDescriçãoiso8601-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
--timeStampFormat
não aceita maisctime
. Um exemplo de data formatadactime
é:Wed Dec 31 18:17:54.811
.
--pidfilepath <path>
Especifica uma localização de arquivo para armazenar o ID de processo (PID) do processo
mongod
. O usuário que executa o processomongod
oumongos
deve ser capaz de gravar nesse caminho. Se a opção--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 opção--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 comsystemctl
. Só use a opção--pidfilepath
se não estiver usando um desses sistemas de inicialização. Para obter mais informações, consulte o 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--pidfilepath
se você não estiver usandobrew
no seu sistema macOS. Para obter mais informações, consulte o Guia de Instalação do seu sistema operacional.
--keyFile <file>
Especifica o caminho para um arquivo de chave que armazena o segredo compartilhado que instâncias do MongoDB usam para autenticar umas às outras em um cluster fragmentado ou conjunto de réplicas.
--keyFile
implica--auth
. 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.
--setParameter <options>
Especifica um dos parâmetros MongoDB descritos em Parâmetros do MongoDB Server para uma implementação autogerenciada. Você pode especificar múltiplos campos
setParameter
.
--nounixsocket
Desabilita a escuta no soquete de domínio UNIX.
--nounixsocket
se aplica somente aos sistemas baseados em Unix.O processo
mongod
sempre escuta no soquete UNIX, a menos que uma das seguintes opções seja verdadeira:--nounixsocket
está definidonet.bindIp
não está definidonet.bindIp
não especificalocalhost
ou seu endereço IP associado
mongod
instalados a partir de pacotes .deb e .rpm oficiais têm a configuraçãobind_ip
definida como127.0.0.1
por padrão.
--unixSocketPrefix <path>
Padrão: /tmp
O caminho para o soquete UNIX.
--unixSocketPrefix
se aplica somente aos sistemas baseados em Unix.Se esta opção não tiver nenhum valor, o processo
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á definidonet.bindIp
não está definidonet.bindIp
não especificalocalhost
ou seu endereço IP associado
--filePermissions <path>
Padrão:
0700
Define a permissão para o arquivo de soquete de domínio UNIX.
--filePermissions
aplica-se apenas a sistemas baseados em Unix.
--fork
Habilita um modo daemon que executa o processo
mongod
em segundo plano. A opção--fork
não é suportada no Windows.Por padrão,
mongod
não é executado como um daemon. Você executamongod
como um daemon utilizando--fork
ou um processo de controle que lida com a daemonização, comoupstart
ousystemd
.Para usar
--fork
, configure a saída de log paramongod
com um dos seguintes:
--auth
Permite a autorização para controlar o acesso do usuário aos recursos do banco de dados e às operações. Quando a autorização está habilitada, o MongoDB exige que todos os clientes se autentiquem primeiro para determinar o acesso para o cliente.
Para configurar usuários, utilize o cliente
mongosh
. Se não houver usuários, a interface do localhost terá acesso ao banco de dados até que você crie o primeiro usuário.Consulte Segurança para obter mais informações.
--noauth
Desabilita a autenticação. Atualmente o padrão. Existe para futura compatibilidade e clareza.
--transitionToAuth
Permite que o
mongod
aceite e crie conexões autenticadas e não autenticadas de e para outras instânciasmongod
emongos
na implantação. Usado para realizar a transição contínua de conjunto 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--keyFile
.Por exemplo, se utilizar keyfiles para autenticação interna,
mongod
criará uma conexão autenticada com qualquermongod
oumongos
no sistema utilizando um arquivo de chave correspondente. Se os mecanismos de segurança não corresponderem,mongod
utilizará uma conexão não autenticada.Um
mongod
em execução com--transitionToAuth
não impõe controles de acesso do usuário. Os usuários podem se conectar a sua implantação sem nenhuma verificação de controle de acesso e realizar operações administrativas, de leitura e gravação.Observação
Um
mongod
executando com autenticação interna e sem--transitionToAuth
exige que os clientes se conectem usando controles de acesso de usuário. Atualize os clientes para conectar aomongod
usando o usuário apropriado antes de reiniciar omongod
sem--transitionToAuth
.
--sysinfo
Retorna informações do sistema de diagnóstico e sai. As informações fornecem o tamanho da página, o número de páginas físicas e o número de páginas físicas disponíveis.
--notablescan
Proíbe operações que exijam uma verificação de collection. Consulte
notablescan
para obter informações adicionais.
--shutdown
A opção
--shutdown
encerra o processomongod
de maneira limpa e segura. Ao invocarmongod
com esta opção, você deve definir a opção--dbpath
diretamente ou por meio do arquivo de configuração e da opção--config
.A opção
--shutdown
está disponível somente em sistemas Linux.Para conhecer outras maneiras de encerrar, consulte também Interromper processos
mongod
.
--redactClientLogData
Disponível apenas no MongoDB Enterprise.
Um
mongod
em execução com--redactClientLogData
oculta qualquer mensagem que acompanhe um determinado evento de log antes do registro de log. Isso impede quemongod
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
--redactClientLogData
em conjunto com criptografia em descanso e TLS/SSL (criptografia de transporte) para auxiliar a conformidade com os requisitos normativos.Por exemplo, uma implantação do MongoDB pode armazenar informações de identificação pessoal (PII, na sigla em inglês) em uma ou mais coleções. O
mongod
registra eventos como aqueles relacionados a operações CRUD, fragmentação de metadados etc. É possível quemongod
exponha PII como parte dessas operações de registro. Ummongod
em execução com--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
em execução com--redactClientLogData
pode ser mais difícil devido à falta de dados relacionados a um evento de log. Consulte a página Log de processos no manual para ver um exemplo do efeito de--redactClientLogData
na saída de log.Em um
mongod
em execução, utilizesetParameter
com o parâmetroredactClientLogData
para definir esta configuração.
--networkMessageCompressors <string>
Default: snappy,zstd,zlib
Especifica o(s) compressor(es) padrão(s) a ser(em) usado(s) para comunicação entre esta instância
mongod
e:outros membros do sistema se a instância fizer parte de um conjunto de réplicas ou de um cluster fragmentado
drivers que suportam o formato de mensagem
OP_COMPRESSED
.
MongoDB é compatível com os seguintes compactadores:
Observação
Ambas as instâncias do
mongod
emongos
padrão para compressores dosnappy,zstd,zlib
, nessa ordem.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 na qual você lista os compressores importa, bem como o iniciador de comunicação. Por exemplo, se
mongosh
especificar os seguintes compressores de redezlib,snappy
emongod
especificarsnappy,zlib
, as mensagens entremongosh
emongod
usarãozlib
.Se as partes não compartilharem pelo menos um compressor comum, as mensagens entre as partes serão descompactadas. Por exemplo, se o
mongosh
especificar ozlib
do compressor de rede e omongod
especificarsnappy
, as mensagens entremongosh
emongod
não serão compactadas.
--timeZoneInfo <path>
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 integrado é 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.
wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip unzip timezonedb-latest.zip mongod --timeZoneInfo timezonedb-2017b/ Aviso
O MongoDB usa a biblioteca timelib de terceiros para fornecer conversões precisas entre fusos horários. Devido a uma atualização recente,
timelib
pode criar conversões de fuso 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 a 5.0, baixe o banco de dados de fuso horário. e utilize o parâmetro
timeZoneInfo
.
--outputConfig
Envia as opções de configuração da instância do
mongod
, formatadas em YAML, parastdout
e sai da instância domongod
. Para opções de configuração que usam Valores de arquivo de configuração de origem externa para implantações autogerenciadas,--outputConfig
retorna o valor resolvido para essas opções.Aviso
Isso pode incluir quaisquer senhas ou segredos configurados anteriormente pela fonte externa.
Para exemplos de uso, consulte:
Opções de autenticação ou autorização LDAP
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.
--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>
Disponível apenas no MongoDB Enterprise.
O servidor LDAP no qual o
mongod
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 sua infraestrutura LDAP dividir o diretório LDAP em vários servidores LDAP, especifique um servidor LDAP ou qualquer uma de suas instâncias replicadas no
--ldapServers
. O MongoDB suporta as seguintes referências LDAP, conforme definido em RFC 4511 4.1.10. Não utilize o--ldapServers
para listar todos os servidores LDAP em sua infraestrutura.Esta configuração pode ser configurada em um
mongod
executando utilizandosetParameter
.Se não for definido,
mongod
não poderá usar autenticação ou autorização LDAP.
--ldapValidateLDAPServerConfig <boolean>
Disponível no MongoDB Enterprise
Um sinalizador que determina se a instância
mongod
verifica a disponibilidade doLDAP server(s)
como parte de sua inicialização:Se o
true
, a instância domongod
executará a verificação de disponibilidade e somente continuará a iniciar se o servidor LDAP estiver disponível.Se
false
, a instânciamongod
ignora a verificação de disponibilidade; ou seja, a instância é iniciada mesmo se o servidor LDAP não estiver disponível.
--ldapQueryUser <string>
Disponível apenas no MongoDB Enterprise.
A identidade com a qual o
mongod
se liga, ao conectar ou executar queries em um servidor LDAP.Obrigatório apenas se alguma das seguintes afirmações for verdadeira:
Utilizando autorização LDAP.
Utilizando uma query LDAP para
username transformation
.O servidor LDAP não permite ligações anônimas
Você deve usar
--ldapQueryUser
com--ldapQueryPassword
.Se não for definido,
mongod
não tentará vincular-se ao servidor LDAP.Esta configuração pode ser configurada em um
mongod
executando utilizandosetParameter
.Observação
As implantações do Windows MongoDB podem utilizar o
--ldapBindWithOSDefaults
ao invés do--ldapQueryUser
e--ldapQueryPassword
. Você não pode especificar--ldapQueryUser
e--ldapBindWithOSDefaults
ao mesmo tempo.
Disponível apenas no MongoDB Enterprise.
A senha costumava vincular a um servidor LDAP ao usar o --ldapQueryUser
. Você deve usar --ldapQueryPassword
com --ldapQueryUser
.
Se não estiver configurado, o mongod
não tentará vincular ao servidor LDAP.
Você pode definir essa configuração em um mongod
em execução usando setParameter
.
O comando ldapQueryPassword
setParameter
aceita uma string ou um array de strings. Se ldapQueryPassword
for definido como array, o MongoDB fará uma tentativa com 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 --ldapBindWithOSDefaults
ao invés do --ldapQueryUser
e --ldapQueryPassword
. Você não pode especificar --ldapQueryPassword
e --ldapBindWithOSDefaults
ao mesmo tempo.
--ldapBindWithOSDefaults <bool>
Padrão: false
Disponível no MongoDB Enterprise apenas para a plataforma Windows.
Permite ao
mongod
autenticar ou vincular, utilizando suas credenciais de login do Windows ao conectar ao servidor LDAP.Necessário apenas se:
Utilizando autorização LDAP.
Utilizando uma query LDAP para
username transformation
.O servidor LDAP não permite ligações anônimas
Use
--ldapBindWithOSDefaults
para substituir--ldapQueryUser
e--ldapQueryPassword
.
--ldapBindMethod <string>
Padrão: simples
Disponível apenas no MongoDB Enterprise.
O método
mongod
usa para autenticar em um servidor LDAP. Use com--ldapQueryUser
e--ldapQueryPassword
para fazer a conexão com o servidor LDAP.--ldapBindMethod
suporta os seguintes valores:simple
-mongod
utiliza autenticação simples.sasl
-mongod
utiliza protocolo SASL para autenticação
Se você especificar
sasl
, poderá configurar os mecanismos SASL disponíveis utilizando o--ldapBindSaslMechanisms
.mongod
usa como padrão o mecanismoDIGEST-MD5
.
--ldapBindSaslMechanisms <string>
Padrão: DIGEST-MD5
Disponível apenas no MongoDB Enterprise.
Uma lista separada por vírgulas de mecanismos SASL
mongod
pode utilizar ao autenticar para o servidor LDAP. Omongod
e o servidor LDAP devem concordar com pelo menos um mecanismo. Omongod
carrega dinamicamente quaisquer bibliotecas de mecanismos SASL instaladas na máquina host no runtime.Instale e configure as bibliotecas apropriadas para o(s) mecanismo(s) SASL selecionado(s) no host do
mongod
e no host do servidor LDAP remoto. Seu sistema operacional pode incluir determinadas bibliotecas SASL por padrão. Respeite 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 Sistemas Autogerenciados, verifique o seguinte para a máquina hostmongod
: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
usar ao se conectar ao servidor LDAP e executar query LDAP.
Windows
- Se estiver conectando a um servidor do Active Directory, a configuração do Windows Kerberos gerará automaticamente um Ticket-Granting-Ticket quando o usuário se conectar ao sistema. Defina
--ldapBindWithOSDefaults
comotrue
para permitir quemongod
use as credenciais geradas ao se conectar ao servidor do Active Directory e executar queries.
Defina
--ldapBindMethod
comosasl
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:
Para Linux, consulte a documentação do Cyrus SASL.
Para Windows, consulte a documentação do Windows SASL.
--ldapTransportSecurity <string>
Padrão: tls
Disponível apenas no MongoDB Enterprise.
Por padrão, o
mongod
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êncialibldap
. Consulte a documentação doTLS 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.
Configure o
--ldapTransportSecurity
paranone
para desabilitar TLS/SSL entremongod
e o servidor LDAP.Aviso
Configurar o
--ldapTransportSecurity
paranone
transmite informações de texto simples e possivelmente credenciais entre omongod
e o servidor LDAP.
--ldapTimeoutMS <int>
Padrão: 10000
Disponível apenas no MongoDB Enterprise.
A quantidade de tempo em milésimos de segundo
mongod
deve aguardar a resposta de um servidor LDAP a uma solicitação.Aumentar o valor de
--ldapTimeoutMS
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--ldapTimeoutMS
reduz o tempo que o MongoDB espera por uma resposta do servidor LDAP.Esta configuração pode ser configurada em um
mongod
executando utilizandosetParameter
.
--ldapRetryCount <int>
Novidades na versão 6.1.
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.
--ldapUserToDNMapping <string>
Disponível apenas no MongoDB Enterprise.
Mapeia o nome de usuário fornecido ao
mongod
para autenticação para um nome diferenciado (DN) LDAP. Você pode precisar utilizar o--ldapUserToDNMapping
para transformar um nome de usuário em um DN 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 de clientes autenticados no Mongo DB usando diferentes mecanismos de autenticação, como x.509 ou Kerberos, em um DN LDAP completo para autorização.
--ldapUserToDNMapping
espera uma JSON-string com aspas que represente uma array ordenada de documentos. Cada documento contém uma expressão regularmatch
e um modelosubstitution
ouldapQuery
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>" } CampoDescriçãoExemplomatch
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 pelosubstitution
ouldapQuery
."(.+)ENGINEERING"
"(.+)DBA"
substitution
Um modelo de formatação de nome diferenciado (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 regexmatch
.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 regexmatch
em um URI de query LDAP criptografado respeitando RFC4515 e RFC4516. 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 expressãomatch
. Omongod
executa a query no servidor LDAP para recuperar o nome diferenciado LDAP do usuário autenticado.mongod
exige exatamente um resultado retornado para que a transformação seja bem-sucedida, oumongod
ignora essa transformação."ou=engineering,dc=example, dc=com??one?(user={0})"
Observação
Para cada documento na array, você deve usar
substitution
ouldapQuery
. Você não pode especificar ambos no mesmo documento.Ao executar a autenticação ou autorização,
mongod
etapas através de cada documento na array no pedido fornecido, verificando o nome de usuário da autenticação no filtromatch
. Se uma correspondência for localizada, omongod
aplicará a transformação e utilizará a saída para autenticar o usuário.mongod
não verifica os documentos restantes na array.Se o documento fornecido não corresponder ao nome de autenticação fornecido,
mongod
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
retornará um erro.mongod
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
rejeita a solicitação de conexão e não verifica os documentos restantes no array.A partir do MongoDB 5.0,
--ldapUserToDNMapping
aceita strings vazias""
ou array vazia[ ]
no lugar de um documento de mapeamento. Se fornecer uma string vazia ou uma array vazia a--ldapUserToDNMapping
, o MongoDB mapeará o nome de usuário autenticado como o DN LDAP. Nas versões anteriores, fornecer um documento de mapeamento vazio faz com que o mapeamento falhe.Exemplo
O seguinte mostra dois documentos de transformação. O primeiro documento corresponde a qualquer cadeia de caracteres que termine em
@ENGINEERING
, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex. O segundo documento corresponde a qualquer cadeia de caracteres que termine em@DBA
, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex.Importante
Você deve passar a array para --ldapUserToDNMapping como uma string.
"[ { 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 caracteresalice
. A saída resultante é o DN"cn=alice,ou=engineering,dc=example,dc=com"
.Um usuário com nome de usuário
bob@DBA.EXAMPLE.COM
corresponde ao segundo documento. O grupo de captura regex{0}
corresponde à cadeia de caracteresbob
. A saída resultante é a query LDAP"ou=dba,dc=example,dc=com??one?(user=bob)"
.mongod
executa esta query no servidor LDAP, retornando o resultado"cn=bob,ou=dba,dc=example,dc=com"
.Se
--ldapUserToDNMapping
estiver desmarcado, omongod
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 definida em um
mongod
em execução usando o comandosetParameter
banco de dados.
--ldapAuthzQueryTemplate <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 host ou hosts especificados em--ldapServers
.Na URL, você pode usar os seguintes tokens de substituição:
Token de substituiçãoDescrição{USER}
Substitui o nome de usuário autenticado, ou o nome de usuário dotransformed
se umusername mapping
for especificado.{PROVIDED_USER}
Substitui o nome de usuário fornecido, ou seja, antes da autenticação ouLDAP transformation
.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 um dos DNs dos quais essa entidade é membro.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 doadmin
. Se uma função no banco de dados doadmin
corresponder exatamente ao DN, omongod
concede ao usuário as funções e privilégios atribuídos a esta função. Consulte o métododb.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.Essa configuração pode ser definida em um
mongod
em execução usando o comandosetParameter
banco de dados.
Opções de armazenamento
--storageEngine string
Padrão:
wiredTiger
Especifica o mecanismo de armazenamento para o banco de dados do
mongod
. Os valores disponíveis incluem:ValorDescriçãowiredTiger
Para especificar o Mecanismo de Armazenamento 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--dbpath
que contenha arquivos de dados produzidos por um storage engine diferente do especificado pelo--storageEngine
, omongod
não iniciará.
--dbpath <path>
Padrão:
/data/db
no Linux e macOS,\data\db
no WindowsO diretório onde a instância do
mongod
armazena seus dados.Se utilizar o Arquivo de Configuração padrão incluído com uma instalação do gerenciador de pacotes do MongoDB, a configuração correspondente do
storage.dbPath
utilizará um padrão diferente.Os arquivos no
--dbpath
devem corresponder ao mecanismo de armazenamento especificado no--storageEngine
. Se os arquivos de dados não corresponderem ao--storageEngine
, omongod
não iniciará.
--directoryperdb
Utiliza um diretório separado para armazenar dados para cada banco de dados. Os diretórios estão sob o diretório
--dbpath
e cada nome de subdiretório corresponde ao nome do banco de dados.Não disponível para instâncias do
mongod
que usam o storage engine na memória.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
--directoryperdb
estiver ativado exclui o subdiretório recém-esvaziado desse banco de dados.Para alterar a opção
--directoryperdb
para implantações existentes:Para instâncias standalone:
Utilize o
mongodump
na instância domongod
existente para gerar uma cópia de segurança.Pare a instância do
mongod
.Adicione o valor
--directoryperdb
e configure um novo diretório de dadosReinicie a instância do
mongod
.Utilize o
mongorestore
para preencher o novo diretório de dados.
Para conjuntos de réplicas:
Pare um membro secundário.
Adicione o valor
--directoryperdb
e configure um novo diretório de dados para esse nó secundário.Reinicie esse secundário.
Utilize sincronização inicial para preencher o novo diretório de dados.
Atualize os secundários restantes da mesma maneira.
Mova para baixo o membro primário e atualize o membro movido para baixo da mesma maneira.
--syncdelay <value>
Padrão: 60
Controla quanto tempo pode passar antes que o MongoDB transfira os 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.--syncdelay
não tem efeito sobre o registro no diário, mas se--syncdelay
estiver definido como0
, o diário consome todo o espaço em disco disponível em algum momento.Não disponível para instâncias do
mongod
que usam o storage engine na memória.Para fornecer dados duráveis, o WiredTiger usa checkpoints. Para obter mais detalhes, consulte Registro no diário e mecanismo de armazenamento WiredTiger.
--upgrade
Atualiza o formato de dados no disco dos arquivos especificados pelo
--dbpath
para a versão mais recente, se necessário.Esta opção afeta somente a operação do
mongod
se os arquivos de dados estiverem em um formato antigo.Na maioria dos casos, você não deve definir esse valor para poder exercer o controle máximo sobre o processo de atualização. Consulte as notas de versão do MongoDB para obter mais informações sobre o processo de atualização.
--repair
Executa uma rotina de reparo em todos os bancos de dados para uma instância do
mongod
.A partir do MongoDB 5.0:
A operação de reparo valida a collection para encontrar quaisquer inconsistências e as corrige, se possível, o que evita a reconstrução dos índices.
Se o ficheiro de dados de uma collection for recuperado ou se a collection tiver inconsistências que a etapa de validação não consegue corrigir, todos os índices serão reconstruídos.
Dica
Se você estiver executando com o journaling ativado, quase nunca será necessário executar o reparo, pois o servidor pode usar os arquivos de journaling para restaurar automaticamente os ficheiros de dados para um estado limpo. No entanto, talvez seja necessário executar o reparo nos casos em que você precise se recuperar de uma corrupção de dados no nível do disco.
Aviso
Utilize
mongod --repair
somente se você não tiver outras opções. A operação remove e não salva quaisquer dados corrompidos durante o processo de reparo.Evite executar o
--repair
em relação a um membro do conjunto de réplica:Para reparar um membro do conjunto de réplicas , se você tiver uma cópia intacta dos seus dados disponíveis (por exemplo, um backup recente ou um membro intacto do conjunto de réplicas), restaure a partir dessa cópia intacta. Para saber mais, consulte Sincronizar novamente um membro de um conjunto de réplicas autogerenciado.
Se você optar por executar
mongod --repair
em um membro do conjunto de réplicas e a operação modificar os dados ou os metadados, ainda será necessário executar uma ressincronização completa para que o membro volte a fazer parte do conjunto de réplicas.
Antes de usar
--repair
, faça uma cópia de backup do diretóriodbpath
.Se o reparo falhar ao completar por qualquer motivo, você deverá reiniciar a instância utilizando a opção
--repair
.
--journalCommitInterval <value>
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 padrão de confirmação do diário é de 100 milésimos de segundo. Uma escrita que inclui ou implica que o(a)
j:true
provoca uma sincronização imediata do diário. Para obter detalhes e condições adicionais que afetam a frequência da sincronização, consulte Processo de diário.Não disponível para instâncias do
mongod
que usam o storage engine na memória.
Opções do WiredTiger
--wiredTigerCacheSizeGB <float>
Define o tamanho máximo do cache interno que o WiredTiger utiliza para todos os dados. A memória consumida por uma construção de índice (consulte
maxIndexBuildMemoryUsageMegabytes
) é separada da memória de cache do WiredTiger.Os valores podem variar de
0.25
GB a10000
GB.O tamanho do cache interno padrão do WiredTiger é o maior entre:
50% de (RAM - 1 GB) ou
256 MB.
Por exemplo, em um sistema com um total de 4 GB de RAM, o cache WiredTiger usa 1.5GB de RAM (
0.5 * (4 GB - 1 GB) = 1.5 GB
). Por outro lado, em um sistema com um total de 1.25 GB de RAM, o WiredTiger aloca 256 MB para o cache do WiredTiger porque isso é mais da metade da RAM total menos um gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
).Observação
Em alguns casos, como quando executado em um container, o banco de dados pode ter restrições de memória inferiores à memória total do sistema. Nesses casos, esse limite de memória, em vez do total memória do sistema, é usado como a RAM máxima disponível.
Para ver o limite de memória, consulte
hostInfo.system.memLimitMB
.Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão.
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
--wiredTigerCacheSizeGB
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 há uma única instância
mongod
por máquina. Se uma única máquina contiver várias instâncias do MongoDB, você deverá diminuir a configuração para acomodar as outras instâncias domongod
.Se executar
mongod
em um container (por exemplo,lxc
,cgroups
, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir--wiredTigerCacheSizeGB
para um valor menor que a quantidade de RAM disponível no container. A quantidade exata depende dos outros processos em execução no contêiner. Consulte a páginamemLimitMB
.
--wiredTigerJournalCompressor <compressor>
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:
--wiredTigerDirectoryForIndexes
Quando você inicia o
mongod
com--wiredTigerDirectoryForIndexes
, omongod
armazena índices e coleções em subdiretórios separados sob o diretório dos dados (ou seja--dbpath
). Especificamente, omongod
armazena os índices em um subdiretório denominadoindex
e os dados de coleção em um subdiretório denominadocollection
.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 oindex
subdiretório do para o destino e crie um link simbólico denominadoindex
no diretório de dados para o novo destino.
--wiredTigerCollectionBlockCompressor <compressor>
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:
--wiredTigerCollectionBlockCompressor
afeta todas as coleções criadas. Se você alterar o valor de--wiredTigerCollectionBlockCompressor
em uma implantação MongoDB existente, todas as novas coleções utilizarão o compressor especificado. Coleções existentes continuam a usar o compressor especificado quando foram criadas ou o compressor padrão naquele momento.
--wiredTigerIndexPrefixCompression <boolean>
Padrão: true
Habilita ou desabilita a compressão de prefixo para dados de índice.
Especifique
true
como--wiredTigerIndexPrefixCompression
a fim de habilitar a compactação de prefixo para dados do índice ou comofalse
a fim de desativar a compactação de prefixo para dados do índice.A configuração
--wiredTigerIndexPrefixCompression
afeta todos os índices criados. Se você alterar o valor do--wiredTigerIndexPrefixCompression
em uma implantação do MongoDB existente, todos os novos índices utilizarão compactação de prefixo. Os índices existentes não são afetados.
Opções de replicação
--replSet <setname>
Configura a replicação. Especifique um nome de conjunto de réplicas como argumento para este conjunto. Todos os hosts no conjunto de réplicas devem ter o mesmo nome de 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.
--oplogSize <value>
O tamanho máximo em megabytes do oplog. A configuração
oplogSize
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 5 bits, o oplog é normalmente % do espaço em disco disponível.Após o
mongod
criar o oplog pela primeira vez, alterar a opção--oplogSize
não afeta o tamanho do oplog. Para alterar o período mínimo de retenção de oplog após iniciar omongod
, usereplSetResizeOplog
. OreplSetResizeOplog
permite redimensionar o oplog dinamicamente sem reiniciar o processo domongod
. Para manter as alterações feitas usandoreplSetResizeOplog
por meio de uma reinicialização, atualize o valor de--oplogSize
..Consulte Tamanho do Oplog para obter mais informações.
--oplogMinRetentionHours <value>
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 de0
indica que omongod
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 entradas de oplog ao impor a retenção de entradas de oplog. O desvio do relógio entre os componentes do cluster pode resultar em um comportamento inesperado de retenção de 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
, utilizereplSetResizeOplog
. OreplSetResizeOplog
permite a você redimensionar o oplog dinamicamente sem reiniciar o processo domongod
. Para manter as alterações feitas usandoreplSetResizeOplog
por meio de uma reinicialização, atualize o valor de--oplogMinRetentionHours
.
--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 comotrue
. 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:
A preocupação de gravação
"majority"
pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como mitigar esses problemas, consulte Atenuar problemas de desempenho com um conjunto de réplicas de PSA autogerenciado.Se você estiver usando um
"majority"
padrão global e o write concern for menor do que o tamanho da maioria, suas consultas poderão retornar dados obsoletos (não totalmente replicados).
Opções de cluster fragmentado
--configsvr
Obrigatório ao iniciar um servidor de configuração.
Declara que esta instância do
mongod
serve como o servidor de configuração de um cluster fragmentado. Ao executar esta opção, os clientes (ou seja, outros componentes do cluster) não podem gravar dados em nenhum banco de dados diferente deconfig
eadmin
. A porta padrão para ummongod
com esta opção é27019
e o diretório--dbpath
padrão é/data/configdb
, a menos que especificado.Importante
Ao iniciar um servidor MongoDB com
--configsvr
, você também deve especificar um--replSet
.O uso de instâncias
mongod
espelhadas obsoletas como servidores de configuração (SCCC) não é mais suportado.Os servidores de configuração do conjunto de réplica (CSRS) devem executar o mecanismo de armazenamento WiredTiger.
A opção
--configsvr
cria um oplog local.Não use a opção
--configsvr
com--shardsvr
. Os servidores de configuração não podem ser um servidor fragmento.Não use
--configsvr
com o parâmetroskipShardingConfigurationChecks
. Ou seja, se você estiver iniciando temporariamente omongod
como autônomo para operações de manutenção, inclua o parâmetroskipShardingConfigurationChecks
e exclua--configsvr
. Após a manutenção ser concluída, remova o parâmetroskipShardingConfigurationChecks
e reinicie com--configsvr
.
--shardsvr
Obrigatório ao iniciar um servidor de shard.
Configura esta instância
mongod
como um fragmento em um cluster fragmentado. A porta padrão para essas instâncias é27018
.Importante
Ao iniciar um servidor MongoDB com
--shardsvr
, você também deve especificar um--replSet
.Não use
--shardsvr
com o parâmetroskipShardingConfigurationChecks
. Ou seja, se você estiver iniciando temporariamente omongod
como autônomo para operações de manutenção, inclua o parâmetroskipShardingConfigurationChecks
e exclua--shardsvr
. Após a manutenção ser concluída, remova o parâmetroskipShardingConfigurationChecks
e reinicie com--shardsvr
.
Opções de TLS
Dica
Consulte:
Configure o mongod
e o mongos
para TLS/SSL para documentação completa do suporte do MongoDB.
--tlsMode <mode>
Ativa o TLS usado para todas as conexões de rede. O argumento para a opção
--tlsMode
pode ser um dos seguintes:ValorDescriçãodisabled
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
outls.CAFile
não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetrotlsUseSystemCA
comotrue
. Isso faz com que o MongoDB use o armazenamento de certificados CA em todo o sistema ao se conectar a um servidor habilitado para TLS.Se estiver usando a autenticação x.509,
--tlsCAFile
outls.CAFile
deverá ser especificado, a menos que esteja usando--tlsCertificateSelector
.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsCertificateKeyFile <filename>
Especifica o arquivo
.pem
que contém o certificado e a chave TLS.No macOS ou no Windows, você pode usar a opção
--tlsCertificateSelector
para especificar um certificado do repositório de certificados seguro do sistema operacional em vez de um arquivo de chave PEM. As opções--tlsCertificateKeyFile
e--tlsCertificateSelector
são mutuamente exclusivas. Você só pode especificar uma.No Linux/BSD, você deve especificar
--tlsCertificateKeyFile
quando o TLS/SSL estiver habilitado.No Windows ou macOS, você deve especificar
--tlsCertificateKeyFile
ou--tlsCertificateSelector
quando TLS/SSL estiver habilitado.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 TLS no Windows, use--tlsCertificateSelector
.
Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsCertificateKeyFilePassword <value>
Especifica a senha para descriptografar o arquivo de chave de certificado (ou seja,
--tlsCertificateKeyFile
). Utilize a opção--tlsCertificateKeyFilePassword
somente se o arquivo da chave de certificado for criptografado. Em todos os casos, omongod
edita a senha de todos os resultados de geração de registros e relatórios.No Linux/BSD, se a chave privada no arquivo PEM estiver criptografada e você não especificar a opção
--tlsCertificateKeyFilePassword
, o MongoDB solicitará uma senha. Consulte Senha do certificado TLS/SSL.No macOS, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção
--tlsCertificateKeyFilePassword
. Como alternativa, é possível usar um certificado do armazenamento seguro do sistema (consulte--tlsCertificateSelector
) em vez de um arquivo 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. Use--tlsCertificateSelector
em vez disso.
Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--clusterAuthMode <option>
Padrão: keyFile
O modo de autenticação usado para autenticação de cluster. Se você usar a autenticação x.509 interna, especifique-a aqui. Esta opção pode ter um dos seguintes valores:
ValorDescriçãokeyFile
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
outls.CAFile
não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetrotlsUseSystemCA
comotrue
. Isso faz com que o MongoDB use o armazenamento de certificados CA em todo o sistema ao se conectar a um servidor habilitado para TLS.Se estiver usando a autenticação x.509,
--tlsCAFile
outls.CAFile
deverá ser especificado, a menos que esteja usando--tlsCertificateSelector
.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsClusterFile <filename>
Especifica 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
--tlsClusterCertificateSelector
para especificar um certificado do repositório de certificados seguro do sistema operacional em vez de um arquivo de chave PEM. As opções--tlsClusterFile
e--tlsClusterCertificateSelector
são mutuamente exclusivas. Você só pode especificar uma.Se
--tlsClusterFile
não especificar o arquivo.pem
para autenticação de cluster interna ou a alternativa--tlsClusterCertificateSelector
, o cluster utilizará o arquivo.pem
especificado na opção--tlsCertificateKeyFile
ou o certificado retornado por--tlsCertificateSelector
.Se estiver usando a autenticação x.509,
--tlsCAFile
outls.CAFile
deverá ser especificado, a menos que esteja usando--tlsCertificateSelector
.O
mongod
/mongos
registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de30
dias a partir da hora do sistema do host domongod/mongos
.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .Importante
Somente para Windows, o MongoDB não aceita arquivos PEM criptografados.
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--tlsClusterCertificateSelector
.
--tlsCertificateSelector <parameter>=<value>
Observação
Disponível no Windows e macOS como alternativa a
--tlsCertificateKeyFile
.Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para usar para TLS.
As opções
--tlsCertificateKeyFile
e--tlsCertificateSelector
são mutuamente exclusivas. Você só pode especificar uma.--tlsCertificateSelector
aceita um argumento do formato<property>=<value>
e a propriedade pode ser uma das abaixo:PropriedadeTipo de valorDescriçãosubject
string ASCIINome do assunto ou nome comum no certificadothumbprint
string hexadecimalUma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.
O
thumbprint
às vezes é denominadofingerprint
.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. Não use--tlsCAFile
ou--tlsClusterCAFile
para especificar o certificado de CA raiz e intermediárioPor exemplo, se o certificado TLS/SSL foi assinado com um único certificado CA raiz, o armazenamento seguro de certificados deverá conter esse certificado CA root. Se o certificado TLS/SSL foi assinado com um certificado CA intermediário, o armazenamento seguro de certificados deverá conter o certificado CA intermediário e o certificado CA raiz.
Observação
Não é possível usar o comando
rotateCertificates
ou o método shelldb.rotateCertificates()
ao usarnet.tls.certificateSelector
ou--tlsCertificateSelector
definido comothumbprint
--tlsClusterCertificateSelector <parameter>=<value>
Observação
Disponível no Windows e macOS como alternativa a
--tlsClusterFile
.Especifica uma propriedade de certificado para selecionar um certificado correspondente no armazenamento de certificados do sistema operacional para autenticação interna de associação de x.509.
As opções
--tlsClusterFile
e--tlsClusterCertificateSelector
são mutuamente exclusivas. Você só pode especificar uma.--tlsClusterCertificateSelector
aceita um argumento do formato<property>=<value>
e a propriedade pode ser uma das abaixo:PropriedadeTipo de valorDescriçãosubject
string ASCIINome do assunto ou nome comum no certificadothumbprint
string hexadecimalUma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.
O
thumbprint
às vezes é denominadofingerprint
.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 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. Não use--tlsCAFile
ou--tlsClusterCAFile
para especificar o certificado de CA raiz e intermediário.Por exemplo, se o certificado cluster tiver sido assinado com um único certificado CA raiz, o armazenamento seguro de certificados deverá conter esse certificado CA raiz. Se o certificado 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 de30
dias a partir da hora do sistema do host domongod/mongos
.
--tlsClusterPassword <value>
Especifica a senha para descriptografar o arquivo da chave de certificado x.509 especificado com
--tlsClusterFile
. Use a opção--tlsClusterPassword
somente se o arquivo da chave de certificado estiver criptografada. Em todos os casos, omongod
suprime 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
--tlsClusterPassword
, o MongoDB solicitará uma senha. Consulte a página "Senha do certificado TLS/SSL".No macOS, se a chave privada no arquivo x.509 estiver criptografada, você deverá especificar explicitamente a opção
--tlsClusterPassword
. Como alternativa, é possível usar um certificado do armazenamento seguro do sistema (consulte a seção--tlsClusterCertificateSelector
) no lugar de usar um arquivo PEM de cluster 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. Use--tlsClusterCertificateSelector
em vez disso.
Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsCAFile <filename>
Especifica 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.Importante
Ao iniciar uma instância do
mongod
com TLS/SSL habilitado, você deve especificar um valor para o sinalizador--tlsCAFile
, a opção de configuração donet.tls.CAFile
ou o parâmetrotlsUseSystemCA
.--tlsCAFile
,tls.CAFile
etlsUseSystemCA
são mutuamente exclusivos.- Somente Windows/macOS
- Se estiver usando
--tlsCertificateSelector
e/ou--tlsClusterCertificateSelector
, não use--tlsCAFile
para especificar os certificados CA raiz e intermediários. Armazene todos os certificados CA necessários para validar a sequência de confiança completa dos certificados--tlsCertificateSelector
e/ou--tlsClusterCertificateSelector
no armazenamento de certificados seguro.
Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsClusterCAFile <filename>
Especifica 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.--tlsClusterCAFile
requer que--tlsCAFile
esteja definido.Se
--tlsClusterCAFile
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--tlsCAFile
.--tlsClusterCAFile
permite que você use autoridades de certificação separadas para verificar as partes cliente-servidor e servidor-cliente do handshake TLS.- Somente Windows/macOS
- Se estiver usando
--tlsCertificateSelector
e/ou--tlsClusterCertificateSelector
, não use--tlsClusterCAFile
para especificar os certificados CA raiz e intermediários. Armazene todos os certificados CA necessários para validar a sequência de confiança completa dos certificados--tlsCertificateSelector
e/ou--tlsClusterCertificateSelector
no armazenamento de certificados seguro.
Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsCRLFile <filename>
Especifica o arquivo
.pem
que contém a lista de certificados revogados. Especifique o nome do arquivo.pem
usando caminhos relativos ou absolutos.Observação
Você não pode especificar um arquivo CRL no macOS. Em vez disso, você pode usar o armazenamento de certificados SSL do sistema, que usa OCSP (Online Certificate Status Protocol) para validar o status de revogação dos certificados. Consulte
--tlsCertificateSelector
para utilizar 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 o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsAllowInvalidCertificates
Ignora as verificações de validação de certificados TLS em outros servidores no cluster e permite o uso de certificados inválidos para conexões.
Observação
Se você especificar
--tlsAllowInvalidCertificates
outls.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
--tlsAllowInvalidCertificates
, o MongoDB registra um aviso sobre o uso do certificado inválido.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsAllowInvalidHostnames
Desabilita a validação dos nomes de host em certificados TLS ao conectar-se a outros membros do conjunto de réplicas ou cluster fragmentado para autenticação entre processos. Isso permite que
mongod
se conecte a outros membros se os nomes de host em seus certificados não corresponderem ao nome de host configurado.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsAllowConnectionsWithoutCertificates
Por padrão, o servidor ignora a validação do certificado de cliente, a menos que o servidor esteja configurado para utilizar um arquivo CA. Se um arquivo CA for fornecido, as regras a seguir serão aplicadas:
Para clientes que não fornecem certificados, o
mongod
oumongos
criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.Para clientes que apresentam um certificado, o
mongod
executa a validação do certificado utilizando a cadeia de certificado raiz especificada pelo--tlsCAFile
e rejeita clientes com certificados inválidos.
Use a opção
--tlsAllowConnectionsWithoutCertificates
se você tiver uma implantação mista que inclua clientes que não apresentam ou não podem apresentar certificados para omongod
.Para obter mais informações sobre TLS e MongoDB, consulte Configurar o
mongod
e omongos
para TLS/SSL e Configuração TLS/SSL para clientes .
--tlsDisabledProtocols <protocol(s)>
Impede que um servidor MongoDB em execução com TLS aceite conexões recebidas que usam um protocolo ou protocolos específicos. Para especificar protocolos, use uma lista de protocolos separados por vírgulas.
--tlsDisabledProtocols
reconhece os seguintes protocolos:TLS1_0
,TLS1_1
,TLS1_2
eTLS1_3
.No macOS, você não pode desativar
TLS1_1
e deixarTLS1_0
eTLS1_2
ativados. Você deve desativar pelo menos um dos outros dois, por exemplo,TLS1_0,TLS1_1
.Para listar vários protocolos, especifique uma lista de protocolos separados por vírgula. Por exemplo
TLS1_0,TLS1_1
.A especificação de um protocolo não reconhecido impede o servidor de iniciar.
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 TLS 1.0 desabilitado, especifique
none
para--tlsDisabledProtocols
.Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.
--tlsFIPSMode
Direciona
mongod
para usar o modo FIPS da biblioteca TLS. Seu sistema deve ter uma biblioteca compatível com FIPS para utilizar a opção--tlsFIPSMode
.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.
Opções de analisador
--profile <level>
Padrão: 0
Configura o nível do perfil do banco de dados. Os seguintes níveis de analisador estão disponíveis:
0
- O analisador está desligado e não coleta dados. Este é o nível do analisador padrão.
1
O profiler coleta dados para operações que excedem o limite de
slowms
ou correspondem a um filtro especificado.Quando um filtro é definido:
As opções
slowms
esampleRate
não são usadas para análise.O criador de perfil captura somente as operações que correspondem ao filtro.
2
- O analisador coleta dados para todas as operações.
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.
--slowms <integer>
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
é definido como0
, o MongoDB registra operações lentas no log de diagnóstico a uma taxa determinada porslowOpSampleRate
.Em configurações
logLevel
mais altas, todas as operações aparecem no log de diagnóstico, independentemente da latência, com a seguinte exceção: o log de mensagens de entrada lentas do oplog pelos secundários. Os secundários registram apenas as entradas lentas do oplog. AumentarlogLevel
não registra todas as entradas do oplog.Para instâncias
mongod
,--slowms
afeta o log de diagnóstico e, se ativado, o criador de perfiler.
--slowOpSampleRate <double>
Padrão: 1.0
A fração de operações lentas que devem ser analisadas ou registradas.
--slowOpSampleRate
aceita valores entre 0 e 1, inclusive.--slowOpSampleRate
não afeta o registro de entrada de oplog lento pelos membros secundários de um conjunto de réplicas. Os membros secundários registram todas as entradas de oplog que demoram mais do que o limite de operação lenta, independentemente do--slowOpSampleRate
.Para instâncias
mongod
,--slowOpSampleRate
afeta o log de diagnóstico e, se ativado, o criador de perfiler.
Opções de auditoria
--auditCompressionMode
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
--auditEncryptionKeyUID
ou--auditLocalKeyFile
.--auditCompressionMode
pode ser definido para um destes valores:ValorDescriçãozstd
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.
--auditDestination
Ativa a auditoria e especifica para onde
mongod
envia todos os eventos de auditoria.--auditDestination
pode ter um dos seguintes valores:ValorDescriçãosyslog
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 deuser
.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 parastdout
no formato JSON.file
Envie os eventos de auditoria para o arquivo especificado em--auditPath
no formato especificado em--auditFormat
.Observação
Disponível somente em MongoDB Enterprise e MongoDB Atlas.
--auditEncryptionKeyUID
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
--auditEncryptionKeyUID
e--auditLocalKeyFile
juntos.Observação
Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.
--auditFormat
Especifica o formato do arquivo de saída para auditoria se
--auditDestination
forfile
. A opção--auditFormat
pode ter um dos seguintes valores:ValorDescriçãoJSON
Emite os eventos de auditoria no formato JSON para o arquivo especificado em--auditPath
.BSON
Saída dos eventos de auditoria no formato binário BSON para o arquivo especificado em--auditPath
.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.
--auditLocalKeyFile
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
--auditLocalKeyFile
apenas para testes porque a chave não está protegida. Para protegê-la, use--auditEncryptionKeyUID
e um servidor de protocolo de interoperabilidade de gerenciamento de chaves (KMIP) externo.Você não pode usar
--auditLocalKeyFile
e--auditEncryptionKeyUID
juntos.Observação
Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.
--auditPath
Especifica o arquivo de saída para auditoria se
--auditDestination
tiver valor defile
. A opção--auditPath
pode receber um nome de caminho completo ou um nome de caminho relativo.Observação
Disponível somente em MongoDB Enterprise e MongoDB Atlas.
--auditFilter
Especifica o filtro para limitar os tipos de operações que o sistema de auditoria registra. A opção usa uma representação de string de um documento de consulta no formato:
{ <field1>: <expression1>, ... } O
<field>
pode ser qualquer campo na mensagem de auditoria, incluindo os campos retornados no documento paramétrico. O<expression>
é uma expressão de condição de consulta.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.
--auditSchema
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
--auditSchema
:ValorDescriçãomongo
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 gravados no formato OCSF . Essa opção fornece logs em um formato padronizado compatível com processadores de logs.
Para ver exemplos de mensagens de log, consulte Mensagens de auditoria de esquema do OCSF.
Opções do inMemory
--inMemorySizeGB <float>
Padrão: 50% da RAM física menos 1 GB.
Quantidade máxima de memória a ser alocada para os dados do mecanismo de armazenamento na memória, incluindo índices, o oplog (se
mongod
fizer parte de um conjunto de réplicas), metadados de cluster fragmentados etc.Os valores podem variar de 256 MB a 10 TB e podem ser instáveis.
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.
Opções de gerenciamento de chave de encriptação
--enableEncryption
Padrão: false
Habilita a criptografia para o mecanismo de armazenamento WiredTiger. Esta opção deve estar habilitada para passar chaves de encriptação e configurações.
Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--encryptionCipherMode <string>
Padrão: AES256-CBC
O modo de cifra a ser usado para encryption at rest:
ModoDescriçãoAES256-CBC
Padrão de criptografia avançada de 256 bits no modo de sequenciamento de blocos de cifraAES256-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.
--encryptionKeyFile <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.
O arquivo-chave pode conter apenas uma única chave. A chave é uma string de 16 ou 32 caracteres.
Requer
--enableEncryption
.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipKeyIdentifier <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 que habilitar a criptografia para a instância
mongod
. Exige--enableEncryption
.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 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.
--kmipRotateMasterKey <boolean>
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.
--kmipServerName <string>
Nome do host ou endereço IP do servidor KMIP ao qual se conectar. Requer
--enableEncryption
.Você pode especificar vários servidores KMIP como uma lista separada por vírgula, por exemplo:
server1.example.com,server2.example.com
. Na inicialização, omongod
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.Ao conectar a um servidor KMIP, o
mongod
verifica se o--kmipServerName
especificado corresponde ao nome alternativo do assuntoSAN
(ou, seSAN
não estiver presente, o nome comumCN
) no certificado apresentado pelo servidor KMIP. SeSAN
estiver presente,mongod
não corresponde aCN
. Se o nome do host não corresponder aSAN
(ouCN
), omongod
não conectará.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.
--kmipPort <number>
Padrão: 5696
Número da porta a ser usada para comunicação com o servidor KMIP. Requer
--kmipServerName
. Requer--enableEncryption
.Se especificar vários servidores KMIP com
--kmipServerName
, omongod
usará a porta especificada com--kmipPort
para todos os servidores KMIP fornecidos.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipConnectRetries <number>
Padrão: 0
Quantas vezes tentar novamente a conexão inicial com o servidor KMIP. Use junto com
--kmipConnectTimeoutMS
para controlar quanto tempo omongod
espera por uma resposta entre cada nova tentativa.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipConnectTimeoutMS <number>
Padrão: 5000
Tempo limite em milissegundos para aguardar uma resposta do servidor KMIP. Se a configuração
--kmipConnectRetries
for especificada, omongod
aguardará o intervalo especificado entre as novas tentativas.O valor deve ser
1000
ou superior.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipClientCertificateSelector <string>
Novo na versão 5.0: Disponível no Windows e macOS como alternativa ao
--kmipClientCertificateFile
.As opções
--kmipClientCertificateFile
e--kmipClientCertificateSelector
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.
--kmipClientCertificateSelector
aceita um argumento do formato<property>=<value>
e a propriedade pode ser uma das abaixo:PropriedadeTipo de valorDescriçãosubject
string ASCIINome do assunto ou nome comum no certificadothumbprint
string hexadecimalUma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1.
O
thumbprint
às vezes é denominadofingerprint
.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipClientCertificateFile <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 opção, você também deve especificar a opção
--kmipServerName
.Importante
Habilitar a criptografia usando um servidor KMIP no Windows falha ao usar
--kmipClientCertificateFile
e o servidor KMIP impõe TLS 1.2.Para habilitar a encryption at rest com KMIP no Windows, você deve:
Importe o certificado do cliente para o Armazenamento de certificados do Windows.
Use a opção
--kmipClientCertificateSelector
.
Observação
No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte
--kmipClientCertificateSelector
.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipClientCertificatePassword <string>
A senha (se houver) do certificado do cliente passou para
--kmipClientCertificateFile
. É usada para autenticar o MongoDB no servidor KMIP. Requer que um--kmipClientCertificateFile
seja fornecido.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.
--kmipServerCAFile <string>
Caminho para o arquivo CA. Usado para validar a conexão segura do cliente com o servidor KMIP.
Observação
No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte
--kmipClientCertificateSelector
. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o--kmipServerCAFile
.
--kmipActivateKeys <boolean>
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
--kmipActivateKeys
étrue
e você têm 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 quekmipActivateKeys
seja falso. Para garantir que você tenha uma chave ativa, gire a chave mestra KMIP usando--kmipRotateMasterKey
.
--kmipKeyStatePollingSeconds <integer>
Padrão: 900 segundos
Novidades na versão 5.3.
Frequência em segundos em que
mongod
pesquisa o servidor KMIP em busca de chaves ativas.Para desabilitar a pesquisa, defina o valor como
-1
.
--kmipUseLegacyProtocol <boolean>
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.
--eseDatabaseKeyRollover
Passe o mouse sobre as chaves de banco de dados do mecanismo de armazenamento criptografado configuradas com cifra
AES256-GCM
.Quando a instância
mongod
é iniciada com esta opção, a instância gira as chaves e sai.Observação
Funcionalidade de empresas
Disponível apenas no MongoDB Enterprise.