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øj tilgængelighed (failover hvis den primære svigter) og læseskalering (distribuere læseforespørgsler). PostgreSQL bruger primært **streaming replication** (fysisk) baseret 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
```

Den primære streamer sin **WAL** (write-ahead log — en registrering af hver ændring) til replicas, som anvender den for at forblive synkroniseret. Replicas er skrivebeskyttede kopier, der kan håndtere læseforespørgsler.

## Fordelene: HA og læseskalering

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

## Høj tilgængelighed 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 betyder noget

Replikering er vigtig for at bygge **highly-available og skalerbare** PostgreSQL-installationer, så forståelse af det er værdifuld seniorlevel-viden for produktionsdatabasearkitektur.

De to kernefordele er kritiske for seriøse applikationer: **høj tilgængelighed** (hvis den primære database svigter, kan en replica forfremmedes til at overtage, hvilket minimerer nedetid — væsentligt for systemer, der skal forblive tilgængelige) og **læseskalering** (routing af skrivebeskyttede forespørgsler til replicas aflaster den primære, hvilket lader systemet håndtere langt mere læsetrafik — værdifuldt for læseheavy workloads).

Forståelse af **streaming replication** (den primære streamer sin WAL til replicas, der forbliver synkroniserede og kan håndtere læsninger) er fundamentet.

Kendskab til **synkron versus asynkron** trade-off er vigtig: asynkron (standarden — hurtigere skrivninger men et lille vindue af potentielt datatab ved failover) versus synkron (intet datatab men langsommere skrivninger) — en durability-vs-performance-beslutning, der påvirker pålidelighed.

Forståelse af **logisk replikering** (replikering af specifikke tabeller via pub/sub, nyttig til migrationer, cross-version og delvis/selektiv replikering) udvider mulighederne.

Viden om, at **HA-værktøjer** (Patroni, repmgr, managed cloud Postgres) automatiserer failover, og at read/write-routing dirigerer trafik passende, er praktisk arkitektonisk viden.

Da høj tilgængelighed og skalerbarhed er væsentlige krav for produktionsdatabasesystemer, og da replikering (med dens HA failover, læseskalering, synkron/asynkron durability trade-off og logisk replikering for fleksibilitet) er den primære mekanisme, PostgreSQL leverer for dem, er forståelse af replikering vigtig seniorlevel-viden for at arkitekturere pålidelige, skalerbare Postgres-installationer — et hyppigt relevant område for produktionssystemer og et emne, der demonstrerer forståelse af databasetilgængelighed og skalering, som forventes for senior database/backend-roller.