A reindexação Magento 2 pode falhar, permanecer em “Processing” ou terminar sem refletir preços, estoque, categorias e regras comerciais na vitrine. Embora executar o comando novamente pareça a solução mais rápida, isso não corrige falta de memória, processos concorrentes, cron interrompido, dependências indisponíveis ou dados inconsistentes.
Antes de limpar caches ou modificar tabelas, registre o horário da falha, o indexador afetado, o comando executado e qualquer alteração recente em produtos, módulos, infraestrutura ou deploy. Os nove passos abaixo ajudam a localizar a camada responsável sem apagar pistas importantes.
Reindexação Magento 2: identifique exatamente o sintoma
Comece diferenciando três situações que podem parecer iguais na vitrine:
- o indexador está inválido e aguarda processamento;
- a reindexação começou, mas ficou presa ou foi interrompida;
- o índice foi atualizado, porém cache, busca ou outra camada continua entregando dados antigos.
No diretório da aplicação, consulte o estado dos indexadores com o mesmo usuário utilizado pela operação da loja:
php bin/magento indexer:status
php bin/magento indexer:show-modeAnote o nome e o identificador de cada item com problema. Evite iniciar uma reindexação geral antes de saber se a falha atinge apenas preços, estoque, categorias, regras ou a busca.
1. Execute somente o indexador afetado
Reindexar tudo aumenta o consumo de CPU, memória e banco de dados, além de dificultar a identificação do ponto exato da falha. Use o identificador retornado pelo comando de status:
php bin/magento indexer:reindex identificador_do_indexadorPreserve toda a saída, inclusive avisos exibidos antes da mensagem final. Se o processo terminar abruptamente sem erro claro, registre também o código de saída:
php bin/magento indexer:reindex identificador_do_indexador
echo $?Um índice isolado que sempre falha sugere problema nos dados ou na lógica correspondente. Vários indexadores interrompidos no mesmo ponto indicam que recursos do servidor, banco de dados ou processos concorrentes merecem prioridade.
2. Confirme o modo de atualização
No modo Update on Save, alterações podem ser processadas durante o salvamento. Em Update by Schedule, o cron e as filas internas de mudanças passam a ser essenciais. Portanto, uma loja configurada por agendamento pode apresentar índices desatualizados mesmo quando a reindexação manual funciona.
Não altere o modo apenas para mascarar o defeito. Primeiro confirme qual comportamento foi planejado para a operação e se o cron está executando regularmente. Uma mudança de modo em catálogo volumoso também pode elevar o custo de salvamento no Admin e nas integrações.
3. Verifique o cron sem criar processos duplicados
Consulte os processos existentes antes de iniciar outra execução:
ps aux | grep '[b]in/magento cron:run'
crontab -lDepois, examine os registros da aplicação e do cron no período da falha. Procure por mensagens de memória esgotada, conexão perdida, deadlock, timeout ou exceção relacionada ao indexador.
grep -Ri "index|deadlock|memory|timeout" var/log/ | tail -n 100Se outros fluxos agendados também falham, como e-mails e consumidores, o problema pode ser mais amplo do que a indexação. O diagnóstico de e-mails que não são enviados pelo Magento 2 mostra como separar geração, cron, transporte e entrega sem trocar configurações aleatoriamente.
4. Confira memória, disco e encerramentos do sistema
Uma reindexação pode consumir mais recursos do que uma página comum da loja. Compare memória disponível, uso do disco e limites do PHP executado pela linha de comando:
php -r 'echo ini_get("memory_limit"), PHP_EOL;'
df -h
free -mO PHP do terminal pode carregar uma configuração diferente daquela usada pelo servidor web. Confirme o arquivo ativo com php --ini. Se o processo simplesmente desaparecer, os logs do sistema operacional e do contêiner podem indicar se ele foi encerrado por falta de memória.
Aumentar limites sem investigar volume, consulta ou extensão responsável apenas adia a falha. Também verifique se var/, generated/ e os diretórios temporários possuem espaço e permissões compatíveis com o usuário da aplicação.
5. Procure concorrência e bloqueios no banco
Importações, atualizações em massa, integrações de estoque e duas reindexações simultâneas podem disputar as mesmas estruturas. Registre quais jobs estavam ativos no horário e consulte, com uma conta autorizada, processos longos ou bloqueados no banco de dados.
Não encerre sessões nem remova locks sem identificar o proprietário e o impacto. Um processo aparentemente parado pode estar concluindo uma operação legítima. Se a falha sempre ocorrer durante uma importação, reproduza o cenário em homologação com uma amostra controlada.
6. Analise dados inconsistentes e o último lote alterado
Quando apenas um indexador falha, procure o último produto, categoria, regra ou atributo processado. Integrações podem enviar valores incompatíveis, referências inexistentes ou volumes inesperados que só aparecem durante a construção do índice.
Compare um item com falha a outro processado corretamente e revise mudanças recentes. Não corrija diretamente o banco como primeira tentativa: alterações manuais podem quebrar relações e dificultar o retorno. Se o problema percebido é um item ausente na vitrine, siga também as verificações para quando o produto não aparece no Magento 2, pois status, site, visibilidade e estoque podem ser a causa mesmo com os índices válidos.
7. Valide busca, cache e serviços dependentes
Um status válido não garante que todas as camadas estejam entregando o dado esperado. Se a falha aparece apenas na pesquisa, confirme a disponibilidade e a saúde do mecanismo de busca configurado. Se categorias ou produtos mostram informações antigas, compare a resposta com e sem as camadas de cache autorizadas no ambiente.
Evite limpar todos os caches repetidamente. Faça uma invalidação controlada somente depois de confirmar que o índice terminou e registre o resultado. Em ambientes com múltiplos nós, verifique se todos usam as mesmas dependências e configurações. Uma auditoria dos requisitos de sistema do Adobe Commerce ajuda a encontrar diferenças entre produção, homologação, contêineres e pipelines.
8. Revise módulos e deploys recentes
Extensões podem adicionar indexadores, interceptar salvamentos ou alterar consultas. Se o defeito começou após um deploy, compare o código, os pacotes e as configurações liberadas naquela janela. Consulte os logs de compilação e implantação antes de desabilitar qualquer módulo.
Verifique ainda se o código publicado corresponde ao arquivo composer.lock e se todos os nós receberam o mesmo artefato. Quando houver falha na instalação de dependências, use o roteiro para descobrir o pacote que bloqueia o Composer no Magento 2 sem executar uma atualização geral indiscriminada.
9. Use reset com critério e valide o resultado
O comando de reset pode ser apropriado quando um indexador permanece marcado como processamento após uma interrupção confirmada e não existe processo correspondente em execução:
php bin/magento indexer:reset identificador_do_indexador
php bin/magento indexer:reindex identificador_do_indexador
php bin/magento indexer:statusNão use o reset para interromper uma tarefa ativa. Antes, confirme processos, cron e jobs de deploy. Evite também apagar tabelas de índice ou modificar estados diretamente no banco: além do risco operacional, isso remove evidências sem resolver a origem.
Após a correção, valide um conjunto conhecido de produtos, preços, categorias, regras e saldos. Teste a vitrine em janela anônima, confirme o tempo de execução e monitore a próxima rodada agendada. O objetivo não é apenas obter a mensagem “Reindex successfully”, mas comprovar que o dado correto chegou ao canal esperado.
Perguntas frequentes
Posso executar indexer:reindex em produção?
É possível, mas o impacto depende do catálogo, do indexador, da infraestrutura e da concorrência com pedidos e integrações. Prefira uma janela controlada, execute somente o índice necessário e monitore banco, memória e tempo de resposta.
Limpar o cache resolve erro de reindexação?
Não resolve a causa de uma reindexação que falhou. O cache pode manter conteúdo antigo depois que o índice foi atualizado, mas falta de memória, cron parado, bloqueios ou dados inconsistentes exigem correções próprias.
Quando devo usar indexer:reset?
Use quando o indexador estiver preso em estado de processamento após uma interrupção confirmada e não houver processo ativo. O reset não corrige o motivo original da falha e deve ser seguido de nova execução e validação.
É seguro apagar tabelas de índice?
Não como procedimento inicial. A exclusão manual pode causar indisponibilidade, inconsistências e perda de evidências. Prefira comandos suportados, backup, diagnóstico dos logs e reprodução em homologação.
Conclusão
Uma falha de reindexação Magento 2 deve ser tratada como um fluxo entre dados, cron, PHP, banco, busca, cache e módulos — não como um simples pedido para “reindexar tudo”. Ao isolar o índice afetado, preservar os registros e validar o resultado na vitrine, a equipe reduz mudanças desnecessárias e encontra a causa com mais segurança.
Se o indexador continuar travando ou afetar preços, estoque e disponibilidade de produtos, uma análise técnica do ambiente pode identificar o bloqueio e preparar a correção com menor risco para a operação. Fale com a equipe do Suporte Magento.
