Read Replicas richtig einsetzen: Skalierung von Lesezugriffen

1. Welches Problem Read Replicas wirklich loesen

Eine Read Replica ist eine Kopie einer Datenbankinstanz, die kontinuierlich Aenderungen vom primaeren Server (Primary) uebernimmt und ausschliesslich fuer Lesezugriffe zur Verfuegung steht. Der Grundgedanke ist einfach: In den meisten Anwendungen uebersteigt die Anzahl der Lesezugriffe die Anzahl der Schreibzugriffe um ein Vielfaches, oft im Verhaeltnis von zehn zu eins oder mehr. Statt die gesamte Last auf einer einzigen Instanz zu buendeln, verteilt man Lesezugriffe auf mehrere Read Replicas und entlastet so den Primary fuer Schreiboperationen und kritische Transaktionen.

Der Effekt zeigt sich zuerst bei CPU- und I/O-Auslastung. Ein Primary, der gleichzeitig Schreibtransaktionen verarbeiten und komplexe Reporting-Abfragen bedienen muss, geraet unter Last schnell an Grenzen, die sich in steigenden Latenzen fuer alle Anfragen aeussern, auch fuer Schreiboperationen. Durch das Auslagern von Leseverkehr auf Read Replicas bleibt der Primary fuer das kritischste Workload reserviert: konsistente, transaktionssichere Schreibzugriffe. Reporting-Queries, Analytics-Dashboards und die meisten Anzeige-Endpunkte einer Anwendung sind ideale Kandidaten fuer diese Auslagerung.

Wichtig ist die Abgrenzung zu Sharding: Read Replicas skalieren Lesezugriffe horizontal, aendern aber nichts an der Schreiblast oder der Datenmenge, die ein einzelner Server verwalten muss. Wer Schreiblast oder Speichervolumen skalieren will, braucht Sharding oder Partitionierung, nicht zusaetzliche Replicas. Diese Unterscheidung entscheidet oft darueber, ob ein Skalierungsprojekt das eigentliche Problem loest oder nur Symptome verschiebt.

2. Replikationsarten: physisch, logisch, statement-basiert

Die gaengigen relationalen Datenbanken bieten mehrere Mechanismen fuer Replikation, die sich in Granularitaet und Flexibilitaet unterscheiden. Physische Replikation, in PostgreSQL als Streaming Replication bekannt, kopiert Aenderungen auf Block-Ebene aus dem Write-Ahead-Log (WAL). Das ist effizient und garantiert eine exakte binaere Kopie, erlaubt aber keine selektive Replikation einzelner Tabellen und erfordert identische Major-Versionen zwischen Primary und Replica.

Logische Replikation arbeitet auf Zeilenebene und erlaubt es, nur bestimmte Tabellen zu replizieren, zwischen unterschiedlichen Datenbankversionen zu synchronisieren oder sogar in ein anderes Schema zu schreiben. PostgreSQL implementiert das ueber Publications und Subscriptions, MySQL ueber row-based Binary Logging. Der Vorteil liegt in der Flexibilitaet, der Nachteil in leicht hoeherem Overhead und komplexerer Konfliktbehandlung bei bidirektionaler Replikation.

Statement-basierte Replikation, historisch der erste Ansatz in MySQL, repliziert die ausgefuehrten SQL-Anweisungen selbst statt der resultierenden Datenaenderungen. Das Problem: nicht-deterministische Funktionen wie NOW() oder RAND() koennen auf der Read Replica zu abweichenden Ergebnissen fuehren, wenn sie zu einem anderen Zeitpunkt ausgefuehrt werden. Moderne Setups nutzen deshalb fast ausschliesslich row-based oder physische Replikation, bei der die tatsaechlichen Datenaenderungen uebertragen werden, nicht die Anweisungen.

-- PostgreSQL: Replikationsstatus auf dem Primary pruefen
SELECT
    client_addr,
    application_name,
    state,
    sync_state,
    pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
FROM pg_stat_replication;

-- MySQL/MariaDB: Status einer Read Replica pruefen
SHOW REPLICA STATUS\G
-- Wichtige Felder: Seconds_Behind_Source, Replica_IO_Running, Replica_SQL_Running

-- Publication fuer logische Replikation anlegen (PostgreSQL)
CREATE PUBLICATION orders_pub FOR TABLE orders, order_items;

-- Auf der Replica-Seite abonnieren
CREATE SUBSCRIPTION orders_sub
    CONNECTION 'host=primary.internal dbname=shop user=replicator'
    PUBLICATION orders_pub;

3. Replication Lag verstehen und messen

Replication Lag ist die Zeitspanne zwischen einer Aenderung auf dem Primary und dem Moment, in dem dieselbe Aenderung auf der Read Replica sichtbar wird. Dieser Lag ist keine seltene Ausnahme, sondern eine strukturelle Eigenschaft asynchroner Replikation. Netzwerklatenz, hohe Schreiblast auf dem Primary, langlaufende Transaktionen auf der Replica und unzureichende I/O-Kapazitaet auf der Replica-Seite sind die haeufigsten Ursachen fuer wachsenden Lag.

Ein oft uebersehenes Muster ist der sogenannte Read-after-Write-Fall: Ein Nutzer aendert ein Profil, die Anwendung schreibt auf den Primary, leitet danach sofort zu einer Leseansicht weiter, und diese liest von einer Read Replica, die die Aenderung noch nicht uebernommen hat. Fuer den Nutzer sieht es so aus, als waere die Aenderung verloren gegangen. Dieses Problem loest man entweder durch kurzzeitiges Lesen vom Primary direkt nach einem Schreibvorgang oder durch sogenanntes Read-your-writes-Routing, bei dem die Anwendung eine Positionsmarke des letzten Schreibvorgangs mitfuehrt und erst dann von einer Replica liest, wenn diese die Marke erreicht hat.

Die Messung von Replication Lag sollte kontinuierlich erfolgen, nicht nur stichprobenartig. PostgreSQL bietet dazu pg_wal_lsn_diff() fuer den Byte-Abstand und zusaetzlich Zeitstempel-basierte Messungen ueber pg_last_xact_replay_timestamp(). MySQL liefert mit Seconds_Behind_Source einen direkten Zeitwert, der allerdings bei Netzwerkproblemen ungenau werden kann, weil er auf dem Zeitstempel des letzten empfangenen Events basiert, nicht auf einer echten Ende-zu-Ende-Messung.

4. Read/Write Splitting in der Anwendung implementieren

Read/Write Splitting bezeichnet die Logik, mit der eine Anwendung entscheidet, ob eine Anfrage an den Primary oder an eine Read Replica geschickt wird. Die einfachste Umsetzung erfolgt auf ORM- oder Repository-Ebene: Schreiboperationen (INSERT, UPDATE, DELETE) gehen immer an den Primary, reine SELECT-Anfragen werden per Round-Robin oder gewichtetem Zufall auf verfuegbare Replicas verteilt. Diese Trennung sollte zentral in einer Verbindungsschicht liegen, nicht verstreut in einzelnen Repository-Methoden, damit sie konsistent angewendet wird.

Ein haeufiger Fehler ist es, Read/Write Splitting nach HTTP-Methode zu entscheiden, also GET immer zur Replica und POST immer zum Primary. Das ignoriert, dass viele GET-Endpunkte direkt nach einem Schreibvorgang aufgerufen werden und deshalb konsistente Daten brauchen. Ein robusteres Muster ist es, Transaktionen explizit zu markieren: innerhalb einer Transaktion, die auch nur einen einzigen Schreibzugriff enthaelt, bleibt die gesamte Verbindung beim Primary, unabhaengig von einzelnen SELECT-Anweisungen darin.

Middleware-Loesungen wie ProxySQL fuer MySQL oder PgBouncer in Kombination mit pgpool-II fuer PostgreSQL koennen Read/Write Splitting transparent auf Infrastrukturebene uebernehmen, sodass die Anwendung nur eine einzige Verbindung sieht und die Verteilung unsichtbar im Hintergrund geschieht. Der Vorteil liegt in geringerer Komplexitaet im Anwendungscode, der Nachteil in einer zusaetzlichen Infrastrukturkomponente, die selbst hochverfuegbar betrieben werden muss.

-- Beispielhafte Konfiguration: Verbindungsrouten fuer eine Anwendung
-- (Pseudo-Konfiguration, wie sie in vielen ORM-Adaptern vorkommt)

-- primary: nur Schreibzugriffe und Transaktionen mit Schreibanteil
-- replicas: reine Lesezugriffe ausserhalb einer Schreibtransaktion

-- Beispiel: explizite Route in einer Transaktion erzwingen
BEGIN;
-- gesamte Transaktion bleibt am Primary, auch wenn sie mit SELECT beginnt
SELECT balance FROM accounts WHERE id = 42 FOR UPDATE;
UPDATE accounts SET balance = balance - 100 WHERE id = 42;
COMMIT;

-- Beispiel: reiner Lesezugriff ausserhalb einer Transaktion,
-- darf an eine Read Replica geroutet werden
SELECT id, name, email FROM customers WHERE id = 42;

5. Wenn Konsistenz wichtiger ist als Lastverteilung

Nicht jede Leseanfrage eignet sich fuer eine Read Replica. Finanzielle Salden, Bestandspruefungen vor einem Checkout und alle Leseoperationen, die unmittelbar Teil eines Schreibvorgangs sind, sollten konsequent vom Primary gelesen werden. Der Grund liegt in genau dem Replication Lag, der im vorherigen Abschnitt beschrieben wurde: Ein veralteter Lagerbestand kann zu Ueberverkauf fuehren, ein veralteter Kontostand zu doppelter Auszahlung.

Eine praktikable Faustregel ist, Leseoperationen nach ihrer Konsistenzanforderung zu klassifizieren, nicht nach technischer Bequemlichkeit. Anzeige-Daten wie Produktbeschreibungen, Blogartikel oder Nutzerprofile in einem oeffentlichen Kontext vertragen typischerweise Sekunden an Lag ohne spuerbaren Nachteil. Transaktionskritische Daten dagegen brauchen entweder den Primary oder eine explizite Synchronisationslogik, die auf die Replay-Position der Replica wartet, bevor die Leseanfrage beantwortet wird.

Manche Datenbanksysteme bieten dafuer eingebaute Mechanismen: PostgreSQL kennt seit Version 10 synchrone Replikation mit synchronous_commit, bei der ein Commit erst bestaetigt wird, nachdem mindestens eine Replica die Aenderung quittiert hat. Das eliminiert Lag fuer diese spezifischen Transaktionen vollstaendig, kostet aber Latenz bei jedem Schreibvorgang und macht Verfuegbarkeit von der Erreichbarkeit der synchronen Replica abhaengig, ein klassischer Tradeoff zwischen Konsistenz und Verfuegbarkeit.

6. Failover und Replica-Promotion planen

Faellt der Primary aus, muss eine Read Replica zum neuen Primary befoerdert werden, ein Vorgang, der als Promotion bezeichnet wird. Automatisiertes Failover erfordert einen Konsens-Mechanismus, der entscheidet, welche Replica befoerdert wird, typischerweise die mit dem geringsten Lag zum Zeitpunkt des Ausfalls. Tools wie Patroni fuer PostgreSQL oder Orchestrator fuer MySQL uebernehmen diese Entscheidung automatisiert und aktualisieren DNS- oder Proxy-Konfiguration, damit Anwendungen ohne manuellen Eingriff auf den neuen Primary zeigen.

Ein kritischer Fallstrick ist das sogenannte Split-Brain-Szenario: Wenn der alte Primary nach einem Netzwerkpartitionsereignis wieder erreichbar wird, aber eine andere Replica bereits befoerdert wurde, existieren kurzzeitig zwei Primaries gleichzeitig, die widerspruechliche Schreibzugriffe akzeptieren. Fencing-Mechanismen, die den alten Primary aktiv isolieren, bevor eine neue Promotion abgeschlossen wird, sind deshalb kein optionales Detail, sondern Voraussetzung fuer sicheres automatisiertes Failover.

Manuelles Failover bleibt fuer viele mittelgrosse Betriebe die pragmatischere Wahl: ein dokumentiertes Runbook, das Lag pruefen, Replica befoerdern und Anwendungskonfiguration aktualisieren in klaren Schritten beschreibt, reduziert das Risiko von Fehlkonfigurationen gegenueber einer selten getesteten automatisierten Loesung. Wichtig ist in jedem Fall, den Promotion-Vorgang regelmaessig in einer Staging-Umgebung zu uebern, damit er im Ernstfall nicht zum ersten Mal ausgefuehrt wird.

7. Monitoring: Lag, Health-Checks und Alarme

Ohne kontinuierliches Monitoring bleibt Replication Lag unsichtbar, bis er sich in fehlerhaften Anwendungsdaten aeussert. Ein solides Setup exportiert Lag-Metriken in Sekunden und in Bytes an ein Monitoring-System wie Prometheus, mit klar definierten Schwellwerten fuer Warnungen und kritische Alarme. Ein Lag von wenigen hundert Millisekunden ist in vielen Anwendungen unproblematisch, ein Lag von mehreren Minuten deutet dagegen meist auf ein strukturelles Problem hin, etwa unzureichende I/O-Kapazitaet auf der Replica.

Health-Checks fuer Read Replicas sollten mehr pruefen als reine Erreichbarkeit. Eine Replica, die erreichbar ist, aber seit Stunden keine neuen Aenderungen mehr empfaengt, weil der Replikationsprozess lautlos abgebrochen ist, liefert konsequent veraltete Daten, ohne dass ein einfacher Ping-Check das erkennen wuerde. Ein guter Health-Check prueft deshalb explizit den Zeitstempel der zuletzt angewendeten Transaktion und vergleicht ihn gegen einen Schwellwert.

Alarmierung sollte gestaffelt erfolgen: eine Warnung bei moderatem Lag-Anstieg, ein kritischer Alarm, sobald ein Schwellwert ueberschritten wird, ab dem Anwendungslogik beginnt, fehlerhafte Daten anzuzeigen. Wichtig ist zudem, aus der Replica automatisch aus dem Load-Balancing-Pool zu entfernen, sobald der Lag einen definierten Grenzwert uebersteigt, statt weiterhin Anfragen an eine erkennbar veraltete Instanz zu senden.

8. Skalierungsgrenzen: wie viele Replicas sind sinnvoll

Read Replicas skalieren nicht unbegrenzt linear. Jede zusaetzliche Replica erhoeht die Netzwerk- und CPU-Last auf dem Primary, weil dieser die Aenderungen an jede Replica einzeln streamen muss. Ab einer gewissen Anzahl, in der Praxis haeufig zwischen fuenf und zehn direkten Replicas, wird der Primary selbst zum Flaschenhals des Replikationsprozesses, nicht mehr zum Flaschenhals der Anwendungslast.

Kaskadierende Replikation loest dieses Problem teilweise: statt dass alle Replicas direkt vom Primary lesen, uebernehmen einige Replicas ihre Aenderungen von einer anderen Replica, die selbst wiederum vom Primary liest. Das reduziert die direkte Last auf dem Primary, erhoeht aber den kumulierten Lag fuer Replicas am Ende der Kaskade, ein weiterer klassischer Tradeoff zwischen Skalierbarkeit und Aktualitaet.

Wer feststellt, dass selbst mit optimaler Verteilung von Leseverkehr auf Read Replicas die Schreiblast oder das Datenvolumen zum limitierenden Faktor wird, sollte nicht weitere Replicas hinzufuegen, sondern Sharding oder Partitionierung in Betracht ziehen. Read Replicas loesen ein Leseverkehrsproblem, kein Schreiblastproblem, und diese Grenze klar zu erkennen verhindert, dass ein Architekturteam Zeit in die falsche Skalierungsstrategie investiert.

9. Read Replicas im Vergleich: Ansaetze und Werkzeuge

Die Wahl zwischen synchroner und asynchroner Replikation, zwischen automatisiertem und manuellem Failover sowie zwischen anwendungsseitigem und infrastrukturseitigem Read/Write Splitting bestimmt massgeblich, wie ein Team mit Read Replicas in der Praxis umgeht. Die folgende Tabelle stellt die wichtigsten Entscheidungspunkte gegenueber.

In der Praxis kombinieren viele Teams beide Ansaetze: asynchrone Read Replicas fuer den Grossteil des Leseverkehrs, ergaenzt durch eine einzelne synchrone Replica fuer die kritischsten Tabellen, etwa Zahlungsstatus oder Bestandsdaten. Diese hybride Strategie liefert die Performance-Vorteile der asynchronen Replikation, ohne bei den wichtigsten Datensaetzen auf Konsistenzgarantien zu verzichten.

10. Zusammenfassung

Read Replicas richtig einzusetzen bedeutet mehr als das Aufsetzen einer zusaetzlichen Instanz. Physische oder logische Replikation liefert die technische Grundlage, aber die eigentliche Arbeit liegt im Umgang mit Replication Lag: welche Leseanfragen konsistente Daten brauchen, welche einen kurzen Lag vertragen, und wie die Anwendung diese Entscheidung zuverlaessig trifft. Read/Write Splitting sollte zentral implementiert sein, nicht verstreut in einzelnen Codepfaden, und Transaktionen mit Schreibanteil gehoeren konsequent auf den Primary.

Failover-Planung, Monitoring von Lag und Health-Checks sind kein nachtraeglicher Feinschliff, sondern integraler Bestandteil eines produktionstauglichen Setups mit Read Replicas. Wer diese Aspekte von Anfang an mitdenkt, gewinnt echte Lastverteilung, ohne die Datenkonsistenz der Anwendung zu gefaehrden. Wichtig bleibt die Grenze im Blick zu behalten: Replicas skalieren Lesezugriffe, nicht Schreiblast, und fuer Letzteres braucht es andere Werkzeuge wie Sharding.

11. FAQ: Read Replicas richtig einsetzen