Replikation
Replikation hält Kopien von Daten an mehreren Orten. Zwischen Schreiben und Übernahme durch eine Kopie kann ein messbarer Verzug liegen.
- VerzugDas Replikat folgt dem Original mit Abstand.
- Alter StandWer im Fenster liest, sieht den alten Wert.
- Preis des Lesens am OriginalAktuell lesen belastet das Schreibsystem.
Einordnung
Warum das wichtig ist
Ein Lesereplikat entlastet das Schreibsystem, liefert im Verzug aber einen älteren Stand. Synchrone Replikation wartet auf die Kopie und ist langsamer; asynchrone ist schnell, lässt Verzug zu und kann beim Failover Änderungen verlieren. Die fachliche Zusage behandelt Konsistenzmodelle.
Dieser Baustein erklärt Datenkopien und Replikationsverzug. Für die fachliche Sichtbarkeitszusage siehe Konsistenzmodelle.
Auf einen Blick · Leader mit Replikas
Replikationsverzug und Status von B-1042
Variante: Der Shop nutzt für Kundenservice-Abfragen ein Lesereplikat der Bestelldatenbank, um viele Abfragen vom Schreibsystem fernzuhalten.
So liest du das Bild
- Verzug Du stellst den Verzug ein; das Replikat zeigt bezahlt erst danach.
- Alter Stand Ab 2 s Verzug zeigt die Abfrage um 12:00:01 noch „Zahlung offen“.
- Preis des Lesens am Original Mit Schalter sieht der Kundenservice bezahlt, die Primärdatenbank trägt mehr Last.
Nutzen & Grenzen
Hilft, wenn
- Viele Leser profitieren von Kopien, die Lesezugriffe auf dieselben Daten verteilen.
- Weitere Replikate bieten zusätzliche erreichbare Datenstände bei Ausfällen oder geografischer Verteilung.
- Fachlich akzeptierter und messbarer Leseverzug erlaubt asynchrone Replikation, Schreibbestätigungen zu entlasten.
Grenzen
- Asynchrone Replikation hat einen Verzug: Wer im Fenster liest, sieht einen älteren Stand.
- Beim Failover können Änderungen fehlen, die das Replikat noch nicht übernommen hatte.
- Replikation verteilt auch Löschfehler und fehlerhafte Änderungen sofort mit; dagegen helfen nur Backups. Die Zusage an Leser regeln Konsistenzmodelle.
In der Praxis
- Wähle synchrone oder asynchrone Bestätigung nach Verlustfenster und Aktualitätsbedarf. Halte fest, wann eine Änderung gegenüber dem Aufrufer als dauerhaft gilt.
- Leite Lesezugriffe nur an Replikate mit passender Aktualitätszusage. Miss Replikationsverzug und übe Failover samt Abgleich des wiederkehrenden Knotens.
- Trenne Replikation von unabhängigen Backups. Konsistenzmodelle klären zulässige Lesestände; Quorum beschreibt Bestätigungsgruppen.
Ausführliche Erklärung lesen
Replikation hält mehrere Kopien eines Datenbestands und überträgt Änderungen zwischen ihnen. Bestätigungsregeln bestimmen, wann ein Schreibvorgang als abgeschlossen gilt. Asynchrone Kopien können hinterherhinken; synchrone Bestätigung wartet auf weitere Teilnehmer und erhöht möglicherweise die Latenz.
Replikate unterstützen Leselast und Failover, ersetzen jedoch kein unabhängiges Backup. Lesewege müssen kenntlich machen, welche Aktualität sie zusichern. Führungswechsel, mögliche Datenverluste und Wiederanlauf brauchen getestete Regeln.
Konsistenzmodelle beschreiben, welche Sicht ein Leser erhält; Quorum bestimmt, welche Replikatantworten für eine Operation genügen.
Leader/Follower ist ein gängiges Schema, und ein Lesereplikat heißt auch Read Replica.
Das Verlustfenster beim Failover heißt im Betrieb oft RPO (Recovery Point Objective): wie viel Änderungsstand höchstens verloren gehen darf. Synchrone Replikation verkleinert es, kostet aber Schreiblatenz.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was zeigt die Abfrage um 12:00:01 bei 3 s Verzug, und was ändert der Schalter?
Lösung mit Begründung ansehen
„Zahlung offen“, denn das Replikat übernimmt erst 12:00:03. Mit Schalter: bezahlt, aber mehr Last auf der Primärdatenbank.
AnwendenAuf eine neue Lage übertragen
Der Kundenservice fragt um 12:00:02 ab. Was ist zu erwarten?
Lösung mit Begründung ansehen
Zahlung noch offen, denn die Replikation hat die Änderung erst um 12:00:03 übernommen. Eine spätere Abfrage zeigt bezahlt.
BewertenEine Alternative abwägen
Soll der Kundenservice stattdessen direkt die Primärdatenbank lesen? Wie wägst du ab?
Lösung mit Begründung ansehen
Der Stand wäre aktuell, aber die vielen Abfragen belasten wieder das Schreibsystem. Das Replikat schafft Lesekapazität gegen den Preis eines möglichen Verzugs.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
WAL und repliziertes Log
Ein Write-Ahead Log sichert Änderungen lokal, bevor Datenbankseiten geschrieben werden, und ermöglicht Wiederherstellung. Ein repliziertes Log ordnet bestätigte Einträge über mehrere Knoten und kann gemeinsame Zustandsänderungen absichern. Konsens beschreibt, wie Knoten sich über solche bestätigten Einträge einigen. Event Sourcing speichert dagegen fachliche Ereignisse als dauerhafte Quelle des Domänenzustands. Im Shop kann das Datenbank-WAL einen Lagerbestand wiederherstellen, während weder daraus allein eine replizierte Bestätigung noch ein fachliches Ereignismodell folgt.
Zum AusprobierenVergleiche im Shop einen Datenbankabsturz, den Ausfall eines Replikats und die Rekonstruktion einer Bestellung. Benenne für jeden Fall, ob WAL-Wiederherstellung, bestätigte Log-Replikation mit Konsens oder fachliche Ereignishistorie mit Event Sourcing zuständig ist, und prüfe den Wiederanlauf mit passenden Daten.
Weiterführende Bausteine
Quellen
- PostgreSQL · Log-Shipping Standby Servers (öffnet in neuem Tab)Erklärt synchrone und asynchrone Replikation mit Failover.
- PostgreSQL · Logical Replication (öffnet in neuem Tab)Beschreibt Replikation anhand logischer Datenänderungen.
- MongoDB · Replication (öffnet in neuem Tab)Beschreibt Replica Sets, Redundanz und automatische Primärwahl.
- Unmesh Joshi · Write-Ahead Log (öffnet in neuem Tab)Dauerhaftes Änderungslog für Wiederherstellung nach Ausfall.
- Unmesh Joshi · Patterns of Distributed Systems (öffnet in neuem Tab)Ordnet Replicated Log und verwandte Koordinationsmuster ein.