Essa arquitetura de referência é mais adequada para os seguintes casos de uso:
- Você precisa de proteção regional além da proteção zonal para seus aplicativos essenciais.
Essa arquitetura de referência de disponibilidade incorpora réplicas de leitura na região para alta disponibilidade e em várias regiões para DR. Essa implantação multirregional protege contra interrupções significativas, incluindo falhas de energia generalizadas e desastres naturais em grande escala.
Considerações sobre a arquitetura de referência de disponibilidade
Ao avaliar essa arquitetura de referência de disponibilidade, considere os seguintes fatores:
- Latência e largura de banda da rede dentro e entre regiões
- Posicionamento geográfico de bancos de dados e servidores de aplicativos
- Estratégia para descarregar cargas de trabalho somente leitura para réplicas
- Implantar a alta disponibilidade na região remota de DR
O balanceamento de carga somente leitura pode ser necessário, especialmente se você usa servidores de aplicativos regionais, para que as solicitações sejam encaminhadas ao banco de dados mais próximo e a resposta seja mais rápida. Para mais informações, consulte Solicitar o roteamento para um balanceador de carga de aplicativo clássico multirregional.
Pode ser necessário o monitoramento extra para garantir que o atraso de replicação não comece a aumentar devido à carga de transação ou à capacidade da rede.
Para garantir que a DR seja bem-sucedida, faça testes completos de DR. É importante testar a funcionalidade e a capacidade de processamento do aplicativo se há conexões de rede de alta latência entre os servidores de aplicativos e o banco de dados.
Arquiteturas de alta disponibilidade na região e de DR entre regiões
A Figura 1 mostra uma configuração sugerida de alta disponibilidade e DR com três bancos de dados de espera de réplica de leitura em três zonas de disponibilidade e duas regiões.
Figura 1. AlloyDB Omni com opções de backups e alta disponibilidade entre regiões.
Como ilustrado na Figura 1, a replicação síncrona de transmissão para réplicas locais (na mesma região) oferece alta disponibilidade, enquanto a replicação assíncrona de transmissão para uma réplica remota geograficamente separada oferece proteção regional de recuperação de desastres. Em toda a configuração, apenas a instância primária pode realizar operações de leitura/gravação, enquanto as outras réplicas podem veicular consultas de leitura.
Configure a replicação do primário para as réplicas na região no modo síncrono, enquanto a replicação para as réplicas entre regiões será configurada no modo assíncrono para evitar que a latência afete o desempenho de gravação do primário. Em caso de falha regional, essa configuração pode resultar em um RPO diferente de zero. No entanto, essa configuração permite um RTO mais rápido em caso de falha. Isso acontece porque o banco de dados primário não precisa esperar a confirmação dos bancos de dados em espera remotos antes de fazer commit das transações.
É possível ter backups adicionais entre regiões que fazem backups dos bancos de dados de réplica de leitura e, assim, adicionar redundância aos backups feitos com base no banco de dados primário.
Backups de réplicas de leitura
Quando você usa implantações do Kubernetes, a implantação secundária na região alternativa é configurada automaticamente com backups adicionais. Ao usar implantações que não são do Kubernetes, é possível implantar backups para atender às necessidades da sua empresa. Considere o seguinte:
- Se o backup remoto estiver sujeito a falhas regionais, inicie backups extras nas regiões alternativas.
- Se você precisar de redundância de backup, faça backups regionais de réplicas de leitura.
Local da réplica de leitura para oferecer suporte à disponibilidade de várias zonas
Em implantações não Kubernetes, é possível escolher réplicas de leitura específicas para assumir a função de primário em caso de falha do primário. O operador do Kubernetes do AlloyDB Omni processa automaticamente o posicionamento de nós em zonas e em quais nós os pods devem ser implantados. Algumas opções de configuração que afetam o posicionamento, como afinidade de pod e tolerância, estão disponíveis na configuração do banco de dados usada para implantação com o operador do AlloyDB Omni.
Migração de uma arquitetura somente de alta disponibilidade para uma de alta disponibilidade e DR
Para implantações que não são do Kubernetes, crie um novo standby em uma nova região e adicione essa configuração à configuração do cluster do Patroni. Para implantações do Kubernetes, crie uma nova implantação regional do Kubernetes, chamada de cluster de banco de dados secundário, e ative a replicação entre data centers.
Implementação
Ao escolher uma arquitetura de referência de disponibilidade, tenha em mente os benefícios, as limitações e as opções a seguir.
Benefícios
- Proteção contra falhas zonais e de instâncias
- Proteção contra falhas regionais
- RTO reduzido quando o banco de dados sofre uma falha regional
Limitações
- É possível reduzir o RPO para recuperação regional com a replicação síncrona, mas essa abordagem causa latência adicional no desempenho das transações. Para DR e replicação em regiões remotas, recomendamos usar apenas a replicação assí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 de espera são perdidas ou ficam inacessíveis da primária, e isso é imediatamente seguido por uma reinicialização da primária.
Opções de proteção de dados
- A Arquitetura de Disponibilidade Padrão para opções de backup e recuperação.
- A Arquitetura de Disponibilidade Avançada para opções de alta disponibilidade.
A seguir
- Visão geral da arquitetura de referência de disponibilidade do AlloyDB Omni.
- Disponibilidade Padrão do AlloyDB Omni.
- Disponibilidade Avançada do AlloyDB Omni.
- Trabalhar com a replicação entre data centers.
- Solicitar o roteamento para um balanceador de carga de aplicativo clássico multirregional.