Come funziona la replica in PostgreSQL?

Question

Accepted Answer

**Replication** copia i dati da un database **primary** a uno o più server **replica** (standby) — per alta disponibilità (failover se il primary fallisce) e read scaling (distribuire le query di lettura). PostgreSQL utilizza principalmente **streaming replication** (fisica) basata sul write-ahead log (WAL).

## Streaming (physical) replication

```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
```

Il primary trasmette il suo **WAL** (write-ahead log — un record di ogni modifica) alle repliche, che lo applicano per rimanere sincronizzate. Le repliche sono copie di sola lettura che possono servire le query di lettura.

## I vantaggi: HA e read scaling

```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
```

## Replication sincrona vs asincrona

```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.
```

## Logical replication (un modello diverso)

```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 disponibilità nella pratica

```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.
```

## Perché è importante

La replication è importante per costruire deployment PostgreSQL **altamente disponibili e scalabili**, quindi comprendere il funzionamento è una conoscenza preziosa di livello senior per l'architettura dei database in produzione.

I due vantaggi principali sono critici per applicazioni serie: **alta disponibilità** (se il database primary fallisce, una replica può essere promossa per sostituirlo, minimizzando il downtime — essenziale per i sistemi che devono rimanere disponibili) e **read scaling** (instradare le query di sola lettura alle repliche riduce il carico sul primary, permettendo al sistema di gestire molto più traffico di lettura — prezioso per i workload ad alta lettura).

Comprendere **streaming replication** (il primary che trasmette il suo WAL alle repliche che rimangono sincronizzate e possono servire letture) è la base.

Conoscere il trade-off **sincrono vs asincrono** è importante: asincrono (il default — scritture più veloci ma una piccola finestra di potenziale perdita di dati al failover) versus sincrono (nessuna perdita di dati ma scritture più lente) — una decisione di durabilità-vs-performance che influenza l'affidabilità.

Comprendere **logical replication** (replicare specifiche tabelle via pub/sub, utile per migrazioni, cross-version, e replica parziale/selettiva) amplia le opzioni.

Sapere che **HA tooling** (Patroni, repmgr, managed cloud Postgres) automatizza il failover, e che il read/write routing indirizza il traffico appropriatamente, è conoscenza architettonica pratica.

Poiché alta disponibilità e scalabilità sono requisiti essenziali per i database in produzione, e poiché la replication (con il suo HA failover, read scaling, il trade-off di durabilità sync/async, e logical replication per flessibilità) è il meccanismo principale fornito da PostgreSQL per raggiungerli, comprendere la replication è conoscenza importante di livello senior per progettare deployment Postgres affidabili e scalabili — una preoccupazione frequentemente rilevante per i sistemi in produzione e un argomento che dimostra comprensione della disponibilità e scalabilità dei database che ci si attende dai ruoli senior di database/backend.