O erro Redis no Magento 2 pode aparecer como página indisponível, lentidão, falha no painel, perda de sessão ou carrinho vazio. Mensagens como Connection refused, read error on connection, max number of clients reached e OOM command not allowed ajudam no diagnóstico, mas não devem ser tratadas como causas equivalentes.
Reiniciar o Redis ou executar uma limpeza completa pode restaurar a loja temporariamente, porém também remove evidências e, dependendo da configuração, encerra sessões de clientes. Antes de intervir, identifique qual função do Magento foi afetada e faça os oito testes abaixo.
Como o Redis é utilizado pelo Magento 2?
Uma instalação pode usar Redis para armazenar cache padrão, Full Page Cache e sessões. Essas funções podem estar no mesmo serviço, em bancos lógicos diferentes ou em instâncias separadas. Portanto, uma falha não necessariamente afeta toda a loja da mesma maneira.
- Cache padrão: armazena configurações, layouts e outros dados reutilizados pela aplicação.
- Full Page Cache: mantém respostas de páginas públicas quando essa camada está configurada no Redis.
- Sessões: preserva a associação entre o visitante, sua autenticação e o carrinho.
Se somente o cache falhar, o site pode ficar lento ou apresentar erros durante a leitura e gravação. Quando o armazenamento de sessões é interrompido, clientes podem sair da conta ou perder a referência do carrinho. Se esse for o principal sintoma, consulte também o diagnóstico para quando o carrinho esvazia sozinho no Magento 2.
Erro Redis no Magento 2: 8 testes para encontrar a causa
1. Registre o erro completo e o horário da ocorrência
Comece pelos arquivos var/log/system.log, var/log/exception.log e pelos logs do PHP-FPM, servidor web e serviço Redis. Registre a URL afetada, o horário, o nó da aplicação e a ação executada pelo usuário.
Não pesquise apenas pela palavra “Redis”. Procure também por exceções de conexão, timeouts, falhas de sessão e mensagens de memória. Um erro HTTP 500 pode ser apenas o efeito visível dessa indisponibilidade; nesse cenário, use os testes para encontrar a causa real do erro 500 sem perder a sequência dos acontecimentos.
2. Descubra qual configuração aponta para a instância afetada
Revise o arquivo app/etc/env.php no servidor, sem copiar senhas, chaves ou outros segredos para chamados públicos. Identifique os hosts, portas, bancos lógicos e parâmetros usados nas seções de cache, page cache e sessão.
Em ambientes com contêineres ou múltiplos servidores, um hostname pode resolver de forma diferente entre os nós. Faça a verificação a partir do mesmo ambiente em que o PHP executa, e não apenas de uma máquina administrativa.
3. Teste DNS, porta e conectividade a partir da aplicação
Um Connection refused normalmente indica que o destino respondeu, mas não existe um serviço aceitando conexões naquela porta. Já um timeout pode apontar para rota, firewall, DNS, sobrecarga ou serviço sem capacidade de responder.
Use ferramentas permitidas pela infraestrutura para verificar a resolução do hostname e a abertura da porta. Se o cliente Redis estiver disponível, um teste autenticado pode ser executado com:
redis-cli -h HOST -p PORT PINGO resultado esperado é PONG. Não coloque a senha diretamente no histórico do terminal. Utilize o mecanismo seguro de autenticação adotado pela operação e evite registrar credenciais em capturas de tela ou logs de automação.
4. Confirme se todos os nós alcançam o mesmo serviço
Em uma arquitetura com balanceamento, a vitrine pode funcionar em um servidor e falhar em outro. Execute o teste de conectividade em cada nó de aplicação e compare DNS, variáveis de ambiente, configuração implantada e regras de rede.
Esse teste é especialmente importante quando o problema ocorre de forma intermitente. Se apenas parte das requisições passa por um nó com configuração antiga ou sem acesso ao Redis, reiniciar o serviço central não corrigirá a inconsistência.
5. Verifique conexões e o limite de clientes
Consulte as métricas do Redis com comandos somente de leitura:
redis-cli -h HOST -p PORT INFO clients
redis-cli -h HOST -p PORT INFO statsCompare connected_clients, conexões rejeitadas e o limite configurado. Um volume elevado pode ser provocado por crescimento legítimo, conexões não reutilizadas, excesso de processos PHP, tarefas paralelas ou uma extensão com comportamento inadequado.
Aumentar maxclients sem avaliar os limites do sistema operacional e o consumo por conexão apenas desloca o problema. Primeiro descubra quais aplicações se conectam e se o aumento coincide com deploys, importações ou picos de tarefas assíncronas.
6. Analise memória, política de remoção e erros OOM
Quando o Redis atinge a memória disponível, o comportamento depende da política configurada. Algumas políticas removem chaves; outras recusam novas gravações. Consulte:
redis-cli -h HOST -p PORT INFO memory
redis-cli -h HOST -p PORT CONFIG GET maxmemory
redis-cli -h HOST -p PORT CONFIG GET maxmemory-policyComandos de configuração podem ser bloqueados pelo provedor, o que é normal em serviços gerenciados. Nesse caso, consulte as métricas e parâmetros pelo painel autorizado.
Não use FLUSHALL ou FLUSHDB como solução para falta de memória. Além de apagar dados, essa ação não corrige vazamentos, dimensionamento insuficiente, TTL inadequado ou mistura indevida de cargas na mesma instância.
7. Procure latência, comandos lentos e pressão do servidor
Uma conexão bem-sucedida não garante respostas rápidas. Analise CPU, memória, swap, armazenamento e latência de rede no mesmo intervalo do erro. Se permitido, consulte informações gerais e o registro de comandos lentos:
redis-cli -h HOST -p PORT INFO server
redis-cli -h HOST -p PORT SLOWLOG GET 20O resultado pode conter detalhes operacionais, portanto deve permanecer restrito à equipe autorizada. Observe se a lentidão está associada a comandos específicos, backups, persistência, disputa por recursos ou chamadas originadas fora do Magento.
8. Diferencie cache descartável de sessões ativas
Antes de limpar qualquer banco lógico, confirme o que ele armazena. Cache pode ser reconstruído, embora a regeneração gere carga. Sessões ativas representam clientes navegando, autenticados ou com carrinhos associados e exigem cuidado maior.
Também verifique se cache e sessões realmente utilizam bancos separados. Uma numeração diferente não fornece isolamento de memória, CPU ou disponibilidade quando tudo continua na mesma instância.
Se a investigação apontar apenas para o Full Page Cache, confira se a falha não está na camada HTTP. O roteiro sobre Varnish retornando MISS no Magento 2 ajuda a separar problemas do proxy daqueles relacionados ao Redis.
Como restaurar o serviço sem aumentar o impacto
Depois de identificar a causa, prepare uma intervenção proporcional. Quando possível, retire um nó defeituoso do balanceador, corrija sua configuração e valide-o antes de devolvê-lo ao tráfego. Se for indispensável reiniciar um serviço compartilhado, avalie previamente o efeito sobre sessões, cache e tarefas em execução.
Após a correção, valide pelo menos:
- home, categorias, busca e páginas de produto;
- login, logout e persistência da sessão;
- adição, atualização e remoção de itens do carrinho;
- checkout de convidado e cliente autenticado;
- painel administrativo e gravação de configurações;
- logs, consumo de memória, conexões e latência do Redis.
Monitore o ambiente depois da recuperação. Uma queda no número de erros não basta se memória e conexões continuam crescendo até o próximo incidente.
Perguntas frequentes
Posso reiniciar o Redis quando o Magento 2 fica fora do ar?
Somente depois de avaliar a função da instância e o impacto. O reinício pode encerrar sessões, provocar regeneração intensa de cache e ocultar a causa original. Registre logs e métricas antes da intervenção.
É seguro executar FLUSHALL para corrigir erro de memória?
Não como procedimento de diagnóstico. O comando apaga todos os bancos da instância e pode remover sessões ativas. Falta de memória deve ser investigada por consumo, política de remoção, TTL, carga e dimensionamento.
Por que o teste retorna PONG, mas o Magento continua falhando?
O PONG confirma uma resposta básica, mas não valida permissões, banco lógico, estabilidade, latência ou capacidade de leitura e gravação. Também pode haver divergência entre os nós da aplicação.
Redis lento pode deixar o checkout Magento lento?
Sim. O checkout depende de várias leituras e gravações de sessão e cache. Contudo, banco de dados, gateway, frete, extensões e serviços externos também podem causar demora, por isso a latência deve ser correlacionada com as requisições.
Conclusão
Um erro Redis no Magento 2 deve ser investigado por função, instância e nó da aplicação. Conectividade, clientes, memória e latência produzem sintomas parecidos, mas exigem correções diferentes. Evite limpezas indiscriminadas e reinícios sem coleta prévia de evidências.
Se a loja apresenta perda de sessão, carrinhos vazios ou indisponibilidade recorrente, uma análise técnica da configuração e das métricas pode localizar o gargalo e permitir uma correção controlada. A equipe do SuporteMagento.com.br pode apoiar esse diagnóstico e o planejamento da intervenção.
