← Alta Disponibilidade: desenho, falhas e recuperação
04 / 12 · 40 MIN

Replicação, promoção e redundância

Relaciona confirmação de commits, dados disponíveis e recuperação segura do papel de primário.

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.

NA PRÁTICA

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

Leva esta ideia contigo

Aceita a recuperação com dados, autoridade e consumidores validados.

Criar conta

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