Como funciona a replicação no PostgreSQL?

Question

Accepted Answer

**Replicação** copia dados de um banco de dados **primário** para um ou mais servidores **réplica** (standby) — para alta disponibilidade (failover se o primário falhar) e escalabilidade de leitura (distribuir consultas de leitura). PostgreSQL usa principalmente **replicação por streaming** (física) baseada no write-ahead log (WAL).

## Replicação por streaming (física)

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

O primário transmite seu **WAL** (write-ahead log — um registro de todas as mudanças) para as réplicas, que o aplicam para ficar sincronizadas. Réplicas são cópias somente leitura que podem servir consultas de leitura.

## Os benefícios: HA e escalabilidade de leitura

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Replicação síncrona vs assíncrona

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Replicação lógica (um modelo diferente)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## Alta disponibilidade na prática

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## Por que isso importa

Replicação é importante para construir deployments PostgreSQL **altamente disponíveis e escaláveis**, então compreendê-la é conhecimento valioso de nível sênior para arquitetura de banco de dados em produção.

Os dois benefícios principais são críticos para aplicações sérias: **alta disponibilidade** (se o banco de dados primário falhar, uma réplica pode ser promovida para assumir, minimizando tempo de inatividade — essencial para sistemas que devem permanecer disponíveis) e **escalabilidade de leitura** (rotear consultas somente leitura para réplicas alivia o primário, permitindo que o sistema trate muito mais tráfego de leitura — valioso para workloads de leitura intensiva).

Compreender **replicação por streaming** (o primário transmitindo seu WAL para réplicas que permanecem sincronizadas e podem servir leituras) é a base.

Conhecer o trade-off **síncrono vs assíncrono** é importante: assíncrono (o padrão — escritas mais rápidas mas uma pequena janela de possível perda de dados no failover) versus síncrono (nenhuma perda de dados mas escritas mais lentas) — uma decisão de durabilidade-vs-performance que afeta confiabilidade.

Compreender **replicação lógica** (replicar tabelas específicas via pub/sub, útil para migrações, cross-version e replicação parcial/seletiva) amplia as opções.

Saber que **ferramentas de HA** (Patroni, repmgr, managed cloud Postgres) automatizam failover, e que roteamento de leitura/escrita direciona tráfego apropriadamente, é conhecimento arquitetural prático.

Como alta disponibilidade e escalabilidade são requisitos essenciais para sistemas de banco de dados em produção, e como replicação (com seu HA failover, escalabilidade de leitura, o trade-off de durabilidade síncrono/assíncrono e replicação lógica para flexibilidade) é o mecanismo primário que PostgreSQL fornece para elas, compreender replicação é importante conhecimento de nível sênior para arquitetar deployments Postgres confiáveis e escaláveis — uma preocupação frequentemente relevante para sistemas em produção e um tópico que demonstra compreensão de disponibilidade e scaling de banco de dados esperado para papéis de banco de dados/backend sênior.