Wie funktioniert die Replikation in PostgreSQL?

Question

Accepted Answer

**Replication** kopiert Daten von einer **Primary**-Datenbank zu einem oder mehreren **Replica**-(Standby-)Servern — für High Availability (Failover, falls die Primary ausfällt) und Read Scaling (Verteilung von Leseanfragen). PostgreSQL nutzt hauptsächlich **Streaming Replication** (physisch) basierend auf dem Write-Ahead Log (WAL).

## Streaming (physische) Replikation

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

Die Primary streamt ihr **WAL** (Write-Ahead Log — ein Datensatz jeder Änderung) zu den Replicas, die es anwenden, um synchronisiert zu bleiben. Replicas sind schreibgeschützte Kopien, die Leseanfragen bedienen können.

## Die Vorteile: HA und Read Scaling

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

## Synchrone vs. asynchrone Replikation

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

## Logische Replikation (ein anderes 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.
```

## High Availability in der Praxis

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

## Warum es wichtig ist

Replikation ist wichtig für den Aufbau von **hochverfügbaren und skalierbaren** PostgreSQL-Deployments, daher ist deren Verständnis wertvolles Wissen auf Senior-Level für die Architektur von Produktionsdatenbanken.

Die zwei Kernvorteile sind entscheidend für ernsthafte Anwendungen: **High Availability** (falls die Primary ausfällt, kann eine Replica übernehmen und Ausfallzeiten minimieren — essentiell für Systeme, die immer verfügbar sein müssen) und **Read Scaling** (Weiterleitung von schreibgeschützten Abfragen zu Replicas entlastet die Primary und ermöglicht dem System, deutlich mehr Lesedatenverkehr zu verarbeiten — wertvoll für Read-intensive Workloads).

Das Verständnis von **Streaming Replication** (die Primary streamt ihr WAL zu Replicas, die synchronisiert bleiben und Lesevorgänge bedienen können) ist die Grundlage.

Die Kenntnis des **synchronen vs. asynchronen** Trade-offs ist wichtig: asynchron (Standard — schnellere Schreibvorgänge, aber ein kleines Fenster potenzieller Datenverluste beim Failover) versus synchron (kein Datenverlust, aber langsamere Schreibvorgänge) — eine Entscheidung zwischen Dauerhaftigkeit und Leistung, die die Zuverlässigkeit beeinflusst.

Das Verständnis von **logischer Replikation** (Replikation spezifischer Tabellen über Pub/Sub, nützlich für Migrationen, versionierungsübergreifend und partielle/selektive Replikation) erweitert die Optionen.

Die Kenntnis, dass **HA-Tools** (Patroni, repmgr, verwaltete Cloud-Postgres-Lösungen) Failover automatisieren, und dass Read/Write-Routing den Datenverkehr angemessen leitet, ist praktisches Architektur-Wissen.

Da High Availability und Skalierbarkeit essenzielle Anforderungen für Produktionsdatenbanken sind und da Replikation (mit ihrem HA-Failover, Read Scaling, dem Durability-Performance-Trade-off und logischer Replikation für Flexibilität) der primäre Mechanismus ist, den PostgreSQL dafür bereitstellt, ist das Verständnis von Replikation wichtiges Senior-Level-Wissen für die Architektur von zuverlässigen, skalierbaren Postgres-Deployments — ein häufig relevantes Anliegen für Produktionssysteme und ein Thema, das das Verständnis für Datenbankverfügbarkeit und Skalierung demonstriert, das von Senior-Database-/Backend-Rollen erwartet wird.