5 Cenários Comuns de Solução de Problemas do MongoDB e Correções Rápidas
Solucione cinco problemas comuns do MongoDB: consultas lentas, lag de replicação, erros de conexão, pressão no espaço em disco e problemas de sharding.
5 Cenários Comuns de Solução de Problemas no MongoDB e Correções Rápidas
A solução de problemas no MongoDB geralmente começa quando seu aplicativo fica lento, as gravações falham ou um conjunto de réplicas fica atrasado. Este guia aborda cinco cenários comuns que você provavelmente encontrará em produção e mostra onde procurar primeiro.
Use essas verificações como uma primeira passagem antes de fazer alterações maiores. Elas ajudam a separar problemas de consulta de problemas de infraestrutura, replicação ou sharding.
1. Desempenho Lento de Consultas
Consultas lentas são talvez o problema de desempenho mais comum relatado em ambientes de produção. Uma consulta que leva segundos em vez de milissegundos pode degradar severamente a capacidade de resposta do aplicativo.
Diagnóstico: Usando explain()
O primeiro passo para diagnosticar uma consulta lenta é entender por que ela é lenta. O método explain() do MongoDB é a ferramenta essencial para esta análise. Ele mostra o plano de execução, detalhando quais índices foram usados (ou não usados).
Exemplo de comando:
db.collection.find({ campo: 'valor' }).explain('executionStats')
Analise a saída, procurando especificamente por:
winningPlan.stage: Se o estágio forCOLLSCAN, o MongoDB está lendo todos os documentos. Isso geralmente aponta para um índice ausente ou inutilizável.executionStats.nReturnedcomparado comexecutionStats.totalKeysExaminedeexecutionStats.totalDocsExamined.
Correções Rápidas
- Crie o índice correto: Se o plano de consulta mostrar uma varredura de coleção, adicione um índice que corresponda ao padrão de filtro e classificação. Por exemplo, se seu aplicativo pesquisa frequentemente pedidos por
user_idetimestampmais recente, crie um índice composto:
db.pedidos.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. Refine a consulta: Verifique se você está buscando muitos dados. Use projeção para retornar apenas os campos que a página ou o trabalho realmente precisa. 3. Revise os logs de consultas lentas: Use o profiler ou o log de consultas lentas com um limite que se ajuste à sua carga de trabalho. Trate qualquer limite exato como uma escolha operacional, não uma regra universal.
Dica: Os índices melhoram a velocidade de leitura, mas diminuem ligeiramente as gravações. Indexe apenas campos que são frequentemente usados em predicados de consulta (
find()), operações de classificação (sort()) ou consultas de intervalo.
2. Lag de Replicação em Conjuntos de Réplicas
O lag de replicação ocorre quando membros secundários de um conjunto de réplicas ficam significativamente atrás do membro primário na aplicação de operações do oplog (log de operações).
Diagnóstico: Verificando replSetGetStatus
Use o comando replSetGetStatus em qualquer membro do conjunto de réplicas para examinar a saúde e o status de sincronização de todos os membros.
Exemplo de comando:
rs.printReplicationInfo()
// Ou consultando diretamente o status:
rs.status()
Procure pelo optimeDate para o primário e os secundários. A diferença entre o optime do primário e o optime de um secundário indica o lag, geralmente mostrado no campo secsBehind para cada membro.
Correções Rápidas
- Verifique a latência da rede: Alta latência entre os membros pode diminuir a transferência do oplog.
- Verifique o secundário com lag: CPU alta, I/O de disco lento ou cargas de trabalho de "vizinho barulhento" podem impedir que um secundário aplique as gravações com rapidez suficiente.
- Revise a cobertura do oplog: Se o lag for severo, o secundário pode não ter mais as entradas do oplog de que precisa. Nesse caso, pode ser necessário ressincronizar ou reconstruir esse membro.
3. Erros de Conexão e Falhas de Autenticação
Serviços de aplicativo frequentemente falham ao conectar ao MongoDB devido a erros de configuração, problemas de firewall ou credenciais incorretas.
Diagnóstico: Verificando Logs e Rede
Primeiro, verifique se o servidor MongoDB está ouvindo no endereço IP e porta esperados. Verifique os logs do servidor MongoDB para erros específicos.
Erros Comuns de Log:
Address already in use: Outro processo está usando a porta.Connection refused: O processo do servidor está inativo, bloqueado ou ouvindo em outro lugar.Authentication failed: O nome de usuário, senha, banco de dados de autenticação ou atribuição de função está errado.
Correções Rápidas
- Verifique as regras do firewall: Certifique-se de que a porta do MongoDB, geralmente
27017, seja acessível a partir dos hosts do aplicativo. - Verifique
bindIp: Semongod.confvincular apenas a127.0.0.1, clientes remotos não poderão conectar. Vincule a uma interface privada específica quando possível. Evite0.0.0.0a menos que os controles de rede e a autenticação já estejam em vigor. - Verifique
authSource: Se o usuário foi criado emadmin, a string de conexão pode precisar de?authSource=admin.
4. Ficando sem Espaço em Disco
Como um banco de dados de documentos, o MongoDB armazena dados diretamente no disco. O crescimento inesperado de dados ou limpezas de banco de dados mal tratadas podem rapidamente levar à exaustão do espaço em disco, interrompendo todas as operações de gravação.
Diagnóstico: Monitoramento e db.stats()
Use ferramentas de monitoramento do SO (df -h no Linux) para verificar o uso geral do disco. Dentro do MongoDB, use o comando db.stats() para ver quanto espaço bancos de dados individuais estão consumindo.
Exemplo de comando:
db.stats()
Observe especificamente os campos storageSize e dataSize.
Correções Rápidas
- Ganhe tempo se as gravações estiverem falhando: Pare trabalhos não essenciais, remova arquivos temporários não relacionados ou expanda o volume se sua plataforma suportar.
- Remova dados não utilizados: Descarte coleções ou bancos de dados antigos somente depois de confirmar que eles não são mais necessários e que existem backups.
- Compacte com cuidado: Para coleções com muitas exclusões ou atualizações,
compactpode liberar espaço reservado, mas pode ser disruptivo. Teste o impacto para sua versão do MongoDB e mecanismo de armazenamento:
db.minhaColecao.runCommand({ compact: 'minhaColecao' }) ``` 4. Aumente a capacidade de armazenamento: A correção de longo prazo geralmente são discos maiores, melhores regras de retenção ou armazenamento separado para logs e backups.
Aviso: Se o disco encher completamente, o MongoDB parará de gravar para evitar corrupção de dados. Você deve resolver os problemas de espaço antes de tentar retomar as operações normais.
5. Erros de Cluster de Sharding (Roteadores/Servidores de Config Desatualizados)
Em ambientes fragmentados, problemas de conectividade ou estado dentro dos servidores de configuração (config servers) ou roteadores de consulta (instâncias mongos) podem parar todo o sistema.
Diagnóstico: Verificando a Saúde do Cluster
O comando sh.status() executado contra uma instância mongos é a principal ferramenta de diagnóstico para a saúde do sharding.
Exemplo de Comando Acionável:
sh.status()
As principais áreas a verificar na saída incluem:
- Servidores de configuração: Confirme se o conjunto de réplicas do servidor de configuração tem uma maioria saudável.
- Shards: Verifique se cada shard listado está conectado e reportando corretamente.
- Status desatualizado: Procure por avisos de que um roteador ou shard tem metadados desatualizados.
Correções Rápidas
- Reinicie
mongosquando apropriado: Se um roteador estiver desatualizado ou sem resposta, reiniciá-lo pode forçar uma nova conexão com os servidores de configuração. - Corrija a saúde do servidor de configuração primeiro: Se o conjunto de réplicas do servidor de configuração não tiver uma maioria saudável, as operações de metadados do shard podem falhar.
- Resolva problemas no nível do shard: Se um shard estiver inativo devido a pressão no disco ou lag de replicação, corrija essa causa raiz antes de perseguir sintomas do roteador.
Quando Consultar um Profissional
Traga um administrador do MongoDB ou engenheiro de plataforma quando houver possibilidade de perda de dados, um conjunto de réplicas precisar de uma ressincronização, servidores de configuração estiverem não saudáveis ou o espaço em disco já estiver afetando as gravações. Obtenha ajuda antes de executar comandos disruptivos, como compactação ou reconstrução de membros em produção.
Conclusão
Comece a solução de problemas do MongoDB com o sintoma mais próximo do impacto no usuário: página lenta, conexão falha, gravação travada, secundário com lag ou erro de cluster fragmentado. Em seguida, use explain(), rs.status(), db.stats() e sh.status() para confirmar a causa antes de alterar índices, reiniciar roteadores ou reconstruir membros.