Pontos-Chave de HA & Failover

Alta disponibilidade para PostgreSQL não é um único botão que você aperta, é um sistema montado a partir de replicação, um orquestrador que detecta falhas e elege um novo líder, e roteamento que redireciona clientes para qualquer nó que esteja atualmente como primário.

Failover é o que acontece quando esse sistema decide que o primário se foi e promove um standby em seu lugar, e a velocidade e segurança dessa decisão é o que separa um breve lapso de uma interrupção real.

Esta página constrói o modelo mental por trás desse sistema antes que as páginas mais procedurais desta seção detalhem a configuração do Patroni, a configuração do proxy e o fencing.

Resumo

• HA combina um standby replicado, um orquestrador baseado em consenso e roteamento voltado para o cliente, de modo que uma falha do primário resulte em promoção automática e segura em vez de intervenção manual.
• Por que Importa: Sem as três camadas trabalhando juntas, um standby saudável ainda significa uma recuperação manual, propensa a erros e lenta.
• Conceitos-Chave: DCS (distributed configuration store - armazenamento distribuído de configuração), quorum, eleição de líder, fencing, STONITH, RTO/RPO.
• Quando Usar: Qualquer banco de dados de produção onde uma interrupção do primário de mais de alguns minutos tenha custo real para o negócio.
• Limitações / Trade-offs: Failover automático troca algum risco de uma promoção incorreta ou prematura por uma grande redução no tempo médio de recuperação.
• Tópicos Relacionados: replicação de streaming, Patroni e etcd/Consul, prevenção de split-brain, proxies de conexão.

Fundamentos

Alta disponibilidade neste contexto significa que o sistema continua servindo leituras e escritas dentro de uma janela de recuperação acordada, mesmo após a falha do nó primário do PostgreSQL.

Essa janela tem dois nomes que valem a pena conhecer precisamente: RTO, o objetivo de tempo de recuperação ou quanto tempo uma interrupção é permitida durar, e RPO, o objetivo de ponto de recuperação ou quanta perda de dados recentes é aceitável.

Um standby sozinho não entrega HA, pois um standby que requer que um humano perceba a interrupção, verifique se o standby está atualizado e o promova manualmente pode levar mais tempo para recuperar do que o RTO que um negócio realmente precisa.

Failover automatiza essa tomada de decisão: um orquestrador monitora continuamente a saúde do primário, e quando decide que o primário realmente se foi, ele promove o standby mais atualizado e saudável sem esperar por uma pessoa.

Um switchover é o primo planejado do failover, uma mudança de líder deliberada e orquestrada usada para manutenção, onde o primário de saída coopera na entrega em vez de simplesmente desaparecer.

As decisões do orquestrador precisam ser confiáveis sob partições de rede, e é por isso que HA de PostgreSQL em produção depende de um armazenamento distribuído de configuração (DCS) como etcd ou Consul, em vez de o orquestrador decidir sozinho.

Uma analogia útil é um grupo de bombeiros concordando por votação via rádio sobre quem lidera uma operação, em vez de cada um decidir independentemente que está no comando, pois um único nó adivinhando "o primário deve estar inativo" de sua própria visão limitada é exatamente como dois primários acabam ativos ao mesmo tempo.

Mecânicas & Interações

O DCS fornece quorum, um mecanismo de votação onde a maioria dos nós do DCS deve concordar antes que uma decisão de liderança, como promover um novo primário, seja considerada válida.

Um orquestrador como o Patroni 3.x detém um lease (concessão) com tempo limitado no DCS representando "Eu sou o líder atual", e ele deve renovar continuamente esse lease ou perder a liderança automaticamente.

Se a instância Patroni do primário não conseguir alcançar o DCS, seu lease expira, e qualquer réplica alcançável pelo quorum sobrevivente do DCS pode ser eleita como o novo líder, tudo sem um humano no circuito.

É aqui que o split brain, dois nós acreditando cada um que são o primário, se torna um risco real em vez de um risco teórico, pois um primário que está apenas isolado da rede do DCS ainda pode estar em execução e aceitando escritas, mesmo enquanto um novo líder é eleito em outro lugar.

Fencing é o conjunto de técnicas que garantem que o antigo primário pare genuinamente de aceitar escritas antes ou imediatamente após um novo assumir, variando de um watchdog de software que mata o processo local do PostgreSQL a STONITH em nível de hardware que desliga ou isola o nó da rede completamente.

-- Qualquer nó promovido deve responder false; um primário antigo remanescente
-- respondendo false também é o sinal de split-brain que os operadores observam durante os treinos
SELECT pg_is_in_recovery();

Uma vez que um novo líder é escolhido, o roteamento tem que acompanhar: as aplicações devem parar de enviar escritas para o antigo primário e começar a enviá-las para o novo, que é o trabalho de uma camada de proxy como HAProxy ou uma verificação de integridade ciente do Patroni, em vez do próprio banco de dados.

Pools de conexão adicionam sua própria complicação aqui, pois um pooler como PgBouncer mantendo conexões abertas para um nó agora demovido continuará roteando tráfego para lá até que suas próprias verificações de integridade ou uma reconexão forçada acompanhem a nova topologia.

Clientes ficam no final desta cadeia, e mesmo um failover perfeitamente executado produz uma breve janela de reinícios de conexão, e é por isso que retentativas em nível de aplicação com backoff são tratadas como parte do design de HA em vez de uma reflexão tardia.

Considerações Avançadas & Aplicações

A lição operacional mais profunda em HA de PostgreSQL é que um sistema com componentes excelentes ainda pode falhar como um todo se esses componentes nunca foram testados juntos sob condições de falha realistas.

O dimensionamento do DCS é a primeira coisa a acertar, pois a matemática do quorum significa que um DCS de N nós tolera a perda de floor(N/2) nós, e é por isso que um cluster etcd de 2 nós não oferece proteção real e 3 ou 5 nós são o mínimo prático para produção.

Colocar o DCS nos mesmos hosts do PostgreSQL é uma armadilha sutil, pois uma única falha de host ou rack pode então derrubar tanto o nó do banco de dados quanto votos suficientes do DCS para perder o quorum ao mesmo tempo.

Guarda como maximum_lag_on_failover existe porque um sistema automatizado promoverá felizmente um standby que é tecnicamente saudável, mas está tão atrasado a ponto de violar o RPO, então os orquestradores expõem um teto de atraso de bytes abaixo do qual a promoção é recusada.

Treinos de "game day", acionando deliberadamente o failover de forma controlada, são o único método confiável para descobrir se as suposições de RTO se sustentam quando os tempos de reconexão do proxy, o comportamento do pooler e a lógica de retentativa da aplicação são incluídos na medição, não apenas a promoção do próprio banco de dados.

Ofertas gerenciadas na nuvem, como implantações Multi-AZ, implementam as mesmas camadas conceituais, consenso equivalente ao DCS, fencing e roteamento, mas as escondem atrás de um plano de controle gerenciado, que troca o controle operacional por uma área menor para configurar incorretamente.

O padrão que separa HA no papel de HA na prática é tratar o DCS, fencing e roteamento como partes de primeira classe do design, e então provar RTO e RPO com treinos em vez de confiar apenas na matemática teórica de uptime.

Concepções Errôneas Comuns

• "Ter um standby replicado é o mesmo que ter alta disponibilidade." Um standby sem um orquestrador e camada de roteamento ainda requer detecção e promoção manual, que é exatamente o processo lento e propenso a erros que o failover automático existe para remover.
• "Failover e switchover são a mesma operação." Failover reage a uma perda não planejada do primário, enquanto switchover é uma entrega planejada e cooperativa para manutenção, e os dois carregam perfis de risco muito diferentes.
• "Dois nós são suficientes para failover automático." Um DCS de 2 nós não pode formar uma maioria após perder um nó, o que torna 3 ou mais nós o piso prático para decisões seguras baseadas em quorum.
• "Fencing é opcional se a rede for geralmente confiável." Split brain só precisa acontecer uma vez para causar divergência real de dados, e redes "geralmente confiáveis" ainda particionam com frequência suficiente para que clusters de produção tratem fencing como obrigatório.
• "Porcentagens de uptime mais altas são sempre alcançáveis adicionando mais standbys." Mais standbys melhoram a capacidade de leitura e os candidatos a failover, mas o RTO é limitado pela detecção, tempo de promoção e roteamento, não apenas pelo número de standbys.

FAQs

Relacionados

• Fundamentos de HA - Alvos de RTO/RPO e a pilha de HA na prática
• Patroni & etcd/Consul - configurando eleição de líder baseada em quorum
• Prevenção de Split-Brain - fencing, matemática de quorum e STONITH
• Proxies de Conexão - roteando clientes para o primário atual
• Testes de HA - executando "game days" de failover
• Replicação de Streaming Explicada - a camada de replicação sobre a qual a HA se baseia

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (versão principal estável 18, linha de manutenção 17 também suportada) e Patroni 3.x.