Falha de teste do Redis

Soluções para falhas de investigação do Redis Enterprise, incluindo limites de fragmentos no Automation Suite no Linux.

Description

As falhas de teste do Redis podem ocorrer nos seguintes cenários.

Arquivo de ID do nó do Redis ausente

A investigação do Redis pode falhar se o arquivo da ID do nó não existir. Isso pode acontecer se o pod ainda não tiver sido inicializado.

Há um trabalho de recuperação que corrige automaticamente esse problema, e as seguintes etapas não devem ser executadas enquanto o trabalho estiver sendo executado.

Quando um cluster da Redis Enterprise perde contato com mais da metade de seus nós (devido a uma falha dos nós ou divisão da rede), o cluster para de responder às conexões do cliente. Os pods também não conseguem reingressar no cluster.

Limite de fragmentos Enterprise do Redis excedido

O Redis Enterprise pode criar vários shards que excedem a cota de licenças. Isso causa um efeito dominó, onde o service-rigger falha ao criar o serviço necessário do Kubernetes para redis-cluster-db, resultando em falhas para todos os serviços dependentes do Redis.

Solução

1. Desabilite a sincronização argo, exclua o banco de dados do Redis e o recurso de cluster do Redis, reabilite a sincronização argo e inicie um trabalho de recuperação, usando os seguintes comandos:

   kubectl -n argocd patch application redis-cluster --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":false}]'
   kubectl -n argocd patch application redis-operator --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":false}]'
   kubectl delete redb -n redis-system redis-cluster-db --force --grace-period=0 &
   kubectl delete rec -n redis-system redis-cluster --force --grace-period=0 &
   kubectl patch redb -n redis-system redis-cluster-db --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"finalizer.redisenterprisedatabases.app.redislabs.com"}]'
   kubectl patch rec redis-cluster -n redis-system --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"redbfinalizer.redisenterpriseclusters.app.redislabs.com"}]'
   kubectl -n redis-system get pods | grep services-rigger | awk '{print $1}' | xargs kubectl -n redis-system delete pod --force
   kubectl -n redis-system get pods | grep -E "redis-cluster-[0-2]" | awk '{print $1}' | xargs kubectl -n redis-system delete pod --force
   kubectl -n argocd patch application redis-cluster --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":true}]'
   kubectl -n argocd patch application redis-operator --type=json -p '[{"op":"replace","path":"/spec/syncPolicy/automated/selfHeal","value":true}]'
   kubectl -n redis-system create job --from=cronjob/redis-cluster-recovery-job cronjob-manual-run
   

2. Se o erro ainda persistir, verifique se há defasagem horária entre os nós do Kubernetes. Se qualquer nó estiver alguns segundos à frente ou atrás, o pod do Redis não conseguirá ser executado nele. Para corrigi-lo, você deve certificar-se de que todos os nós tenham os relógios sincronizados.