Hvordan fungerer replikering i PostgreSQL?

Question

Accepted Answer

**Replikering** kopierer data fra en **primær** database til en eller flere **replica** (standby) servere — for høy tilgjengelighet (failover hvis primæren svikter) og leseskalering (distribuer leseforespørsler). PostgreSQL bruker primært **streaming replication** (fysisk) basert på write-ahead log (WAL).

## Streaming (fysisk) replikering

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

Primæren streamer sin **WAL** (write-ahead log — en registrering av hver endring) til replika, som anvender den for å holde seg synkronisert. Replika er skrivebeskyttede kopier som kan betjene leseforespørsler.

## Fordelene: HA og leseskalering

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

## Synkron vs asynkron replikering

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

## Logisk replikering (en annen 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.
```

## Høy tilgjengelighet i praksis

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

## Hvorfor det betyr noe

Replikering er viktig for å bygge **høyt tilgjengelige og skalerbare** PostgreSQL-distribusjoner, så forståelse av det er verdifull senior-level kunskap for produksjonsdatabasearkitektur.

De to kjerneforslagene er kritiske for seriøse applikasjoner: **høy tilgjengelighet** (hvis primærdatabasen svikter, kan en replica forfremmets til å ta over, og minimerer nedetid — viktig for systemer som må holde seg tilgjengelige) og **leseskalering** (ruting av skrivebeskyttede forespørsler til replika reduserer belastningen på primæren, slik at systemet kan håndtere langt mer lesetrafikkk — verdifullt for lesekrevende arbeidsmengder).

Forståelse av **streaming replication** (primæren streamer sin WAL til replika som holder seg synkronisert og kan betjene leseforespørsler) er grunnlaget.

Kjennskap til **synkron vs asynkron** kompromisset er viktig: asynkron (standard — raskere skrivinger men et lite vindu av potensiell datakorreksjon ved failover) versus synkron (ingen datakorreksjon men saktere skrivinger) — en holdbarhets-vs-ytelsebeslutning som påvirker påliteligheten.

Forståelse av **logisk replikering** (replikering av spesifikke tabeller via pub/sub, nyttig for migrasjoner, tversjon og delvis/selektiv replikering) utvider mulighetene.

Kjennskap til at **HA-verktøy** (Patroni, repmgr, administrert cloud Postgres) automatiserer failover, og at les-/skriverutting dirigerer trafikken passende, er praktisk arkitektonisk kunskap.

Siden høy tilgjengelighet og skalerbarhet er essensielle krav for produksjonsdatabasesystemer, og siden replikering (med sin HA-failover, leseskalering, synkron/asynkron holdbarhetskompromiss og logisk replikering for fleksibilitet) er den primære mekanismen PostgreSQL gir for dem, er forståelse av replikering viktig senior-level kunskap for å arkitekturere pålitelige, skalerbare Postgres-distribusjoner — en hyppig relevant bekymring for produksjonssystemer og et emne som demonstrerer forståelse av databasetilgjengelighet og skalering som forventes for senior database/backend-roller.