Proteger seus dados usando a replicação zonal

Selecione uma versão da documentação:

Esta página descreve a arquitetura de referência de disponibilidade avançada do AlloyDB Omni, que oferece alta disponibilidade implantando uma ou mais réplicas de banco de dados na mesma região, protegendo 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 zonais.
  • 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 avançada complementa a disponibilidade padrão adicionando instâncias de réplica de leitura na região para ativar 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 a transmissão 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, oferecendo suporte a operações de leitura e gravação. As instâncias restantes funcionam como réplicas de leitura, operando em um modo somente leitura.

Confira a seguir alguns conceitos importantes de HA:

  • 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 reconstruído e agir como um standby. Para oferecer alta disponibilidade, há mecanismos para tornar os failovers automáticos.
  • Uma alternância, também conhecida como reversão de função, é 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 vice-versa. As substituições geralmente acontecem de maneira controlada e gradual, e podem ser iniciadas por vários motivos, por exemplo, para permitir o tempo de inatividade e a correção do banco de dados primário anterior. As substituições suaves precisam permitir um futuro reversão sem precisar reinstanciar o novo standby ou outros aspectos da configuração de replicação.

Opções de alta disponibilidade

Para oferecer suporte à alta disponibilidade, é possível implantar o AlloyDB Omni das seguintes maneiras:

Observação: Patroni e HAProxy são ferramentas de terceiros não comerciais e compatíveis com o AlloyDB Omni.

Recomendamos que você tenha pelo menos dois bancos de dados em espera para que a perda de um deles não afete a alta disponibilidade do cluster. Nesse modo, você tem pelo menos um par de alta disponibilidade em caso de 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 tornar mais suaves os procedimentos de failover e substituição é a presença de um balanceador de carga. Para implantações que não são do Kubernetes, o software HAProxy oferece balanceamento de carga. O HAProxy oferece balanceamento de carga ao distribuir o tráfego de rede entre vários servidores. O HAProxy também mantém o estado de integridade dos servidores de back-end a que se conecta realizando verificações de integridade. Se um servidor falhar em uma verificação de integridade, o HAProxy vai parar de enviar tráfego para ele até que ele passe nas verificações de integridade novamente.

O operador do Kubernetes implanta o próprio balanceador de carga, que se comporta de maneira semelhante, criando um serviço para o banco de dados que aponta para o balanceador de carga para tornar isso transparente para o usuário.

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 primário, o banco de dados em espera é promovido para substituir o primário, e o aplicativo continua com pouco ou nenhum tempo de inatividade.

É recomendável fazer verificações regulares anuais ou semestrais na forma de failovers 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. Para isso, coloque 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 descarregar operações somente leitura para os bancos de dados de espera, que podem atuar como bancos de dados de relatórios usando dados atualizados. Essa abordagem reduz a carga e a sobrecarga na primária de leitura/gravação.

Configuração de backups e alta disponibilidade

As réplicas de leitura podem ser configuradas em várias zonas que oferecem alta disponibilidade. Embora ofereçam RTO e RPO baixos, eles não protegem contra determinadas interrupções, como corrupção lógica de dados, como exclusões acidentais de tabelas ou atualizações incorretas de dados. Portanto, backups regulares precisam ser feitos além da configuração de alta disponibilidade. Consulte a documentação da 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 réplica de leitura em espera 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 se proteger contra perda de dados em caso de falha da instância principal, é necessário configurar a replicação no modo síncrono. Embora esse método ofereça proteção de dados forte, 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.

Implantações de alta disponibilidade do Kubernetes

Para implantações do Kubernetes, usando algumas mudanças básicas de atributos e adições ao arquivo de implantação do AlloyDB Omni, é possível adicionar um standby de failover ou réplicas de leitura para permitir falhas no banco de dados principal. Um standby de failover e uma réplica somente leitura podem ser configurados, e o operador cuida do provisionamento e da publicação do serviço. O operador também automatiza muitos dos processos de alta disponibilidade, como a recriação de bancos de dados em espera após um failover e o uso dos mecanismos de recuperação integrados ao mecanismo do AlloyDB Omni Kubernetes.

Em uma implantação do Kubernetes, a disponibilidade da infraestrutura e dos aplicativos se beneficia de recursos integrados do Kubernetes que cuidam de falhas de nós e pods, incluindo:

Além da proteção integrada, o operador expõe os seguintes parâmetros para influenciar a detecção de um banco de dados principal ou de espera com falha:

  • healthcheckPeriodSeconds: o tempo entre as verificações de integridade. O padrão é 30 segundos.
  • autoFailoverTriggerThreshold: o número de verificações de integridade consecutivas com falha antes de iniciar o failover. o padrão é 3;

Para mais informações, consulte Gerenciar a alta disponibilidade no Kubernetes.

Implantações de alta disponibilidade que não são do Kubernetes

A implantação independente não Kubernetes é uma configuração manual que requer ferramentas de terceiros, que são mais complexas de configurar e manter do que a implantação do Kubernetes.

Ao usar uma implantação que não é do Kubernetes, há alguns parâmetros que afetam a detecção e a rapidez com que um failover ocorre depois que o primário fica indisponível. Confira a seguir um breve resumo desses parâmetros:

  • Ttl: o tempo máximo necessário para adquirir um bloqueio do banco de dados principal antes de iniciar um failover. O padrão é 30 segundos.
  • Loop_wait: o tempo de espera antes de verificar novamente. O padrão é 10 segundos.
  • Retry_timeout: o tempo limite antes de rebaixar a instância principal devido a uma falha de rede. O padrão é 10 segundos.

Para mais informações, consulte Arquitetura de alta disponibilidade do AlloyDB Omni para PostgreSQL.

Implementação

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

Vantagens

  • Protege contra falhas de instâncias.
  • Protege contra falhas no servidor.
  • Protege contra falhas de zona.
  • O RTO foi reduzido significativamente em relação à disponibilidade padrão.

Limitações

  • Sem proteção extra para desastres regionais.
  • Possível impacto no desempenho do principal devido à replicação síncrona.
  • A configuração do streaming 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 de espera são perdidas ou ficam inacessíveis da primária, e isso é imediatamente seguido por uma reinicialização da primária.

Alternativas

A seguir