Datenbank-Replikation verstehen: Von Primary bis Read-Replica

1. Was Datenbank-Replikation wirklich loest

Datenbank-Replikation kopiert Daten von einer Primary-Instanz kontinuierlich auf eine oder mehrere Replica-Instanzen. Der Grund ist selten reine Redundanz zum Selbstzweck, sondern zwei sehr konkrete Probleme: Leselast, die eine einzelne Instanz nicht mehr stemmen kann, und Ausfallsicherheit, wenn die Primary-Instanz aus irgendeinem Grund nicht mehr erreichbar ist. Ohne Datenbank-Replikation ist jede Anwendung von der Verfuegbarkeit genau einer Datenbank-Instanz abhaengig, ein Single Point of Failure, der in produktiven Systemen selten akzeptabel ist.

Der Unterschied zwischen guter und schlechter Replikations-Architektur liegt selten in der Technik selbst, sondern im Verstaendnis der Konsistenzgarantien. Wer Datenbank-Replikation als reine Kopie ohne Verzoegerung missversteht, baut Anwendungen, die auf einer Replica lesen und veraltete Daten fuer aktuell halten. Die folgenden Abschnitte erklaeren physische und logische Replikation, synchrone gegenueber asynchroner Replikation, und wie Read-Replicas und Failover-Strategien in der Praxis konfiguriert werden.

2. Physische vs. logische Replikation

Physische Datenbank-Replikation kopiert die Datenbank auf Byte-Ebene: jede Aenderung an Datenseiten wird identisch auf die Replica uebertragen, meist ueber denselben Write-Ahead-Log-Mechanismus, der auch fuer Crash-Recovery genutzt wird. Das Ergebnis ist eine exakte Kopie der Primary-Instanz, inklusive Indizes, Statistiken und interner Struktur. Physische Replikation ist effizient, weil sie keine SQL-Interpretation braucht, hat aber einen Nachteil: Die Replica muss dieselbe Datenbank-Version und dieselbe Architektur haben wie die Primary.

Logische Datenbank-Replikation repliziert auf Ebene von Aenderungsoperationen (INSERT, UPDATE, DELETE), nicht auf Byte-Ebene. Das erlaubt Flexibilitaet, die physische Replikation nicht bietet: unterschiedliche Datenbank-Versionen zwischen Primary und Replica, selektive Replikation nur bestimmter Tabellen, und sogar Replikation zwischen unterschiedlichen Datenbank-Engines. Der Preis dafuer ist ein hoeherer Verarbeitungsaufwand, weil jede Aenderung interpretiert und erneut angewendet werden muss.

-- PostgreSQL: set up physical streaming replication
-- On the primary (postgresql.conf)
-- wal_level = replica
-- max_wal_senders = 10

-- On the replica: base backup, then recovery config
-- pg_basebackup -h primary_host -D /var/lib/postgresql/data -U replicator -P

-- Check replication status on the primary
SELECT client_addr, state, sync_state, replay_lag
FROM pg_stat_replication;

-- Logical replication: publication on primary, subscription on replica
CREATE PUBLICATION orders_pub FOR TABLE orders;
-- On the replica
CREATE SUBSCRIPTION orders_sub
CONNECTION 'host=primary_host dbname=shop user=replicator'
PUBLICATION orders_pub;

3. Synchrone vs. asynchrone Replikation

Bei synchroner Datenbank-Replikation bestaetigt die Primary-Instanz eine Transaktion erst dann als committed, wenn mindestens eine Replica die Aenderung ebenfalls bestaetigt hat. Das garantiert, dass ein committeter Datensatz niemals verloren geht, selbst wenn die Primary unmittelbar danach ausfaellt. Der Preis ist erhoehte Latenz bei jeder Schreiboperation, weil auf die Netzwerk-Bestaetigung der Replica gewartet werden muss, was bei geografisch entfernten Replicas spuerbar wird.

Asynchrone Datenbank-Replikation bestaetigt eine Transaktion sofort auf der Primary, unabhaengig davon, ob die Replica die Aenderung bereits erhalten hat. Das minimiert Schreib-Latenz, hat aber eine ernste Konsequenz: Faellt die Primary genau zwischen Commit und Uebertragung an die Replica aus, gehen die letzten Transaktionen unwiederbringlich verloren. Die meisten produktiven Systeme nutzen asynchrone Replikation fuer Read-Replicas und reservieren synchrone Replikation fuer Faelle, in denen Datenverlust inakzeptabel ist, etwa bei Finanztransaktionen.

4. Read-Replicas fuer Leselast-Verteilung

Eine Read-Replica ist eine schreibgeschuetzte Kopie der Primary-Datenbank, die ausschliesslich Leseanfragen bedient. Diese Form der Datenbank-Replikation loest ein sehr konkretes Skalierungsproblem: Bei stark lesenden Anwendungen (Reporting-Dashboards, Produktkataloge, Suchfunktionen) ist die Leselast oft um Groessenordnungen hoeher als die Schreiblast. Statt die Primary mit dieser Leselast zu belasten, verteilt man Leseanfragen auf mehrere Read-Replicas und entlastet die Primary fuer Schreiboperationen.

Wichtig ist, dass Anwendungscode explizit zwischen Lese- und Schreibverbindung unterscheidet, meist ueber einen Connection-Router oder ein Datenbank-Proxy wie PgBouncer oder ProxySQL. Eine haeufige Fehlerquelle: Eine Anwendung schreibt auf die Primary und liest unmittelbar danach von einer Replica, bevor die Aenderung dort angekommen ist, der Nutzer sieht seine eigene Aenderung nicht. Dieses Problem heisst Read-after-Write-Konsistenz und muss bei Datenbank-Replikation explizit adressiert werden, etwa durch gezieltes Lesen von der Primary direkt nach einem Schreibvorgang.

5. Replikations-Lag verstehen und messen

Replikations-Lag ist die Zeitspanne zwischen einer Aenderung auf der Primary und ihrer Ankunft auf einer Replica. Bei asynchroner Datenbank-Replikation ist dieser Lag niemals exakt null, sondern schwankt je nach Netzwerklatenz, Schreiblast auf der Primary und Ressourcen der Replica. Wachsender Lag ist ein Fruehwarnsignal: Entweder die Replica-Hardware ist unterdimensioniert, oder die Schreiblast auf der Primary uebersteigt die Verarbeitungskapazitaet der Replica.

Monitoring des Replikations-Lags gehoert zu jedem produktiven Replikations-Setup. In PostgreSQL liefert pg_stat_replication den Lag in Bytes und optional in Zeit, in MySQL zeigt SHOW REPLICA STATUS den Wert Seconds_Behind_Source. Alerting bei einem Lag oberhalb eines definierten Schwellwerts verhindert, dass Anwendungen unbemerkt stark veraltete Daten von einer Replica lesen.

-- MySQL: check replication lag on a replica
SHOW REPLICA STATUS\G
-- Look for: Seconds_Behind_Source, Replica_IO_Running, Replica_SQL_Running

-- PostgreSQL: replication lag in bytes and time on the primary
SELECT
  client_addr,
  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes,
  replay_lag
FROM pg_stat_replication;

-- Alert threshold example: fail health check if lag exceeds 30 seconds
SELECT CASE
  WHEN EXTRACT(EPOCH FROM replay_lag) > 30 THEN 'UNHEALTHY'
  ELSE 'HEALTHY'
END AS replica_status
FROM pg_stat_replication
LIMIT 1;

6. Failover-Strategien beim Primary-Ausfall

Faellt die Primary-Instanz aus, muss eine der Replicas zur neuen Primary befoerdert werden, ein Prozess namens Failover. Manuelles Failover, bei dem ein Mensch den Ausfall erkennt und die Beforderung ausloest, ist einfach zu verstehen, aber langsam, oft mehrere Minuten. Automatisches Failover mit Werkzeugen wie Patroni oder Orchestrator erkennt den Ausfall selbststaendig und promotet eine geeignete Replica innerhalb von Sekunden, birgt aber ein eigenes Risiko: Split-Brain, bei dem zwei Instanzen gleichzeitig glauben, die Primary zu sein.

Ein robustes Failover-Setup fuer Datenbank-Replikation nutzt einen externen Konsens-Mechanismus (etwa etcd oder Consul), um eindeutig festzulegen, welche Instanz die Primary ist, statt sich auf lokale Heuristiken einzelner Knoten zu verlassen. Nach einem Failover muessen zudem alle verbleibenden Replicas neu auf die neue Primary ausgerichtet werden, und Anwendungsverbindungen muessen automatisch auf die neue Primary umgeleitet werden, meist ueber einen virtuellen Hostnamen oder einen Proxy.

-- Check current replica status before promoting it during failover
SELECT pg_is_in_recovery(); -- true on a replica, false on a primary

-- Promote a PostgreSQL replica to become the new primary
-- (executed by the failover tool, e.g. Patroni, not manually in normal operation)
SELECT pg_promote();

-- After promotion, verify the new primary accepts writes
INSERT INTO health_check (checked_at) VALUES (NOW());

7. Multi-Primary-Replikation und ihre Fallstricke

Multi-Primary-Replikation erlaubt Schreiboperationen auf mehreren Instanzen gleichzeitig, statt sie auf eine einzige Primary zu beschraenken. Das klingt attraktiv fuer geografisch verteilte Anwendungen, bringt aber ein grundlegendes Problem mit sich: Konflikterkennung. Werden dieselbe Zeile auf zwei verschiedenen Primaries gleichzeitig geaendert, muss ein Konfliktloesungsmechanismus entscheiden, welche Aenderung gewinnt, meist ueber Last-Write-Wins oder anwendungsspezifische Logik.

In der Praxis ist Multi-Primary-Datenbank-Replikation deutlich komplexer zu betreiben als ein einfaches Primary-Replica-Modell und wird meist nur eingesetzt, wenn geografisch verteilte Schreiblast einen echten geschaeftlichen Vorteil bringt. Fuer die meisten Anwendungen ist ein einzelnes Primary mit mehreren Read-Replicas ausreichend und deutlich einfacher zu betreiben, zu debuggen und zu ueberwachen.

-- Last-write-wins conflict resolution: a common pattern for multi-primary setups
CREATE TABLE customer_profile (
  customer_id INT PRIMARY KEY,
  email VARCHAR(200),
  updated_at TIMESTAMP NOT NULL,
  origin_node VARCHAR(50) NOT NULL
);

-- Conflict resolution logic applied during replication merge:
-- keep the row with the most recent updated_at, break ties by origin_node
SELECT DISTINCT ON (customer_id) *
FROM customer_profile
ORDER BY customer_id, updated_at DESC, origin_node ASC;

8. Replikation in der Anwendung beruecksichtigen

Anwendungscode muss Datenbank-Replikation aktiv beruecksichtigen, statt sie als transparente Infrastruktur-Angelegenheit zu behandeln. Kritische Leseoperationen unmittelbar nach einem Schreibvorgang gehoeren auf die Primary geroutet, nicht auf eine Replica mit unbekanntem Lag. Weniger kritische Leseoperationen, etwa fuer Reporting oder Analytics, koennen problemlos auf Replicas laufen, selbst mit mehreren Sekunden Verzoegerung.

Ein bewaehrtes Muster ist das explizite Markieren von Datenbank-Verbindungen als read-write oder read-only im Anwendungscode, kombiniert mit einem Connection-Router, der diese Markierung respektiert. So bleibt die Entscheidung, ob eine Query auf die Primary oder eine Replica geht, eine bewusste, testbare Entscheidung, statt eines impliziten Zufallsergebnisses eines Load Balancers.

-- Example: explicit read/write connection routing at the application layer
-- Write connection: always the primary
-- DSN: postgresql://app_user@primary.internal:5432/shop

-- Read connection: routed to a replica pool via a proxy
-- DSN: postgresql://app_user@replica-pool.internal:5432/shop

-- Critical read right after a write: force primary explicitly
BEGIN;
UPDATE orders SET status = 'paid' WHERE order_id = 1001;
COMMIT;

-- Immediately re-reading order 1001 must use the primary connection,
-- not the replica pool, to guarantee read-after-write consistency
SELECT status FROM orders WHERE order_id = 1001; -- via primary DSN

-- Non-critical reporting query: safe to run on any replica
SELECT region, SUM(total_amount)
FROM orders
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY region; -- via replica-pool DSN

9. Replikationsmodelle im Vergleich

Die Wahl des richtigen Replikationsmodells haengt von Konsistenzanforderungen, Latenztoleranz und Betriebsaufwand ab.

Fuer die meisten Anwendungen ist asynchrone Datenbank-Replikation mit einer oder mehreren Read-Replicas und automatisiertem Failover ein guter Kompromiss zwischen Betriebsaufwand und Ausfallsicherheit. Synchrone Replikation lohnt sich nur, wenn Datenverlust im Failover-Fall geschaeftlich inakzeptabel ist, und Multi-Primary sollte die Ausnahme bleiben, nicht die Standard-Architektur.

10. Zusammenfassung

Datenbank-Replikation loest zwei zentrale Probleme: Verteilung von Leselast auf mehrere Instanzen und Ausfallsicherheit gegenueber dem Verlust der Primary-Instanz. Physische Replikation kopiert auf Byte-Ebene und ist effizient, logische Replikation repliziert Aenderungsoperationen und bietet mehr Flexibilitaet. Synchrone Replikation verhindert Datenverlust um den Preis hoeherer Latenz, asynchrone Replikation minimiert Latenz um den Preis eines moeglichen Datenverlusts im Failover-Fall.

Read-Replicas entlasten die Primary bei lesehastigen Anwendungen, muessen aber mit Read-after-Write-Konsistenz im Anwendungscode explizit beruecksichtigt werden. Automatisches Failover reduziert Ausfallzeiten drastisch, erfordert aber einen robusten Konsens-Mechanismus, um Split-Brain zu vermeiden. Wer Datenbank-Replikation richtig konfiguriert, gewinnt Skalierbarkeit und Ausfallsicherheit, ohne stille Konsistenzprobleme in Kauf zu nehmen.

11. FAQ: Datenbank-Replikation verstehen