Comandos Essenciais de Administração do MongoDB para Iniciantes

A administração do MongoDB começa no mongosh, mas o objetivo não é memorizar todos os comandos. O objetivo é saber como olhar ao redor com segurança, confirmar onde você está, fazer pequenas alterações deliberadamente e evitar comandos destrutivos no banco de dados errado.

Se você é novo no MongoDB, pratique esses comandos primeiro em uma instância local ou em um banco de dados de desenvolvimento descartável. Alguns comandos neste guia, como dropDatabase() e drop(), removem dados permanentemente. O MongoDB fará o que você pedir; ele não saberá que você pretendia executar o comando em outro lugar.

Conecte-se com mongosh

Para uma instância local do MongoDB na porta padrão, conecte-se com:

mongosh

Para um servidor remoto, use uma string de conexão fornecida pelo seu administrador ou provedor de hospedagem:

mongosh "mongodb://[email protected]:27017/admin"

Para TLS, conjuntos de réplicas ou MongoDB Atlas, a URI incluirá mais opções. Evite colar senhas no histórico do shell quando possível. Use prompts, manipulação de segredos específica do ambiente ou ferramentas de credenciais da sua plataforma.

Uma vez conectado, verifique onde você está:

db

Isso imprime o contexto atual do banco de dados. Muitos erros começam assumindo que o shell está apontado para um banco de dados quando está apontado para outro.

Listar e alternar bancos de dados

Mostre bancos de dados visíveis:

show dbs

Você pode não ver todos os bancos de dados se seu usuário não tiver permissões. Isso é normal em ambientes seguros.

Alterne o contexto do banco de dados com use:

use myAppDB

O MongoDB não cria o banco de dados imediatamente quando você executa use. Ele o cria quando os dados são gravados pela primeira vez, como quando você insere um documento ou cria explicitamente uma coleção.

Verifique o banco de dados atual novamente:

db

Para scripts, prefira identificadores de banco de dados explícitos para que o código dependa menos do contexto do shell:

const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()

Coleções: listar, criar, inspecionar, remover

Liste coleções no banco de dados atual:

show collections

Ou use JavaScript:

db.getCollectionNames()

Crie uma coleção explicitamente quando precisar de opções como validação, comportamento limitado ou escolhas de índice/cluster suportadas pela sua versão do MongoDB:

db.createCollection("logs")

A maioria das coleções de aplicativos é criada automaticamente na primeira inserção, mas a criação explícita é mais clara para configuração administrativa.

Inspecione estatísticas da coleção:

db.orders.stats()

Veja índices:

db.orders.getIndexes()

Eliminar uma coleção é destrutivo:

db.logs.drop()

Antes de executá-lo em qualquer ambiente compartilhado, confirme o banco de dados e a coleção:

db
db.getCollectionNames()
db.logs.countDocuments({})

Para coleções muito grandes, countDocuments({}) pode ser caro. Nesse caso, use metadados, amostragem ou painéis operacionais em vez de executar contagens amplas durante picos de tráfego.

Inserir um documento de teste e consultá-lo

Mesmo administradores precisam de alguns fundamentos de CRUD para verificação. Insira um pequeno documento:

db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })

Leia-o de volta:

db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)

Remova apenas o documento de teste:

db.healthcheck.deleteMany({ source: "admin-test" })

Use filtros específicos. Evite exclusões amplas enquanto aprende. Um comando como deleteMany({}) remove todos os documentos da coleção.

Noções básicas de administração de usuários

Comandos de usuário são executados no banco de dados onde o usuário está definido. Usuários administrativos são frequentemente criados em admin. Usuários de aplicativos podem ser criados no banco de dados do aplicativo, dependendo do seu modelo de segurança.

Alterne para admin:

use admin

Crie um usuário administrativo com uma senha solicitada:

db.createUser({
  user: "appAdmin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

Para um aplicativo normal, use permissões mais restritas. Por exemplo, um aplicativo que apenas lê e escreve em myAppDB não deve receber funções amplas de administrador:

use myAppDB

db.createUser({
  user: "myAppUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myAppDB" }
  ]
})

Liste usuários no banco de dados atual:

show users

Atualize funções com cuidado:

db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])

Remova funções com a mesma deliberação:

db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])

O hábito mais seguro é o privilégio mínimo: dê ao usuário apenas o banco de dados e a função necessários para o trabalho.

Status do servidor e operações atuais

serverStatus retorna um documento grande com contadores e informações de tempo de execução:

db.serverStatus()

Iniciantes geralmente não precisam do documento inteiro. Extraia as seções que lhe interessam:

db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters

Operações atuais podem ajudar quando algo está travado ou lento:

db.currentOp()

Em um servidor ocupado, filtre:

db.currentOp({ active: true, secs_running: { $gte: 5 } })

Não mate operações casualmente. Se precisar encerrar uma, inspecione-a primeiro e entenda se é uma consulta de usuário, construção de índice, backup, migração ou trabalho de replicação interno.

Verificações de conjunto de réplicas

Se sua implantação for um conjunto de réplicas, esses comandos são comuns:

rs.status()
rs.conf()

rs.status() mostra membros, saúde, estado, informações de optime e qual nó é primário. Execute-o quando os aplicativos relatarem falhas de gravação, quando um nó for reiniciado ou quando houver suspeita de atraso na replicação.

Para uma verificação rápida de preferência de leitura, pergunte quem o nó atual pensa que é:

db.hello()

Exemplos mais antigos podem usar isMaster(). Versões mais recentes do MongoDB suportam hello; você ainda pode ver o comando antigo em scripts existentes.

Comandos perigosos merecem rituais

Para trabalho destrutivo, vá devagar. Um ritual simples evita interrupções reais:

db
show collections
// confirme o hostname ou string de conexão no prompt do terminal ou anotações
// confirme o plano de backup ou restauração se for produção
db.collectionName.drop()

Para remoção de banco de dados:

use databaseToRemove
db.dropDatabase()

Esse comando elimina o banco de dados atual. O perigo não é a sintaxe; o perigo é estar no contexto errado.

Uma lista de verificação administrativa amigável para iniciantes

Quando você se conectar a um ambiente MongoDB, acostume-se com esta sequência:

db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })

Esses comandos informam onde você está, o que existe, se o acesso básico funciona e se algo óbvio está acontecendo agora.

A administração do MongoDB se torna muito menos intimidante quando você trata o mongosh como uma ferramenta de inspeção primeiro e uma ferramenta de alteração depois. Olhe, confirme, depois aja. Use funções restritas, senhas solicitadas, consultas filtradas e nomes de banco de dados explícitos. Esse hábito é mais importante do que memorizar uma longa lista de comandos.

Leia os tamanhos do banco de dados e da coleção com cuidado

Iniciantes costumam usar show dbs como uma ferramenta de dimensionamento, mas é apenas um ponto de partida. Mecanismos de armazenamento, compressão, índices e espaço excluído podem tornar os números de tamanho surpreendentes. Use estatísticas de coleção quando precisar de mais detalhes:

db.orders.stats()

Veja também o tamanho do índice:

db.orders.totalIndexSize()

Índices não são gratuitos. Eles aceleram leituras e algumas ordenações, mas cada índice adiciona sobrecarga de gravação e armazenamento. Se uma coleção tiver muitos índices e as gravações forem lentas, liste-os e pergunte quais consultas realmente os usam:

db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")

Não elimine índices casualmente em produção. Um índice de aparência não utilizada pode suportar um relatório mensal ou uma tela administrativa raramente usada. Verifique logs de consulta, proprietários de aplicativos e monitoramento antes de removê-lo.

Consciência básica de backup

A administração de linha de comando deve estar sempre conectada a hábitos de backup. Antes da manutenção destrutiva, saiba como o banco de dados é copiado e como a restauração foi testada. No MongoDB autogerenciado, você pode ver mongodump e mongorestore para backups lógicos:

mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup

Para grandes sistemas de produção, snapshots de sistema de arquivos, snapshots de provedor de nuvem, Ops Manager ou backups do Atlas podem ser mais apropriados. O ponto de nível iniciante é simples: não trate drop, deleteMany ou alterações de função como reversíveis, a menos que você tenha um caminho de restauração testado.

Um backup que você nunca restaurou é uma suposição. Pratique a restauração em um ambiente que não seja de produção para conhecer as credenciais, acesso à rede e compatibilidade de versão antes de um incidente.

Verifique os logs quando os comandos não forem suficientes

mongosh mostra respostas do servidor, mas não substitui logs. Se os usuários relatarem consultas lentas, falhas de autenticação ou rotatividade de conexão, verifique os logs do MongoDB e os logs da sua plataforma. Em implantações Linux autogerenciadas, os logs podem estar em /var/log/mongodb/, dependendo do pacote e da configuração. Em contêineres, use os logs de tempo de execução do contêiner. No Atlas, use a interface do Atlas e logs para download.

Um erro comum de iniciante é ficar olhando para serverStatus() enquanto a pista real é uma falha de autenticação, problema de DNS, incompatibilidade TLS ou esgotamento do pool de conexões do aplicativo em logs fora do MongoDB.

Saiba a diferença entre funções de banco de dados e acesso ao sistema operacional

Usuários do MongoDB não são usuários Linux. Criar myAppUser no MongoDB não cria uma conta de shell. Dar a alguém acesso SSH a um servidor de banco de dados não dá automaticamente permissões de banco de dados, embora possa dar acesso indireto perigoso se o servidor estiver mal configurado.

Mantenha essas camadas separadas:

Usuário Linux: controla o acesso ao host e arquivos
Usuário MongoDB: controla autenticação e autorização do banco de dados
Política de rede: controla quem pode alcançar a porta do MongoDB
TLS: protege o tráfego e pode suportar identidade baseada em certificado

Uma implantação segura precisa de todos eles considerados. Uma senha forte do MongoDB não é suficiente se o banco de dados escuta publicamente sem regras de firewall. Uma rede privada não é suficiente se todos os aplicativos usam uma função de administrador.

Um hábito mais seguro para shells de produção

Ao trabalhar em produção, torne o prompt e a conexão óbvios. Algumas equipes usam cores de terminal, aliases de shell ou usuários somente leitura para inspeção. No mínimo, execute algumas verificações de identidade após conectar:

db.runCommand({ connectionStatus: 1 })
db
db.hello()

connectionStatus mostra usuários e funções autenticados. db mostra contexto. hello fornece informações de topologia. Essas três verificações evitam um número surpreendente de erros.

Para inspeção de rotina, use uma conta somente leitura. Alterne para uma conta privilegiada apenas para a janela de alteração específica. Esse pequeno atrito é útil. Isso força você a perceber quando está prestes a fazer algo que pode alterar dados.

Quando parar e pedir ajuda

Alguns comandos do MongoDB são amigáveis para iniciantes; outros não. Tenha cuidado com reconfiguração de conjunto de réplicas, metadados de sharding, reconfigurações forçadas, eliminação de operações, compactação de coleções e alteração de configurações de autenticação em um sistema ativo. Essas ações podem afetar a disponibilidade.

Se o comando alterar a topologia do cluster ou remover dados, pause e obtenha uma segunda revisão. Os melhores administradores não são os que digitam mais rápido. São aqueles que sabem quando um comando merece um backup, uma janela de manutenção e outro par de olhos.

Entenda read concern e write concern em alto nível

Iniciantes não precisam ajustar read concern e write concern no primeiro dia, mas devem saber que essas configurações existem. Write concern controla a confirmação que o MongoDB dá após uma gravação. Um write concern mais forte pode esperar pela replicação para mais membros. Um mais fraco pode retornar mais cedo, mas dá menos garantia sobre durabilidade em falhas.

Read concern controla qual nível de consistência de dados uma leitura solicita. Em muitos aplicativos simples, os padrões são suficientes, mas em conjuntos de réplicas e sistemas distribuídos, essas configurações influenciam o que seu aplicativo pode assumir com segurança após failover ou durante atraso de replicação.

A lição administrativa é prática: quando alguém relatar "MongoDB perdeu uma gravação" ou "o aplicativo leu dados obsoletos", não olhe apenas para o comando de inserção. Verifique as configurações do driver, write concern, read preference, read concern, saúde do conjunto de réplicas e comportamento de repetição do aplicativo.

Tenha cuidado com exemplos copiados da internet

A sintaxe do MongoDB mudou ao longo do tempo. Postagens de blog mais antigas podem usar o shell mongo legado em vez de mongosh, nomes de ajudantes antigos ou comandos que ainda funcionam, mas não são mais preferidos. Alguns exemplos também são executados com autenticação desabilitada, o que não é uma suposição segura de produção.

Ao copiar um comando, faça três perguntas:

Para qual versão do MongoDB isso foi escrito?
Em qual contexto de banco de dados ele é executado?
Quais permissões o usuário conectado precisa?

Se o comando for destrutivo, adicione uma quarta pergunta: como faço para restaurar se isso der errado?

Use Compass e Atlas sem abandonar o shell

Ferramentas gráficas são úteis. O MongoDB Compass pode ajudar a inspecionar documentos, índices e planos de consulta. O Atlas fornece monitoramento, backups, alertas e gerenciamento de usuários para clusters hospedados. Essas ferramentas são frequentemente mais fáceis para inspeção visual do que a saída bruta do shell.

Ainda assim, aprenda os comandos do shell. Durante incidentes, automação, ambientes somente SSH ou revisões de documentação, um comando mongosh preciso é mais fácil de compartilhar do que "clique na terceira aba da interface". O melhor fluxo de trabalho não é shell versus GUI. Use a GUI para explorar e o shell para expressar ações repetíveis claramente.