Alta Disponibilidade PostgreSQL¶

O PostgreSQL replica através do WAL (Write-Ahead Log): tudo o que é alterado é primeiro escrito no log de transações, e é esse log que alimenta os standbys, o arquivo de backup e a recuperação a um ponto no tempo. Entender para onde o WAL vai é entender toda a estratégia de disponibilidade do banco.

Esta página trata de HA dentro do mesmo datacenter, que resolve falha de host, disco, rack e manutenção. Para reduzir latência de aplicações em outra região e distribuir dados geograficamente, veja PostgreSQL Multi-Região.

A InteSys implanta a arquitetura em Kubernetes, com um operador PostgreSQL, ou em máquinas virtuais, com um gerenciador de cluster apoiado em um store de consenso. As duas rodam em br-sp-1 (Cirion SAO1) e br-sp-2 (Equinix SP3).

O que HA resolve — e o que não resolve¶

Os dois números que definem o projeto:

• RPO — quanto de dado é aceitável perder. Com standby síncrono, zero.
• RTO — quanto tempo até voltar. Com promoção automática, dezenas de segundos.

Topologia em Kubernetes¶

Para aplicações que já rodam em Kubernetes, o PostgreSQL fica no próprio cluster, sob um operador PostgreSQL que trata provisionamento, replicação, failover, arquivamento de WAL e backup como estado declarativo.

O operador reconcilia a topologia; a aplicação usa os endpoints -rw e -ro, e o WAL é arquivado fora do cluster.

• Serviços separados para leitura e escrita — o endpoint -rw sempre aponta para o primário atual, o -ro distribui leitura entre os standbys. A aplicação não reconfigura nada durante um failover.
• Pooler de conexões integrado — PgBouncer no caminho, porque o PostgreSQL usa um processo por conexão e centenas de conexões ociosas custam memória real.
• Anti-affinity obrigatória — um pod de banco por nó físico.
• Arquivamento contínuo do WAL para armazenamento de objetos, base do point-in-time recovery.
• Volumes persistentes de baixa latência, com snapshot de volume criptografado e retenção definida.

Topologia em máquinas virtuais¶

O gerenciador de cluster mantém o leader lock em um store de consenso; o proxy segue o líder e a aplicação continua com um único endereço.

• Três nós de banco em hosts físicos distintos: primário, standby síncrono e standby assíncrono.
• Store de consenso com número ímpar de membros — é ele que decide quem é o líder, evitando que dois nós se promovam.
• Proxy em par com VIP — HAProxy ou equivalente, roteando escrita para o líder e leitura para os standbys.
• Replicação por streaming com slots de replicação, para que o primário não descarte WAL que um standby ainda não consumiu.
• Arquivamento de WAL e backup fora dos nós de banco.

Kubernetes ou máquinas virtuais?¶

WAL, RPO e backup¶

O standby síncrono define o RPO; o arquivo de WAL permite voltar a qualquer ponto no tempo; o teste de restauração é o que transforma backup em garantia.

Como funciona o failover¶

1. Detecção — o leader lock expira no store de consenso; a decisão é do quórum, não de um observador isolado.
2. Fencing — o primário antigo é rebaixado e isolado antes de qualquer promoção, evitando split-brain.
3. Promoção — o standby síncrono assume; como já confirmou as transações, não há perda de dados.
4. Redirecionamento — o pooler passa a apontar para o novo primário, sem mudança na aplicação.
5. Reincorporação — o nó antigo volta como standby após alinhamento com a nova linha de tempo do WAL.

Monitoramento que acompanha o cluster¶

• replication lag em bytes e em segundos, por standby;
• estado do leader lock e histórico de promoções;
• slots de replicação inativos — a causa mais comum de disco cheio no primário;
• transações longas, bloat e progresso do autovacuum;
• conexões em uso versus limite do pooler;
• sucesso do backup e da restauração de teste.

Soberania de dados¶

Todo o dado deste cluster fica no Brasil. As duas regiões da InteSys são brasileiras — br-sp-1 (Cirion SAO1), em Cotia/SP, e br-sp-2 (Equinix SP3), na região metropolitana de São Paulo — e o dado só sai do país se o cliente pedir.

• Residência de dados no Brasil — nós primários, réplicas, arquivos de log de transação e backups ficam em datacenter brasileiro, em infraestrutura operada pela InteSys.
• LGPD sem transferência internacional — na configuração padrão não existe transferência internacional de dados pessoais para documentar, nem base legal adicional a construir.
• Jurisdição única — infraestrutura brasileira, contrato brasileiro e operação por equipe brasileira, sem a exposição a legislação estrangeira de acesso a dados que alcança provedores sediados fora do país.
• Latência como consequência — manter o dado perto do usuário brasileiro é, ao mesmo tempo, requisito de conformidade e ganho de desempenho.
• Saída de dados é decisão explícita do cliente — qualquer cópia fora do país existe apenas quando pedida, e apenas em volume criptografado.

Snapshot de volume criptografado¶

Além do backup base com arquivamento contínuo de WAL, o cluster em Kubernetes pode usar snapshots de volume (VolumeSnapshot via CSI): uma cópia do volume inteiro, tirada em segundos, sem varrer a base.

• Snapshot consistente — o operador coordena o flush e o congelamento da escrita antes de disparar o snapshot, para que a restauração não dependa de recuperação de falha.
• Sempre em volume criptografado — o dado é cifrado em repouso e o snapshot herda essa criptografia; a chave é gerenciada pela InteSys ou fornecida pelo cliente.
• Cópia cifrada em trânsito — a replicação do snapshot para outro destino trafega criptografada e é armazenada cifrada no destino.
• Retenção e restauração testada — política de retenção definida e restauração exercitada periodicamente; snapshot que nunca foi restaurado é hipótese, não backup.
• Recuperação rápida — o snapshot devolve o volume inteiro em minutos; o backup base mais o arquivo de WAL continua sendo o que permite voltar a qualquer ponto no tempo.

Como a InteSys implanta¶

1. Dimensionamento — volume, perfil de escrita, extensões em uso, requisitos de RPO/RTO.
2. Topologia — Kubernetes ou VMs, número de standbys e modo de replicação.
3. Provisionamento — nós em hosts físicos distintos, storage dedicado, parâmetros do PostgreSQL ajustados à carga.
4. Camada de acesso — pooler e endpoints separados de leitura e escrita.
5. Arquivamento e backup — WAL contínuo e backup completo em armazenamento de objetos, fora dos nós.
6. Teste de falha — derrubamos o primário em ambiente controlado e medimos o RTO real.
7. Observabilidade e alertas — métricas, painéis e alertas ligados ao time de operação.
8. Runbook — procedimento documentado para intervenção humana quando necessária.

Próximos Passos¶

• PostgreSQL Multi-Região — Latência, réplicas de leitura e replicação lógica entre regiões
• Alta Disponibilidade MySQL — A mesma arquitetura aplicada ao MySQL
• Alta Disponibilidade ClickHouse — Réplicas e shards para cargas analíticas
• Kubernetes — Clusters gerenciados onde o banco pode ser operado
• Datacenters InteSys — Detalhes das regiões br-sp-1 e br-sp-2