Sobre as réplicas de leitura

O nível Standard do Memorystore para Redis permite escalonar as consultas de leitura do aplicativo usando réplicas de leitura. Presume-se que você tenha familiaridade com os diferentes níveis de recursos do Redis no Memorystore.

Com as réplicas de leitura, é possível escalonar a carga de trabalho de leitura consultando as réplicas. Um endpoint de leitura facilita a distribuição de consultas entre réplicas pelos aplicativos. Para mais informações, consulte Como escalonar leituras com endpoint de leitura.

Para instruções sobre como gerenciar uma instância do Redis com réplicas de leitura, consulte Como gerenciar réplicas de leitura.

Casos de uso para réplicas de leitura

Casos de uso como armazenamento de sessão, placar, mecanismo de recomendação, entre outros, exigem que a instância seja altamente disponível. Nesses casos, há muito mais leituras do que gravações, então geralmente é possível tolerar algumas leituras desatualizadas. Assim, faz sentido aproveitar as réplicas de leitura para aumentar a disponibilidade e a escalonabilidade da instância.

Comportamento da réplica de leitura

  • Por padrão, as réplicas de leitura não estão ativadas nas instâncias de nível Standard.
  • Depois que as réplicas de leitura são ativadas em uma instância, as réplicas de leitura não podem mais ser desativadas para essa instância.
  • As instâncias de nível Standard podem ter de uma a cinco réplicas de leitura.
  • O endpoint de leitura é um único endpoint que serve para distribuir consultas entre nós de réplica.
  • As réplicas de leitura são mantidas usando a replicação assíncrona do Redis.

Advertências e limitações

  • As réplicas de leitura só são compatíveis com tamanhos de instâncias com nós maiores ou iguais a 5 GB.
  • As réplicas de leitura só podem ser ativadas em instâncias que usam o Redis versão 5.0 ou mais recente.
  • Se você designar uma zona e uma zona alternativa para o provisionamento de nós, o Memorystore usará essas zonas para o primeiro e o segundo nós na instância. Depois disso, o Memorystore seleciona as zonas de todos os nós restantes provisionados para a instância.
  • É necessário provisionar a instância com um intervalo de endereços IP CIDR de /28 ou maior. Tamanhos maiores, como /27 e /26, são válidos. Intervalos menores, como /29, não são compatíveis com esse recurso.

Arquitetura

Ao ativar réplicas de leitura, você especifica o número de réplicas que quer na instância. O Memorystore distribui os nós principal e de réplica de leitura automaticamente pelas zonas disponíveis em uma região.

Cada instância tem um endpoint principal e um de leitura. O endpoint principal sempre direciona o tráfego para o nó principal, enquanto o endpoint de leitura faz o balanceamento de carga das consultas de leitura automaticamente nas réplicas disponíveis.

O serviço de monitoramento de integridade do Memorystore para Redis monitora a instância e é responsável por detectar qualquer falha no nó principal. escolher uma réplica como o novo principal e iniciar um failover automático para o novo principal.

Failovers para instâncias com réplicas de leitura

Quando um principal falha, o serviço de monitoramento de integridade do Memorystore inicia o failover e o novo principal é disponibilizado para leituras e gravações. O failover geralmente é concluído em menos de 30 segundos.

Quando ocorre um failover, o endpoint principal automaticamente redireciona o tráfego para o novo principal. No entanto, todas as conexões de cliente com o endpoint principal são desconectadas durante um failover. Os aplicativos com lógica de repetição de conexão serão reconectados automaticamente quando o novo principal estiver on-line. Algumas das conexões de cliente com o endpoint de leitura também passam por desconexões da réplica de leitura promovida para o principal durante o failover. As conexões com as réplicas restantes continuam sendo disponibilizadas durante um failover. Na repetição, as conexões são redirecionadas para as novas réplicas.

Quando ocorre um failover, devido à natureza assíncrona da replicação, as réplicas podem ter um atraso diferente. No entanto, o processo tenta fazer o failover para a réplica com o menor atraso possível. Isso ajuda a minimizar a quantidade de perda de dados e a redução da capacidade de leitura durante um failover. O principal recém-promovido pode estar na mesma zona ou em uma zona diferente do antigo. Uma réplica será selecionada para ser o novo principal se estiver na mesma zona que o antigo e um atraso menor. Caso contrário, uma réplica de uma zona diferente pode se tornar o novo principal.

Como a replicação é assíncrona, sempre há a possibilidade de ler dados desatualizados durante um failover. Além disso, enquanto o novo principal é promovido, pode ser que algumas gravações na instância sejam perdidas. Os aplicativos precisam ser capazes de lidar com esse comportamento.

O Redis se esforça para evitar que as outras réplicas precisem de uma sincronização completa durante o failover. No entanto, isso pode acontecer em casos raros. Uma sincronização completa pode levar de alguns minutos a uma hora, dependendo da taxa de gravação e do tamanho do conjunto de dados que está sendo replicado. Durante esse período, as réplicas que passam por uma sincronização completa ficam indisponíveis para leituras. Quando a sincronização for concluída, as réplicas poderão ser acessadas para leitura.

Modos de falha para réplicas de leitura

Instâncias com réplicas de leitura podem se deparar com várias falhas e condições não íntegras que afetam o aplicativo. O comportamento varia caso a instância tenha uma ou duas réplicas. Nesta seção, descrevemos alguns modos comuns de falha e o comportamento da instância nessas condições.

A réplica não está disponível

  • Quando uma réplica falha por qualquer motivo, ela é marcada como indisponível e todas as conexões dela são encerradas após um determinado tempo limite. Depois que a réplica for recuperada, novas conexões serão roteadas para a réplica restaurada. O tempo para recuperar uma réplica varia de acordo com o modo de falha.

  • No caso de falha na zona ou esgotamento do Compute Engine, a réplica não será recuperada até que a condição seja resolvida.

Falha na zona

  • Se a zona em que o principal estiver localizada falhar, ele fará o failover automaticamente para uma réplica em outra zona. Se a instância tiver apenas uma réplica, o endpoint de leitura ficará indisponível durante a interrupção da zona. Se a instância tiver mais de uma réplica, as que estiverem fora da zona afetada estarão disponíveis para leitura

  • Se a zona em que uma ou mais réplicas estiverem localizadas falhar, elas ficarão indisponíveis durante a falha da zona. Se houver uma falha em duas zonas e houver duas ou mais réplicas, a réplica com o menor atraso nas zonas restantes será promovida a principal. As réplicas restantes nas zonas não afetadas estão disponíveis para leitura.

Partição de rede

Uma partição de rede é um cenário em que os nós permanecem em execução, mas não alcançam todos os clientes, zonas ou outros nós. O Memorystore usa um sistema baseado em quórum para evitar que nós isolados veiculem gravações. No caso de uma partição de rede, qualquer principal em uma partição de minoria é rebaixado. A partição de maioria (se houver) escolhe um novo principal caso ainda não haja. As réplicas isoladas continuam veiculando leituras. No entanto, elas poderão acabar desatualizadas se não puderem ser sincronizadas com o novo principal.

Para determinar se a conexão está corrompida, monitore as métricas master_link_down_since_seconds e offset_diff para identificar nós isolados.

Esgotado

Às vezes, os recursos do Compute Engine necessários para o Memorystore não estão disponíveis em uma zona, o que causa um esgotamento. Se houver um esgotamento em uma região onde você está tentando provisionar uma instância, a operação de criação da instância falha.

Sincronização completa

Quando uma réplica fica muito atrás do principal, ela aciona uma sincronização completa que copia um snapshot inteiro do principal para uma réplica. No pior dos casos, essa operação pode levar de minutos a uma hora. Uma sincronização completa não causa uma falha na instância. No entanto, durante esse período, a réplica em que a sincronização completa não está disponível para leituras e o principal usa mais CPU e memória.

O endpoint principal retorna READONLY

Suas gravações no endpoint principal de uma instância do Memorystore para Redis com réplicas de leitura podem receber erros -READONLY You can't write against a read only replica. inesperadamente. Recomendamos fechar e recriar as conexões com a instância. Na maioria dos casos, reiniciar o aplicativo cliente pode atenuar o problema. Se essas opções não forem viáveis ou o comportamento persistir, entre em contato com a equipe de suporte do Google Cloud.

Como escalonar leituras com o endpoint de leitura

Graças às réplicas de leitura, os aplicativos são capazes de escalonar a leitura. Os aplicativos podem se conectar a réplicas de leitura por meio do endpoint de leitura.

Endpoint de leitura

O endpoint de leitura é um endereço IP a que o aplicativo se conecta. Ele balanceia a carga de conexões de maneira uniforme nas réplicas da instância. As conexões com a réplica de leitura podem enviar consultas de leitura, mas não gravar consultas. Cada instância de nível Standard com réplicas de leitura ativadas tem um endpoint de leitura. Para instruções sobre como visualizar o endpoint de leitura da instância, consulte Como visualizar informações de réplica de leitura para sua instância.

Comportamento do endpoint de leitura

  • O endpoint de leitura automaticamente distribui as conexões entre todas as réplicas disponíveis. As conexões não são direcionadas para o principal.
  • Uma réplica é considerada disponível enquanto puder exibir o tráfego do cliente. Isso não inclui os horários em que uma réplica passa por uma sincronização completa com o novo principal.
  • Uma réplica com um atraso alto de replicação continua veiculando o tráfego. Aplicativos com alto volume de gravação podem ler dados desatualizados de uma réplica com um alto número de gravações.
  • Se um nó de réplica se tornar o principal, as conexões com esse nó são encerradas e novas conexões são redirecionadas para um novo nó de réplica.
  • As conexões individuais do endpoint de leitura são voltadas à mesma réplica durante o ciclo de vida da conexão. Não há garantia de que conexões diferentes do mesmo host de cliente sejam voltadas ao mesmo nó de réplica.

Consistência de leitura

As réplicas de leitura são mantidas com a replicação assíncrona do OSS Redis nativo. Devido à natureza da replicação assíncrona, é possível que a réplica fique atrasada em relação ao principal. Aplicativos com gravações constantes que também estão lendo a réplica precisam tolerar leituras inconsistentes.

Se o aplicativo exige consistência de "leitura e gravação", recomendamos usar o endpoint principal para gravações e leituras. O uso do endpoint principal garante que as leituras sejam sempre direcionadas ao principal. Mesmo nesse caso, é possível que as leituras estejam desatualizadas após um failover.

Definir TTLs nas chaves do principal garante que as chaves expiradas não sejam lidas no principal ou na réplica. Isso ocorre porque o Redis garante que uma chave expirada não possa ser lida na réplica.

Comportamento da ativação de réplicas de leitura em uma instância atual

  • Ativar réplicas de leitura em uma instância atual do Redis é uma operação exclusiva, o que significa que não é possível executar outras modificações de instância de operação de atualização como parte da mesma operação que ativa as réplicas de leitura.

  • A ativação de réplicas de leitura em uma instância do Redis atual exige que você aloque um intervalo de endereços IP válido adicional de tamanho /28, independentemente do tamanho do intervalo de endereços IP atual alocado para o Memorystore para Redis.

    • Forneça o intervalo de IP adicional ao ativar réplicas de leitura para a instância do Redis. É possível escolher um intervalo específico ou deixar que o Memorystore selecione um automaticamente para você.

  • O endereço IP de leitura/gravação da instância não é alterado ao ativar réplicas de leitura. O endereço IP do endpoint de leitura está localizado no intervalo original alocado para a instância do Memorystore, e não no intervalo extra fornecido ao ativar as réplicas de leitura.

  • Para encontrar o novo endpoint de leitura, confira as informações das réplicas de leitura da sua instância após a conclusão da operação para ativar as réplicas de leitura.

Como redimensionar uma instância

É possível escalonar o número de réplicas de leitura da instância e também modificar o tamanho do nó:

Recomendamos escalonar a instância durante um período de baixo tráfego de leitura e gravação para minimizar o impacto no aplicativo.

Adicionar uma nova réplica resulta em carga extra no principal enquanto a réplica executa uma sincronização completa. Ao adicionar nós, as conexões atuais não são afetadas nem transferidas. Quando a nova réplica estiver disponível, ela começará a receber conexões do endpoint e veicular leituras. Remover uma réplica fecha todas as conexões ativas roteadas para essa réplica. O aplicativo cliente precisa ser configurado para se reconectar automaticamente ao endpoint de leitura e restabelecer as conexões com as réplicas restantes.

Práticas recomendadas

Gerenciamento de memória

O Redis não permite que as gravações do cliente excedam o limite maxmemory da instância. No entanto, a sobrecarga, como fragmentação, buffers de replicação e comandos caros, como EVAL, podem aumentar o uso da memória além para desse limite. Nesses casos, as gravações do Memorystore falham até que a pressão na memória seja reduzida. Consulte as Práticas recomendadas de gerenciamento de memória para saber mais.

Se o Memorystore estiver passando por uma operação BGSAVE devido a uma exportação ou replicação de sincronização completa e uma condição OOM ocorrer, o processo secundário será eliminado. Nesse caso, a operação BGSAVE falha e o servidor de nó do Redis permanece disponível.

Para garantir a replicação e a criação de snapshots em todas as circunstâncias, recomendamos manter o uso de memória inferior a 50% durante operações importantes, como exportação, escalonamento etc. É possível acionar manualmente a exportação ou o failover para ver o impacto nessas operações.

Gerenciamento de CPU

O Memorystore fornece métricas para o uso da CPU e a contagem de conexões de cada nó. Recomendamos alocar sobrecarga suficiente para que a perda de uma única zona de disponibilidade seja tolerada. A meta ideal pode variar de acordo com o número de réplicas e os padrões de uso, mas um bom ponto de partida é manter o uso da CPU da réplica abaixo de 50%.

Os nós individuais poderão ter uso elevado se os padrões do cliente não estiverem balanceados ou se as operações de failover resultarem em uma distribuição de conexão desbalanceada. Nesse caso, recomendamos fechar as conexões de tempos em tempos para permitir que o Memorystore reequilibre as conexões automaticamente. O Memorystore não reequilibra conexões abertas.

Gerenciamento de saldo de conexão

Sempre que as conexões de um nó forem fechadas, os clientes precisarão se reconectar, normalmente ativando a reconexão automática na biblioteca de cliente de sua escolha. Quando o nó é reintroduzido, as conexões atuais não são redirecionadas, mas as novas conexões são roteadas para o novo nó. Os clientes podem eliminar conexões periodicamente para garantir que estejam balanceados nos nós disponíveis.

Gerenciamento de atraso de replicação

É possível que as réplicas fiquem atrasadas, especialmente quando a taxa de gravação for muito alta. Nesses cenários, a réplica continua disponível para leitura. Nessas circunstâncias, as leituras da réplica podem estar desatualizadas e o aplicativo precisa ser capaz de lidar com isso. Caso contrário, a alta taxa de gravação precisa ser resolvida.

A seguir