Kako repliciranje funkcionira u PostgreSQL-u?

Question

Accepted Answer

**Repliciranje** kopira podatke iz **primarnog** databaza na jedan ili više **repličnih** (standby) servera — za visoku dostupnost (failover ako primarni padne) i čitanje skalabilnosti (raspodjela čitanja). PostgreSQL primarno koristi **streaming replication** (fizičku) na osnovu write-ahead loga (WAL).

## Streaming (fizička) repliciranje

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

Primarni prenosi svoj **WAL** (write-ahead log — zapis svakih promjena) na replike, koje ga primjenjuju da ostanu sinkronizirane. Replike su samo-za-čitanje kopije koje mogu poslužiti čitanja.

## Prednosti: HA i čitanje skalabilnosti

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

## Sinkrono vs asinkrono repliciranje

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

## Logičko repliciranje (drugačiji model)

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

## Visoka dostupnost u praksi

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

## Zašto je to važno

Repliciranje je važno za gradnju **visoko dostupnih i skalabilnih** PostgreSQL deploymenata, pa je razumijevanje toga vrijedna znanja na seniorskoj razini za arhitekturu produkcijskih databaza.

Dva osnovna prednosti su kritični za ozbiljne aplikacije: **visoka dostupnost** (ako primarni databaz padne, replika može biti promovirana da preuzme, minimizirajući downtime — bitno za sustave koji moraju ostati dostupni) i **čitanje skalabilnost** (usmjeravanje samo-za-čitanje upita na replike rasterećuje primarne, omogućavajući sustavu da rukuje daleko više čitanja prometa — vrijedna za čitanja-teška radna opterećenja).

Razumijevanje **streaming repliciranja** (primarni prenosi svoj WAL replikama koje ostaju sinkronizirane i mogu poslužiti čitanja) je osnova.

Znanje **sinkronog vs asinkronog** kompromisa je važno: asinkrono (zadano — brže pisanje ali mali prozor potencijalne gubitka podataka na failoveru) naspram sinkronog (bez gubitka podataka ali sporije pisanje) — odluka trajnosti-naspram-performansi koja utječe na pouzdanost.

Razumijevanje **logičkog repliciranja** (repliciranje specifičnih tablica preko pub/sub, korisno za migracije, cross-verzije i djelomičko/selektivno repliciranje) proširuje opcije.

Znanje da **HA tooling** (Patroni, repmgr, upravdani cloud Postgres) automatizira failover, i da rutiranje čitanja/pisanja usmjerava promet prikladnije, je praktično arhitekturalno znanje.

Jer su visoka dostupnost i skalabilnost bitni zahtjevi za produkcijske database sisteme, i jer je repliciranje (s njenom HA failover, čitanja skalabilnosti, sinkronog/asinkronog kompromisa trajnosti, i logičkim repliciranjem za fleksibilnost) primarni mehanizam koji PostgreSQL pruža za njih, razumijevanje repliciranja je važno znanja na seniorskoj razini za arhitekturu pouzdanih, skalabilnih Postgres deploymenata — често relevantna briga za produkcijske sustave i temu koja pokazuje razumijevanje dostupnosti databaza i skaliranja koja se očekuje za senior database/backend uloge.