Resolver problemas

Esta página explica vários cenários de erro e fornece orientações para resolver os erros.

Cenários de replicação

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

Como monitorar atrasos de replicação?

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

Ao manter a diferença de deslocamento de replicação baixa, 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 definir um limite para a métrica maximum_offset_diff. Se o limite for excedido, o Memorystore for Redis Cluster poderá notificar você por um alerta.

Com base no tipo de nó do cluster, recomendamos definir 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 para ser menor que 64 MB.

• Se o tipo de nó for redis-highmem-xlarge ou redis-highmem-2xlarge, defina o limite para ser menor que 1 GB.

Atenção: recomendamos usar o tipo de nó redis-shared-core-nano apenas para fins de desenvolvimento ou teste porque esse tipo de nó não tem SLA. Se você executar o Memorystore for Redis Cluster em um ambiente de produção, recomendamos usar outro tipo de nó. Para mais informações sobre esses tipos de nó, consulte Escolher um tipo de nó.

Cenários de erro de conectividade

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

Erro de conexão causado por regras de firewall

As regras de firewall podem causar erros de conexão bloqueando as portas usadas pelo Memorystore para Redis Cluster. Para os dois endpoints do Private Service Connect do cluster, permita 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

É possível que você tenha uma política da organização que bloqueie as 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 é uma pasta 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 ao Memorystore para Redis Cluster. Quando uma conexão sem resposta é detectada, o cliente precisa redefini-la. Para criar um aplicativo resiliente, recomendamos as seguintes configurações do cliente:

• Configurar 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 conexões sem resposta de forma proativa, mesmo quando as conexões estiverem 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 inativas sem resposta em um minuto.
• Configurar tempos limite de usuário TCP: defina esse tempo limite nos clientes para redefinir conexões que têm solicitações pendentes e param 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 problemas de uso da CPU que podem ocorrer com o cluster.

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 maxmemory parâmetro.
• Use a política allkeys-lru maxmemory.

Quando a memória do cluster está cheia e uma nova gravação chega, o Memorystore para 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 monitorar a maxmemory e a memória usada do cluster. Isso ajuda a saber se o cluster atinge a capacidade provisionada. Além disso, ao reduzir o valor do parâmetro maxmemory, você terá mais espaço para a sobrecarga.

Por que as métricas externas podem estar ausentes do cluster?

Se o cluster tiver um alto uso da CPU ou se os recursos dele ficarem esgotados (por exemplo, por ter muitas conexões), o cluster poderá ter 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 ou do aplicativo cliente e do ambiente de rede, use a ferramenta redis-cli para executar um teste de latência contínuo.

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 do cluster.

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

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

     sudo apt-get install redis-tools
     

   • Para VMs baseadas no RHEL ou no 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 a criptografia em trânsito, será necessário anexar a flag --tls e especificar as autoridades certificadoras (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 de porta é 6379.

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

5. Para interromper a execução do comando e visualizar 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 o desempenho típico do servidor, mas o aplicativo cliente ainda tiver atrasos, os seguintes problemas poderão causar a latência:

• Rede: o tráfego roteado em diferentes regiões ou zonas entre o seu cliente e o cluster pode introduzir atrasos significativos na rede.
• Cliente: o alto uso da CPU ou da memória no cliente, os pools de conexão esgotados ou os gargalos de 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 o cluster.

O tráfego de gravação excede a capacidade do Memorystore para Redis Cluster de compactar e recuperar espaço por meio da reescrita do AOF

Se essa situação ocorrer, o arquivo somente de anexação (AOF) vai crescer mais rápido do que o processo de reescrita pode 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 a sincronização completa.

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