mongos

Opções principais

--help, -h

Retorna informações sobre as opções e uso de mongos.

--version

Retorna o número de versão mongos.

--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 mongos. As opções são equivalentes às opções de configuração da linha de comando. Consulte Opções de arquivo de configuração para obter mais informações.

Certifique-se de que o arquivo de configuração use codificação ASCII. A instância mongos não suporta arquivos de configuração com codificação não ASCII, incluindo UTF-8.

--configExpand <none|rest|exec>

Padrão: nenhum

Novidades na versão 4.2.

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:

Valor	Descrição
none	Padrão. mongos não expande diretivas de expansão. mongos falha ao iniciar se alguma configuração do arquivo de configuração usar diretivas de expansão.
rest	mongos expande as diretivas de expansão __rest ao analisar o arquivo de configuração.
exec	mongos expande as diretivas de expansão __exec ao analisar o arquivo de configuração.

Você pode 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, mongos retornará um erro e encerrará.

Consulte Valores de arquivo de configuração de origem externa 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.

--quiet

Executa mongos 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

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

Alterado na versão 7.0.3: A opção --port aceita uma faixa de valores entre 0 e 65535. A definição da porta como 0 configura mongos 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 mongos deve escutar as conexões do cliente. Você pode anexar mongos 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 especificar um endereço IPv6 ou um nome de host que resolva para um endereço IPv6 para --bind_ip, você deve começar mongos com --ipv6 para habilitar o suporte a IPv6 . Especificar um endereço IPv6 para --bind_ip não habilita o suporte a IPv6 .

Se estiver especificando um endereço IPv7 de link local6 (fe80::/10), você deverá anexar o índice de zona para esse endereço (ou seja, fe80::<address>%<adapter-name>).

Exemplo

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

Importante

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

Use nomes de host em vez de endereços IP para configurar clusters em um horizonte de rede dividido. A partir do MongoDB 5.0, os nós que são configurados apenas com um endereço IP falham na validação de inicialização e não iniciam.

Aviso

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

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

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

Para vincular a todos os endereços IPv4 e IPv6, digite ::,0.0.0.0 ou, a partir do MongoDB 4.2, um asterisco "*" (coloque o asterisco entre aspas para evitar a expansão do padrão do nome do arquivo). Como alternativa, use a configuração net.bindIpAll.

Observação

• --bind_ip e --bind_ip_all são mutuamente exclusivos. Especificar as duas opções faz com que mongos gere um erro e encerre.

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

--bind_ip_all

Se especificada, a instância mongos vincula-se a todos os endereços IPv4 (ou seja, 0.0.0.0). Se mongos começar com --ipv6, --bind_ip_all também se vinculará a todos os endereços IPv6 (ou seja, ::).

mongos 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 acessos não autorizados. Para obter uma lista completa das recomendações de segurança, consulte Lista de verificação de segurança. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.

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

Como alternativa, você pode definir a opção --bind_ip para ::,0.0.0.0 ou, a partir do MongoDB 4.2, para um 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.

--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 constante SOMAXCONN 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 constante SOMAXCONN ou do argumento --listenBacklog e também pode ser limitado por configurações do sistema, como net.core.somaxconn no Linux.

Passar um valor para o parâmetro listenBacklog que excede a constante SOMAXCONN 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âmetro listenBacklog 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 mongos 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.

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

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

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

--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 moverá 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 registro 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 é suportada no Windows.

Aviso

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

A partir da versão 4.2, o MongoDB inclui o componente em suas mensagens de registro 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 mongos é reiniciada. Sem essa opção, o mongod fará backup do registro existente e criará 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. Especifique rename ou reopen:

• rename renomeia o arquivo de log.

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

  Se você especificar reopen, também deverá usar --logappend.

--redactClientLogData

Disponível apenas no MongoDB Enterprise.

Um mongos em execução com --redactClientLogData redige qualquer mensagem que acompanhe determinado evento de registro antes do registro. Isso impede que mongos escreva dados potencialmente confidenciais armazenados no banco de dados no registro 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 registros.

Use --redactClientLogData em conjunto com encryption at rest e TLS/SSL (criptografia de transporte) para auxiliar a conformidade com os requisitos normativos.

Por exemplo, um sistema do MongoDB pode armazenar informações de identificação pessoal (PII) em uma ou mais collections. O mongos registra eventos como aqueles relacionados a operações CRUD, fragmentação de metadados etc. É possível que o mongos exponha PII como parte dessas operações de registro. Um mongos em execução com --redactClientLogData remove qualquer mensagem que acompanhe esses eventos antes de ser enviada para o registro, removendo efetivamente a PII.

O diagnóstico em um mongos em execução com --redactClientLogData pode ser mais difícil devido à falta de dados relacionados a um evento de registro. Consulte a página do manual de registro de processos para ver um exemplo do efeito de --redactClientLogData no resultado de registro.

Em um mongos em execução, utilize setParameter com o parâmetro redactClientLogData para definir esta configuração.

--timeStampFormat <string>

Padrão: iso8601-local

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

Valor	Descrição
iso8601-utc	Exibe carimbos de data/hora em Tempo Universal Coordenado (UTC) no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1970-01-01T00:00:00.000Z
iso8601-local	Exibe carimbos de data e hora na hora local no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1969-12-31T19:00:00.000-05:00

Observação

--timeStampFormat não suporta mais ctime. Um exemplo de data formatada ctime é: Wed Dec 31 18:17:54.811.

--pidfilepath <path>

Especifica uma localização de arquivo para armazenar o ID de processo (PID) do processo mongos . O usuário que executa o processo mongod ou mongos deve ser capaz de escrever neste 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 em systemctl. Só use a opção --pidfilepath se não estiver usando um desses sistemas de inicialização. Para obter mais informações, consulte o respectivo Guia de instalação do seu sistema operacional.

Observação

macOS

No macOS, o gerenciamento de arquivos PID geralmente é tratado pelo brew. Utilize somente a opção --pidfilepath se você não estiver utilizando o brew em seu sistema macOS. Para obter mais informações, consulte o respectivo 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 client authorization. Consulte Autenticação interna/de associação para obter mais informações.

A partir do MongoDB 4.2, os arquivos de chave para autenticação de membros interna usam o formato YAML para permitir várias chaves em um arquivo de chave. 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 servidor MongoDB. Você pode especificar múltiplos campos setParameter.

--noscripting

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

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

--nounixsocket

Desabilita a escuta no soquete de domínio UNIX. --nounixsocket se aplica somente aos sistemas baseados em Unix.

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

• --nounixsocket está definido

• net.bindIp não está definido

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

mongos instalados a partir de pacotes .deb e .rpm oficiais têm a configuração bind_ip definida como 127.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 mongos cria um soquete com /tmp como prefixo. O MongoDB cria e escuta em um soquete UNIX, a menos que um dos seguintes seja verdadeiro:

• net.unixDomainSocket.enabled é false

• --nounixsocket está definido

• net.bindIp não está definido

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

--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 mongos em background. A opção --fork não é suportada no Windows.

Por padrão, mongos não é executado como um daemon. Você executa mongos como um daemon utilizando --fork ou um processo de controle que lida com a daemonização, como upstart ou systemd.

O uso da opção --fork exige que você configure a saída de registro para mongos com uma das seguintes opções:

• --logpath

• --syslog

--transitionToAuth

Permite que mongos aceite e crie conexões autenticadas e não autenticadas de e para outras instâncias mongod e mongos no sistema. 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 interno , como --keyFile.

Por exemplo, se utilizar keyfiles para autenticação interna, o mongos criará uma conexão autenticada com qualquer mongod ou mongos no sistema utilizando um arquivo de chave correspondente. Se os mecanismos de segurança não corresponderem, mongos utilizará uma conexão não autenticada.

Um mongos em execução com --transitionToAuth não impõe controles de acesso de usuário. Os usuários podem se conectar ao seu sistema sem nenhuma verificação de controle de acesso e realizar operações de leitura, gravação e administrativas.

Observação

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

--networkMessageCompressors <string>

Padrão: snappy,zstd,zlib

Especifica o(s) compressor(es) padrão(s) a ser(em) usado(s) para comunicação entre esta instância mongos e:

• outros membros do cluster fragmentado

• mongosh

• drivers que suportam o formato de mensagem OP_COMPRESSED .

MongoDB é compatível com os seguintes compactadores:

• snappy

• zlib

• zstd

Ambas as instâncias do mongod e mongos padrão para compressores do snappy,zstd,zlib, neste pedido.

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 importam, bem como o iniciador de comunicação. Por exemplo, se o mongosh especificar os seguintes compressores de rede zlib,snappy e o mongod especificar snappy,zlib, as mensagens entre mongosh e mongod utilizarão zlib.

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

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

wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip
unzip timezonedb-latest.zip
mongos --timeZoneInfo timezonedb-2017b/

Aviso

O MongoDB usa a timelib de terceiros biblioteca 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 antes de 5.0, 4.4.7 e 4.2.14, baixe o banco de dados de fuso horário . e utilize o parâmetro timeZoneInfo .

--outputConfig

Novidades na versão 4.2.

Envia as opções de configuração da instância do mongos , formatadas em YAML, para stdout e sai da instância do mongos . Para opções de configuração que usam valores de arquivo de configuração de origem externa, --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:

• Enviar o arquivo de configuração com valores de diretiva de expansão resolvidos

• Converter opções de linha de comando em YAML

Opções de cluster fragmentado

--configdb <replicasetName>/<config1>,<config2>...

Especifica os servidores de configuração para o cluster fragmentado.

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

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

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

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

--localThreshold

Padrão: 15

Especifica o tempo de ping, em milissegundos, que mongos usa para determinar quais nós do conjunto de réplicas secundárias passam operações de leitura dos clientes. O valor padrão de 15 corresponde ao valor padrão em todos os drivers do cliente.

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

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

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

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

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

O tempo de ping usado para um membro em comparação com a configuração --localThreshold é uma média móvel dos tempos de ping recentes, calculada no máximo a cada 10 segundos. Como resultado, algumas queries podem alcançar nós acima do limite até que o mongos recalcule a média.

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

Opções de TLS

--tlsMode <mode>

Novidades na versão 4.2.

Ativa o TLS usado para todas as conexões de rede. O argumento para a opção --tlsMode pode ser um dos seguintes:

Valor	Descrição
disabled	O servidor não usa TLS.
allowTLS	As conexões entre servidores não usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
preferTLS	As conexões entre servidores usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
requireTLS	O servidor usa e aceita apenas conexões criptografadas TLS.

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

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

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateKeyFile <filename>

Novidades na versão 4.2.

Observação

No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de especificar um arquivo PEM. Consulte --tlsCertificateSelector.

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

• No Linux/BSD, você deve especificar --tlsCertificateKeyFile quando TLS estiver habilitado.

• No Windows ou macOS, você deve especificar --tlsCertificateKeyFile ou --tlsCertificateSelector quando TLS estiver habilitado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateKeyFilePassword <value>

Novidades na versão 4.2.

Especifica a senha para descriptografar o arquivo da chave de certificado (ou seja, --tlsCertificateKeyFile). Use a opção --tlsCertificateKeyFilePassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, mongos 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 ou no Windows, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção --tlsCertificateKeyFilePassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte --tlsCertificateSelector) em vez de um arquivo PEM ou usar um arquivo PEM não criptografado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos 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:

Valor	Descrição
keyFile	Use um arquivo-chave para autenticação. Aceite apenas arquivos-chave.
sendKeyFile	Para fins de atualização contínua. Envie um arquivo-chave para autenticação, mas pode aceitar arquivos-chave e certificados x.509.
sendX509	Para fins de atualização contínua. Envie o certificado x.509 para autenticação, mas pode aceitar arquivos-chave e certificados x.509.
x509	Recomendado. Envie o certificado x.509 para autenticação e aceite apenas certificados x.509.

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

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

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterFile <filename>

Novidades na versão 4.2.

Observação

No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo PEM. Consulte --tlsClusterCertificateSelector.

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.

Se o --tlsClusterFile não especificar o arquivo .pem para autenticação de cluster interno ou a alternativa --tlsClusterCertificateSelector, o cluster usará o arquivo .pem especificado na opção --tlsCertificateKeyFile ou o certificado retornado pelo --tlsCertificateSelector.

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

mongod / mongos registra um aviso na conexão se o x for apresentado. O certificado 509 expira dentro 30 dias a partir da hora do sistema host mongod/mongos . Consulte x.509 Avisos de gatilho de certificados próximos da expiração para obter mais informações.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterPassword <value>

Novidades na versão 4.2.

Especifica a senha para descriptografar o x.509 arquivo de chave de certificado especificado com --tlsClusterFile. Use a opção --tlsClusterPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, mongos edita a senha de todos os resultados de geração de registros e relatórios.

• No Linux/BSD, se a chave privada no x.509 estiver criptografado e você não especificar a opção --tlsClusterPassword , o MongoDB solicitará uma senha. Consulte Senha do Certificado TLS/SSL.

• No macOS ou no Windows, se a chave privada no x.509 estiver criptografado, você deve especificar explicitamente a opção --tlsClusterPassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte --tlsClusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCAFile <filename>

Novidades na versão 4.2.

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.

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 --tlsCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --tlsCAFile.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterCAFile <filename>

Novidades na versão 4.2.

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.

Se --tlsClusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente 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.

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 --tlsClusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --tlsClusterCAFile.

Exige que --tlsCAFile esteja definido.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateSelector <parameter>=<value>

Novidade na versão 4.2: disponível no Windows e macOS como alternativa ao --tlsCertificateKeyFile.

As opções --tlsCertificateKeyFile e --tlsCertificateSelector 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.

--tlsCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

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

Observação

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

--tlsClusterCertificateSelector <parameter>=<value>

Novidade na versão 4.2: disponível no Windows e macOS como alternativa ao --tlsClusterFile.

--tlsClusterFile e --tlsClusterCertificateSelector são opções 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 usar na autenticação interna.

--tlsClusterCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

mongod / mongos registra um aviso na conexão se o x for apresentado. O certificado 509 expira dentro 30 dias a partir da hora do sistema host mongod/mongos . Consulte x.509 Avisos de gatilho de certificados próximos da expiração para obter mais informações.

--tlsCRLFile <filename>

Novidades na versão 4.2.

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 em MongoDB 4.2+ para usar o armazenamento de certificados SSL do sistema.

• Para verificar a revogação de certificados, o MongoDB enables o uso do OCSP (Online Certificate Status Protocol) por padrão como uma 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 o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowConnectionsWithoutCertificates

Novidades na versão 4.2.

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, mongod ou mongos criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.

• Para clientes que apresentam um certificado, mongos executa a validação do certificado usando a cadeia de certificados raiz especificada por --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 o mongos.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowInvalidCertificates

Novidades na versão 4.2.

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 ou tls.allowInvalidCertificates: true ao usar a autenticação x.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação.

Ao usar a configuração --tlsAllowInvalidCertificates , o MongoDB registra um aviso sobre o uso de um certificado inválido.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowInvalidHostnames

Novidades na versão 4.2.

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 mongos 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 o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsDisabledProtocols <protocol(s)>

Novidades na versão 4.2.

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 e TLS1_3.

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

• Para listar vários protocolos, especifique 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 TLS 1.1+ está disponível no sistema. Para habilitar o TLS desabilitado 1.0, especifique none para --tlsDisabledProtocols.

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

Dica

Veja também:

Não permitir protocolos

--tlsFIPSMode

Novidades na versão 4.2.

Direciona mongos para usar o modo FIPS da biblioteca TLS. Seu sistema deve ter uma biblioteca compatível com FIPS para usar 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 SSL (obsoleto)

--sslOnNormalPorts

Descontinuado desde a versão 2.6: Em vez disso, use --tlsMode requireTLS.

Ativa TLS/SSL para mongos.

Com o --sslOnNormalPorts, um mongos exige criptografia TLS/SSL para todas as conexões na porta MongoDB padrão ou a porta especificada por --port. Por padrão, --sslOnNormalPorts está desabilitado.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslMode <mode>

Descontinuado desde a versão 4.2: em vez disso, use--tlsMode.

Habilita TLS/SSL ou TLS/SSL misto usado para todas as conexões de rede. O argumento para a opção --sslMode pode ser um dos seguintes:

Valor	Descrição
disabled	O servidor não usa TLS/SSL.
allowSSL	As conexões entre servidores não usam TLS/SSL. Para conexões recebidas, o servidor aceita TLS/SSL e não TLS/não SSL.
preferSSL	As conexões entre servidores usam TLS/SSL. Para conexões recebidas, o servidor aceita TLS/SSL e não TLS/não SSL.
requireSSL	O servidor usa e aceita apenas conexões criptografadas TLS/SSL.

Se --tlsCAFile/net.tls.CAFile (ou seus aliases --sslCAFile/net.ssl.CAFile) não for especificado e você não estiver usando a autenticação x.509, você deve definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados de CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Para usar a autenticação x.509, --tlsCAFile ou net.tls.CAFile deve-se especificar a menos que você esteja usando --tlsCertificateSelector ou --net.tls.certificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslPEMKeyFile <filename>

Descontinuado desde a versão 4.2: em vez disso, use--tlsPEMKeyFile.

Observação

No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo PEM. Consulte --sslCertificateSelector.

Especifica o arquivo .pem que contém o certificado e a chave TLS/SSL.

• No Linux/BSD, você deve especificar --sslPEMKeyFile quando TLS/SSL estiver habilitado.

• No Windows ou macOS, você deve especificar --sslPEMKeyFile ou --sslCertificateSelector quando TLS/SSL estiver habilitado.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslPEMKeyPassword <value>

Descontinuado desde a versão 4.2: em vez disso, use--tlsPEMKeyPassword.

Especifica a senha para descriptografar o arquivo da chave de certificado (ou seja, --sslPEMKeyFile). Use a opção --sslPEMKeyPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, mongos 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 --sslPEMKeyPassword , o MongoDB solicitará uma senha. Consulte Senha do Certificado TLS/SSL.

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

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslClusterFile <filename>

Descontinuado desde a versão 4.2: em vez disso, use--tlsClusterFile.

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 --sslClusterCertificateSelector.

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.

Se o --sslClusterFile não especificar o arquivo .pem para autenticação de cluster interno ou a alternativa --sslClusterCertificateSelector, o cluster usará o arquivo .pem especificado na opção --sslPEMKeyFile ou o certificado retornado pelo --sslCertificateSelector.

Para usar a autenticação x.509, --tlsCAFile ou net.tls.CAFile deve-se especificar a menos que você esteja usando --tlsCertificateSelector ou --net.tls.certificateSelector.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslClusterPassword <value>

Descontinuado desde a versão 4.2: em vez disso, use--tlsClusterPassword.

Especifica a senha para descriptografar o x.509 arquivo de chave de certificado especificado com --sslClusterFile. Use a opção --sslClusterPassword somente se o arquivo de chave de certificado estiver criptografado. Em todos os casos, mongos edita a senha de todos os resultados de geração de registros e relatórios.

• No Linux/BSD, se a chave privada no x.509 estiver criptografado e você não especificar a opção --sslClusterPassword , o MongoDB solicitará uma senha. Consulte Senha do Certificado TLS/SSL.

• No macOS ou no Windows, se a chave privada no x.509 estiver criptografado, você deve especificar explicitamente a opção --sslClusterPassword . Como alternativa, você pode usar um certificado do armazenamento seguro do sistema (consulte --sslClusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslCAFile <filename>

Descontinuado desde a versão 4.2: em vez disso, use--tlsCAFile.

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.

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 --sslCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --sslCAFile.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslClusterCAFile <filename>

Descontinuado desde a versão 4.2: em vez disso, use--tlsClusterCAFile.

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.

Se --sslClusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente estabelecendo uma conexão, o cluster utilizará o arquivo .pem especificado na opção --sslCAFile .

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

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 --sslClusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --sslClusterCAFile.

Exige que --sslCAFile esteja definido.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslCertificateSelector <parameter>=<value>

Descontinuado desde a versão 4.2: em vez disso, use--tlsCertificateSelector.

Disponível no Windows e macOS como uma alternativa ao --tlsCertificateKeyFile.

--tlsCertificateKeyFile e --sslCertificateSelector são opções mutuamente exclusivas. Você só pode especificar uma.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional.

--sslCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

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

--sslClusterCertificateSelector <parameter>=<value>

Descontinuado desde a versão 4.2: em vez disso, use--tlsClusterCertificateSelector.

Disponível no Windows e macOS como uma alternativa ao --sslClusterFile.

--sslClusterFile e --sslClusterCertificateSelector são opções 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 usar na autenticação interna.

--sslClusterCertificateSelector aceita um argumento do formato <property>=<value> onde a propriedade pode ser uma das seguintes:

Propriedade	Tipo de valor	Descrição
subject	String ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

--sslCRLFile <filename>

Descontinuado desde a versão 4.2: em vez disso, use--tlsCRLFile.

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 em MongoDB 4.2+ para usar o armazenamento de certificados SSL do sistema.

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

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslAllowConnectionsWithoutCertificates

Descontinuado desde a versão 4.2: em vez disso, use--tlsAllowConnectionsWithoutCertificates.

Para clientes que não fornecem certificados, mongod ou mongos criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.

No entanto, para clientes que apresentam um certificado, mongos executa a validação do certificado usando a sequência de certificados raiz especificada por --sslCAFile e rejeita clientes com certificados inválidos.

Use a opção --sslAllowConnectionsWithoutCertificates se você tiver uma implantação mista que inclua clientes que não apresentam ou não podem apresentar certificados para o mongos.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslAllowInvalidCertificates

Descontinuado desde a versão 4.2: em vez disso, use--tlsAllowInvalidCertificates.

Ignora as verificações de validação de certificados TLS/SSL em outros servidores no cluster e permite o uso de certificados inválidos para conexões.

Observação

A partir do MongoDB 4,0, se você especificar qualquer uma das seguintes opções de autenticação x.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação:

• --sslAllowInvalidCertificates ou net.ssl.allowInvalidCertificates: true para MongoDB 4.0 e versões mais recentes

• --tlsAllowInvalidCertificates ou net.tls.allowInvalidCertificates: true para MongoDB 4.2 e versões mais recentes

Ao usar a configuração --sslAllowInvalidCertificates , o MongoDB registra um aviso sobre o uso de um certificado inválido.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslAllowInvalidHostnames

Descontinuado desde a versão 4.2: em vez disso, use--tlsAllowInvalidHostnames.

Desabilita a validação dos nomes de host em certificados TLS/SSL ao conectar-se a outros membros do conjunto de réplicas ou cluster fragmentado para autenticação entre processos. Isso permite que mongos 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/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

--sslDisabledProtocols <protocol(s)>

Descontinuado desde a versão 4.2: em vez disso, use--tlsDisabledProtocols.

Impede que um servidor MongoDB em execução com TLS/SSL aceite conexões recebidas que usam um ou mais protocolos específicos. Para especificar protocolos, use uma lista de protocolos separados por vírgulas.

--sslDisabledProtocols reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e TLS1_3.

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

• Para listar vários protocolos, especifique 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 TLS 1.1+ está disponível no sistema. Para habilitar o TLS desabilitado 1.0, especifique none para --sslDisabledProtocols.

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

Dica

Veja também:

Não permitir protocolos

--sslFIPSMode

Descontinuado desde a versão 4.2: em vez disso, use--tlsFIPSMode.

Direciona mongos para usar o modo FIPS da biblioteca TLS/SSL. Seu sistema deve ter uma biblioteca compatível com FIPS para utilizar a opção --sslFIPSMode .

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 auditoria

--auditCompressionMode

Novidades na versão 5.3.

Especifica o modo de compactação para criptografia de registros de auditorias. Você também deve ativar a criptografia do log de auditoria usando --auditEncryptionKeyUID ou --auditLocalKeyFile.

--auditCompressionMode pode ser definido para um destes valores:

Valor	Descrição
zstd	Use o algoritmo zstd para comprimir o registro de auditoria.
none (padrão)	Não comprima o registro de auditorias.

Observação

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

--auditDestination

Ativa a auditoria e especifica para onde mongos envia todos os eventos de auditoria.

--auditDestination pode ter um dos seguintes valores:

Valor	Descrição
syslog	Envie os eventos de auditoria para syslog no formato JSON. Não disponível no Windows. As mensagens de auditoria têm um nível de severidade syslog de info e um nível de facilidade de user. O limite de mensagens syslog pode resultar no truncamento de mensagens de auditoria. O sistema de auditoria não detecta o truncamento nem erros na sua ocorrência.
console	Envie os eventos de auditoria para stdout no formato JSON.
file	Envie os eventos de 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 utilizar --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 for file. A opção --auditFormat pode ter um dos seguintes valores:

Valor	Descrição
JSON	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 apenas --auditLocalKeyFile para testes porque a chave não está protegida. Para proteger a chave, use --auditEncryptionKeyUID e um servidor KMIP (protocolo de interoperabilidade de gerenciamento de chaves) externo.

Você não pode utilizar --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 de file. A opção --auditPath pode levar 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.

Opções de analisador

--slowms <integer>

Padrão: 100

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

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

Em configurações logLevel mais altas, todas as operações aparecem no registro de diagnóstico, independentemente da latência.

Para instâncias mongos, afeta somente o registro de diagnóstico e não o analisador, já que o analisador não está disponível em mongos.

--slowOpSampleRate <double>

Padrão: 1.0

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

Para instâncias mongos , --slowOpSampleRate afeta somente o registro de diagnóstico e não o analisador, já que o analisador não está disponível em mongos.

Opções de autenticação e autorização LDAP

--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>

Disponível apenas no MongoDB Enterprise.

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

Se 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 . O MongoDB suporta as --ldapServers seguintes referências LDAP, conforme definido em RFC . .4511 4110. Não utilize o para listar todos os servidores LDAP em sua --ldapServers infraestrutura.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Se não for definido, mongos 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 mongos verifica a disponibilidade do LDAP server(s) como parte de sua inicialização:

• Se o true, a instância do mongos executará a verificação de disponibilidade e somente continuará a iniciar se o servidor LDAP estiver disponível.

• Se false, a instância mongos 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 mongos 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.

• Usando 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, mongos não tentará vincular-se ao servidor LDAP.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Observação

Os sistemas do Windows MongoDB podem utilizar o --ldapBindWithOSDefaults ao invés do --ldapQueryUser e --ldapQueryPassword. Não é possível especificar --ldapQueryUser e --ldapBindWithOSDefaults ao mesmo tempo.

--ldapQueryPassword <string>

Disponível apenas no MongoDB Enterprise.

A senha usada para vincular a um servidor LDAP ao utilizar o --ldapQueryUser. Você deve usar --ldapQueryPassword com --ldapQueryUser.

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

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Observação

Os sistemas do Windows MongoDB podem utilizar o --ldapBindWithOSDefaults ao invés do --ldapQueryPassword e --ldapQueryPassword. Não é possível especificar --ldapQueryPassword e --ldapBindWithOSDefaults ao mesmo tempo.

--ldapBindWithOSDefaults <bool>

Padrão: false

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

Permite ao mongos autenticar ou vincular, utilizando suas credenciais de login do Windows ao conectar ao servidor LDAP.

Necessário apenas se:

• Utilizando autorização LDAP.

• Usando uma query LDAP para username transformation.

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

Use --ldapBindWithOSDefaults para substituir --ldapQueryUser e --ldapQueryPassword.

--ldapBindMethod <string>

Padrão: simples

Disponível apenas no MongoDB Enterprise.

O método mongos utiliza para autenticar em um servidor LDAP. Utilize com --ldapQueryUser e --ldapQueryPassword para conectar ao servidor LDAP.

--ldapBindMethod suporta os seguintes valores:

• simple - mongos utiliza autenticação simples.

• sasl - mongos utiliza protocolo SASL para autenticação

Se você especificar sasl, você poderá configurar os mecanismos SASL disponíveis utilizando --ldapBindSaslMechanisms. mongos tem como padrão usar DIGEST-MD5 mecanismo.

--ldapBindSaslMechanisms <string>

Padrão: DIGEST-MD5

Disponível apenas no MongoDB Enterprise.

Uma lista separada por vírgulas de mecanismos SASL mongos pode utilizar ao autenticar para o servidor LDAP. O mongos e o servidor LDAP devem concordar com pelo menos um mecanismo. O mongos 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 mongos 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, verifique o seguinte para a máquina host mongos :

Linux

• A KRB5_CLIENT_KTNAME variável de ambiente é 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 mongos usar ao se conectar ao servidor LDAP e executar query LDAP.

Windows

Se estiver conectando a um servidor Active Directory, a configuração do Windows Kerberos gerará automaticamente um Ticket-Granting-Ticket quando o usuário faz login no sistema. Defina --ldapBindWithOSDefaults como true para permitir mongos que use as credenciais geradas ao se conectar ao servidor do Active Directory e executar queries.

Configure --ldapBindMethod para sasl para utilizar 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 mongos cria uma conexão segura TLS/SSL para o servidor LDAP.

Para sistemas do Linux, você deve configurar as Opções de TLS apropriadas no /etc/openldap/ldap.conf arquivo . O gerenciador de pacotes do seu sistema operacional cria esse arquivo como parte da instalação do MongoDB Enterprise, por meio da dependência . Consulte libldap a documentação do TLS Options na documentação do OpenLDAP ldap.conf para obter 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 --ldapTransportSecurity para none para desabilitar o TLS/SSL entre mongos e o servidor LDAP.

Aviso

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

--ldapTimeoutMS <int>

Padrão: 10000

Disponível apenas no MongoDB Enterprise.

A quantidade de tempo em milésimos de segundo mongos 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 mongos executando utilizando setParameter.

--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 a mongos para autenticação para um Nome Distinto (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 string JSON-string com aspas que represente uma array ordenada de documentos. Cada documento contém uma expressão regular match e um modelo substitution ou ldapQuery usado para transformar o nome de usuário recebido.

Cada documento na array tem o seguinte formato:

{
  match: "<regex>"
  substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}

Campo	Descrição	Exemplo
match	Uma expressão regular (regex) formatada pelo ECMAScript para corresponder a um nome de usuário fornecido. Cada seção de parênteses representa um grupo de captura regex utilizado pelo substitution ou ldapQuery.	"(.+)ENGINEERING" "(.+)DBA"
substitution	Um modelo de formatação de nome distinto (DN) LDAP que converte o nome de autenticação correspondente pelo match regex em um DN LDAP. Cada valor numérico entre colchetes é substituído pelo grupo de captura de regex correspondente extraído do nome de usuário de autenticação por meio da match regex . O resultado da substituição deve ser um RFC4514 string que escapou.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Um modelo de formatação de consulta LDAP que insere o nome de autenticação correspondente ao match regex em um URI de consulta LDAP codificado respeitando RFC4515 e RFC4516. Cada valor numérico entre colchetes é substituído pelo grupo de captura de regex correspondente extraído do nome de usuário de autenticação por meio da match expressão . mongos O executa a query no servidor LDAP para recuperar o DN LDAP do usuário autenticado. mongos exige exatamente um resultado retornado para que a transformação seja bem-sucedida, ou mongos ignora essa transformação.	"ou=engineering,dc=example, dc=com??one?(user={0})"

Observação

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

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

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

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

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

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

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 caracteres alice. 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 caracteres bob. A saída resultante é a query LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongos executa esta query no servidor LDAP, retornando o resultado "cn=bob,ou=dba,dc=example,dc=com".

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

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

Opções adicionais

--ipv6

Habilita o suporte a IPv6. mongos desabilita o suporte a IPv6 por padrão.

A configuração --ipv6 não direciona mongos para escutar em nenhum endereço ou interface IPv56 local. Para configurar mongos para escutar em uma interface IPv6 , você deve:

• Configurar --bind_ip com um ou mais endereços IPv6 ou nomes de host que resolvam para endereços IPv6 , ou

• Defina --bind_ip_all como true.