Sobre a replicação entre regiões

Nesta página, apresentamos uma visão geral da replicação entre regiões do Memorystore para Redis Cluster.

Para instruções sobre como gerenciar a replicação entre regiões, consulte Trabalhar com a replicação entre regiões.

Com a replicação entre regiões, é possível criar clusters secundários de um cluster principal para disponibilizar o cluster para leituras em diferentes regiões. Os clusters secundários também oferecem redundância para cenários de recuperação de desastres em caso de interrupções regionais.

Os principais conceitos desta página incluem:

  • Cluster principal. Um cluster de leitura/gravação em uma única região.
  • Clusters secundários. Um cluster secundário é um cluster somente leitura que replica de forma assíncrona do cluster principal. Para informações sobre como promover e separar secundárias, consulte as seções failover e separar de Como trabalhar com a replicação entre regiões.
  • Nó replicador. Um nó no fragmento do cluster principal que é replicado para um nó seguidor no cluster secundário. Qualquer nó principal ou de réplica no shard pode servir como replicador.
  • Nós seguidores. Nós no cluster secundário que replicam de um nó replicador no cluster principal. Somente os nós principais no cluster secundário podem ter a função de seguidor.
  • Contagem de fragmentos e atribuição de slots. Os clusters principal e secundário têm o mesmo número de fragmentos e atribuições de slots.

Vantagens

Confira os benefícios da replicação entre regiões no Memorystore for Redis Cluster:

  • Recuperação de desastres. Se a região do cluster principal ficar indisponível, será possível fazer failover ou separar um cluster secundário em outra região para atender às solicitações de leitura e gravação. Os clusters secundários estão sempre prontos para atender solicitações de leitura sem emitir um comando de failover ou remoção.
  • Dados distribuídos geograficamente. Distribuir os dados geograficamente os aproxima de você e diminui a latência de leitura.
  • Balanceamento de carga geográfico para tráfego de leitura. No caso de conexões lentas ou sobrecarregadas em uma região, é possível rotear o tráfego para outra.

Funcionamento do recurso

Esta seção explica um comportamento importante da replicação entre regiões que você precisa conhecer.

  • Escalonamento da capacidade da instância. Quando você escalona a capacidade da instância do cluster principal, os clusters secundários são escalonados automaticamente para corresponder ao principal.
  • Escalonando a contagem de réplicas. É possível escalonar a contagem de réplicas para clusters principais e secundários de forma independente com base nas necessidades da carga de trabalho. As atualizações na contagem de réplicas são locais e não são propagadas para outros clusters na coleção de clusters de replicação entre regiões.
  • Failover durante uma possível interrupção. É possível fazer uma troca para promover um cluster secundário, mesmo que o cluster principal esteja indisponível devido a uma interrupção. Nesse cenário, o cluster principal indisponível acaba se tornando um cluster secundário quando a interrupção é resolvida.
  • Criação de cluster secundário on-line. Ao adicionar um cluster secundário a um principal, o cluster principal permanece on-line. A principal atende às solicitações enquanto a secundária é criada e replica dados.
  • Clusters secundários. Você pode ter até dois secundários. Eles podem estar localizados em todas as regiões disponíveis. Se quiser, eles podem estar em regiões diferentes. Não é possível transformar um cluster atual em um cluster secundário. Somente novos clusters podem ser adicionados como secundários a um cluster existente.
  • Configurações sincronizadas. A maioria das configurações é sincronizada automaticamente entre os clusters principal e secundário. Para mais informações sobre essas configurações, consulte Configurações do cluster.
  • Preços. Os clientes que usam a replicação entre regiões vão receber cobranças por todos os clusters secundários provisionados para essa replicação. Para cada nó e réplica implantados no cluster secundário, os clientes vão receber cobranças como em qualquer outro cluster principal. Além disso, os clientes geram taxas de rede para transferência de dados entre clusters em regiões diferentes.
  • Atualização de manutenção. Para garantir a compatibilidade com a replicação entre regiões, ao criar o cluster secundário, o cluster principal pode passar por uma atualização de manutenção se ainda não estiver executando a versão de software necessária. Esse processo de atualização pode gerar mais latência ao criar o cluster secundário. Para mais informações sobre manutenção, consulte Sobre a manutenção.

Como trabalhar com a replicação entre regiões

Trabalhar com a replicação entre regiões do Memorystore for Redis Cluster envolve as seguintes tarefas:

  • Crie um cluster secundário. Você cria um cluster secundário que replica continuamente do cluster principal.
  • Ver um cluster secundário. É possível conferir informações sobre um cluster secundário, incluindo o nome do cluster principal e o outro cluster secundário no grupo de replicação.

  • Remova os clusters secundários. A remoção de clusters secundários é uma operação em que você os desconecta do cluster principal. Isso os torna clusters independentes e totalmente funcionais que permitem leituras e gravações. Depois de uma operação de remoção, os clusters secundários não replicam mais os dados do cluster principal a que estavam associados. O cluster principal original e os clusters recém-desconectados (antigos secundários) funcionam como clusters independentes sem relação entre si.

    Há dois cenários principais para desvincular clusters secundários:

    • Migração regional. Faça uma migração planejada dos recursos do Memorystore for Redis Cluster da região principal para outra região.
    • Recuperação de desastres. Ative rapidamente os recursos do Memorystore para Redis Cluster em uma região secundária caso os recursos na região principal fiquem indisponíveis. Se os clusters secundários não estiverem totalmente atualizados com o cluster principal, poderá ocorrer perda de dados.

  • Troque os clusters. Com uma alternância, é possível inverter as funções dos clusters principal e secundário. É possível fazer uma alternância para testar a configuração de recuperação de desastres, durante um cenário real de recuperação de desastres ou para migrar sua carga de trabalho. Quando você conclui a alternância, a direção da replicação é invertida, e o cluster secundário antigo pode aceitar leituras e gravações, enquanto o cluster principal antigo muda para somente leitura.

Exemplo de arquitetura de replicação entre regiões

O diagrama a seguir mostra um cluster principal na região us-east1 com clusters secundários em us-west1 e asia-east1. A direção da replicação é sempre de us-east1 para as outras regiões. Embora o diagrama a seguir mostre o mesmo número de réplicas em todas as regiões, o recurso de replicação entre regiões oferece a flexibilidade de ter números variados de réplicas de acordo com seus requisitos.

imagem

Configurações de cluster

Esta seção explica quais configurações são necessárias, copiadas e substituídas para clusters primários e secundários que usam a replicação entre regiões. Ele também explica quais configurações são definidas no primário e quais são definidas localmente.

Parâmetros obrigatórios para criar um cluster secundário

  • Projeto do Google Cloud. Esse é o projeto em que o cluster principal está localizado e onde o cluster secundário será criado.
  • Região. É a região em que você quer colocar o cluster secundário.
  • Configuração do Private Service Connect. Esta é a configuração de rede do cluster.
  • Cluster principal. É necessário indicar um cluster principal para o secundário ao criar o secundário. Qualquer cluster que não seja secundário pode ser usado como principal. Se você não tiver um cluster principal, crie um primeiro.

Configurações copiadas da instância principal durante a criação

Durante a criação do cluster secundário, ele copia as seguintes configurações do cluster principal:

Substituição permitida durante a criação da instância

As configurações a seguir permitem substituir o padrão durante a criação da instância.

Atualizar as configurações do cluster

Ao atualizar as configurações do cluster, algumas só podem ser alteradas no principal, e as mudanças são sincronizadas automaticamente com os clusters secundários eventualmente. Outras configurações podem ser alteradas de forma independente nos clusters principal e secundário, e elas são aplicadas apenas localmente, não sendo sincronizadas com os outros clusters.

Definir como principal

As seguintes configurações precisam ser alteradas no primário, e a atualização é sincronizada com o secundário:

Definido localmente

Você configura essas opções localmente:

Práticas recomendadas para failover

Ao fazer uma troca, recomendamos seguir as instruções desta seção para que seu aplicativo possa acompanhar as gravações e enviá-las para o cluster apropriado.

  1. Interrompa a gravação do aplicativo no cluster principal.

  2. Determine o cluster secundário a ser promovido (se houver vários secundários para escolher). Alguns fatores que podem ajudar a determinar qual secundário promover são:

    • A proximidade do seu aplicativo com o cluster. Isso pode afetar a latência de gravação.

    • O cluster mais atualizado em termos de dados.

    • O cluster mais próximo em termos de configurações dos clusters principais.

  3. Faça uma troca no cluster secundário.

  4. Aguarde a conclusão da operação de failover.

  5. Atualize o aplicativo para enviar as gravações ao cluster promovido escolhido na etapa 2.