1. Multimaster-Replikation
Arno Schmidhauser
Letzte Revision: März 2010
Email: arno.schmidhauser@bfh.ch
Webseite: http://www.sws.bfh.ch/db

2. Replikation ist allgegenwärtig
• Durch die Verfügbarkeit von Daten auf
verschiedensten Endgeräten mit
unterschiedlicher Connectivity sind
heute viele Datenbestände in
mehreren Replikaten vorhanden:
– Filesysteme
– Emails
– Kalender
– SQL-Datenbanken
– Applikationsobjekte

3. Ausgangslage für Multimaster-
Replikation
• Replizierte Daten sollen in einer beliebigen Topologie
abgleichbar sein, insbesondere sternförmig (Server mit
Clients) oder N:N (Clients unter sich, oder Server unter
sich).
• Der Abgleich zwischen den Knoten findet zeitlich zufällig
zu nicht vorhersehbaren Zeitpunkten statt.
• Das Schlussresultat aller Abgleiche in einem Replikatsnetz
soll unabhängig von der Abgleichreihenfolge sein.
→ Verfahren mit Zeitstempeln
→ Verfahren mit Versionenvektoren
→ Verfahren mit Versionenvektoren für Knoten

4. Verfahren mit Zeitstempeln
Knoten R1 Knoten R2 Knoten R3
X = 1 (t1) X = 1 (t1) X = 1 (t1)
T1: x = 2 T3: x = 3
send X = 2
X = 2 (t2)
X = 2 (t2) gewinnt send X = 2
X = 3 (t3)
send X = 3 X = 3 (t3) gewinnt
X = 3 (t3) gewinnt
send X = 3
X = 3 (t3) gewinnt
X = 3 (t3) X = 3 (t3) X = 3 (t3)
Der Zeitstempel-Vergleich kann nicht unterscheiden zwischen einer neueren
Version eines Datensatzes und einem Konflikt zwischen zwei Datensätzen !

5. Verfahren mit Versionenvektoren
• Ein Versionenvektor ermöglicht die Steuerung des
Datenabgleichs und die Erkennung von Konflikten in einer
beliebigen Topologie. Jedes Datenelement (Datensatz, File
etc) wird dazu um folgende Informationen ergänzt:
– Eine VersionenID, bestehend aus KnotenID und
fortlaufender Versionennummer für den Knoten, der die
letzte Änderung vorgenommen hat.
– Ein Vektor von Versionennummern, welche die letzte
bekannte Änderung an diesem Datensatz für jeden
Knoten im Replikationsnetz wiedergeben.
Daten VersionenID Versionenvektor Version xi
eines Datenelementes
100 R1, 5 5, 3, 1

6. Versionenvektor, einfacher Ablauf
Knoten R1 Knoten R2 Knoten R3
x=0, [R1,1], [1,0,0]
T
send
x=1, [R1,2], [2,0,0] x=1, [R1,2], [2,0,0]
T
send
x=2, [R2,1], [2,1,0] x=2, [R2,1], [2,1,0]
T
send send
x=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1]

7. Versionenvektor, Konflikterkennung
Anhand der zwei Versionenvektoren wird festgestellt, ob
beim Abgleich zweier Versionen eines Datensatzes ein
Konflikt vorliegt, oder eine erlaubte Update-Operation
durchgeführt werden kann.
Beispiel 1 Beispiel 2 Beispiel 3
Xi = 100, [R1,1], [1,0,0] Xi = 100, [R1,1], [1,0,0] Xi = 102, [R1,2], [2,1,0]
Xk = 101, [R1,2], [2,0,0] Xk = 104, [R3,2], [2,0,2] Xk = 104, [R3,3], [2,0,3]
Kein Konflikt, nur Update Kein Konflikt, nur Update Konflikt, unabhängige Änderungen

8. Versionenvektoren,
Vergleichsoperatoren
• Ein Versionenvektor V dominiert den Versionenvektor W,
wenn beide die gleiche Anzahl Einträge (Dimension) haben
und gilt: V[i] ≥ W[i] für jedes i.
Beispiel: [3,0,2] dominiert [2,0,1]
• Zwei Versionenvektoren sind inkompatibel, wenn keiner
den anderen dominiert.
Beispiel: [3,0,2] und [2,1,0] sind inkompatibel.

9. Abgleichregeln für Datensätze
Ausgangslage
Die Datensatzversion Xi werde vom Knoten R1 an den
Knoten R2 zum Abgleich geschickt. Auf R2 existiert bereits
die Datensatzversion Xk. Vi sei der Versionenvektor von Xi
und Vk sei der Versionenvektor von Xk.
Abgleichsregeln
1. Wenn Vk dominiert Vi : keine Aktion
2. Wenn Vi dominiert Vk : Xi ersetzt Xk
3. Wenn Vi und Vk inkompatibel : Konfliktauflösung
notwendig.

10. Versionenvektor, Ablauf mit Konflikten
Knoten R1 Knoten R2 Knoten R3
x=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1]
T T
send send
x=4, [R1,3], [3,1,1] x=5, [R2,2], [2,2,1] x=5, [R2,2], [2,2,1]
x=5, [R2,2], [2,2,1]
Konfliktauflösung
send
x=4, [R1,4], [4,2,1] x=4, [R1,4], [4,2,1]
Update
send
x=4, [R1,4], [4,2,1] x=4, [R1,4], [4,2,1]

11. Versionenvektor für Knoten
• Um Datensätze in Paketen mit anderen Knoten abzugleichen, wird für
jeden Knoten als Ganzes ein Versionenvektor mitgeführt.
• Der Versionenvektor gibt den Stand des Knotens bezüglich
abgeglichenen Versionen an. Beispiel: Versionenvektor [10,5,3] auf
dem Knoten R1 bedeutet, dass R1 selber als Letztes die Versionen-
nummer 10 vergeben hat, dass R1 alle Versionen von Knoten R2 bis
und mit 5 erhalten hat, und dass R1 von Knoten R3 alle Versionen bis
und mit 3 erhalten hat.
• Nach jedem Abgleich wird der Versionenvektor des Knotens, der den
Abgleich angefordert hat, aktualisert.
• Der Eintrag im Versionenvektor, der dem eigenen Knoten entspricht,
enthält die Versionennummer des letzten auf dem eigenen Knoten
geänderten Datensatzes.

12. Knoten R1 Knoten R2 Knoten R3
[1,0,0] [0,1,0] (0,0,1]
x[R1,1],[1,0,0] y[R2,1],[0,1,0] z[R3,1],[0,0,1]
Anfrage
[0,1,0]
x[R1,1],[1,0,0]
[1,1,0]
Anfrage
[0,0,1]
y[R2,1],[0,1,0]
x[R1,1],[1,0,0]
Anfrage (1,1,1]
[1,1,0]
z[R3,1],[0,0,1]
Anfrage
[1,1,1]
[1,0,0]
y[R2,1],[0,1,0]
z[R3,1],[0,0,1]
[1,1,1)

13. Knoten R1 Knoten R2 Knoten R3
[1,1,1] [1,1,1] [1,1,1]
x[R1,1],[1,0,0] x[R1,1],[1,0,0] x[R1,1],[1,0,0]
T T
x[R1,2],[2,0,0] x[R3,2],[1,0,2]
[2,1,1] Anfrage [1,1,2]
[1,1,1]
x[R3,2],[1,0,2]
Anfrage
[2,1,1] [1,1,2]
x[R3,2],[1,0,2]
Konfliktauflösung
x[R1,3],[3,0,2]
[3,1,2]
usw.
usw.

14. Abgleichprozesse
• Da der Aufbau der Replikationsfähigkeit die Struktur der Nutzdaten
einer Datenbank nicht beeinflussen sollte, werden folgende
Zusatzinformation meist in eigenen Datenbank-Tabellen abgelegt:
– Angaben zur VersionenID und zum Versionenvektor alter oder
aktueller Datensätze
– VersionenID und Versionenvektor von gelöschten Datensätzen
(tombstone table)
– Versionenvektor des Knotens als Ganzes
• Da alle für die Replikation benötigten Daten selber persistent sind,
kann die gesamte Replikation transaktionsorientiert durchgeführt
werden und ist damit selbst fehlersicher und concurrent.

15. Microsoft Sync Framework
• Universales Replikationsframework für Datenelemente
(Datensätze, relationale Tabellen, Emails, News)

17. Microsoft Sync Framework
• Die Metadaten zur Kontrolle des Abgleichs zwischen den
Replikaten basiert auf Versionenvektoren, mit folgenden
Vereinfachungen:
– Ein vollständiger Versionenvektor wird nur auf
Knotenebene, nicht auf Datenelement-Ebene
mitgeführt.
– Datenelemente besitzen eine VersionenID (KnotenID
und Versionennummer).
Knoten A Knoten B
VA[AA=2,AB=0] Abgleich VB[BA=0,BB=3]
x[A,cA=2] y[B,cB=3]

18. III
CAP

19. CAP - Prinzip
Eine nützliche Betrachtung von replizierten und verteilten System geht
von drei Hauptanforderungen aus:
• Consistency
Die Daten aller Knoten eines replizierten Datenbestandes müssen zu
jeder Zeit vollständig übereinstimmen.
• Availability
Jede mögliche Anfrage an das System muss von mindestens einem
Knoten sofort beantwortet werden können.
• Partition Tolerance
Ein Knoten der eine Anfrage bearbeitet muss dies auch dann tun
können, wenn andere Knoten ausfallen oder nicht verfügbar sind.
 Ein verteiltes System kann leider nie alle drei Bedingungen gleichzeitig
erfüllen, sondern höchstens zwei davon!

20. CAP, Replikationsarten
Replikationsarten
Synchronität  Asynchron Synchron
Symmetrie 
Asymmetrisch C nein C ja C ja
A ja A nein A ja
P ja P Ja P nein
C nein C ja C ja
Symmetrisch
A ja A nein A ja
P ja P ja P nein