Hogyan működik a replikáció a PostgreSQL-ben?

Question

IT Interview Practice · Accepted Answer

**A replikáció** az adatokat egy **elsődleges** (primary) adatbázisból egy vagy több **replika** (standby) szerverbe másolja — magas rendelkezésre állás (failover, ha az elsődleges meghibásodna) és olvasási skálázhatóság (olvasási lekérdezések elosztása) érdekében. A PostgreSQL elsősorban **streaming replikációt** (fizikai) használ, amely a write-ahead log (WAL) alapú.

## Streaming (fizikai) replikáció

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

Az elsődleges streameli a **WAL**-t (write-ahead log — minden változás naplója) a replikáknak, amelyek alkalmazzák azt a szinkronizáltsággal. A replikák csak olvasható másolatok, amelyek olvasási lekérdezéseket szolgálnak ki.

## Az előnyök: HA és olvasási skálázhatóság

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

## Szinkron vs aszinkron replikáció

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

## Logikai replikáció (egy másik modell)

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

## Magas rendelkezésre állás a gyakorlatban

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

## Miért számít

A replikáció fontos a **nagy rendelkezésre állású és skálázható** PostgreSQL rendszerek kialakításához, így ennek megértése értékes szeniorrási szintű ismeret az üzemi adatbázis-architektúra terén.

A két alapvető előny kritikus a komoly alkalmazások számára: **magas rendelkezésre állás** (ha az elsődleges adatbázis meghibásodna, egy replika előléptethető az átvételre, minimalizálva a leállást — lényeges az olyan rendszerek számára, amelyeknek elérhetőnek kell maradniuk) és **olvasási skálázhatóság** (csak olvasható lekérdezések replikákra való irányítása tehermentesíti az elsődlegest, lehetővé téve a rendszert, hogy sokkal több olvasási forgalmat kezeljen — értékes olvasási intenzív terhelésekhez).

A **streaming replikáció** megértése (az elsődleges streameli WAL-ját a szinkronizáltsággal maradó és olvasási kéréseket kiszolgáló replikáknak) az alapelv.

A **szinkron vs aszinkron** kompromisszum ismerete fontos: aszinkron (az alapértelmezés — gyorsabb írások, de kis ablak a potenciális adatvesztésre failover során) versus szinkron (nincs adatvesztés, de lassabb írások) — egy megbízhatóságot befolyásoló tartósság-vs-teljesítmény döntés.

A **logikai replikáció** megértése (specifikus táblák replikálása pub/sub-on keresztül, hasznos migrációkhoz, verziók közötti használathoz és részleges/szelektív replikációhoz) szélesíti a lehetőségeket.

Annak ismerete, hogy a **HA eszközöket** (Patroni, repmgr, felügyelt felhő Postgres) a failover automatizálják, és hogy az olvasási/írási útválasztás megfelelően irányítja a forgalmat, gyakorlati építészeti ismeret.

Mivel a magas rendelkezésre állás és skálázhatóság alapvető követelmények az üzemi adatbázis-rendszerek számára, és mivel a replikáció (HA failover-jével, olvasási skálázhatóságával, szinkron/aszinkron tartósság kompromisszumával és logikai replikációjával a rugalmasság érdekében) az elsődleges mechanizmus, amelyet a PostgreSQL biztosít ezekhez, a replikáció megértése fontos szeniorrási szintű ismeret a megbízható, skálázható Postgres-telepítések tervezéséhez — gyakran releváns szempont az üzemi rendszerekhez és olyan téma, amely az adatbázis elérhetőségét és skálázhatóságát bemutató ismereteket mutat, amelyet szeniorrási szintű adatbázis/backend szerepköröktől várnak.

Streaming (fizikai) replikáció

Az előnyök: HA és olvasási skálázhatóság

Szinkron vs aszinkron replikáció

Logikai replikáció (egy másik modell)

Magas rendelkezésre állás a gyakorlatban

Miért számít

Kapcsolódó kérdések