Proteja os seus dados através da replicação zonal

Selecione uma versão da documentação:

Esta página descreve a arquitetura de referência de disponibilidade melhorada do AlloyDB Omni, que oferece alta disponibilidade através da implementação de uma ou mais réplicas da base de dados na mesma região que protege contra falhas ao nível do nó ou da zona.

Exemplos de utilização

Esta arquitetura de referência de disponibilidade é adequada para os seguintes exemplos de utilização:

  • Aplicações críticas para a empresa que requerem um RTO e um RPO mais baixos.
  • Quer implementar uma réplica noutra zona ou nó que ofereça elevada disponibilidade para as suas bases de dados e proteja contra falhas de instâncias, servidores e zonas.
  • Quer proteção contra erros do utilizador e danos nos dados (através de cópias de segurança).

Como funciona a arquitetura de referência

A disponibilidade melhorada adiciona-se à disponibilidade padrão adicionando instâncias de réplica de leitura na região para ativar a alta disponibilidade (HA) que reduz o objetivo de tempo de recuperação (RTO). Esta abordagem também reduz o objetivo de ponto de recuperação (RPO) ao permitir a transmissão em fluxo de alterações transacionais para a réplica.

A alta disponibilidade no AlloyDB Omni usa, pelo menos, duas instâncias da base de dados. Uma instância funciona como a base de dados principal, suportando operações de leitura e escrita. As restantes instâncias funcionam como réplicas de leitura, operando num modo só de leitura.

Seguem-se conceitos importantes de HA:

  • A comutação por falha é o procedimento durante uma interrupção não planeada em que a instância principal falha ou fica indisponível, e a réplica em espera é ativada para assumir o modo principal (leitura/escrita). Este processo chama-se promoção. Normalmente, nestes cenários, quando o servidor ou a base de dados principal volta a ficar online, a base de dados tem de ser reconstruída e, em seguida, tem de atuar como um servidor em espera. Para oferecer um tempo de atividade elevado, existem mecanismos para tornar as comutações por falha automáticas.
  • Uma mudança, também conhecida como inversão de funções, é um procedimento usado para mudar os modos entre a base de dados principal e uma das bases de dados de reserva, de modo que a principal se torna a de reserva e a de reserva se torna a principal. As comutações ocorrem normalmente de forma controlada e gradual, e podem ser iniciadas por vários motivos, por exemplo, para permitir o tempo de inatividade e a aplicação de patches na antiga base de dados principal. As comutações suaves têm de permitir uma futura comutação de volta sem necessidade de voltar a instanciar a nova espera ou outros aspetos da configuração de replicação.

Opções de alta disponibilidade

Em implementações não Kubernetes, use o Patroni e o HAProxy. Para mais informações, consulte a arquitetura de alta disponibilidade do AlloyDB Omni para PostgreSQL.

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

Recomendamos que tenha, pelo menos, duas bases de dados em espera para que a perda de uma base de dados não afete a elevada disponibilidade do cluster. Nesse modo, tem, pelo menos, um par de HA em caso de comutação por falha ou durante qualquer manutenção planeada de um nó.

Para planear o tamanho e o formato da sua implementação do AlloyDB Omni, consulte o artigo Planeie a instalação do AlloyDB Omni numa VM.

Balanceadores de carga

Outro mecanismo importante que ajuda a simplificar os procedimentos de comutação e tolerância a falhas é a presença de um equilibrador de carga.

Para implementações não relacionadas com o Kubernetes, o software HAProxy oferece equilíbrio de carga. O HAProxy oferece o equilíbrio de carga através da distribuição do tráfego de rede por vários servidores. O HAProxy também mantém o estado de funcionamento dos servidores de back-end aos quais se liga através da realização de verificações de funcionamento. Se um servidor falhar numa verificação de estado, o HAProxy deixa de lhe enviar tráfego até voltar a passar nas verificações de estado.

Alta disponibilidade

As bases de dados de réplicas de leitura implementadas numa região oferecem alta disponibilidade se a base de dados principal falhar. Quando ocorre uma falha na base de dados principal, a base de dados de reserva é promovida para substituir a principal e a aplicação continua com pouca ou nenhuma indisponibilidade.

Geralmente, é uma boa prática realizar verificações anuais ou semestrais regulares sob a forma de comutações para garantir que todas as aplicações que dependem destas bases de dados continuam a conseguir estabelecer ligação e responder num período adequado.

A proteção ao nível da zona pode ser alcançada através de qualquer um dos tipos de implementação, colocando uma das réplicas de leitura em espera numa zona de disponibilidade diferente da base de dados principal.

Uma vantagem adicional de ter réplicas de leitura é a capacidade de transferir operações só de leitura para as bases de dados em espera, que podem atuar como bases de dados de relatórios com dados atualizados. Esta abordagem reduz a carga e a sobrecarga no primário de leitura/escrita.

Configuração de cópias de segurança e alta disponibilidade

As réplicas de leitura podem ser configuradas em várias zonas que oferecem elevada disponibilidade. Embora ofereçam um RTO e um RPO baixos, não protegem contra determinadas interrupções, como a corrupção lógica de dados, como eliminações acidentais de tabelas ou atualizações de dados incorretas. Por isso, devem ser feitas cópias de segurança regulares além da configuração de HA. Consulte a documentação sobre a arquitetura de disponibilidade padrão para ver detalhes.

A Figura 1 mostra uma configuração de HA recomendada com duas bases de dados de reserva de réplicas de leitura em duas zonas de disponibilidade diferentes.

AlloyDB Omni com opções de cópias de segurança e alta disponibilidade

Figura 1. AlloyDB Omni com opções de cópias de segurança e alta disponibilidade.

Para se proteger contra a perda de dados se a instância principal falhar, é necessário configurar a replicação no modo síncrono. Embora este método ofereça uma forte proteção de dados, pode afetar o desempenho da base de dados principal, uma vez que todas as confirmações têm de ser escritas na base de dados principal e em todas as bases de dados de reserva sincronizadas. Uma ligação de rede de baixa latência entre estas instâncias da base de dados é crucial para esta configuração.

Implementações de HA não Kubernetes

A implementação autónoma não baseada no Kubernetes é uma configuração manual que requer ferramentas de terceiros, que são mais complexas de configurar e manter do que a implementação do Kubernetes.

Quando usa uma implementação não Kubernetes, existem alguns parâmetros que afetam a forma como uma comutação por falha é detetada e a rapidez com que ocorre uma comutação por falha após a indisponibilidade do servidor principal. Segue-se um breve resumo desses parâmetros:

  • Ttl: o tempo máximo necessário para adquirir um bloqueio para a base de dados principal antes de iniciar uma comutação por falha. A predefinição são 30 segundos.
  • Loop_wait: o tempo de espera antes de verificar novamente. A predefinição é 10 segundos.
  • Retry_timeout: o limite de tempo antes de despromover a instância principal devido a uma falha de rede. A predefinição é 10 segundos.

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

Implementação

Quando escolhe uma arquitetura de referência de disponibilidade, tenha em atenção as seguintes vantagens, limitações e alternativas.

Vantagens

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

Limitações

  • Sem proteção adicional para desastres regionais.
  • Potencial impacto no desempenho do servidor principal devido à replicação síncrona.
  • A configuração da transmissão em fluxo WAL do PostgreSQL no modo síncrono oferece zero perda de dados (RPO=0) durante o funcionamento normal ou as comutações por falha típicas. No entanto, esta abordagem não protege contra a 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 a partir da instância principal, e isto é imediatamente seguido de um reinício da instância principal.

Alternativas

O que se segue?