Vista geral da replicação entre regiões

Esta página apresenta uma vista geral da replicação entre regiões do AlloyDB for PostgreSQL.

A replicação entre regiões do AlloyDB permite-lhe criar clusters e instâncias secundárias a partir de um cluster principal para disponibilizar os recursos em diferentes regiões, no caso de uma indisponibilidade na região principal. Estes clusters e instâncias secundários funcionam como cópias dos recursos de cluster e instância primários.

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 numa região diferente da principal, que replica a partir do cluster principal de forma assíncrona. Em caso de falha de um cluster principal do AlloyDB, pode promover um cluster secundário a cluster principal.

    Pode criar até cinco clusters secundários para um cluster principal. Todos os clusters secundários são replicados a partir de um único cluster principal. Se promover um cluster secundário, este torna-se um cluster principal independente.

  • Instância secundária. Um líder só de leitura de um cluster secundário. É responsável por receber uma stream de replicação de um cluster principal. A stream de replicação atualiza o volume de armazenamento na região secundária com base no volume de armazenamento na região principal. Se um cluster secundário for promovido a cluster principal, a instância secundária torna-se a instância principal.

    Uma instância secundária pode ser básica (zonal) ou de alta disponibilidade (regional).

    O diagrama seguinte ilustra como funciona a replicação entre regiões:

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

Figura 1. Exemplo da arquitetura de replicação entre regiões do AlloyDB.

Vantagens

As vantagens da replicação entre regiões no AlloyDB incluem o seguinte:

  • Recuperação de desastres. Caso a região do cluster principal fique indisponível, pode promover recursos do AlloyDB noutra região para atender pedidos.

  • Tempo de inatividade reduzido. O suporte de alta disponibilidade (HA) em clusters secundários reduz o tempo de inatividade durante eventos de manutenção ou interrupções não planeadas.

  • Dados distribuídos geograficamente. A distribuição geográfica dos dados aproxima-os de si e diminui a latência de leitura.

  • Escalabilidade de leitura aumentada: cada réplica entre regiões (ou cluster secundário) pode suportar até 20 nós de leitura, o que lhe permite dimensionar ainda mais as suas leituras.

  • Alternância sem perda de dados. Para configurações de replicação entre regiões, o AlloyDB suporta a comutação entre a instância principal e a secundária sem perda de dados.

Trabalhe com a replicação entre regiões

Trabalhar com a replicação entre regiões do AlloyDB envolve as seguintes tarefas:

  • Crie um cluster secundário. Um cluster secundário é uma cópia atualizada continuamente do seu cluster principal do AlloyDB.

  • Veja um cluster secundário. Depois de criar um cluster secundário, pode ver os respetivos detalhes na página Clusters na Google Cloud consola.

  • Adicione instâncias do conjunto de leitura. Pode adicionar instâncias do conjunto de leitura a um cluster secundário. Se quiser dimensionar a capacidade de leitura horizontalmente, pode adicionar até 20 nós de leitura ao cluster secundário.

  • Promova um cluster secundário. Pode ler os dados de um cluster secundário, mas não pode escrever nele até o promover a um cluster primário autónomo com todas as funcionalidades. Quando promove um cluster secundário, a instância secundária do cluster também é promovida como uma instância principal com capacidades de leitura e escrita.

    O exemplo de utilização principal para promover um cluster secundário é a recuperação de desastres. Se ocorrer uma indisponibilidade regional na região do cluster principal, pode promover o cluster secundário a um cluster principal autónomo e retomar a publicação da sua aplicação.

  • Alternância sem perda de dados. A comutação permite-lhe inverter as funções do cluster principal e secundário sem perda de dados. Pode fazer uma comutação para testar a configuração de recuperação de desastres ou fazer a migração da sua carga de trabalho. Quando conclui a comutação, a direção da replicação é invertida.

    Se tiver vários clusters secundários, o cluster secundário que recebe o comando de comutação torna-se um cluster principal. O cluster principal anterior torna-se um cluster secundário, replicando a partir do novo cluster principal. Todos os outros clusters secundários passam a ser replicados a partir do novo cluster principal.

    Existem dois cenários comuns para mudar para o cluster secundário:

    • Exercícios de recuperação de desastres. Pode executar testes dos seus processos de recuperação de desastres mudando a sua aplicação para outra região sem perda de dados para simular uma indisponibilidade regional.
    • Migração regional. Realizar uma migração planeada dos recursos do AlloyDB da respetiva região principal para outra região. A comutação garante que o cluster secundário se torna um cluster principal com um objetivo de ponto de recuperação (RPO) de 0, o que garante que a migração não perde dados.
  • Configure cópias de segurança automáticas e contínuas. Por predefinição, o AlloyDB copia automaticamente as configurações de cópia de segurança automáticas e contínuas do cluster principal para um cluster secundário criado recentemente. Se quiser usar configurações de cópia de segurança diferentes para o cluster secundário, pode modificar a configuração de cópia de segurança quando criar um cluster secundário.

    Se o cluster principal usar a encriptação de chaves de encriptação geridas pelo cliente (CMEK) para as cópias de segurança, faça uma das seguintes ações quando criar um cluster secundário:

    • Forneça definições de encriptação CMEK para as cópias de segurança do cluster secundário.
    • Desative as cópias de segurança para o cluster secundário.

Para mais informações sobre a encriptação das suas cópias de segurança com CMEK, consulte o artigo Use CMEK

Pode modificar as definições de cópia de segurança automatizadas e contínuas para o cluster secundário após a respetiva criação.

O que se segue?