PostgreSQL em Alta Disponibilidade: Replicação, Standby em Cascata e Failover sem Perda de Dados

Bancos de dados concentram o risco operacional de qualquer empresa. Aplicações podem ser reimplantadas em minutos; um banco corrompido ou indisponível costuma significar horas de paralisação e, no pior cenário, perda definitiva de informação. É por isso que alta disponibilidade em PostgreSQL deixou de ser assunto de grandes corporações e passou a ser requisito de qualquer ambiente que sustenta operação contínua.

O PostgreSQL oferece replicação nativa madura e confiável. O que costuma faltar é clareza sobre o que cada modo garante — e, principalmente, sobre o que nenhum deles garante. Este artigo trata dos mecanismos, das topologias e das decisões que separam um ambiente resiliente de um ambiente que apenas parece resiliente.

O WAL: a Base de Tudo

Toda replicação em PostgreSQL se apoia no Write-Ahead Log. Antes de alterar qualquer página de dados, o banco registra a modificação em um log sequencial. Esse mecanismo existe originalmente para garantir durabilidade após uma queda abrupta: ao reiniciar, o banco reaplica o WAL e recupera um estado consistente.

A replicação reutiliza essa estrutura. Se o WAL descreve integralmente toda mudança, então transmitir o WAL para outro servidor e reaplicá-lo lá produz uma cópia fiel do banco original. Compreender isso esclarece várias consequências práticas: a réplica está sempre reaplicando mudanças, o atraso é medido em bytes de WAL pendentes, e um servidor primário que não consegue enviar WAL acumula arquivos em disco — uma das causas mais comuns de esgotamento de espaço em ambientes replicados.

Replicação Física e Replicação Lógica

Replicação Física (Streaming)

Transmite o WAL em nível de bloco. A réplica é uma cópia byte a byte do primário: mesma versão do PostgreSQL, mesma arquitetura, todos os bancos da instância, todos os objetos. É o modo usado para alta disponibilidade e para distribuir leitura, já que o standby pode atender consultas enquanto reaplica o log.

• Baixa sobrecarga no primário
• Réplica em modo somente leitura
• Replica tudo — não é possível filtrar tabelas ou bancos
• Exige compatibilidade estrita de versão

Replicação Lógica

Transmite mudanças em nível de linha, decodificadas a partir do WAL e aplicadas como operações em tabelas específicas. Permite replicar apenas parte do banco, entre versões diferentes, e para destinos que aceitam escrita própria.

• Seleção granular de tabelas e operações
• Viabiliza upgrade de versão maior com janela mínima de indisponibilidade
• Destino aceita escrita, o que exige cuidado com conflitos
• Não replica automaticamente mudanças de estrutura nem sequências

A escolha não é excludente. Ambientes maduros frequentemente usam replicação física para o par de alta disponibilidade e replicação lógica para alimentar ambientes analíticos ou integrações.

Síncrono ou Assíncrono: a Decisão que Define o RPO

Em replicação assíncrona, o primário confirma a transação ao cliente assim que grava localmente, sem esperar a réplica. É o modo padrão, tem melhor desempenho e tolera latência de rede. O preço aparece em um failover não planejado: transações confirmadas ao cliente e ainda não transmitidas são perdidas.

Em replicação síncrona, o primário só confirma a transação depois que a réplica reconhece o recebimento do WAL. O ganho é objetivo: nenhuma transação confirmada se perde na promoção. O custo também: cada escrita passa a incluir pelo menos um tempo de ida e volta na rede, e a latência entre os servidores entra diretamente no tempo de resposta da aplicação.

Há um ponto crítico frequentemente subestimado. Com replicação síncrona e uma única réplica configurada como obrigatória, a indisponibilidade da réplica bloqueia as escritas no primário — o mecanismo desenhado para aumentar a disponibilidade passa a reduzi-la. Ambientes que exigem modo síncrono precisam de pelo menos duas réplicas candidatas, para que a perda de uma não paralise a operação.

A decisão, portanto, é de negócio antes de ser técnica: qual volume de transações pode ser perdido em um desastre? Se a resposta é "nenhuma", o modo síncrono é obrigatório e a topologia precisa ser dimensionada para sustentá-lo.

Topologias na Prática

Primário com Standby Único

A configuração mais simples e o ponto de partida da maioria dos ambientes. Protege contra falha de hardware do primário e permite direcionar relatórios para o standby. Não protege contra erro humano: um comando destrutivo executado no primário é replicado fielmente em segundos.

Standby em Cascata

Uma réplica pode alimentar outras réplicas, em vez de todas se conectarem ao primário. A topologia em cascata reduz a carga de rede e de processos no primário e é especialmente útil quando há réplicas em localidades remotas: o WAL atravessa o enlace uma única vez e é redistribuído localmente.

O efeito colateral a considerar é o acúmulo de atraso. Cada nível adiciona sua própria latência, de modo que o último standby da cadeia está sempre mais distante do primário do que o primeiro. Monitorar o atraso em cada elo, e não apenas no primeiro, é essencial.

Réplica Isolada para Restore e Testes

Manter um servidor fora da cadeia de replicação, destinado a restaurar backups e validar procedimentos, é uma prática que se paga na primeira emergência. É nesse ambiente que se descobre — em condições controladas — que um backup estava truncado ou que o procedimento de restauração leva o triplo do tempo estimado.

Slots de Replicação: Proteção com Risco Embutido

Slots de replicação instruem o primário a preservar os segmentos de WAL até que a réplica confirme o consumo. Resolvem um problema real: sem eles, uma réplica desconectada por tempo suficiente pode voltar e descobrir que o WAL de que precisava já foi reciclado, exigindo recriação completa.

O risco é o inverso. Um slot associado a uma réplica que nunca mais volta faz o primário acumular WAL indefinidamente até esgotar o disco — e um primário sem espaço em disco para fora do ar. Slots exigem monitoramento do atraso e limite máximo de retenção configurado. Slot órfão é uma das causas mais frequentes de indisponibilidade em ambientes replicados.

Failover: o que Realmente Acontece

Promover um standby a primário é tecnicamente simples. O que torna o failover difícil são as decisões ao redor dele.

Detecção confiável. Distinguir um primário realmente indisponível de uma partição de rede temporária é o problema central. Promover um standby enquanto o primário original continua ativo e recebendo escritas produz o cenário de dois primários — situação em que as bases divergem e a reconciliação manual é dolorosa.

Redirecionamento das aplicações. A promoção não move o endereço do banco. Sem uma camada de abstração — IP virtual, proxy de conexão ou serviço de descoberta — as aplicações continuam apontando para o servidor antigo.

Destino dos demais standbys. Réplicas que apontavam para o primário antigo precisam ser reapontadas para o novo, e o procedimento depende de quanto elas divergiram.

Reintegração do servidor antigo. O ex-primário raramente volta como standby sem intervenção: ele pode ter transações que o novo primário nunca recebeu, e essa divergência precisa ser resolvida antes de reconectá-lo à cadeia.

Por essas razões, muitas organizações operam com failover assistido em vez de automático. A automação reduz o tempo de recuperação, mas introduz a possibilidade de promoção indevida. A escolha depende da tolerância a indisponibilidade e da maturidade da equipe de plantão.

Replicação Não Substitui Backup

Este é o equívoco mais caro em ambientes de banco de dados. Replicação protege contra falha de infraestrutura. Não protege contra:

• Exclusão acidental de dados — replicada em segundos para todas as réplicas
• Corrupção lógica causada por defeito de aplicação
• Ação maliciosa com credencial legítima
• Necessidade de consultar o estado do banco em uma data passada

A proteção completa exige backup com retenção, arquivamento contínuo do WAL para permitir recuperação a um ponto no tempo, e — o item mais negligenciado — restauração testada periodicamente. Um backup que nunca foi restaurado é uma hipótese, não uma garantia. Essa validação periódica é justamente um dos pontos cobertos pelo PostDB, a consultoria dedicada em PostgreSQL da LaraClaud.

O que Monitorar

• Atraso de replicação em bytes e em tempo, por réplica e por elo da cascata
• Estado dos processos de envio e de recebimento de WAL
• Slots inativos e volume de WAL retido por cada um
• Espaço no diretório do WAL, com alerta antecipado
• Conflitos de recuperação em réplicas que atendem consultas longas
• Sucesso e duração dos backups, e a data do último restore validado

Conclusão

Alta disponibilidade em PostgreSQL é resultado de decisões explícitas: modo de replicação alinhado à tolerância a perda de dados, topologia dimensionada para a distribuição geográfica, slots com limites de retenção, procedimento de failover ensaiado e backup independente da replicação. Cada um desses pontos, isoladamente, é simples. A resiliência vem de tratá-los como um conjunto coerente e de testá-los antes que a emergência os teste.

A LaraClaud projeta, implanta e opera ambientes PostgreSQL de alta disponibilidade, incluindo topologias com standby em cascata, definição de objetivos de recuperação junto ao negócio, rotinas de backup validadas por restauração e monitoramento contínuo de replicação.

Referências

• POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL Documentation: High Availability, Load Balancing, and Replication. Disponível em: https://www.postgresql.org/docs/current/high-availability.html. Acesso em: 12 ago. 2026.
• POSTGRESQL GLOBAL DEVELOPMENT GROUP. Write-Ahead Logging (WAL). PostgreSQL Documentation. Disponível em: https://www.postgresql.org/docs/current/wal-intro.html. Acesso em: 12 ago. 2026.
• POSTGRESQL GLOBAL DEVELOPMENT GROUP. Logical Replication. PostgreSQL Documentation. Disponível em: https://www.postgresql.org/docs/current/logical-replication.html. Acesso em: 12 ago. 2026.
• RIGGS, Simon; CIOLLI, Gianni. PostgreSQL 14 Administration Cookbook. Birmingham: Packt Publishing, 2021.
• SCHÖNIG, Hans-Jürgen. Mastering PostgreSQL 15. Birmingham: Packt Publishing, 2023.
• DROGON, Bruce Momjian. PostgreSQL: Introduction and Concepts. Boston: Addison-Wesley, 2001.