Este documento oferece uma visão geral da configuração de alta disponibilidade (HA) para instâncias do AlloyDB para PostgreSQL. Para configurar uma nova instância de alta disponibilidade ou ativar a alta disponibilidade em uma instância atual, consulte Visualizar configurações de cluster e instância.
Uma configuração de alta disponibilidade garante a continuidade das operações mesmo após eventos de falha. Embora as instâncias zonais possam sofrer um tempo de inatividade prolongado durante eventos de falha, com a alta disponibilidade, seus dados permanecem disponíveis para aplicativos cliente.
Instâncias primárias e secundárias
Uma instância principal do AlloyDB configurada com alta disponibilidade inclui um nó ativo e um nó em espera, que estão localizados em zonas diferentes. Para armazenamento, o AlloyDB usa um persistente de registros regional para armazenar registros prévios de gravação (WAL) do banco de dados e o serviço de armazenamento regional do AlloyDB para armazenar blocos de dados. O endereço IP da instância roteia o tráfego para o nó ativo usando um balanceador de carga.
Ao processar gravações, o banco de dados AlloyDB primeiro grava o WAL no gravador de registros regional no nó ativo e, em seguida, de forma assíncrona transfere os registros para os servidores regionais de processamento de registros do AlloyDB, que materializam os registros em blocos de dados para armazenamento de longo prazo. Em seguida, o AlloyDB limpa os registros processados.
O diagrama a seguir mostra a arquitetura de alta disponibilidade.
Fig. 1. Arquitetura de alta disponibilidade.
Failover
Se o nó ativo ficar indisponível, o AlloyDB fará automaticamente o failover da instância principal para o nó em espera, que se tornará o novo nó ativo. O balanceador de carga reconhece o novo nó ativo e começa a rotear o tráfego para ele. Após um failover, o novo nó ativo permanece ativo mesmo depois que o nó original volta a ficar on-line. Não há perda de dados durante o failover devido a gravações síncronas de WAL no persistente de registros regional.
O diagrama a seguir mostra o fluxo de tráfego após o failover.
Fig. 2. Fluxo de tráfego após o failover.
Um failover ocorre na seguinte sequência de eventos:
- O nó ou a zona ativa falha. O sistema de monitoramento de integridade do AlloyDB verifica periodicamente se o nó ativo está íntegro. Se o sistema de monitoramento de integridade falhar em várias verificações, ele vai iniciar o failover. Essa detecção pode levar até 30 segundos.
- O banco de dados é iniciado no nó de espera e começa a aceitar conexões. Isso geralmente leva menos de 30 segundos.
- O nó de espera é promovido para principal. Usando o endereço IP estático da instância, o novo nó principal começa a veicular dados, e as consultas do cliente são bem-sucedidas após uma reconexão.
- O AlloyDB recria um nó de espera na zona ativa anterior. Esse nó de espera fica pronto para futuros failovers.
Requisitos
Para o AlloyDB permitir um failover, a configuração precisa atender a estes requisitos:
- A instância principal precisa estar em um estado operacional normal (não interrompida ou em manutenção).
- A zona e o nó de espera precisam estar íntegros.
Nova arquitetura
As instâncias do AlloyDB recém-criadas com o PostgreSQL 18 oferecem failover aprimorado usando uma réplica de leitura no nó de espera (nó de espera ativa).
O AlloyDB inclui uma réplica de leitura no nó de espera ativa. Durante o failover, essa réplica de leitura pode fazer a transição para um modo de leitura e gravação mais rápido, reduzindo o tempo de inatividade. Além disso, a réplica de leitura permite caches ativos, o que ajuda a garantir um desempenho de consulta consistente após o failover.
O diagrama a seguir mostra a arquitetura de alta disponibilidade com o standby
a quente incluído.
Figura 3. Espera ativa.
Pools de leitura
As instâncias do pool de leitura com dois ou mais nós são altamente disponíveis. Os nós são distribuídos uniformemente entre as zonas, criando resiliência a eventos de falha. Em caso de eventos de falha, como uma falha de nó ou de zona, um balanceador de carga regional encaminha o tráfego para os nós íntegros restantes, garantindo que não haja inatividade para seus clientes.
Os pools de leitura permanecem on-line durante um failover da instância principal. A replicação de WAL da instância principal é pausada temporariamente durante o failover e é retomada automaticamente após a recuperação da instância principal.
A seguir
- Fazer failover manual de uma instância principal ou secundária.
- Teste uma instância principal para alta disponibilidade.
- Reduzir custos usando instâncias básicas.