Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte

Präsentation zum Thema: "Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte"—  Präsentation transkript:

1 Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte
The Dangers of Replication and a Solution Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte Company Logo

2 Non-Transactional Replication
Einführung Replication Modelle Eager Replication Lazy Replication Non-Transactional Replication Two-Tier Replication Zusammenfassung Company Logo

3 Replikation • Replikation wird zumeist angewandt, wenn
– große Datenmengen verwaltet werden müssen und man gleichzeitig effizient (im Wesentlichen also schnell) auf die Daten zugreifen möchte = Erhöhung der Performanz – wenn man mehrere spezialisierte Anwendungssysteme gleichzeitig betreibt und in jedem dieser Systeme bestimmte Daten verwaltet werden (müssen), z.B. KIS, PDM und SAP (in denen jeweils Patientenstammdaten gespeichert werden) – Wenn garantiert werden soll, dass Daten immer verfügbar sind, auch wenn ein System ausfällt (bzw. wenn mehrere Systeme ausfallen) = Erhöhung der Verfügbarkeit – wenn man Daten auf mobilen Geräten verfügbar machen möchte und diese Geräte nicht immer mit dem Netzwerk verbunden sind = Unterstützung von Mobilität Company Logo

4 Replikation • In einem replizierten System gibt es einen logischen Datenbestand (z.B. Datenbank) … • … der in Wahrheit jedoch auf mehrere (N) replizierte physische Datenbestände verteilt ist • Alle diese Replikate sind in einem Netzwerk miteinander verbunden. • Beim Zugriff auf Datenelemente sollte die Replikation vor einem Client verborgen werden, d.h. er sollte sich an eines der physischen Replikate verbinden können, ohne zu wissen, dass es weitere davon gibt. Company Logo

5 Ziele der Replikation: Erhöhte Skalierbarkeit
• Skalierbarkeit bedeutet, dass mit einer wachsenden Zahl von Ressourcen auch die Anzahl der Benutzer (und damit auch Operationen, Transaktionen, etc.) wachsen soll. • Replikationen sollen also idealerweise bei doppelt so vielen Ressourcen auch doppelt so viele Benutzer unterstützen können (was auch bedeutet, dass wenig bis kein Aufwand auf die Verwaltung der Replikate verwendet werden sollte). Der Idealzustand lässt sich nicht realisieren, aber Replikation trägt doch zu einem großen Leistungsgewinn bei. Company Logo

6 Ziele der Replikation: Erhöhte Verfügbarkeit
Grundidee bei der Erhöhung der Verfügbarkeit und der Zuverlässigkeit ist das Einfügen von Redundanz, z.B. durch Replikate (identische Kopien von Datenquellen) – Eine Komponente k fällt mit einer Wahrscheinlichkeit Psingle = p aus – Ausfallwahrscheinlichkeit PRep bei n Replikaten von k: PRep pn Company Logo

7 Ziele der Replikation: Mobilitätsunterstützung
• Daten werden vom Server auf mobile Geräte kopiert (repliziert), z.B. auf Laptops, PDAs, Mobiltelefone, etc. • Danach werden die mobilen Geräte vom Netz getrennt. Durch die Replikation kann man auf dem mobilen Gerät weiterhin mit den Daten arbeiten, ohne dass ein direkter Zugang zum Server existiert Company Logo

8 Replikation und Änderungsoperationen
• Leseoperationen in replizierten Systemen sind unkritisch. Da Leseoperationen nicht den Zustand des Systems verändern, in dem sie stattfinden, müssen nach einer Leseoperation auch keine Aktivitäten in den replizierten Systemen ausgeführt werden. • Änderungsoperationen in einem System müssen jedoch an alle Replikate propagiert werden, erfordern also zusätzlichen Aufwand. Für die korrekte Behandlung von Änderungsoperationen werden verschiedene Ansätze unterschieden, die sich im Aufwand und in den erreichbaren Korrektheits- und Konsistenzgarantien unterscheiden. Company Logo

9 Klassifikation von Replikationsverfahren
Bei der Analyse von Replikationsverfahren wird unterschieden, • wo, d.h. an welcher Stelle im System, Änderungsoperationen durchgeführt werden können und • wie Änderungen an die Replikate propagiert werden Bezüglich des Orts der Durchführung von Änderungsoperationen unterscheidet man • Primary Copy: Ein Replikat im System beherbergt die „führende“ Kopie. • Update Everywhere: Änderungen können überall ausgeführt werden Bezüglich der Propagierung der Änderungen lassen sich folgende beiden Verfahren unterscheiden: • Eager Replication: ursprüngliche Operation und Änderung der Replikate in einer Transaktion • Lazy Replication: ursprüngliche Operation und Änderungsoperationen auf Replikaten erfolgen in unterschiedlichen Transaktionen Company Logo

10 Symmetrische Replikation
Bei der symmetrischen Replikation wird ein Update auf allen Rechnern, bzw. auf allen Replikaten des Replikationsverbundes durchgeführt, man spricht auch von „Update anywhere“/„Update everywhere“. Company Logo

11 Asymmetrische Replikation
Bei einer asymmetrischen Replikation wird ein Update der Daten nur auf einem Rechner(verbund)/Replikat, der sogenannten „Primary Copy“ bzw. dem „Update Master“, zugelassen und durchgeführt. Dieser Rechner(verbund) propagiert nach erfolgtem Update die Änderungen an den Rest des Replikationsverbundes. Company Logo

12 Synchrone/Asynchrone Replikation
Synchrone Replikation („eager“/„pessimistic“ Replication): Bei der synchronen Replikation wird eine Transaktion zeitgleich auf allen Replikaten durchgeführt und ist erst dann erfolgreich beendet, wenn die Transaktion auf allen Replikaten erfolgreich durchgeführt wurde. Sollte auf einem Replikat die lokale Transaktion scheitern, so ist auch die globale Transaktion gescheitert. Asynchrone Replikation („lazy“/„optimistic“ Replication): Bei der asynchronen Replikation ist es erlaubt, dass sich die Replikate unterscheiden, d.h. es wird lediglich sichergestellt, dass das replizierte Datenbankobjekt konvergiert. Company Logo

13 Primary Copy • Beim Primary-Copy-Ansatz ist pro Datenelement genau eine Datenquelle als führendes System festgelegt. Alle Änderungsoperationen gehen zu diesem führenden System. Von dort werden dann die Änderungen an die so genannten Secondary Copies, an die Replikate, verteilt. Secondary Copies sind also Systeme, die für den Benutzer nur Leseoperationen zur Verfügung stellen. • Die Rolle der Primary-Copy kann auch per Datenelement definiert werden. Ein System A kann demnach die Primary-Kopie von Datenelement x beherbergen und nur ein Replikat von y, während System B umgekehrt die Primary-Kopie von y verwaltet und nur ein Replikat von x besitzt. Company Logo

14 Update Everywhere • Beim Update-Everywhere-Ansatz sind alle Datenquellen gleichberechtigt. Änderungsoperationen können (wie auch Leseoperationen) an jeder Stelle im System erfolgen. • Beim Update-Everywhere-Ansatz können dann Probleme auftreten, wenn parallel (zeitgleich) Änderungen am selben Datenelement in unterschiedlichen Replikaten durchgeführt werden. Die Problembehandlung nennt man dann auch Reconciliation. Es braucht hier dann Regeln, wie man in solchen Fällen verfahren muss. Company Logo

15 Die wichtigsten Variablen
DB_Size Anzahl der Objekte in der Datenbank Knoten Anzahl der Knoten Transaktionen Anzahl der Transaktionen auf einem Knoten TPS Zahl der Transaktionen pro Sekunde in einem Knoten. Aktionen Anzahl von Updates in einer Transaktion Action_Time Zeit, um eine Aktion durchzuführen Time_Between_Dis connects Mittlere Zeit zwischen dem Trennen des Knotens vom Netz. Disconnected_time Zwischenzeit, die vergeht, wenn die Knoten vom Netz getrennt sind Company Logo

16 Transactions = TPS x Actions x Action_Time
Jeder Knoten erzeugt einige TPS-Transaktionen pro Sekunde. Jede Transaktion hat eine feste Anzahl von Aktionen. Jede Aktion benötigt eine feste Zeit für ihre Durchführung. Die Transaktionsdauer berechnet sich wie folgt: Aktionen x Aktionsdauer. Die Anzahl der Transaktionen mit Ursprung in einem Knoten ist: Transactions = TPS x Actions x Action_Time Company Logo

17 Eager Replication • Im Eager-Replication-Ansatz (auch synchrone Replikation genannt) werden für die eigentliche Änderungsoperation und die zugehörigen Änderungsoperationen an den Replikaten ACID-Garantien verlangt. Insbesondere bedeutet dies, dass jede Änderungsoperation in einer verteilten Transaktion eingebettet sein muss. Leseoperationen können im Gegensatz dazu auf nur einem System erfolgen. • Bei der Eager Replication wird garantiert, dass die Replikate zu jedem Zeitpunkt konsistent sind, d.h. genau übereinstimmen. Company Logo

18 Lazy Replication • Bei der Lazy-Replication (auch asynchrone Replikation genannt) laufen die ursprüngliche Änderungsoperation und die danach benötigten Änderungsoperationen auf den Replikaten („Replica Updates“) in komplett getrennten Transaktionen ab (die ursprüngliche Transaktion ist dabei in der Regel nicht verteilt, die Replica Updates definieren jedoch eine verteilte Transaktion). • Da die ursprüngliche Änderungstransaktion entkoppelt von der Replikation abläuft ist diese in der Regel schneller beendet. Allerdings können Inkonsistenzen zwischen Originaldaten und Replikaten entstehen. Company Logo

19 bereits veraltet sein kann, also nicht konsistent ist.
Lazy vs. Eager: • Eager Replication wird in der Regel als sehr „teuer“ charakterisiert, da alle beteiligten Systeme verfügbar sein müssen, wenn man an einer Stelle Änderungen ausführt (eine verteilte Transaktion kann nicht komplett und korrekt ausgeführt werden, wenn ein Replikat nicht verfügbar ist). Die Konsistenzgarantien muss man daher mit aufwändigen Änderungsoperationen erkaufen. • Lazy Replication, im Gegensatz, ist einfach realisierbar (da Änderungsoperationen immer erfolgreich sind, auch wenn einzelne Replikate im System nicht verfügbar sind). Allerdings ist bei Leseoperationen Vorsicht geboten, da der gelesene Wert bereits veraltet sein kann, also nicht konsistent ist. Company Logo

20 Primary vs. Everywhere:
• Der Master-Copy-Ansatz bietet wenig Flexibilität; Ausfallsicherheit ist nur in Bezug auf Leseoperationen gegeben: Wenn das Master-System nicht verfügbar ist, dann kann zwar durch die Replikate weiter gelesen werden, es können aber keine Änderungsoperationen ausgeführt werden. Allerdings ist in diesem Ansatz immer der aktuelle Zustand jedes Datenelements eindeutig bestimmbar. • Der Update-Everywhere-Ansatz bietet das größte Maß an Flexibilität und Ausfallsicherheit, da immer Lese- und Änderungsoperationen möglich sind, so lange zumindest eines der physischen Replikate verfügbar ist. Allerdings ist die Reconciliation sehr aufwändig und kann zumeist nur durch sehr strikte Regeln gelöst werden (problematisch vor allem in Kombination mit lazy replication !). Für die Reconciliation verwendet man zumeist Zeitstempel (und lässt dann die älteren Änderungsoperationen zu, weist jedoch die Jüngeren zurück). Jedoch kann es auch hier zu Problemen kommen, da auch die Zeitstempel im verteilten System koordiniert werden müssen. Company Logo

21 Weitere Replikationsverfahren
• Pull-basierte Replikation: Hier sind die Replikate verantwortlich, regelmäßig beim Server nachzuschauen, ob es neue Daten gibt, die dann lokal eingespielt werden müssen • Push-basierte Replikation: Server sind dafür verantwortlich, die Änderungen an die Replikate weiterzugeben („zu pushen“). Dies ist der Fall bei lazy replication. – Unicast: Änderungen werden nur an einen Empfänger versandt. Bei mehreren Replikaten müssen Änderungen also mehrmals versendet werden. – Multicast: Hier werden die Änderungen gleichzeitig an mehrere Empfänger versandt (es wird eine Änderungsbenachrichtigung erzeugt, die gleichzeitig an mehrere Empfänger geht) – Epidemische Protokolle: Diese sind vor allem in großen Systemen nützlich, bei denen der Server nicht alle Replikate kennt, also nicht weiß, an wen alles die Änderungen propagiert werden sollen (z.B. in Peer-to-Peer- Umgebungen). Der Server kennt einige „benachbarte“ Replikate, denen er die Änderungen mitteilt (sie mit den neuen Daten „infiziert“). Diese geben die Änderungen wiederum an Nachbarn weiter. Änderungen verbreiten sich also wie eine Epidemie im gesamten System, bis sie schließlich an allen Replikaten angekommen sind. Company Logo

22 Beispiele von Replikationsverfahren
Cold Standby: Primary Copy – Lazy Replication • Dies wird in Server-Architekturen für ein Server-seitiges Backup verwendet (“cold standby”) • Änderungen werden in der Primary Copy direkt ausgeführt. Gleichzeitig werden diese außerhalb des Servers dauerhaft protokolliert (z.B. in einer persistenten Queue), aber nicht sofort auf den Replikaten ausgeführt. • Falls der Server ausfällt, werden zuerst die Änderungen aus der Queue im Replikat ausgeführt. Wenn das Replikat konsistent ist, dann kann es die Verarbeitung vom ausgefallenen Server übernehmen Company Logo

23 Beispiele von Replikationsverfahren
Hot Standby: Primary Copy – Eager Replication • Dies wird in Server-Architekturen für ein Server-seitiges Backup verwendet, bei dem im Fehlerfall sofort auf ein repliziertes System umgeschaltet werden kann (“hot standby”) • Änderungen werden in der Primary Copy direkt ausgeführt und innerhalb derselben Transaktion auch im replizierten System. Um die Verfügbarkeit des Systems hoch zu halten, werden nur sehr wenige Replikate (zumeist nur eines) neben dem eigentlichen Server betrachtet. • Falls der Server ausfällt, kann sofort das Replikat zur weiteren Verarbeitung von Lese- und Änderungsoperationen verwendet werden, ohne dass erst protokollierte Änderungen aufwändig eingespielt werden müssen. Dieser Ansatz kann also den Betrieb ohne Stillstand am besten realisieren. Company Logo

24 Beispiele von Replikationsverfahren
Read One Write All: Update Everywhere – Eager Replication • Dies ist die klassische Form von Replikation in einem verteilten System mit gleichberechtigten Datenquellen. • Änderungen können beliebig ausgeführt werden, kommen aber nur dann korrekt zum Ende, wenn jedes System die Änderungen akzeptiert. • Der Ansatz ist sehr gut geeignet in Systemen, in denen die Anzahl der Leseoperationen deutlich höher ist als die Anzahl von Änderungsoperationen. Insbesondere werden bei vielen Änderungsoperationen, die von unterschiedlichen Replikaten ausgehen, sehr viele Deadlocks erzeugt, so dass dann Änderungsoperationen nicht mehr komplett durchlaufen und die Leistung des Gesamtsystems deutlich eingeschränkt wird. Company Logo

25 Beispiele von Replikationsverfahren
Zweistufige Replikation für die Unterstützung von Mobilität • Die erste Stufe betrachtet einen “konventionellen“ Replikationsansatz, z.B. eine Menge von Datenquellen, die mittels eager / update everywhere koordiniert werden können (Basissysteme) • Die zweite Stufe beinhaltet mobile Systeme, die von den Basissystemen replizieren. Diese mobilen Systeme können dann ohne Verbindung zu den Basissystemen Änderungen durchführen (tentative Änderungen), müssen diese dann aber später, wenn sie wieder mit dem Netz verbunden sind, einspielen. Dieses Einspielen muss konsistent zur Replikationsstrategie in den Basissystemen erfolgen (also im Beispiel auch mittels eager / update everywhere). Erst dann werden die tentativen Änderungen auch akzeptiert. Company Logo

26 Non-Transactional Replication Schemen
Idee: Statt serializability, benutzen wir "Konvergenz Eigenschaften": Wenn keine neuen Transaktionen kommen, und alle Knoten wieder neu reconnected sind, kommen alle auf den gleichen Stand. Beispiel: Lotus Notes. Nur zwei Möglichkeiten für die Aktualisierung: 1. Eine Zeitmarkierung beachten. 2. Commutive Updates. Funktioniert gut, aber verliert Updates, was nicht wünschenswert sein kann (z.B. Scheckheft) Company Logo

27 Two-Tier Replication Modifiziertes Primärkopie-Verfahren Zwei Arten von Knoten - Mobile Knoten (MK) - Basis-Knoten (BK) Zwei Arten von Transaktionen: - Vorläufige Transaktionen (Vorläufige Version) - Basis-Transaktionen (Master Version) Ein ideales Replikationsschema muss 4 Punkte erfüllen: - Verwendbarkeit und Skalierbarkeit: Dies wird erreicht durch Replikate, um dadurch Instabilität zu vermeiden. - Mobilität: Erlaubt mobilen Knoten ihre Datenbank zu aktualisieren, wenn sie vom Netz getrennt sind. - Skalierbarkeit: Stellt eine single-copy-Transaktion zur Verfügung - Konvergenz: Bietet Konvergenz an, um Systemtäuschungen zu vermeiden. Company Logo

28 Two-Tier Replikation: Arbeitsweise
Online: Erweitertes Primary-Copy Verfahren Offline: Mobiler Knoten erzeugt vorläufige Transaktionen auf der von ihm replizierten Datenbank Beim Wiederanschließen (mobile Knoten): - Senden der Updates der Objekte an den BK, für die der MK Master ist - Senden vorläufiger Transaktionen (+ Parameter) an BK, um dort ausgeführt zu werden - Akzeptieren von Updates vom Basisknoten - Akzeptieren von Rückmeldungen über Erfolg oder Fehlschlag jeder vorläufigen Transaktion - Löschen vorläufiger Objektversionen, da sie vom Master erneuert werden Company Logo

29 Two-Tier Replikation: Arbeitsweise
Beim Wiederanschließen (Basis-Knoten): - Senden verzögerter Update-Transaktionen an den MK - Akzeptieren verzögerter Update-Transaktionen für Objekte, deren Master ein mobiler Knoten ist - Akzeptieren vorläufiger Transaktionen, ihrer Eingabeparameter und Akzeptanzkriterien - Propagieren der Updates an alle anderen Knoten des Replikationsschemas Company Logo

30 Two-Tier Replikation: Eigenschaften
Mobile Knoten führen vorläufige Updates aus Basis-Transaktionen sind serialisierbar Replikate aller verbundenen Knoten konvergieren gegen die Master Kopie Company Logo

31 Allgemeine Konfliktauflösung
Timestamp-basierte Verfahren: „Latest Timestamp“: Tritt ein Konflikt zwischen zwei Replikaten bei einem Timestamp-basierten Replikationsverfahren auf, so wird das Replikat mit dem „ jüngeren“ Timestamp gewählt. Diese Strategie ist zwar Problem- behaftet, erfüllt aber trotzdem das Konvergenzkriterium. „Earliest Timestamp“: Stellt das Gegenteil der „Latest Timestamp“- Methode dar, wählt also das „älteste“ Replikat. Master/Slave - „Mastercopy wins“: Bei Konflikten gewinnt immer das Replikat auf dem Master-Server, dies kommt häufig beim „Disconnected Computing“ zum Einsatz. Company Logo

32 Allgemeine Konfliktauflösung
„Site Priority“: Bei Prioritäts-basierten Konfliktauflösungsverfahren werden nicht alle Replikations-Standorte als gleichberechtigt erachtet. Dies ist meist der Fall, wenn ein Standard den Anspruch auf „Präzision“ erhebt. „Notice User“: Wird oft als letzte Möglichkeit angesehen, wenn andere Verfahren scheitern. Der Nutzer wird aufgefordert, den entstandenen Konflikt manuell aufzulösen. Company Logo

33 Attribut-basierte/Spalten-basierte Konfliktauflösung
„Additive and Average“: Bei zwei konkurrierenden Werten wird einfach der Durchschnitt der beiden gebildet. Je nachdem, ob man „Additive“ oder „Average“ verwendet, wird dabei auf eine andere Formel zurückgegriffen. „Minimum and Maximum“: Bei zwei konkurrierenden Werten wird einfach das Minimum, bzw. Maximum der beiden gebildet. „Priority Group“: Kommt bei konkurrierenden Zugriffen auf eine Relation zum Einsatz. Dabei werden die Spalten der Relation mit Prioritäten versehen, die Spalte mit der höchsten Priorität bekommt als erstes den Zugriff. Company Logo

34 Zusammenfassung Replikation von Daten durch viele Knoten und zugelassene anyone updates ist problematisch. Sicherheit ist die eine Frage, Leistung die andere. Wenn das Standard-Transaktions-Modell für eine replizierte Datenbank angepasst ist, erhöht sich die Größe der einzelnen Transaktion um den Grad der Replikation, was wiederum zu sehr großen deadlock rates führt. Auf den ersten Blick kann man sagen, dass lazy replication das Problem lösen kann. Lazy-master replication ist hingegen noch besser als eine einfache Lazy replication. Beide erzielen sehr viele deadlocks. Die Master- Schemen geben jedoch keine Möglichkeit zum Updaten der Datenbank. Die Lösung ist timestamps and commutative transactions kombiniert mit two-tier replication. Die two-tier replication arbeitet mit mobilen Knoten und kombiniert eager-master-replication- und local update-Schemen. Company Logo

35 Literaturverzeichnis
The Dangers of Replication and a Solution Jim Gray, Pat Helland, Patrick O'Neil and Dennis Shasha G. Vossen, G. Weikum: Transactional Information Systems, Morgan Kaufmann, 2002. Company Logo

36 Danke für eure Aufmerksamkeit!
Company Logo