Cum funcționează replicarea în PostgreSQL?

Question

Accepted Answer

**Replicarea** copiază date din baza de date **primară** pe unul sau mai multe servere **replică** (standby) — pentru disponibilitate ridicată (failover dacă serverul primar eșuează) și scalabilitate de citire (distribuire a interogărilor de citire). PostgreSQL utilizează în principal **replicarea prin streaming** (fizică) bazată pe write-ahead log (WAL).

## Replicarea prin streaming (fizică)

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

Serverul primar transmite prin streaming **WAL**-ul său (write-ahead log — înregistrare a fiecărei schimbări) către replici, care o aplică pentru a rămâne sincronizate. Replicile sunt copii doar pentru citire care pot servi interogări de citire.

## Beneficiile: HA și scalabilitate de citire

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

## Replicarea sincronă vs asincronă

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

## Replicarea logică (un model diferit)

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

## Disponibilitate ridicată în practică

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

## De ce este important

Replicarea este importantă pentru construirea implementărilor PostgreSQL **extrem de disponibile și scalabile**, deci înțelegerea ei este cunoștințe valoroase la nivel senior pentru arhitectura bazelor de date în producție.

Două beneficii fundamentale sunt critice pentru aplicații serioase: **disponibilitate ridicată** (dacă baza de date primară eșuează, o replică poate fi promovată pentru a prelua controlul, minimizând perioada de inactivitate — esențial pentru sisteme care trebuie să rămână disponibile) și **scalabilitate de citire** (rutarea interogărilor doar pentru citire către replici descarcă serverul primar, permițând sistemului să gestioneze mult mai mult trafic de citire — valoros pentru sarcini cu citiri intensive).

Înțelegerea **replicării prin streaming** (serverul primar transmite WAL-ul către replici care rămân sincronizate și pot servi citiri) este fundamentul.

Cunoașterea compromisului **sincron vs asincron** este importantă: asincron (implicit — scrieri mai rapide dar o fereastră mică de potențială pierdere de date la failover) versus sincron (fără pierdere de date dar scrieri mai lente) — o decizie de durabilitate-vs-performanță care afectează fiabilitatea.

Înțelegerea **replicării logice** (replicarea unor tabele specifice prin pub/sub, utilă pentru migrații, versiuni încrucișate și replicare parțială/selectivă) lărgește opțiunile.

Cunoașterea că **instrumentele HA** (Patroni, repmgr, Postgres cloud gestionat) automatizează failoverul, și că rutarea citire/scriere direcționează traficul corespunzător, este cunoștință arhitecturală practică.

Deoarece disponibilitatea ridicată și scalabilitatea sunt cerințe esențiale pentru sisteme de baze de date în producție, și deoarece replicarea (cu failoverul HA, scalabilitatea de citire, compromisul durabilitate sincron/asincron și replicarea logică pentru flexibilitate) este mecanismul primar pe care PostgreSQL îl oferă pentru acestea, înțelegerea replicării este cunoștință importantă la nivel senior pentru arhitectarea implementărilor Postgres fiabile și scalabile — o preocupare frecvent relevantă pentru sisteme în producție și un subiect care demonstrează înțelegerea disponibilității și scalabilității bazelor de date care se așteaptă pentru roluri senior de baze de date/backend.