Acerca das réplicas de leitura

O nível Standard do Memorystore for Redis permite dimensionar as consultas de leitura da sua aplicação através de réplicas de leitura. Esta página pressupõe que tem conhecimentos das diferentes capacidades do nível do Redis do Memorystore.

As réplicas de leitura permitem-lhe dimensionar a carga de trabalho de leitura consultando as réplicas. É fornecido um ponto final de leitura para facilitar a distribuição de consultas pelas réplicas por parte das aplicações. Para mais informações, consulte o artigo Dimensionar leituras com o ponto final de leitura.

Para instruções sobre como gerir uma instância do Redis com réplicas de leitura, consulte o artigo Gerir réplicas de leitura.

Exemplos de utilização de réplicas de leitura

A loja de sessões, a tabela de classificação, o motor de recomendações e outros exemplos de utilização requerem que a instância esteja altamente disponível. Para estes exemplos de utilização, existem muito mais leituras do que escritas, e estes exemplos de utilização geralmente conseguem tolerar algumas leituras desatualizadas. Em casos como estes, faz sentido tirar partido das réplicas de leitura para aumentar a disponibilidade e a escalabilidade da instância.

Ler comportamento da réplica

  • Por predefinição, as réplicas de leitura não estão ativadas em instâncias do nível padrão.
  • Depois de ativadas as réplicas de leitura numa instância, já não é possível desativá-las para essa instância.
  • As instâncias do nível padrão podem ter entre 1 e 5 réplicas de leitura.
  • O ponto final de leitura fornece um único ponto final para distribuir consultas pelos nós de réplica.
  • As réplicas de leitura são mantidas através da replicação assíncrona do Redis.

Advertências e limitações

  • As réplicas de leitura só são suportadas para tamanhos de instâncias com nós >= 5 GB.
  • As réplicas de leitura só podem ser ativadas em instâncias que usam a versão 5.0 ou superior do Redis.
  • Se designar uma zona e uma zona alternativa para o aprovisionamento de nós, o Memorystore usa essas zonas para o primeiro e o segundo nós na instância. Depois disso, o Memorystore seleciona as zonas para todos os nós restantes aprovisionados para a instância.
  • Tem de aprovisionar a instância com um intervalo de endereços IP CIDR de /28 ou superior. Os tamanhos de intervalos maiores, como /27 e /26, são válidos. Os intervalos mais pequenos, como /29, não são suportados para esta funcionalidade.

Arquitetura

Quando ativa as réplicas de leitura, especifica o número de réplicas que quer na instância. O Memorystore distribui automaticamente os nós primários e de réplica de leitura pelas zonas disponíveis numa região.

Cada instância tem um ponto final principal e um ponto final de leitura. O ponto final principal encaminha sempre o tráfego para o nó principal, enquanto o ponto final de leitura equilibra automaticamente a carga das consultas de leitura nas réplicas disponíveis.

O serviço de monitorização do estado de funcionamento do Memorystore for Redis monitoriza a instância e é responsável por detetar qualquer falha do nó principal, elege uma réplica como o novo principal e inicia uma comutação por falha automática para o novo principal.

Failovers para instâncias com réplicas de leitura

Quando um nó principal falha, o serviço de monitorização do estado do Memorystore inicia a comutação por falha e o novo nó principal fica disponível para leituras e escritas. Normalmente, a comutação por falha é concluída em menos de 30 segundos.

Quando ocorre uma comutação por falha, o ponto final principal redireciona automaticamente o tráfego para o novo principal. No entanto, todas as ligações de cliente ao ponto final principal são desligadas durante uma comutação por falha. As aplicações com lógica de nova tentativa de ligação voltam a estabelecer ligação automaticamente assim que o novo servidor principal estiver online. Algumas das ligações de cliente ao ponto final de leitura também sofrem desconexões da réplica de leitura que é promovida a principal durante a comutação por falha. As ligações às réplicas restantes continuam a ser servidas durante uma comutação por falha. Na nova tentativa, as ligações são redirecionadas para as novas réplicas.

Quando ocorre uma comutação por falha, devido à natureza assíncrona da replicação, as réplicas podem ter um atraso de replicação diferente. No entanto, o processo de comutação por falha faz o seu melhor para comutar por falha para a réplica com o menor atraso. Isto ajuda a minimizar a quantidade de perda de dados e a redução da taxa de transferência de leitura durante uma comutação por falha. O novo servidor principal promovido pode estar na mesma zona ou numa zona diferente do antigo servidor principal. É selecionada uma réplica para ser a nova principal se estiver na mesma zona que a antiga principal e tiver o menor atraso. Caso contrário, uma réplica de uma zona diferente pode tornar-se a nova principal.

Uma vez que a replicação é assíncrona, existe sempre a possibilidade de ler dados desatualizados durante uma ativação pós-falha. Além disso, enquanto o novo servidor principal está a ser promovido, podem perder-se algumas gravações na instância. As aplicações devem conseguir lidar com este comportamento.

O Redis faz todos os possíveis para evitar que as outras réplicas exijam uma sincronização completa durante a comutação por falha, mas pode acontecer em cenários raros. Uma sincronização completa pode demorar alguns minutos a uma hora, consoante a taxa de gravação e o tamanho do conjunto de dados que está a ser replicado. Durante este período, as réplicas que estão a passar por uma sincronização completa ficam indisponíveis para leituras. Assim que a sincronização estiver concluída, é possível aceder às réplicas para leituras.

Modos de falha para réplicas de leitura

As instâncias com réplicas de leitura podem deparar-se com várias falhas e condições não saudáveis que afetam a aplicação. O comportamento varia consoante a instância tenha uma réplica ou duas ou mais réplicas. Esta secção descreve alguns modos de falha comuns e o comportamento da instância durante estas condições.

A réplica está indisponível

  • Quando uma réplica falha por qualquer motivo, é marcada como indisponível e todas as ligações à réplica são terminadas após um determinado limite de tempo. Assim que a réplica for recuperada, as novas ligações são encaminhadas para a réplica restaurada. O tempo de recuperação de uma réplica varia consoante o modo de falha.

  • Em caso de rutura de stock ou falha de zona do Compute Engine, a réplica não é recuperada até a condição ser resolvida.

Falha da zona

  • Se a zona onde o servidor principal está localizado falhar, o servidor principal muda automaticamente para uma réplica noutra zona. Se a instância tiver apenas uma réplica, o ponto final de leitura fica indisponível durante a indisponibilidade da zona. Se a instância tiver mais do que uma réplica, as réplicas fora da zona afetada estão disponíveis para leituras

  • Se a zona onde se encontra uma ou mais réplicas falhar, essas réplicas ficam indisponíveis durante a falha da zona. Se ocorrer uma falha em duas zonas e existirem duas ou mais réplicas, a réplica com o menor atraso nas zonas restantes é promovida a principal. As réplicas restantes nas zonas não afetadas estão disponíveis para leituras.

Partição de rede

Uma partição de rede é um cenário em que os nós permanecem em execução, mas não conseguem alcançar todos os clientes, zonas ou nós de pares. O Memorystore usa um sistema baseado em quorum para impedir que nós isolados publiquem escritas. No caso de uma partição de rede, qualquer nó principal numa partição minoritária é rebaixado automaticamente. A partição maioritária (se existir) elege uma nova partição principal se ainda não tiver uma. As réplicas isoladas continuam a publicar leituras. No entanto, podem ficar desatualizados se não for possível sincronizá-los a partir do servidor principal.

Para determinar se o link está danificado, monitorize as métricas master_link_down_since_seconds e offset_diff para identificar nós isolados.

Esgotado

Ocasionalmente, os recursos do Compute Engine necessários para o Memorystore não estão disponíveis numa zona, o que leva a uma indisponibilidade. Se houver uma rutura de stock numa região onde tenta aprovisionar uma instância, a operação de criação da instância falha.

Sincronização completa

Quando uma réplica fica demasiado atrasada em relação à principal, aciona uma sincronização completa que copia uma imagem instantânea completa da principal para uma réplica. Esta operação pode demorar entre alguns minutos e uma hora, no pior dos casos. Uma sincronização completa não causa uma falha de instância. No entanto, durante este período, a réplica em sincronização completa não está disponível para leituras, e a instância principal regista uma utilização mais elevada da CPU e da memória.

O ponto final principal devolve READONLY

As suas gravações no ponto final principal de uma instância do Memorystore for Redis com réplicas de leitura podem receber inesperadamente erros -READONLY You can't write against a read only replica.. Recomendamos que feche e recrie as ligações à instância. Na maioria dos casos, reiniciar a aplicação cliente pode mitigar o problema. Se estas opções não forem viáveis ou o comportamento persistir, contacte a Google Cloud equipa de apoio técnico.

Dimensionar leituras com o ponto final de leitura

As réplicas de leitura permitem que as aplicações dimensionem as respetivas leituras lendo a partir das réplicas. As aplicações podem ligar-se a réplicas de leitura através do ponto final de leitura.

Ler ponto final

O ponto final de leitura é um endereço IP ao qual a sua aplicação se liga. Faz o balanceamento de carga das ligações de forma uniforme entre as réplicas na instância. As ligações à réplica de leitura podem enviar consultas de leitura, mas não consultas de escrita. Todas as instâncias de nível padrão com réplicas de leitura ativadas têm um ponto final de leitura. Para ver instruções sobre como ver o ponto final de leitura da sua instância, consulte o artigo Veja informações da réplica de leitura da sua instância.

Comportamento do ponto final de leitura

  • O ponto final de leitura distribui automaticamente as ligações por todas as réplicas disponíveis. As ligações não são direcionadas para o dispositivo principal.
  • Uma réplica é considerada disponível desde que consiga publicar tráfego de clientes. Não inclui os momentos em que uma réplica está a passar por uma sincronização completa com o respetivo principal.
  • Uma réplica com um atraso de replicação elevado continua a publicar tráfego. As aplicações com um elevado volume de escrita podem ler dados desatualizados de uma réplica que serve escritas elevadas.
  • No caso de um nó de réplica se tornar o principal, as ligações a esse nó são terminadas e as novas ligações são redirecionadas para um novo nó de réplica.
  • As ligações individuais ao ponto final de leitura segmentam a mesma réplica durante a duração da ligação. Não é garantido que diferentes ligações do mesmo anfitrião cliente sejam segmentadas para o mesmo nó de réplica.

Consistência de leitura

As réplicas de leitura são mantidas através da replicação assíncrona do Redis OSS nativo. Devido à natureza da replicação assíncrona, é possível que a réplica fique atrasada em relação à principal. As aplicações com escritas constantes que também leem a partir da réplica devem conseguir tolerar leituras inconsistentes.

Se a aplicação exigir consistência de "ler o que escreve", recomendamos que use o ponto final principal para escritas e leituras. A utilização do ponto final principal garante que as leituras são sempre direcionadas para o principal. Mesmo neste caso, é possível ter leituras desatualizadas após uma comutação por falha.

A definição de TTLs nas chaves na base de dados primária garante que as chaves expiradas não são lidas a partir da base de dados primária nem da réplica. Isto deve-se ao facto de o Redis garantir que não é possível ler uma chave expirada da réplica.

Comportamento da ativação de réplicas de leitura numa instância existente

  • A ativação de réplicas de leitura é uma operação exclusiva, o que significa que não pode fazer outras modificações de instâncias de operações de atualização como parte da mesma operação que ativa as réplicas de leitura.

  • A ativação de réplicas de leitura numa instância do Redis existente requer que atribua um intervalo de endereços IP secundários válido para o posicionamento de nós. Tem de ser um intervalo de Classless Inter-Domain Routing (CIDR) de tamanho /28, independentemente do tamanho do intervalo de endereços IP existente que está atribuído ao Memorystore para Redis.

    • Tem de fornecer o intervalo de IP adicional quando ativar as réplicas de leitura para a instância do Redis. Pode escolher um intervalo específico ou permitir que o Memorystore selecione automaticamente um para si.

  • O endereço IP de leitura/escrita da sua instância não se altera quando ativa as réplicas de leitura. O endereço IP do ponto final de leitura está localizado no intervalo original atribuído à sua instância do Memorystore e não no intervalo adicional que fornece quando ativa as réplicas de leitura.

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

Dimensionar uma instância

Pode dimensionar o número de réplicas de leitura para a sua instância e também pode modificar o tamanho do nó:

Recomendamos que dimensione a sua instância durante um período de tráfego de leitura e escrita baixo para minimizar o impacto na aplicação.

A adição de uma nova réplica resulta numa carga adicional na principal enquanto a réplica executa uma sincronização completa. Quando adiciona nós, as associações existentes não são afetadas nem transferidas. Assim que a nova réplica estiver disponível, começa a receber ligações do ponto final e a servir leituras. A remoção de uma réplica fecha todas as ligações ativas encaminhadas para essa réplica. A aplicação cliente deve ser configurada para se voltar a ligar automaticamente ao ponto final de leitura para restabelecer as ligações às réplicas restantes.

Práticas recomendadas

Gestão de memória

O Redis não permite que as escritas do cliente excedam o limite de maxmemory da instância. No entanto, a sobrecarga, como a fragmentação, os buffers de replicação e os comandos dispendiosos, como EVAL, podem aumentar a utilização de memória para além deste limite. Nestes casos, o Memorystore falha as gravações até que a pressão de memória seja reduzida. Consulte as práticas recomendadas de gestão de memória para mais detalhes.

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

Para garantir a replicação e a criação de instantâneos em todas as circunstâncias, recomendamos que mantenha a utilização de memória abaixo de 50% durante operações importantes, como a exportação, o dimensionamento, etc. Pode acionar manualmente a exportação ou a transferência de responsabilidade para ver o impacto no desempenho destas operações.

Gestão da CPU

O Memorystore fornece métricas sobre a utilização da CPU e a contagem de ligações para cada nó. Recomendamos que afete uma sobrecarga suficiente para que a perda de uma única zona de disponibilidade possa ser tolerada. O alvo ideal pode variar com base no número de réplicas e nos padrões de utilização, mas um bom ponto de partida é manter a utilização da CPU das réplicas abaixo de 50%.

Os nós individuais podem registar uma utilização elevada se os padrões de utilização do cliente forem desequilibrados ou se as operações de comutação por falha resultarem numa distribuição desequilibrada das ligações. Neste caso, recomendamos que feche periodicamente as ligações para permitir que o Memorystore reequilibre automaticamente as ligações. O Memorystore não reequilibra as ligações abertas.

Gestão do saldo da associação

Sempre que as ligações de um nó são fechadas, os clientes têm de voltar a estabelecer ligação, normalmente ativando a ligação automática na biblioteca de cliente da sua escolha. Quando o nó é reintroduzido, as ligações existentes não são reencaminhadas. No entanto, as novas ligações são encaminhadas para o novo nó. Os clientes podem terminar periodicamente as ligações para garantir que estão equilibradas entre os nós disponíveis.

Gestão do atraso de replicação

É possível que as réplicas fiquem atrasadas, especialmente quando a taxa de gravação é muito elevada. Nestes cenários, a réplica continua disponível para leituras. Nesta circunstância, as leituras da réplica podem estar desatualizadas e a aplicação deve conseguir processá-las ou a taxa de gravação elevada deve ser resolvida.

O que se segue?