Legacy mongo Shell

Opções principais

--shell

Habilita a interface shell. Se você invocar o comando mongo e especificar um arquivo JavaScript como um argumento, ou utilizar --eval para especificar JavaScript na linha de comando, a opção --shell fornecerá ao usuário um prompt de shell após o arquivo finalizar a execução.

--nodb

Impede que o shell se conecte a quaisquer instâncias de reconhecimento de data center. Posteriormente, para se conectar a um reconhecimento de data center dentro do shell, consulte Abrindo novas conexões.

--norc

Impede que o shell forneça e avalie ~/.mongorc.js na inicialização.

--quiet

Calma a saída do shell durante o processo de conexão.

--port <port>

Especifica a porta em que a instância mongod ou mongos está escutando. Se --port não for especificado, mongo tentará se conectar à porta 27017.

--host <hostname>

Especifica o nome da máquina host onde o mongod ou mongos está executando. Se isso não for especificado, mongo tentará se conectar a um processo MongoDB em execução no localhost.

Para se conectar a um conjunto de réplicas,

Especifique o replica set name e uma lista de sementes de membros do conjunto. Use o seguinte formulário:

<replSetName>/<hostname1><:port>,<hostname2><:port>,<...>

Para conexões TLS/SSL (--ssl),

mongosh verifica se o nome de host (especificado na ou na ) corresponde { --host } ao SAN (ou, se SAN não estiver presente, ao CN) no certificado apresentado pelo mongod ou mongos. Se SAN estiver presente, mongosh não corresponde ao CN. Se o nome do host não corresponder a SAN (ou CN), mongosh não conseguirá se conectar.Começando no MongoDB 4.2, ao executar a comparação de SAN, o MongoDB suporta a comparação de nomes DNS ou endereços IP. Nas versões anteriores, o MongoDB suporta apenas comparações de nomes DNS.

Para conexões da lista de sementes de DNS,

Especifique o protocolo de conexão como mongodb+srv, seguido pelo registro de nome de host DNS SRV e quaisquer opções. As opções authSource e replicaSet , se incluídas na string de conexão, substituirão quaisquer opções correspondentes configuradas pelo DNS definidas no registro TXT. O uso da string de conexão mongodb+srv: ativa implicitamente o TLS/SSL (normalmente definido com ssl=true) para a conexão do cliente. A opção TLS/SSL pode ser desativada configurando o ssl=false na query.

Exemplo:

mongodb+srv://server.example.com/?connectionTimeout=3000ms

Novidade na versão 3.6.

--eval <javascript>

Avalia uma expressão JavaScript especificada como um argumento. mongo não carrega seu próprio ambiente ao avaliar código. Como resultado, muitas opções do ambiente de shell não estão disponíveis.

--username <username>, -u <username>

Especifica um nome de usuário com o qual autenticar em um banco de dados MongoDB que usa autenticação. Utilize em conjunto com as opções --password e --authenticationDatabase .

Se estiver se conectando a um cluster MongoDB Atlas usando o MONGODB-AWS authentication mechanism, especifique seu ID de chave de acesso da AWS nesse campo ou na connection string. Alternativamente, este valor também pode ser fornecido como a variável de ambiente AWS_ACCESS_KEY_ID. Consulte Conectar-se a um Cluster do MongoDB Atlas usando Credenciais AWS IAM.

--password <password>, -p <password>

Especifica uma senha com a qual autenticar em um banco de dados MongoDB que usa autenticação. Utilize em conjunto com as opções --username e --authenticationDatabase . Para forçar mongo a solicitar uma senha, digite a opção --password como a última opção e deixe de fora o argumento.

Se estiver se conectando a um cluster MongoDB Atlas usando o MONGODB-AWS authentication mechanism, especifique sua chave de acesso secreto AWS neste campo ou na cadeia de conexão. Alternativamente, este valor também pode ser fornecido como a variável de ambiente AWS_SECRET_ACCESS_KEY. Consulte Conectar-se a um Cluster do MongoDB Atlas usando Credenciais AWS IAM.

--apiVersion <version number>

Novidades na versão 5,0.

Especifica a apiVersion. "1" é atualmente o único valor suportado.

--apiStrict

Novidades na versão 5,0.

Especifica que o servidor responderá com APIStrictError se sua aplicação usar um comando ou comportamento fora da stable API.

Se você especificar --apiStrict, você também deverá especificar --apiVersion.

--apiDeprecationErrors

Novidades na versão 5,0.

Especifica que o servidor responderá com APIDeprecationError se seu aplicativo usar um comando ou comportamento que é preterido na apiVersion especificada.

Se você especificar --apiDeprecationErrors, você também deverá especificar --apiVersion.

--awsIamSessionToken <aws session token>

Se estiver se conectando a um cluster MongoDB Atlas usando o MONGODB-AWS authentication mechanism e usando tokens de sessão além do ID da chave de acesso da AWS e da chave de acesso secreta, especifique o token de sessão da AWS nesse campo ou na cadeia de conexão. Alternativamente, este valor também pode ser fornecido como a variável de ambiente AWS_SESSION_TOKEN. Consulte Conectar-se a um Cluster do MongoDB Atlas usando Credenciais AWS IAM.

Válido somente ao utilizar o MONGODB-AWS authentication mechanism.

--help, -h

Retorna informações sobre as opções e uso do mongo.

--version

Retorna o número de versão do mongo .

--verbose

Aumenta a verbosidade da saída do shell durante o processo de conexão.

--networkMessageCompressors <string>

Novidade na versão 3.4.

Habilita a compactação de rede para comunicação entre este shell mongo e:

• uma instância mongod

• uma instância mongos .

Você pode especificar os seguintes compressores:

• snappy

• zlib (Disponível a partir do MongoDB 3.6)

• zstd (Disponível a partir do MongoDB 4.2)

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.

--ipv6

Ativa o suporte a IPv6 . mongo desabilita IPv6 por padrão.

Para se conectar a um cluster MongoDB via IPv6, você deve especificar --ipv6 e --host <mongod/mongos IPv6 address> ao iniciar o shell mongo .

mongod e mongos desabilitam o suporte a IPv6 por padrão. Especificar --ipv6 ao conectar-se a um mongod/mongos não habilita o suporte a IPv6 no mongod/mongos. Para obter a documentação sobre como ativar o suporte a IPv6 no mongod/mongos, consulte net.ipv6.

<db name>

Especifica o nome do reconhecimento de data center ao qual se conectar. Por exemplo:

mongo admin

O comando acima conectará o shell mongo ao banco de dados admin da deployment do MongoDB em execução na máquina local. Você pode especificar uma instância do banco de dados remoto, com o nome do host ou endereço IP resolvível. Separe o nome do banco de dados do nome do host usando um caractere / . Veja os seguintes exemplos:

mongo mongodb1.example.net/test
mongo mongodb1/admin
mongo 10.8.8.10/test

Essa sintaxe é a única maneira de se conectar a um reconhecimento de data center específico.

Para especificar hosts alternativos e um banco de dados, você deve usar esta sintaxe e não pode usar --host ou --port.

--enableJavaScriptJIT

Novidades na versão 4.0.

Ative o compilador JIT do mecanismo JavaScript.

--disableJavaScriptJIT

Alterado na versão 4.0: o compilador JIT do mecanismo JavaScript agora está desabilitado por padrão.

Desabilita o compilador JIT do mecanismo JavaScript.

--disableJavaScriptProtection

Permite que os campos do tipo javascript e javascriptWithScope (*Obsoleto*) sejam automaticamente ordenados para funções JavaScript no shell mongo .

Com o sinalizador --disableJavaScriptProtection definido, é possível executar imediatamente funções JavaScript contidas em documentos. O exemplo a seguir demonstra esse comportamento dentro do shell:

> db.test.insertOne( { _id: 1, jsFunc: function(){ print( "hello" ) } } )
WriteResult({ "nInserted" : 1 })
> var doc = db.test.findOne( { _id: 1 } )
> doc
{ "_id" : 1, "jsFunc" : function (){ print ( "hello" ) } }
> typeof doc.jsFunc
function
> doc.jsFunc()
hello

O comportamento padrão (quando mongo é iniciado sem o sinalizador --disableJavaScriptProtection ) é converter as funções JavaScript incorporadas para o tipo de shell não executável Code do MongoDB . O exemplo a seguir demonstra o comportamento padrão dentro do shell:

> db.test.insertOne( { _id: 1, jsFunc: function(){ print("hello") } } )
WriteResult({ "nInserted" : 1 })
> var doc = db.test.findOne( { _id: 1 } )
> doc
{ "_id" : 1, "jsFunc" : { "code" : "function (){print(\"hello\")}" } }
> typeof doc.jsFunc
object
> doc.jsFunc instanceof Code
true
> doc.jsFunc()
uncaught exception: TypeError: doc.jsFunc is not a function :
@(shell):1:1

<file.js>

Especifica um arquivo JavaScript para ser executado e depois sair. Geralmente, esta deve ser a última opção especificada.

Observação

Opcional

Para especificar um arquivo JavaScript para executar e permitir que mongo solicite uma senha usando --password, passe o nome do arquivo como o primeiro parâmetro com --username e --password como as últimas opções, como no exemplo a seguir:

mongo file.js --username username --password

Use a opção --shell para retornar a um shell depois que o arquivo finalizar a execução.

Opções de autenticação

--authenticationDatabase <dbname>

Especifica o banco de dados de autenticação onde o --username especificado foi criado. Consulte Banco de Dados de Autenticação.

Se você não especificar um valor para --authenticationDatabase, o mongo utilizará o banco de dados especificado na connection string.

Se estiver usando o GSSAPI (Kerberos), PLAIN (LDAP SASL) ou MONGODB-AWS authentication mechanisms, você deverá definir --authenticationDatabase como $external.

--authenticationMechanism <name>

Padrão: SCRAM-SHA-1

Especifica o mecanismo de autenticação que a instância do mongo utiliza para autenticar no mongod ou mongos.

Alterado na versão 4.4: Com MongoDB 4.4, o shell mongo adiciona suporte ao novo mecanismo de autenticação MONGODB-AWS ao se conectar a um cluster MongoDB Atlas .

Valor	Descrição
SCRAM-SHA-1	RFC 5802 Mecanismo de autenticação de resposta de desafio salgado padrão usando a1 função de hash SHA- .
SCRAM-SHA-256	RFC 7677 Mecanismo de autenticação de resposta de desafio salgado padrão usando a256 função de hash SHA- . Exige featureCompatibilityVersion definido para 4.0. Novidades na versão 4.0.
MONGODB-X509	Autenticação de certificado TLS/SSL do MongoDB.
MONGODB-AWS	Autenticação externa usando credenciais AWS IAM para uso na conexão com um cluster do MongoDB Atlas . Consulte Conectar-se a um Cluster do MongoDB Atlas usando Credenciais AWS IAM.
GSSAPI (Kerberos)	Autenticação externa usando Kerberos. Esse mecanismo está disponível somente no MongoDB Enterprise.
PLAIN (LDAP SASL)	Autenticação externa usando LDAP. Você também pode utilizar o PLAIN para autenticar usuários do banco de dados. PLAIN transmite senhas em texto simples. Esse mecanismo está disponível somente no MongoDB Enterprise.

--gssapiHostName

Especifique o nome de host de um serviço usando GSSAPI/Kerberos. Só é necessário se o nome do host de uma máquina não corresponder ao nome do host resolvido pelo DNS.

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

--gssapiServiceName

Especifique o nome do serviço usando GSSAPI/Kerberos. Obrigatório apenas se o serviço não usar o nome padrão mongodb.

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

Opções de TLS

--tls

Novidades na versão 4.2.

Habilita a conexão com um mongod ou mongos que tenha o suporte a TLS/SSL habilitado.

A partir da versão 3.2.6, se --tlsCAFile ou net.tls.CAFile (ou seus pseudônimos --sslCAFile ou ssl.CAFile) não for especificado, o armazenamento de certificados CA de todo o sistema será usado ao conectar-se a um servidor habilitado por TLS/SSL. Em versões anteriores do MongoDB, mongosh era encerrado com um erro informando que não foi possível validar o certificado.

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.

--tlsCertificateKeyFile <filename>

Novidades na versão 4.2.

Especifica o arquivo .pem que contém o certificado TLS/SSL e a chave para o shell mongo . Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Esta opção é exigida ao utilizar a opção --tls para conectar a uma instância do mongod ou mongos que exige certificados de cliente. Ou seja, o shell mongo apresenta este certificado ao servidor.

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 trigger de certificados próximos da expiração para obter mais informações.

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.

--tlsCertificateKeyFilePassword <value>

Novidades na versão 4.2.

Especifica a senha para descriptografar o arquivo da chave de certificado (ou seja, --tlsCertificateKeyFile).

Utilize a opção --tlsCertificateKeyFilePassword somente se o arquivo da chave de certificado for codificado. Em todos os casos, o mongo eliminará a senha de todos os registros e relatórios.

Se a chave privada no arquivo PEM for codificada e você não especificar a opção --tlsCertificateKeyFilePassword , o mongo solicitará uma senha. Consulte Senha do Certificado TLS/SSL.

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.

--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. Este arquivo é utilizado para validar o certificado apresentado pela instância mongod/mongos .

Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

A partir da versão 3.2.6, se --tlsCAFile ou net.tls.CAFile (ou seus pseudônimos --sslCAFile ou ssl.CAFile) não for especificado, o armazenamento de certificados CA de todo o sistema será usado ao conectar-se a um servidor habilitado por TLS/SSL. Em versões anteriores do MongoDB, mongosh era encerrado com um erro informando que não foi possível validar o certificado.

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.

--tlsCRLFile <filename>

Novidade na versão 4.2: No MongoDB 4.0 e anteriores, consulte --sslCRLFile.

Especifica o arquivo .pem que contém a lista de certificados revogados. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

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.

Observação

A partir da versão 4.4, para verificar a revogação de certificados, o MongoDB enables a utilização 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.

--tlsAllowInvalidHostnames

Novidades na versão 4.2.

Desabilita a validação dos nomes de host no certificado apresentado pela instância mongod/mongos . Permite que mongo se conecte a instâncias do MongoDB mesmo que o nome do host nos certificados do servidor não corresponda ao host do servidor.

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.

--tlsAllowInvalidCertificates

Novidades na versão 4.2.

Ignora as verificações de validação dos certificados apresentados pela instância mongod/mongos e permite conexões com servidores que apresentam certificados inválidos.

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

Aviso

Embora disponível, evite utilizar a opção --sslAllowInvalidCertificates se possível. Se o uso do --sslAllowInvalidCertificates for necessário, use a opção somente em sistemas em que a intrusão não seja possível.

Se o mongosh (e outras ferramentas MongoDB) executar com a opção --sslAllowInvalidCertificates , o mongosh (e outras ferramentas MongoDB) não tentará validar os certificados do servidor. Isso cria uma vulnerabilidade para certificados mongod e mongos expirados, bem como para processos externos que se fazem passar por instâncias mongod ou mongos válidas. Se você só precisar desabilitar a validação do nome de host nos certificados TLS/SSL, consulte --sslAllowInvalidHostnames.

Ao usar a configuração allowInvalidCertificates , o MongoDB registra como aviso o uso do 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.

--tlsFIPSMode

Novidades na versão 4.2.

Direciona mongo para usar o modo FIPS da biblioteca TLS/SSL. 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.

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

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 trigger de certificados próximos da expiração para obter mais informações.

--tlsDisabledProtocols <string>

Novidades na versão 4.2.

Desabilita os protocolos TLS especificados. A opção reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e iniciando na versão 4.0.4 (e 3.6.9 e 3.4.24), TLS1_3.

• No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você também 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.

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

A partir da versão 4.0, 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 a --tlsDisabledProtocols.

Opções SSL (obsoleto)

--ssl

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

Habilita a conexão com um mongod ou mongos que tenha o suporte a TLS/SSL habilitado.

A partir da versão 3.2.6, se --tlsCAFile ou net.tls.CAFile (ou seus pseudônimos --sslCAFile ou ssl.CAFile) não for especificado, o armazenamento de certificados CA de todo o sistema será usado ao conectar-se a um servidor habilitado por TLS/SSL. Em versões anteriores do MongoDB, mongosh era encerrado com um erro informando que não foi possível validar o certificado.

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

Especifica o arquivo .pem que contém o certificado e a chave TLS/SSL. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Esta opção é necessária ao utilizar a opção --ssl para conectar a um mongod ou mongos que tenha o CAFile habilitado sem allowConnectionsWithoutCertificates.

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

Especifica a senha para descriptografar o arquivo da chave de certificado (ou seja, --sslPEMKeyFile). Utilize a opção --sslPEMKeyPassword somente se o arquivo da chave de certificado for codificado. Em todos os casos, o mongo eliminará a senha de todos os registros e relatórios.

Se a chave privada no arquivo PEM for codificada e você não especificar a opção --sslPEMKeyPassword , o mongo solicitará uma senha. Consulte Senha do Certificado TLS/SSL.

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.

A partir da versão 3.2.6, se --tlsCAFile ou net.tls.CAFile (ou seus pseudônimos --sslCAFile ou ssl.CAFile) não for especificado, o armazenamento de certificados CA de todo o sistema será usado ao conectar-se a um servidor habilitado por TLS/SSL. Em versões anteriores do MongoDB, mongosh era encerrado com um erro informando que não foi possível validar o certificado.

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.

--sslCertificateSelector <parameter>=<value>

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

Novo na versão 4.0: Disponível no Windows e macOS como 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.

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

A partir da versão 4.4, para verificar a revogação de certificados, o MongoDB enables a utilização 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.

--sslFIPSMode

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

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

--sslAllowInvalidCertificates

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

Ignora as verificações de validação de certificados de servidor e permite o uso de certificados inválidos para conexão.

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

Aviso

Embora disponível, evite utilizar a opção --sslAllowInvalidCertificates se possível. Se o uso do --sslAllowInvalidCertificates for necessário, use a opção somente em sistemas em que a intrusão não seja possível.

Se o mongosh (e outras ferramentas MongoDB) executar com a opção --sslAllowInvalidCertificates , o mongosh (e outras ferramentas MongoDB) não tentará validar os certificados do servidor. Isso cria uma vulnerabilidade para certificados mongod e mongos expirados, bem como para processos externos que se fazem passar por instâncias mongod ou mongos válidas. Se você só precisar desabilitar a validação do nome de host nos certificados TLS/SSL, consulte --sslAllowInvalidHostnames.

Ao usar a configuração allowInvalidCertificates , o MongoDB registra como aviso o uso do 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. Permite que o mongo se conecte às instâncias do MongoDB mesmo que o nome do host em seus certificados não corresponda ao nome de host especificado.

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 <string>

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

Desabilita os protocolos TLS especificados. A opção reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e iniciando na versão 4.0.4 (e 3.6.9), TLS1_3.

• No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você também 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.

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

A partir da versão 4.0, 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 a --sslDisabledProtocols.

Novidades na versão 3.6.5.

Sessões

--retryWrites

Novidade na versão 3.6.

Habilita gravações repetitivas como padrão para sessões no shell mongo .

Para obter mais informações sobre sessões, consulte Sessões de clientes e garantias de consistência causal.

Opções de criptografia no nível de campo do lado do cliente

--awsAccessKeyId <string>

Uma chave de acesso AWS associado a um usuário IAM List Read com permissões do e para o AWS Key Management Service (KMS). O shell mongo --awsAccessKeyId usa o especificado para acessar o KMS.

--awsAccessKeyId é necessário para habilitar a criptografia em nível de campo do lado do cliente para a sessão do shell mongo . --awsAccessKeyId requer todas as seguintes opções de linha de comando:

• --awsSecretAccessKey

• --keyVaultNamespace

Se o --awsAccessKeyId for omitido, utilize o construtor Mongo() dentro da sessão de shell para habilitar a criptografia de nível de campo do lado do cliente.

Para mitigar o risco de vazamento de chaves de acesso em logs, considere especificar uma variável ambiental para --awsAccessKeyId.

--awsSecretAccessKey <string>

Uma chave secreta AWS associado ao --awsAccessKeyId especificado.

--awsSecretAccessKey é necessário para habilitar a criptografia em nível de campo do lado do cliente para a sessão do shell mongo . --awsSecretAccessKey requer todas as seguintes opções de linha de comando:

• --awsAccessKeyId

• --keyVaultNamespace

Se o --awsSecretAccessKey e suas opções de suporte forem omitidas, utilize o Mongo() dentro da sessão de shell para habilitar a criptografia de nível de campo do lado do cliente.

Para mitigar o risco de vazamento de chaves de acesso em logs, considere especificar uma variável ambiental para --awsSecretAccessKey.

--awsSessionToken <string>

Um token de sessão da AWS associado ao --awsAccessKeyId especificado.

--awsSessionToken é necessário para habilitar a criptografia em nível de campo do lado do cliente para a sessão do shell mongo . --awsSessionToken requer todas as seguintes opções de linha de comando:

• --awsAccessKeyId

• --awsSecretAccessKey

• --keyVaultNamespace

Se o --awsSessionToken e suas opções de suporte forem omitidas, utilize o Mongo() dentro da sessão de shell para habilitar a criptografia de nível de campo do lado do cliente.

Para mitigar o risco de vazamento de chaves de acesso em logs, considere especificar uma variável ambiental para --awsSessionToken.

--keyVaultNamespace <string>

O namespace completo (<database>.<collection>) da coleção usado como um cofre de chaves para criptografia de nível de campo do lado do cliente. --keyVaultNamespace é necessário para habilitar a criptografia em nível de campo no lado do cliente. para a sessão de shell mongo . mongo cria o namespace especificado se não existir.

--keyVaultNamespace requer todas as seguintes opções de linha de comando:

• --awsAccessKeyId

• --awsSecretAccessKey

Se o --keyVaultNamespace e suas opções de suporte forem omitidas, utilize o construtor do Mongo() dentro da sessão de shell para habilitar a criptografia de nível de campo do lado do cliente.

Conecte-se a uma instância mongod com controle de acesso

Para se conectar a um reconhecimento de data center em um host remoto usando autenticação e uma porta não padrão, use o seguinte formulário:

mongo --username <user> --password --host <host> --port 28015

Como alternativa, considere o seguinte formulário curto:

mongo -u <user> -p  --host <host> --port 28015

Substitua <user> e <host> pelos valores apropriados para sua situação e substitua ou omita o --port conforme necessário.

Se você não especificar a senha para a opção de linha de comando --password ou -p , o shell mongo solicitará a senha.

Conectar-se a um conjunto de réplicas usando o formato de conexão DNS lista de sementes

Para se conectar a um conjunto de réplicas descrito usando o formato de conexão SRV, use a opção --host para especificar a connection string para o shell mongo . No exemplo a seguir, a configuração de DNS é semelhante a:

Record                            TTL   Class    Priority Weight Port  Target
_mongodb._tcp.server.example.com. 86400 IN SRV   0        5      27317 mongodb1.example.com.
_mongodb._tcp.server.example.com. 86400 IN SRV   0        5      27017 mongodb2.example.com.

O registro TXT para a entrada DNS inclui as opções replicaSet e authSource :

Record              TTL   Class    Text
server.example.com. 86400 IN TXT   "replicaSet=rs0&authSource=admin"

O seguinte comando conecta então o shell mongo ao conjunto de réplicas:

mongo --host "mongodb+srv://server.example.com/?username=allison"

O shell mongo solicitará automaticamente que você forneça a senha do usuário especificada na opção username .

Conecte-se a um cluster MongoDB Atlas usando as credenciais AWS IAM

Para conectar-se a um cluster do MongoDB Atlas que foi configurado para suportar autenticação via Credenciais AWS IAM, forneça uma connection string para o shell semelhante a mongo esta:

mongo 'mongodb+srv://<aws access key id>:<aws secret access key>@cluster0.example.com/testdb?authSource=$external&authMechanism=MONGODB-AWS'

Conectar-se ao Amazon Web Services IAM usando credenciais do Atlas dessa maneira usa o MONGODB-AWS authentication mechanism e o $external authSource, como mostrado neste exemplo.

Se estiver usando um token de sessão da AWS também, forneça o AWS_SESSION_TOKEN authMechanismProperties valor em sua connection string, como segue:

mongo 'mongodb+srv://<aws access key id>:<aws secret access key>@cluster0.example.com/testdb?authSource=$external&authMechanism=MONGODB-AWS&authMechanismProperties=AWS_SESSION_TOKEN:<aws session token>'

: / ? # [ ] @

Como alternativa, o ID da chave de acesso da AWS, a chave de acesso secreta e, opcionalmente, o token de sessão podem ser fornecidos fora da cadeia de conexão usando as opções --username, --password e --awsIamSessionToken , assim:

mongo 'mongodb+srv://cluster0.example.com/testdb?authSource=$external&authMechanism=MONGODB-AWS' --username <aws access key id> --password <aws secret access key> --awsIamSessionToken <aws session token>

Quando fornecidos como parâmetros da linha de comando, estas três opções não exigem codificação percentual.

Você também pode definir essas credenciais em sua plataforma usando variáveis de ambiente padrão do AWS IAM . O shell verifica as seguintes variáveis de ambiente quando você usa mongo o MONGODB-AWS authentication mechanism:

• AWS_ACCESS_KEY_ID

• AWS_SECRET_ACCESS_KEY

• AWS_SESSION_TOKEN

Se definidas, essas credenciais não precisam ser especificadas na connection string ou por meio das opções explícitas para o shell mongo (ou seja, --username e --password).

O exemplo a seguir define essas variáveis de ambiente no shell bash :

export AWS_ACCESS_KEY_ID='<aws access key id>'
export AWS_SECRET_ACCESS_KEY='<aws secret access key>'
export AWS_SESSION_TOKEN='<aws session token>'

A sintaxe para definir variáveis de ambiente em outros shells será diferente. Consulte a documentação da sua plataforma para obter mais informações.

Você pode verificar se essas variáveis de ambiente foram definidas com o seguinte comando:

env | grep AWS

Depois de definido, o exemplo a seguir se conecta a um MongoDB Atlas cluster usando estas variáveis de ambiente:

mongo 'mongodb+srv://cluster0.example.com/testdb?authSource=$external&authMechanism=MONGODB-AWS'

Executar JavaScript no shell mongo

Para executar um arquivo JavaScript sem avaliar o arquivo ~/.mongorc.js antes de iniciar uma sessão de shell, use o seguinte formulário:

mongo --shell --norc alternate-environment.js

Para executar um arquivo JavaScript com autenticação, com senha solicitada em vez de fornecida na linha de comando, use o seguinte formulário:

mongo script-file.js -u <user> -p

Use --eval para executar código JavaScript

Você pode usar a opção --eval para executar JavaScript diretamente da linha de comando.

Por exemplo, a seguinte operação avalia uma string JavaScript que faz query de uma collection e imprime os resultados como JSON.

No Linux e macOS, você precisará usar aspas simples (por exemplo ') para delimitar o JavaScript, usando o seguinte formulário:

mongo --eval 'db.collection.find().forEach(printjson)'

No Windows, você precisará usar aspas duplas (por exemplo, ") para delimitar o JavaScript, usando o seguinte formulário:

mongo --eval "db.collection.find().forEach(printjson)"