Was ist logische Replikation und wann ist sie nützlich?

Question

Accepted Answer

**Logische Replikation** repliziert Datenänderungen auf der Ebene **spezifischer Tabellen** (mit einem Publish/Subscribe-Modell), anstatt das gesamte Datenbankcluster byte-für-byte wie bei physischer (Streaming-)Replikation zu kopieren. Dies macht sie flexibel — selektiv, versionsübergreifend und zu verschiedenen Schemas — ideal für Migrationen und Integrationen.

## Logische vs. physische Replikation

```text
PHYSICAL (streaming) → replicates the ENTIRE cluster at the storage/WAL level
  ✓ exact copy, simple   ✗ all-or-nothing, same Postgres version, read-only replica

LOGICAL → replicates specific TABLES' changes via a publish/subscribe model
  ✓ SELECTIVE (choose tables), CROSS-VERSION, to DIFFERENT schemas, replica is WRITABLE
  ✗ more setup, some limitations (DDL not replicated automatically, etc.)
```

## Einrichten logischer Replikation (Pub/Sub)

```sql
-- on the SOURCE (publisher): publish specific tables
CREATE PUBLICATION my_pub FOR TABLE users, orders;
-- (or FOR ALL TABLES)

-- on the TARGET (subscriber): subscribe to the publication
CREATE SUBSCRIPTION my_sub
  CONNECTION 'host=source dbname=mydb user=rep'
  PUBLICATION my_pub;
-- → the subscriber receives and applies changes to users and orders
```

Eine **Publication** definiert, was repliziert werden soll (spezifische Tabellen); ein **Subscription** konsumiert sie. Änderungen (INSERT/UPDATE/DELETE) fließen vom Publisher zum Subscriber.

## Wann logische Replikation nützlich ist

```text
✓ ZERO-DOWNTIME MAJOR UPGRADES — replicate from an old version to a new version, then
  switch over (physical replication can't cross versions) — a key use case
✓ MIGRATIONS — move data to a new server/cluster with minimal downtime
✓ SELECTIVE replication — replicate only certain tables (not the whole database)
✓ INTEGRATIONS — feed specific data to another system (analytics, data warehouse)
✓ Consolidating data from multiple databases into one
✓ The replica is WRITABLE (can have its own additional data/tables)
```

## Warum es wichtig ist

Logische Replikation ist wertvolles PostgreSQL-Wissen für **flexible Datenreplikations-Szenarien** — besonders Migrationen, Upgrades und Integrationen — daher ist das Verständnis dafür wertvolles Know-how auf Senior-Level für Datenbankoperationen und -architektur.

Der Schlüsselunterschied zur physischen (Streaming-)Replikation ist **Flexibilität**: Anstatt das gesamte Cluster byte-für-byte zu kopieren (physisch), repliziert logische Replikation **spezifische Tabellen** über Publish/Subscribe und funktioniert entscheidend **über PostgreSQL-Versionen hinweg** und zu **verschiedenen Schemas**, mit einem **beschreibbaren** Subscriber.

Diese Flexibilität ermöglicht wichtige Anwendungsfälle, die physische Replikation nicht bewältigen kann: am wichtigsten sind **ausfallfreie Major-Version-Upgrades** (Replizieren von einer alten Postgres-Version zu einer neuen, dann Umschalten — eine kritische Fähigkeit, da physische Replikation übereinstimmende Versionen erfordert, was logische Replikation zum Standard-Ansatz für Upgrades ohne Ausfallzeit macht), **Migrationen** (Verschieben von Daten auf einen neuen Server/Cluster mit minimaler Ausfallzeit), **selektive Replikation** (Replizieren nur bestimmter Tabellen) und **Integrationen** (Zuführung spezifischer Daten zu Analytics-Systemen, Data Warehouses oder anderen Datenbanken).

Das Verständnis des Publish/Subscribe-Setups (Publications definieren, was repliziert wird, Subscriptions konsumieren sie) und der angemessenen Anwendungsfälle (besonders Upgrades und Migrationen) spiegelt wertvolles Operational-Wissen wider.

Da Major-Version-Upgrades und Migrationen mit minimaler Ausfallzeit wichtige, reale Operational-Herausforderungen sind (und logische Replikation das Schlüssel-Tool dafür ist) und da selektive/systemübergreifende Replikation wertvolle Integrations-Muster ermöglicht, ist das Verständnis logischer Replikation — wie sie sich von physischer unterscheidet, ihre Flexibilität (versionsübergreifend, selektiv, beschreibbar) und ihre Anwendungsfälle (besonders ausfallfreie Upgrades und Migrationen) — wertvolles Senior-Level-Wissen für PostgreSQL-Operationen und -Architektur, besonders relevant für die wiederkehrende, risikoreiche Notwendigkeit, Datenbanken ohne Ausfallzeit zu aktualisieren und zu migrieren, ein Thema, das fortgeschrittenes Verständnis von Postgres-Bereitstellung und -Operationen demonstriert.