Conceito e mecanismo
Replicação não oferece sempre as mesmas garantias. Nos exemplos PostgreSQL 18, streaming replication é assíncrona por omissão; um standby pode estar atrasado relativamente aos commits confirmados no primário. Estar ligado ou aceitar SELECT não demonstra que todos os dados necessários chegaram. Uma medição de atraso em segundos também não dá, sozinha, uma contagem exata de transações perdidas. Na replicação síncrona, observa a configuração efetiva. synchronous_commit=remote_write confirma escrita no sistema operativo do standby, sem exigir flush durável nesse disco. on e remote_apply estabelecem condições diferentes; este último inclui replay e visibilidade. Latência, número de confirmações e disponibilidade dos standbys influenciam o comportamento observado pela aplicação.
Aplicação guiada
PostgreSQL não fornece por si todo o sistema externo de deteção, decisão e routing de failover. O plano precisa de autoridade única, candidato adequado, promoção e reconexão dos consumidores. Se o antigo primário regressar, não deve retomar escrita independente; é necessário reconciliar o estado e o papel segundo o procedimento suportado. Num cenário fictício, o negócio exige não perder operações confirmadas mas só existe uma réplica assíncrona atrasada. A decisão precisa de evidência e escalada do trade-off, sem prometer perda zero porque o prazo está próximo. Depois de recuperar o serviço, confirma se existe novamente standby. Um primário único funcional continua com redundância degradada e essa ação deve permanecer visível no handover.
Promoção concluída não demonstra clientes reconectados nem redundância reposta.
Armadilhas comuns
Streaming como síncrono; remote_write como flush; leitura como failover automático; primário antigo como seguro por historial.
Tópicos relacionados: Objetivos e impacto no serviço · Domínios de falha e capacidade residual · Quorum e isolamento de escritores
Aceita a recuperação com dados, autoridade e consumidores validados.
Referência: PostgreSQL 18 standby replication and commit acknowledgement · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior