O AlloyDB Hot Standby transforma a arquitetura de alta disponibilidade do banco de dados gerenciado PostgreSQL da Google Cloud, reduzindo o tempo de failover e eliminando a degradação de performance pós-falha. Para empresas brasileiras que operam cargas críticas e precisam de resiliência sem comprometer a experiência do usuário, essa atualização representa um avanço direto em RTO e consistência operacional — tudo sem custo adicional.
Como funciona a arquitetura de HA do AlloyDB?
Uma instância primária do AlloyDB configurada para alta disponibilidade consiste em um nó ativo e um nó standby, localizados em zonas diferentes dentro de uma região para resiliência. A arquitetura cloud-native separa compute e storage, permitindo escalonamento independente de cada recurso. Os logs WAL (write-ahead logs) do banco são gravados de forma síncrona em um persistor regional de logs, garantindo durabilidade, enquanto os blocos de dados residem no serviço regional de storage do AlloyDB. Um load balancer direciona o tráfego para o nó ativo atual usando um endereço IP estável.
No modelo tradicional de HA, se o nó ativo ficasse indisponível, o AlloyDB iniciava automaticamente um failover. O nó standby, anteriormente ocioso do ponto de vista do PostgreSQL, precisava iniciar o banco, processar logs pendentes e então assumir. Embora isso garanta alta disponibilidade, o tempo de inicialização e o subsequente aquecimento de cache (cache warming) impactavam o tempo de recuperação da aplicação e a performance.
Como o Hot Standby muda o jogo?
Com a nova capacidade Hot Standby, a função do nó standby foi transformada: em vez de passivo, ele agora aplica continuamente os registros WAL transmitidos pelo primário. Essa mudança arquitetural traz duas vantagens massivas:
-
Redução drástica no tempo de failover: como o PostgreSQL já está rodando, inicializado e replicando ativamente no standby, o tempo necessário para promovê-lo a primário em caso de falha é significativamente menor. O sistema detecta a falha (tipicamente em 30 segundos), promove o standby e redireciona as conexões. A fase de startup do banco é eliminada, reduzindo o downtime total e melhorando o RTO.
-
Performance consistente após o failover: como o nó Hot Standby está reproduzindo logs ativamente, seus caches de memória (como o buffer cache do PostgreSQL) permanecem "aquecidos" — contêm boa parte dos dados frequentemente acessados pelo nó primário. Quando ocorre o failover, o novo primário pode atender requisições em velocidade ideal quase imediatamente, evitando o "brownout" de performance típico durante o aquecimento de caches a partir do disco.
E a melhor parte? Essa melhoria substancial em disponibilidade e resiliência vem sem custo adicional para você.
Hot Standby em ação: o que demonstra o teste?
O Google Cloud preparou uma demonstração curta para ilustrar a diferença entre o novo Hot Standby e o modelo de HA legado. No vídeo, um benchmark é executado em duas instâncias AlloyDB e um failover é disparado simultaneamente em ambas.
Como mostrado:
- A instância com Hot Standby completa o failover em aproximadamente 15 segundos. A taxa de transações por segundo (TPS) retorna aos níveis pré-falha quase imediatamente.
- A instância com HA Legado leva visivelmente mais tempo para concluir o failover. Mesmo quando volta a ficar online, o TPS é significativamente menor e leva vários minutos para retornar ao nível original, enquanto os caches aquecem.
Essa comparação lado a lado deixa claro os benefícios do Hot Standby em minimizar o downtime e eliminar o impacto de performance pós-failover.
Como começar com o HA aprimorado?
O Hot Standby está sendo disponibilizado para novas instâncias AlloyDB criadas com PostgreSQL 18, proporcionando uma experiência de HA atualizada automaticamente, e será estendido para versões anteriores nos próximos meses. Você pode continuar contando com o SLA de 99,99% do AlloyDB, agora suportado por failovers ainda mais rápidos e performance pós-failover mais previsível.
Essa melhoria reforça o compromisso em oferecer uma experiência gerenciada PostgreSQL de nível empresarial.
Para saber mais sobre os recursos de alta disponibilidade do AlloyDB, consulte a documentação oficial. Novo no AlloyDB? Experimente hoje mesmo!
Perguntas Frequentes
-
Como o Hot Standby reduz o tempo de failover em comparação com a arquitetura tradicional?
- No modelo anterior, o nó standby ficava ocioso e precisava iniciar o banco de dados, processar logs e aquecer o cache durante o failover. Com o Hot Standby, o PostgreSQL já está rodando e replicando ativamente, então a promoção para primário é quase instantânea — o sistema detecta a falha em ~30s e conclui a troca em cerca de 15s.
-
O Hot Standby afeta o SLA de 99,99% do AlloyDB?
- Não. O SLA permanece o mesmo de 99,99%, mas agora é suportado por failovers mais rápidos e performance pós-falha mais previsível. Isso melhora o RTO (Recovery Time Objective) e reduz o impacto na experiência do usuário final.
-
Essa funcionalidade tem custo adicional?
- Não. O Google Cloud afirma explicitamente que o Hot Standby é fornecido sem custo extra para os clientes. A melhoria na arquitetura de alta disponibilidade já está incluída no valor do serviço gerenciado AlloyDB.
-
Quando o Hot Standby estará disponível para instâncias existentes?
- A funcionalidade está sendo disponibilizada inicialmente para novas instâncias criadas com PostgreSQL 18. Para versões anteriores, o rollout ocorrerá nos próximos meses, conforme mencionado no anúncio original.
-
O que acontece com a performance da aplicação durante o failover no Hot Standby?
- Como o nó standby mantém os caches (buffer cache do PostgreSQL) aquecidos ao aplicar continuamente os logs WAL, após a promoção a taxa de transações por segundo (TPS) retorna aos níveis pré-falha quase imediatamente. Isso evita o 'brownout' de performance típico de caches frios.
Artigo originalmente publicado por Ramkumar VadaliEngineering Manager em Cloud Blog.
