A alta disponibilidade (HA) no AlloyDB para PostgreSQL mantém o banco de dados operacional e os dados acessíveis aos aplicativos cliente durante falhas zonais ou de instância. Ao contrário das instâncias zonais, que podem sofrer um tempo de inatividade prolongado durante uma interrupção, as instâncias de alta disponibilidade fazem failover automaticamente entre nós ativos e em espera em todas as zonas. Para configurar uma instância para alta disponibilidade, consulte Visualizar configurações de cluster e instância.
Instâncias primárias e secundárias
Uma instância primária do AlloyDB configurada com alta disponibilidade inclui um nó ativo e um nó de espera, que estão localizados em zonas diferentes. Para armazenamento, o AlloyDB usa um persistente de registro regional para armazenar registros prévios de escrita (WAL) do banco de dados e o serviço de Regional Storage 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 do AlloyDB primeiro grava o WAL no persistente de registros regional no nó ativo e, em seguida, transfere os registros de forma assíncrona para os servidores regionais de processamento de registros no AlloyDB, que materializam os registros em blocos de dados para armazenamento de longo prazo. Em seguida, o AlloyDB limpa os registros que foram 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 primária 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 ocorre perda de dados durante o failover devido às 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 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ó primário começa a disponibilizar dados, e as consultas do cliente são bem-sucedidas após uma reconexão.
- O AlloyDB recria um nó de espera na zona anteriormente ativa. Esse nó de espera fica pronto para futuros failovers.
Requisitos
Para que o AlloyDB permita o failover, a configuração precisa atender a estes requisitos:
- A instância primária precisa estar em um estado operacional normal (em oposição a um estado de execução ou manutenção).
- A zona e o nó de espera precisam estar íntegros.
Arquitetura de espera ativa
As instâncias do AlloyDB com o PostgreSQL 18 oferecem failover aprimorado usando o recurso de espera ativa.
Com o recurso de espera ativa, o AlloyDB executa o nó de espera como uma réplica. Durante o failover, essa réplica 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 replicação permite caches quentes, 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
hot standby incluído.
Fig. 3. Espera ativa.
Pools de leitura
As instâncias de 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 zona, um balanceador de carga regional roteia o tráfego para os nós íntegros restantes, garantindo que não haja inatividade para os clientes.
Os pools de leitura permanecem on-line durante um failover de instância principal. A replicação do WAL da instância principal é pausada temporariamente durante o failover e retomada automaticamente após a recuperação da instância principal.