Replikation

Dr. Alexander Paar

Duale Hochschule Schleswig-Holstein
Replikation
Replikation (engl. replication) bezeichnet die mehrfache Speicherung
derselben Daten an meist mehreren verschiedenen Standorten und die
Synchronisation dieser Datenquellen
• Für niedrige Latenz sollen Daten geographisch nah bei den Anwendern sein
• Ein System soll auch nach dem Ausfall einzelner Knoten verfügbar sein
• Mit zusätzlichen Knoten soll horizontal skaliert werden (engl. scale out)
Annahme
• Der Datensatz ist klein genug, um auf einem Knoten gespeichert zu werden
• Ohne diese Annahme: Partitionierung (engl. partitioning, sharding)
erforderlich
Replikation
Replikation ist einfach wenn sich die Daten nicht ändern
• Kopiere den Datensatz auf jeden Knoten
Die Herausforderung ist die Handhabung von Änderungen
Drei gängige Ansätze für die Replikation von Änderungen
• Single leader
• Multi leader
• Leaderless
Fast alle verteilten Datenbanken verwenden einen dieser Ansätze, mit
dessen Vor- und Nachteilen (z.B. synchrone/asynchrone Replikation)
Literatur
Designing Data-Intensive Applications: The
Big Ideas Behind Reliable, Scalable, and
Maintainable Systems (O'Reilly UK Ltd.) von
Martin Kleppmann
Leader-basierte Replikation
Master-slave, active/passive replication
Leader-basierte
Replikation
Jeder Knoten mit einer Kopie der Datenbank ist ein
Replikat (engl. replica)
Damit alle Daten alle Replikate erreichen, muss
jeder Schreibzugriff von jedem Replikat verarbeitet
werden
Master-slave, active/passive replication:
• Ein Replikat ist der Leader (master, primary)
• Schreibzugriffe erfolgen nur über den Leader
• Die anderen Replikate sind die Follower (engl.
read replicas, slaves, secondaries)
• Der Leader schreibt Daten in seinen Speicher
und in ein Replikationslog (engl. replication log,
change stream)
• Die Follower verarbeiten die Schreibzugriffe
dieses Logs in der identischen Reihenfolge
• Lesezugriffe können von Leader und Follower
beantwortet werden
Synchrone vs.
asynchrone
Replikation
Die Replikation zu Follower 1 ist synchron (engl.
synchronous)
• Der Leader wartet auf eine Bestätigung der
Schreiboperation durch den Follower
Vorteil einer synchronen Replikation
• Follower sind garantiert up-to-date
Nachteil einer synchronen Replikation
• Wenn synchrone Follower nicht verfügbar
sind können keine Schreiboperationen
durchgeführt werden
Halb-synchrone (engl. semi-synchronous)
Replikation
• In der Praxis bedeutet synchrone Replikation
dass ein Follower synchron und alle anderen
asynchron sind
Synchrone vs.
asynchrone
Replikation
Die Replikation zu Follower 2 ist asynchron
(engl. asynchronous)
• Der Leader wartet nicht auf eine
Benachrichtigung durch Follower 2
Vorteil einer asynchronen Replikation
• Der Leader kann, auch wenn alle Follower
zurückgefallen sind, weiter Schreib-
operationen durchführen sind
Nachteil einer asynchronen Replikation
• Wenn der Leader ausfällt kann er nicht
wiederhergestellt werden
• Schreibzugriffe, die noch nicht an die
Follower repliziert wurden, sind verloren
Asynchrone Replikation ist weit verbreitet bei
vielen (geographisch verteilten) Followers

Neue Follower
Von Zeit zu Zeit müssen neue Follower
erzeugt werden
• Höhere Anzahl Replikate, Ersetzung
ausgefallener Follower
Ein einfaches Kopieren von Daten ist nicht
ausreichend
• Klienten senden ununterbrochen
Schreibzugriffe
• Sperre von Schreibzugriffen (engl. write
lock) oft nicht akzeptabel
Die konkreten Schritte für das Erzeugen
neuer Follower variieren ja nach System
Prozess für das Erzeugen neuer Follower
1. Erzeuge einen konsistenten Schnappschuss (engl.
snapshot) der Datenbank, am besten ohne Sperre der DB
2. Kopiere den Schnappschuss auf den neuen Follower
3. Der neue Follower verbindet sich mit dem Leader und
fragt alle Änderungen seit der Erstellung des
Schnappschusses an. Dazu muss der Schnappschuss
eindeutig einer Position im Replikationslog zugeordnet
werden können (MySQL: binlog coordinates, PostgreSQL:
log sequence number).
4. Wenn der neue Follower alle Änderungen seit dem
Schnappschuss verarbeitet hat ist er auf dem aktuellen
Stand (engl. caught up)

Ausfall von Knoten
Jeder Knoten im System kann ausfallen
• Hardwareausfall
• Planmäßige Reboots
Die Möglichkeit, Knoten ohne Ausfallzeit
(engl. downtime) neu zu starten ist ein
wichtiges Feature
Follower Failure: Catch-up Recovery
Jeder Follower verwaltet lokal ein Log der empfangenen
Schreiboperationen
Ein Follower kann von einem Ausfall (Knoten, Netzwerk)
leicht wiederhergestellt werden
1. Aus dem Log ist die letzte vor dem Ausfall verarbeitete
Schreiboperation bekannt
2. Der Follower verbindet sich erneut mit dem Leader und
fragt alle verpassten Schreibzugriffe an
3. Wenn alle Schreibzugriffe seit dem Ausfall verarbeitet
wurden ist der Follower wieder auf dem aktuellen Stand

Leader Failure:
Failover
Wenn ein Leader ausfällt (Failover) muss ein
Follower zum neuen Leader ernannt werden
und alle Schreibzugriffe empfangen
Die anderen Follower müssen Änderungen
von dem neuen Leader empfangen
Ein Failover kann manuell durch den
Administrator oder automatisch erfolgen
Automatic Failover
1. Stelle den Ausfall des Leaders fest (z.B. mit gegenseitigen
Botschaften oder Watchdog Timer)
2. Bestimme einen neuen Leader
• Wahl durch Mehrzahl der verbleibenden Follower
• Auswahl durch dedizierten Kontrollknoten
• Bester Kandidat ist der aktuellste Follower
• Auswahlprozess ist ein Konsensusproblem
3. Rekonfiguriere das System mit dem neuen Leader
• Klienten senden Schreibzugriffe an den neuen
Leader
• Der alte Leader, wenn er wiederkommen sollte,
muss sicher zum Follower werden und den neuen
Leader anerkennen
Failover – Was alles schiefgehen kann
Der neue Leader hatte vielleicht nicht alle Änderungen erhalten
• Was passiert mit diesen Änderungen wenn der alte Leader wiederkommt?
• Einfachste Lösung: die Änderungen werden verworfen (aber was für eine Dauerhaftigkeit
erwarten die Klienten?)
Das Verwerfen von Änderungen ist besonders gefährlich wenn andere Systeme mit
dem Datenbankinhalt koordiniert werden müssen
Zwei Knoten können sich für den Leader halten (Split Brain)
• Einer der beiden Leader muss heruntergefahren werden
• Fencing oder STONITH (Shoot the other one in the head)
• Achtung: es dürfen nicht beide Leader heruntergefahren werden
Nach welcher Zeitspanne gilt ein Leader als nicht mehr verfügbar?
• Bei einer zu kurzen Zeitspanne gibt es zu viele falsche Failovers
• Bei einer zu langen Zeitspanne dauert die Wiederherstellung zu lange
Mögliche Lösung: Manuelle Failovers
Statement-based
Replication Achtung!
Der Leader protokolliert jeden Schreibzugriff
(d.h. Statement) und sendet dieses
• Nichtdeterministische Statements wie NOW() oder
Statement Log an die Follower RAND() erzeugen wahrscheinlich unterschiedliche
Werte auf unterschiedlichen Replikaten
In einer relationalen SQL-Datenbank wird
jedes INSERT-, UPDATE- und DELETE-
Statement protokolliert und an die Follower • Statements die eine Spalte mit laufender Nummer (d.h.
gesendet auto increment) verwenden müssen in identischer
Nichtdeterministische Funktionen können für Reihenfolge ausgeführt werden
das Replikationslog durch feste Werte ersetzt
werden • Statements mit nichtdeterministischen Seiteneffekten
Statement-basierte Replikation wurde in (Trigger, Stored Procedures, benutzerdefinierte
MySQL bis vor Version 5.1 verwendet (heute: Funktionen) erzeugen unterschiedliche Effekte
Zeilen-basierte Replikation)
Write-ahead Log
(WAL) Shipping
Bei B-Baum-basierten physischen Schemata
werden Modifikationen zuerst in ein Write-
ahead Log (WAL) geschrieben
• Nach einem Crash kann mit dem WAL der
Datenbankindex wiederhergestellt
werden
Dasselbe WAL kann für die Erzeugung von
Replikaten verwendet werden
Follower erzeugen mit dem WAL exakt
dieselben Datenstrukturen wie der Leader
PostgreSQL und Oracle verwenden WAL
Shipping
Achtung!
• Write-ahead Log Shipping beschreibt Daten auf der
Ebene des physischen Schemas (welche Bytes wurden in
welchen Blöcken auf der Festplatte geändert?)
• Die Replikation ist eng an die Storage Engine
gekoppelt
• Leader und Follower müssen dieselbe (Version der)
Storage Engine verwenden
• Mit unterschiedlichen Versionen der Storage Engine auf
den verschiedenen Knoten wären Upgrades ohne
Ausfallzeit möglich
• Write-ahead Log Shipping erfordert für Upgrades oft
Ausfallzeit
Logical (Row-based)
Log Replication
Verwende unterschiedliche Log-Formate für
die Storage Engine und die Replikation
• Physisches Log für die Storage Engine
• Logisches Log für die Replikation
Eine Transaktion die mehrere Zeilen
modifiziert, erzeugt mehrere Log Records,
gefolgt von einem Commit-Vermerk
Mit logischen Replikationslogs können die
Replikate unterschiedliche Storage Engines
verwenden
Logische Logs können auch von externen
Anwendungen verwendet werden
• Change Data Capture für Data Warehouse
Logische Replikationslogs
• Für eine eingefügte Zeile enthält das Log für alle Spalten
alle neuen Werte
• Für eine gelöschte Zeile enthält das Log ausreichend viele
Informationen die gelöschte Zeile eindeutig zu
identifizieren
• Primärschlüssel
• Alte Werte aller Spalten
• Für eine modifizierte Zeile enthält das Log ausreichend
viele Informationen die modifizierte Zeile eindeutig zu
identifizieren und die neuen Werte aller Spalten
(mindestens die neuen Werte der geänderten Spalten)
Trigger-based Log Replication
Trigger-basierte Replikation läuft auf der Anwendungsebene ab
Verfügbare Funktionalität für Trigger-basierte Replikation sind Trigger
und Stored Procedures
Mit einem Trigger kann benutzerdefinierter Code bei der Änderung von
Daten ausgeführt werden
Diese Änderung kann in einer separaten Tabelle geloggt werden
Ein externer Prozess kann die Änderungen in einem anderen System
replizieren
Trigger-basierte Replikation hat einen höheren Overhead als andere
Verfahren, ist aber dafür besonders flexibel
Replikationsverzögerungen (Replication Lags)
Motivation für Replikation sind
• Ausfallsicherheit
• Skalierbarkeit (gleichzeitige Verarbeitung vieler Anfragen)
• Verringerte Latenz (geographische Nähe zu den Klienten)
Leader-basierte Replikation ermöglicht die Bearbeitung von Lese-
Anfragen durch alle Replikate (engl. read-scaling architecture)
Für hohe Skalierbarkeit und niedrige Latenz ist nur asynchrone
Replikation praktikabel
Replikationsverzögerungen (Replication Lags)
Ein Klient der von einem asynchronen Follower liest…
… kann veraltete Informationen erhalten
Die Datenbank ist scheinbar inkonsistent, allerdings nur zeitweilig
Ohne weitere Schreibzugriffe holen die Follower auf sind…
… mit dem Leader konsistent
Dieser Effekt ist bekannt als Eventual Consistency
Reading Your Own
Writes Consistency
Auch: Read-After-Write-Consistency
Garantie des Speichersystems, dass ein Klient der
ein Datum mit einer bestimmten Versionsnummer
geschrieben hat dieses Datum nicht mehr in einer
älteren Version lesen wird
Mögliche Implementierung
• Alle Anfragen einer Sitzung in der ein Klient
Daten schreibt werden vom Leader
beantwortet (Session Consistency)
• Alle Anfragen innerhalb einer bestimmten
Zeitspanne nach einem Schreibzugriff werden
vom Leader beantwortet
• Der Klient hält den Zeitstempel seines letzten
Schreibzugriffs vor. Das Speichersystem sorgt
dafür, dass Lesezugriffe nur von Replikaten mit
aktuellen Zeitstempeln beantwortet werden
Besonders schwierig ist Cross-Device-Read-After-
Write Consistency (d.h. Schreib- und Lesezugriffe
erfolgen von Klienten auf mehreren Geräten)
Monotonic Read
Consistency
Garantie des Speichersystems, dass ein Klient
der ein Datum einmal in einer bestimmten
Version gelesen hat dieses Datum nicht mehr
in einer älteren Version lesen wird
Achtung: Ein Klient kann ein Datum immer
noch in einer veralteten Version lesen
Mögliche Implementierung
• Lesezugriffe eines Klienten werden immer
von demselben Replikat beantwortet
• Die Auswahl des Replikats erfolgt zum
Beispiel über den Hashwert der User ID
• Aber: Wenn dieses Replikat ausfällt
werden Lesezugriffe von einem anderen
beantwortet
Weitere Client-Centric Consistency
Monotonic Write Consistency
Das Speichersystem garantiert dass wenn ein Klient erst Wert 1 und dann
Wert 2 schreibt, diese Werte ebenfalls in dieser Reihenfolge geschrieben
werden
Ohne weitere Schreibzugriffe wird in keinem Replikat Wert 1 Wert 2
überschreiben
Write Follows Reads Consistency
Das Speichersystem garantiert dass wenn ein Klient ein Datum in einer
bestimmten Version gelesen hat und dann überschreibt, dieser Schreibzugriff
nur auf Replikaten stattfindet die mindestens in dieser Version vorliegen
Causal Consistency
Auch: Consistent Prefix Reads
Garantie des Speichersystems, dass alle
Operationen, die in einer kausalen Beziehung
stehen, in der gleichen Reihenfolge auf allen
Replikaten serialisiert werden
Eine Operation O ist genau dann kausal von einer
Operation P abhängig, wenn eine oder mehrere der
folgenden Bedingungen gelten:
• O und P wurden beide vom gleichen Prozess
ausgelöst und P lag chronologisch vor O
• O ist ein Read, P ist ein Write und O hat das
Ergebnis von P gelesen
• O ist kausal abhängig von einer Operation X, die
wiederum kausal abhängig von P ist
Mögliche Lösung
• Schreibzugriffe, die in einem kausalen
Zusammenhang stehen, erfolgen in die gleiche
Partition eines verteilten Systems
Weitere Data-centric Prozessor 1:
Prozessor 2:
<-- A1 --> <-- B1 -->
<-- A2 --> <-- B2 -->
<-- C1 -->

Consistency Zeit ------------------------------------------------------------->

Sequential Consistency
Alle Operationen werden auf allen Replikaten in der
gleichen Reihenfolge serialisiert
Die Operationen jedes Klienten werden in ihrer
korrekten finalen Reihenfolge ausgeführt
Sequentielle Konsistenz führt dazu, dass
Speicheroperationen atomar erscheinen.
Linearizability
Auch: Atomic Consistency, Strong Consistency,
Immediate Consistency, External Consistency
Die einheitliche Ordnung der Operationen
entspricht der tatsächlichen chronologischen
Reihenfolge
Alle Requests erscheinen so, als würden sie anstelle
während eines Zeitintervalls an einem Zeitpunkt
passieren
Das Speichersystem erscheint als ein Replikat
CAP-Theorem
Vermutung des Informatikers Eric Brewer (UCB)
im Jahr 2000, im Jahr 2002 axiomatischer
Beweis durch Seth Gilbert und Nancy Lynch
(MIT)
Wenn eine Anwendung Linearizability erfordert
und einige Replikate sind durch einen
Netzwerkausfall von anderen getrennt, dann
können diese abgetrennten Replikate keine
Anfragen mehr beantworten: sie müssen warten
bis das Problem behoben ist oder eine
Fehlermeldung zurückgeben
→ die Replikate sind nicht verfügbar
Wenn eine Anwendung keine Linearizability
erfordert können einzelne Replikate
Schreibzugriffe unabhängig voneinander
verarbeiten, auch wenn sie von anderen
Replikaten abgetrennt sind
→ die Replikate sind auch bei einem
Netzwerkausfall verfügbar
Bildnachweis
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, O'Reilly UK Ltd.