Réplicas e failover

Um banco PostgreSQL no CloudNativePG pode rodar de 1 a 3 instâncias, cada uma num servidor diferente, em Instâncias e replicação na sua página. Mais instâncias precisam de mais servidores.

Isto não é alta disponibilidade

O plano de controle do cluster roda só no servidor principal. Se o servidor principal for perdido, nenhum failover acontece. Veja O que o Orbit não promete.

A prévia

Ela escolhe um servidor para cada instância, começando pelo do primário, e recusa:

• quando não há servidores suficientes com espaço para a memória do banco;
• replicação síncrona com duas instâncias, porque perder qualquer um dos servidores pararia todas as escritas.

Replicação

• Assíncrona (o padrão): os commits não esperam as réplicas, então um failover pode perder as últimas escritas.
• Síncrona (três instâncias): cada commit espera até uma réplica tê-lo, e só é promovida uma réplica que tem todas as escritas confirmadas, então um failover não perde nenhuma. As escritas ficam mais lentas e param se dois dos três servidores forem perdidos.

Failover

Quando o servidor do primário é perdido, uma réplica é promovida e o endereço do banco passa a apontar para o novo primário, então as aplicações mantêm as suas variáveis. Quando aquele servidor volta, a instância dele entra de novo como réplica.

Um primário que perde a rede mas continua rodando não alcança nem o cluster nem as réplicas, então ele se reinicia e encerra as sessões cerca de meio minuto depois do corte. Isso acontece antes de uma réplica ser promovida, então só um primário aceita escritas de cada vez.

Tornar primário numa réplica a promove de propósito (um switchover). Levou de 9 a 10 segundos num cluster de teste.

O que o Orbit mostra

A página lista cada instância com o seu servidor, o seu papel e o quanto uma réplica está atrasada. Todo failover e switchover fica registrado na atividade e na linha do tempo do banco com o que o Orbit mediu:

• Quanto tempo o banco ficou sem primário: do momento em que o antigo funcionou pela última vez (o último sinal do seu servidor ou o último commit replicado) até a promoção.
• O que foi mantido: com replicação síncrona, toda escrita confirmada. Com assíncrona, o horário da escrita mais nova que o novo primário tem; o que o primário antigo confirmou depois disso se perdeu.

Backups e a recuperação até um momento continuam funcionando depois de um failover, já que o arquivo segue o primário.

Testado sob falhas

O teste de aceitação do Orbit quebra de propósito um cluster de três nós: o servidor principal e mais dois, rodando como contêineres numa máquina só. Dois bancos PostgreSQL 17 rodam ali com três instâncias cada, uma por servidor. Um replica de forma assíncrona; o outro, de forma síncrona, e arquiva o WAL num armazenamento compatível com S3. Uma aplicação escreve em cada um pelo endereço do banco cinco vezes por segundo e registra quais escritas foram confirmadas.

Cenário	Medido
O servidor do primário para	63 a 64 s sem primário; escritas de volta depois de 67 a 70 s. Nenhuma escrita confirmada perdida, assíncrona ou síncrona.
O servidor do primário perde a rede	96 s sem primário; escritas de volta depois de 101 a 103 s. O primário assíncrono isolado parou de aceitar escritas 34 s depois do corte, 61 s antes da promoção, e as escritas que ele aceitou nesses 34 s se perderam. O síncrono não aceitou nenhuma. Nunca houve dois primários aceitando escritas.
Uma mudança destrutiva (delete sem where)	Restaurado para o segundo anterior em 63 s.
Todas as instâncias e volumes perdidos	Reconstruído só a partir do arquivo: escritas de volta 51 s depois da perda. Os 41 s de escritas que não tinham chegado ao arquivo se perderam, e o Orbit informou exatamente até qual commit recuperou.
Uma configuração que não sobrevive à perda de um servidor	A prévia recusa.

O que continua em aberto está em O que o Orbit não promete.