Acerca da replicação entre regiões

Esta página apresenta uma vista geral da replicação entre regiões para o Memorystore for Redis Cluster.

Para ver instruções sobre como gerir a replicação entre regiões, consulte o artigo Trabalhe com a replicação entre regiões.

A replicação entre regiões permite-lhe criar clusters secundários a partir de um cluster principal para disponibilizar o seu 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 falhas regionais.

Os conceitos-chave nesta página incluem o seguinte:

  • Cluster principal. Um cluster de leitura/escrita numa única região.
  • Cluster secundário. Um cluster só de leitura que é replicado a partir do cluster principal de forma assíncrona. Para obter informações sobre a promoção e a desassociação de clusters secundários, consulte as tarefas detach e switchover que aparecem no artigo Como gerir a replicação entre regiões.
  • Nó replicador: um nó no fragmento do cluster principal que replica para um nó seguidor no cluster secundário. Qualquer nó principal ou de réplica no fragmento pode desempenhar a função de replicador.
  • Nós seguidor: nós no cluster secundário que replicam a partir de um nó replicador no cluster principal. Apenas os nós principais no cluster secundário podem ter a função de seguidor.
  • Número de fragmentos e atribuição de ranhuras: os clusters primários e secundários têm o mesmo número de fragmentos e atribuições de ranhuras.

Vantagens

As vantagens da replicação entre regiões no Memorystore for Redis Cluster incluem o seguinte:

  • Recuperação de desastres: se a região do cluster principal ficar indisponível, pode desanexar ou mudar para um cluster secundário noutra região para atender pedidos de leitura e escrita. Os clusters secundários atendem pedidos de leitura sem emitir um comando de comutação ou desanexação.
  • Dados distribuídos geograficamente: a distribuição geográfica dos dados aproxima-os de si e diminui a latência de leitura.
  • Equilíbrio de carga geográfico para tráfego de leitura: se ocorrerem ligações lentas ou sobrecarregadas numa região, pode encaminhar o tráfego para outra região.

Comportamento das funcionalidades

Esta secção explica o comportamento importante da funcionalidade de replicação entre regiões.

  • Dimensione a capacidade do cluster: quando dimensiona a capacidade do cluster principal, o Memorystore for Redis Cluster dimensiona automaticamente os clusters secundários para corresponderem ao cluster principal.
  • Dimensione a contagem de réplicas: pode dimensionar a contagem de réplicas para clusters primários e secundários de forma independente com base nas necessidades da sua carga de trabalho. As atualizações à contagem de réplicas são apenas locais e não são propagadas a outros clusters na coleção de clusters de replicação entre regiões.
  • Mudar durante uma potencial indisponibilidade: pode fazer uma mudança para promover um cluster secundário, mesmo que o cluster principal não esteja disponível devido a uma indisponibilidade. Quando a indisponibilidade é resolvida, o cluster principal indisponível torna-se um cluster secundário.
  • Crie clusters secundários online: quando adiciona um cluster secundário a um cluster principal, o cluster principal permanece online. Enquanto o Memorystore for Redis Cluster cria o cluster secundário, o cluster principal processa pedidos e replica dados.
  • Crie clusters secundários: pode ter até dois clusters secundários. Podem estar localizados na mesma região ou em regiões diferentes entre si. Não pode transformar um cluster existente num cluster secundário. Só pode adicionar novos clusters como clusters secundários.
  • Sincronizar definições: o Memorystore for Redis Cluster sincroniza automaticamente a maioria das definições do cluster entre clusters primários e secundários. Para mais informações sobre estas definições, consulte o artigo Definições de cluster.
  • Preços: o Memorystore for Redis Cluster cobra aos clientes que usam a replicação entre regiões por todos os clusters secundários que o Memorystore for Redis Cluster aprovisiona para a replicação entre regiões. Por cada nó e réplica que o Memorystore for Redis Cluster implementa no cluster secundário, é-lhe cobrado o mesmo valor que por qualquer outro cluster principal. Além disso, incorre em custos de rede pela transferência de dados entre clusters em regiões diferentes.
  • Fazer atualizações de manutenção: para garantir a compatibilidade com a replicação entre regiões, enquanto cria o cluster secundário, o cluster principal pode ser submetido a uma atualização de manutenção. Se o cluster principal não estiver a executar a versão do software necessária, esta atualização ocorre. O processo de atualização pode introduzir alguma latência adicional quando cria o cluster secundário. Para mais informações, consulte o artigo Acerca da manutenção.

Como gerir a replicação entre regiões

A replicação entre regiões envolve as seguintes tarefas:

  • Crie um cluster secundário: crie um cluster secundário que replique continuamente os dados do seu cluster principal.
  • Ver o cluster secundário: veja informações sobre o cluster secundário, incluindo o nome do cluster principal e o outro cluster secundário no grupo de replicação.

  • Desanexar clusters secundários: a desanexação de clusters secundários é uma operação na qual desvincula os clusters secundários do respetivo cluster principal. Isto torna-os clusters totalmente funcionais e independentes que permitem leituras e escritas. Após uma operação de desassociação, os clusters secundários deixam de replicar dados do cluster principal ao qual estavam associados anteriormente. Tanto o cluster principal original como os clusters recém-separados (antigos secundários) funcionam como clusters independentes sem relação entre si.

    Desassocia clusters secundários pelos seguintes motivos:

    • Migração regional: execute uma migração planeada de recursos do Memorystore for Redis Cluster da respetiva região principal para outra região.
    • Recuperação de desastres: ative os recursos do Memorystore for Redis Cluster numa região secundária rapidamente se os recursos na região principal ficarem indisponíveis. Se os clusters secundários não estiverem totalmente sincronizados com o cluster principal, pode ocorrer alguma perda de dados.

  • Mude os seus clusters: faça uma mudança para inverter as funções dos clusters principal e secundário. Pode fazer uma comutação por um dos seguintes motivos:

    • Teste a configuração de recuperação de desastres
    • Mude durante um cenário de recuperação de desastres real
    • Faça uma migração da sua carga de trabalho

    Depois de concluir a comutação, o Memorystore for Redis Cluster inverte a direção da replicação. O antigo cluster secundário pode agora aceitar leituras e escritas, enquanto o antigo cluster principal muda para só de leitura.

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

Este diagrama mostra um cluster principal na região us-east1 e clusters secundários nas regiões us-west1 e asia-east1. A direção da replicação é sempre do cluster principal para os clusters secundários (para este exemplo, da região us-east1 para as outras regiões).

Embora este diagrama mostre o mesmo número de réplicas em todas as regiões, a replicação entre regiões permite ter um número variável de réplicas de acordo com os seus requisitos.

imagem

Definições do cluster

Esta secção explica as definições necessárias, copiadas e substituídas para clusters primários e secundários que usam a replicação entre regiões. Também explica as definições que configura no cluster principal e as definições que configura localmente.

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

Para criar um cluster secundário, tem de definir valores para os seguintes parâmetros:

  • Google Cloud project: o projeto onde o cluster principal está localizado e onde cria o cluster secundário.
  • Região: a região onde quer que o cluster secundário esteja localizado.
  • Configuração do Private Service Connect: a configuração de rede para o cluster secundário.
  • Cluster principal: quando cria o cluster secundário, tem de indicar um cluster principal. Pode usar qualquer cluster que não seja um cluster secundário como cluster principal. Se não tiver um cluster principal, crie-o.

Definições que um cluster secundário copia do cluster principal

Quando cria um cluster secundário, este cluster copia as seguintes definições do cluster principal:

Substitua as predefinições

Quando cria um cluster secundário, pode usar as seguintes definições para substituir as predefinições:

Atualize as definições do cluster

Quando atualiza as definições do cluster no Memorystore for Redis Cluster, só pode alterar algumas definições no cluster principal. O Memorystore for Redis Cluster sincroniza automaticamente estas alterações com os clusters secundários.

Pode alterar outras definições nos clusters principal e secundário de forma independente. O Memorystore for Redis Cluster aplica estas alterações apenas localmente e não as sincroniza com os outros clusters.

Configure as definições no cluster principal

Tem de alterar as seguintes definições no cluster principal. O Memorystore for Redis Cluster sincroniza automaticamente estas alterações com os clusters secundários.

Configure as definições locais

Pode configurar as seguintes definições localmente:

Práticas recomendadas para alternar clusters principais e secundários

Quando efetua uma comutação, recomendamos que siga as instruções nesta secção. Desta forma, a sua aplicação pode acompanhar as escritas e enviar todas as escritas para o cluster adequado.

  1. Impedir que a sua aplicação escreva no cluster principal.

  2. Se existirem vários clusters secundários para promover, determine o cluster secundário que quer promover para o cluster principal. Os seguintes fatores podem ajudar a determinar que cluster secundário promover:

    • A proximidade da sua aplicação ao cluster. Isto pode afetar a latência de escrita.
    • O cluster secundário mais atualizado em termos de dados.
    • O cluster secundário mais próximo do cluster principal, em termos de definições.

  3. Faça uma comutação no cluster secundário.

  4. Aguarde pela conclusão da operação de comutação.

  5. Atualize a sua aplicação para enviar todas as gravações para o cluster recém-promovido que selecionou no passo 2.