Resolver problemas

Nesta página, explicamos vários cenários de erro e fornecemos orientações para resolver os erros.

Cenários de replicação

Esta seção explica problemas de replicação que podem ocorrer com seu cluster.

Como você monitora atrasos de replicação?

O Memorystore for Redis Cluster tem a métrica /cluster/replication/maximum_offset_diff. Essa métrica monitora a diferença máxima de deslocamento de replicação (em bytes) para um nó em um cluster principal.

Ao manter baixa a diferença de compensação de replicação, as réplicas podem realizar operações de sincronização incremental com mais frequência e a um custo menor do que as operações de sincronização completa.

Recomendamos que você defina um limite para a métrica maximum_offset_diff. Se o limite for excedido, o Memorystore for Redis Cluster poderá enviar uma notificação por alerta.

Com base no tipo de nó do cluster, recomendamos que você defina o limite da seguinte maneira:

• Se o tipo de nó for redis-shared-core-nano, redis-standard-small, redis-highmem-medium, redis-highcpu-medium ou redis-standard-large, defina o limite como menos de 64 MB.

• Se o tipo de nó for redis-highmem-xlarge ou redis-highmem-2xlarge, defina o limite como menos de 1 GB.

Cenários de erro de conectividade

Esta seção explica os problemas de conectividade que seu cluster pode encontrar.

Erro de conexão causado por regras de firewall

Se você não permitir as portas corretas no firewall, o cluster poderá encontrar erros de conexão porque o firewall pode bloquear as portas que o Memorystore para Redis Cluster usa.

Para todos os endpoints do Private Service Connect do cluster, é necessário permitir a porta TCP 6379 e as portas TCP de 11000 a 13047. Para mais informações sobre esses endpoints, consulte Endereços de rede reservados.

Erro de conexão causado por políticas da organização

Talvez você tenha uma política da organização que bloqueie suas conexões do Private Service Connect com o cluster.

Se a política da organização usar a política .restrictPrivateServiceConnectProducer, permita a pasta 961333125034, que é específica para o Memorystore para Redis Cluster. Exemplo:

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/961333125034

Se a política da organização usar a política .disablePrivateServiceConnectCreationForConsumers, permita SERVICE_PRODUCERS. Exemplo:

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

Erro de conexão causado por conexões sem resposta

Recomendamos configurar o aplicativo cliente para detectar conexões sem resposta com o cluster do Memorystore para Redis. Quando uma conexão sem resposta é detectada, o cliente precisa redefini-la. Para criar um aplicativo resiliente, recomendamos as seguintes configurações de cliente:

• Configure os parâmetros de sinal de atividade do TCP: defina os parâmetros TCP keepalive time, TCP keepalive interval e TCP keepalive probes para que os clientes detectem e descartem proativamente conexões sem resposta, mesmo quando elas estão inativas. Por exemplo, se você definir o parâmetro TCP keepalive time como 30 segundos, TCP keepalive interval como 10 segundos e TCP keepalive probes como 3, os clientes vão redefinir as conexões ociosas sem resposta em um minuto.
• Configure tempos limite de usuário do TCP: defina esse tempo limite nos clientes para redefinir conexões com solicitações pendentes e parar de responder. Por exemplo, se você definir o tempo limite como 15 segundos, os clientes vão redefinir as conexões sem resposta que têm solicitações pendentes após 15 segundos.

Cenários de uso da CPU

Esta seção explica os problemas de uso da CPU que seu cluster pode encontrar.

O buffer de saída do cluster fica sem espaço.

Se o buffer de saída do cluster ficar sem espaço, faça o seguinte:

• Defina um valor menor para o parâmetro maxmemory.
• Use a política maxmemory allkeys-lru.

Quando a memória do cluster está cheia e uma nova gravação chega, o Memorystore for Redis Cluster remove as chaves para liberar espaço para a gravação com base na política maxmemory do cluster. A política allkeys-lru remove as chaves usadas menos recentemente (LRU, na sigla em inglês) de todo o conjunto de chaves.

Recomendamos que você monitore o maxmemory e a memória usada do cluster. Isso ajuda você a saber se o cluster atinge a capacidade provisionada. Além disso, ao reduzir o valor do parâmetro maxmemory, você ganha mais espaço para o overhead.

Por que as métricas externas podem estar faltando no seu cluster?

Se o cluster tiver alta utilização da CPU ou os recursos dele se esgotarem (por exemplo, por ter muitas conexões), o cluster poderá apresentar um comportamento inadequado e as métricas externas poderão estar ausentes.

Isolar a origem da latência do cluster

Para determinar se a latência que você está enfrentando se origina do cluster, do aplicativo cliente ou do ambiente de rede, use a ferramenta redis-cli para executar um teste contínuo de latência.

Para isolar a origem da latência do cluster, faça o seguinte:

1. Conecte-se a uma VM do Compute Engine localizada na mesma região e rede VPC que o cluster.

2. Se ele ainda não estiver instalado, instale a ferramenta redis-cli na sua VM.

   • Para VMs baseadas em Debian ou Ubuntu, execute o seguinte comando:

     sudo apt-get install redis-tools
     

   • Para VMs baseadas em RHEL ou CentOS, execute o seguinte comando:

     sudo yum install redis
     

3. Para medir a latência do cluster em milissegundos, execute o seguinte comando:

   redis-cli --latency -h DISCOVERY_ENDPOINT_ADDRESS -p PORT
   

   Se o cluster usar criptografia em trânsito, adicione a flag --tls e especifique as autoridades de certificação (CAs) para se conectar.

   Faça as seguintes substituições:

   • DISCOVERY_ENDPOINT_ADDRESS: o endereço IP do endpoint de descoberta do cluster.
   • PORT: o número da porta reservada para o endpoint de descoberta do cluster. Normalmente, esse número é 6379.

4. Deixe o comando ser executado por alguns minutos. A ferramenta envia pings continuamente ao servidor e calcula os valores de latência mínima, máxima e média.

5. Para interromper o comando e ver os resultados, pressione Ctrl+C.

Se o comando gerar uma latência média consistentemente baixa (normalmente 1 milissegundo ou menos), o cluster estará íntegro e respondendo rapidamente.

Se o comando mostrar uma latência consistentemente baixa, mas o aplicativo cliente ainda apresentar atrasos, os seguintes problemas podem estar causando a latência:

• Rede: o tráfego roteado por diferentes regiões ou zonas entre seu cliente e o cluster pode causar atrasos significativos na rede.
• Cliente: o uso alto de CPU ou memória no cliente, o esgotamento dos pools de conexões ou gargalos na lógica do aplicativo podem aumentar o tempo de retorno total que o cliente enfrenta.

Cenários de persistência

Esta seção explica problemas de persistência que podem ocorrer com seu cluster.

Seu tráfego de gravação excede a capacidade do Memorystore para Redis Cluster de compactar e recuperar espaço com a reescrita do AOF.

Se isso acontecer, o arquivo somente de anexação (AOF, na sigla em inglês) vai crescer mais rápido do que o processo de reescrita consegue gerenciar. Isso leva ao esgotamento do disco, causa falhas de gravação e bloqueia operações que exigem a criação de réplicas e sincronização completa.

O Memorystore for Redis Cluster implementou barreiras de proteção para regular a capacidade de processamento de gravação. Isso garante que a reescrita do AOF possa acompanhar cargas de trabalho de gravação alta e sustentada.