Proteger seus dados usando a replicação zonal

Selecione uma versão da documentação:

Nesta página, descrevemos a arquitetura de referência da Disponibilidade Avançada do AlloyDB Omni, que oferece alta disponibilidade ao implantar uma ou mais réplicas de banco de dados na mesma região que protege contra falhas no nível do nó ou da zona.

Casos de uso

Essa arquitetura de referência de disponibilidade é adequada para os seguintes casos de uso:

  • Aplicativos essenciais para os negócios que exigem RTO e RPO mais baixos.
  • Você quer implantar uma réplica em outra zona ou nó que ofereça alta disponibilidade para seus bancos de dados e proteja contra falhas de instância, servidor e zona.
  • Você quer proteção contra erros do usuário e corrupção de dados (usando backups).

Como funciona a arquitetura de referência

A disponibilidade aprimorada complementa a disponibilidade padrão adicionando instâncias de réplica de leitura na região para permitir a alta disponibilidade (HA) que reduz o objetivo do tempo de recuperação (RTO). Essa abordagem também reduz o objetivo do ponto de recuperação (RPO) ao permitir o streaming de mudanças transacionais para a réplica.

A alta disponibilidade no AlloyDB Omni usa pelo menos duas instâncias de banco de dados. Uma instância funciona como o banco de dados principal, que oferece suporte a operações de leitura e gravação. As instâncias restantes servem como réplicas de leitura, operando em um modo somente leitura.

Veja a seguir conceitos importantes de alta disponibilidade:

  • Failover é o procedimento durante uma interrupção não planejada em que a instância principal falha ou fica indisponível, e a réplica em espera é ativada para assumir o modo principal (leitura e gravação). Esse processo é chamado de promoção. Normalmente, nesses cenários, quando o servidor ou banco de dados principal volta a ficar on-line, o banco de dados precisa ser recriado e, em seguida, atuar como um banco de dados em espera. Para garantir um alto tempo de atividade, existem mecanismos que automatizam os failovers.
  • Uma alternância, também conhecida como reversão de papel, é um procedimento usado para alternar os modos entre o banco de dados principal e um dos bancos de dados em espera, de modo que o principal se torne o em espera e o em espera se torne o principal. As alternâncias normalmente ocorrem de maneira controlada e podem ser iniciadas por vários motivos, por exemplo, para permitir o tempo de inatividade e a aplicação de patches no banco de dados principal anterior. As alternâncias normais precisam permitir uma futura reversão sem a necessidade de reinstanciar o novo modo de espera ou outros aspectos da configuração de replicação.

Opções de alta disponibilidade

Recomendamos que você tenha pelo menos dois bancos de dados em espera para que a perda de um banco de dados não afete a alta disponibilidade do cluster. Nesse modo, você tem pelo menos um par de alta disponibilidade no caso de um failover ou durante qualquer manutenção planejada de um nó.

Para planejar o tamanho e o formato da implantação do AlloyDB Omni, consulte Planejar a instalação do AlloyDB Omni em uma VM.

Balanceadores de carga

Outro mecanismo importante que ajuda a facilitar os procedimentos de alternância e failover é a presença de um balanceador de carga.

Alta disponibilidade

Os bancos de dados de réplica de leitura implantados em uma região oferecem alta disponibilidade se o banco de dados principal falhar. Quando ocorre uma falha no banco de dados principal, o banco de dados em espera é promovido para substituí-lo, e o aplicativo continua com pouca ou nenhuma interrupção.

Em geral, é recomendável realizar verificações anuais ou semestrais regulares na forma de alternâncias para garantir que todos os aplicativos que dependem desses bancos de dados ainda possam se conectar e responder em um período adequado.

A proteção no nível da zona pode ser alcançada usando qualquer tipo de implantação, colocando uma das réplicas de leitura em espera em uma zona de disponibilidade diferente do banco de dados principal.

Outro benefício de ter réplicas de leitura é a capacidade de transferir operações somente leitura para os bancos de dados em espera, que podem atuar como bancos de dados de relatórios usando dados atualizados. Essa abordagem reduz a carga e a sobrecarga na instância principal de leitura e gravação.

Backups e configuração de alta disponibilidade

As réplicas de leitura podem ser configuradas em várias zonas que oferecem alta disponibilidade. Embora forneçam RTO e RPO baixos, eles não protegem contra determinadas interrupções, como corrupção lógica de dados, como quedas acidentais de tabelas ou atualizações incorretas de dados. Portanto, é necessário fazer backups regulares, além da configuração de alta disponibilidade. Consulte a documentação sobre a arquitetura de disponibilidade padrão para mais detalhes.

A Figura 1 mostra uma configuração de alta disponibilidade recomendada com dois bancos de dados de espera de réplica de leitura em duas zonas de disponibilidade diferentes.

AlloyDB Omni com opções de backups e alta disponibilidade

Figura 1. AlloyDB Omni com opções de backups e alta disponibilidade.

Para proteger contra perda de dados se a instância principal falhar, é necessário configurar a replicação no modo síncrono. Embora esse método ofereça uma forte proteção de dados, ele pode afetar o desempenho do banco de dados principal, porque todos os commits precisam ser gravados no banco de dados principal e em todos os bancos de dados de espera sincronizados. Uma conexão de rede de baixa latência entre essas instâncias de banco de dados é crucial para essa configuração.

Implementação

Ao escolher uma arquitetura de referência de disponibilidade, considere as vantagens, as limitações e as alternativas a seguir.

Vantagens

  • Proteção contra falhas de instâncias.
  • Proteção contra falhas do servidor.
  • Protege contra falhas de zona.
  • O RTO é drasticamente reduzido em relação à disponibilidade padrão.

Limitações

  • Não há proteção extra para desastres regionais.
  • Possível impacto no desempenho da instância principal devido à replicação síncrona.
  • A configuração da transmissão do WAL do PostgreSQL no modo síncrono não causa perda de dados (RPO=0) durante a operação normal ou failovers típicos. No entanto, essa abordagem não protege contra perda de dados em situações específicas de falha dupla, como quando todas as instâncias em espera são perdidas ou ficam inacessíveis da primária, e isso é imediatamente seguido por uma reinicialização da primária.

Alternativas