Multimaster-Replikation  Arno SchmidhauserLetzte Revision: März 2010Email: arno.schmidhauser@bfh.chWebseite: http://www.sw...
Replikation ist allgegenwärtig• Durch die Verfügbarkeit von Daten auf  verschiedensten Endgeräten mit  unterschiedlicher C...
Ausgangslage für Multimaster-             Replikation• Replizierte Daten sollen in einer beliebigen Topologie  abgleichbar...
Verfahren mit Zeitstempeln  Knoten R1                         Knoten R2                         Knoten R3    X = 1 (t1)   ...
Verfahren mit Versionenvektoren• Ein Versionenvektor ermöglicht die Steuerung des  Datenabgleichs und die Erkennung von Ko...
Versionenvektor, einfacher Ablauf Knoten R1                     Knoten R2                     Knoten R3x=0, [R1,1], [1,0,0...
Versionenvektor, Konflikterkennung   Anhand der zwei Versionenvektoren wird festgestellt, ob   beim Abgleich zweier Versio...
Versionenvektoren,             Vergleichsoperatoren• Ein Versionenvektor V dominiert den Versionenvektor W,  wenn beide di...
Abgleichregeln für DatensätzeAusgangslage  Die Datensatzversion Xi werde vom Knoten R1 an den  Knoten R2 zum Abgleich gesc...
Versionenvektor, Ablauf mit Konflikten   Knoten R1                     Knoten R2                     Knoten R3  x=3, [R3,1...
Versionenvektor für Knoten•   Um Datensätze in Paketen mit anderen Knoten abzugleichen, wird für    jeden Knoten als Ganze...
Knoten R1                    Knoten R2                    Knoten R3    [1,0,0]                      [0,1,0]               ...
Knoten R1                      Knoten R2                   Knoten R3      [1,1,1]                       [1,1,1]           ...
Abgleichprozesse•   Da der Aufbau der Replikationsfähigkeit die Struktur der Nutzdaten    einer Datenbank nicht beeinfluss...
Microsoft Sync Framework• Universales Replikationsframework für Datenelemente  (Datensätze, relationale Tabellen, Emails, ...
Microsoft Sync Framework• Die Metadaten zur Kontrolle des Abgleichs zwischen den  Replikaten basiert auf Versionenvektoren...
IIICAP
CAP - Prinzip    Eine nützliche Betrachtung von replizierten und verteilten System geht    von drei Hauptanforderungen aus...
CAP, ReplikationsartenReplikationsartenSynchronität         Asynchron   SynchronSymmetrie    Asymmetrisch         C nein...
Multimaster Replikation und Synchronisation
Nächste SlideShare
Wird geladen in …5
×

Multimaster Replikation und Synchronisation

1.047 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.047
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Multimaster Replikation und Synchronisation

  1. 1. Multimaster-Replikation Arno SchmidhauserLetzte Revision: März 2010Email: arno.schmidhauser@bfh.chWebseite: http://www.sws.bfh.ch/db
  2. 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. 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. 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 = 3X = 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. 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. 6. Versionenvektor, einfacher Ablauf Knoten R1 Knoten R2 Knoten R3x=0, [R1,1], [1,0,0] T sendx=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 sendx=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1] x=3, [R3,1], [2,1,1]
  7. 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 3Xi = 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. 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. 9. Abgleichregeln für DatensätzeAusgangslage 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. 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. 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. 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. 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 Tx[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ösungx[R1,3],[3,0,2] [3,1,2] usw. usw.
  14. 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. 15. Microsoft Sync Framework• Universales Replikationsframework für Datenelemente (Datensätze, relationale Tabellen, Emails, News)
  16. 16. 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]
  17. 17. IIICAP
  18. 18. 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!
  19. 19. CAP, ReplikationsartenReplikationsartenSynchronität  Asynchron SynchronSymmetrie  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

×