Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Www.themegallery.com Company Logo Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte The Dangers of Replication and a Solution."—  Präsentation transkript:

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

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

3 Company Logo 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

4 Company Logo 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.

5 Company Logo 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.

6 Company Logo 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

7 Company Logo 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

8 Company Logo 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.

9 Company Logo 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

10 Company Logo 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.

11 Company Logo 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.

12 Company Logo 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.

13 Company Logo 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.

14 Company Logo 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.

15 Company Logo Die wichtigsten Variablen DB_SizeAnzahl der Objekte in der Datenbank KnotenAnzahl der Knoten TransaktionenAnzahl der Transaktionen auf einem Knoten TPSZahl der Transaktionen pro Sekunde in einem Knoten. AktionenAnzahl von Updates in einer Transaktion Action_TimeZeit, um eine Aktion durchzuführen Time_Between_Dis connects Mittlere Zeit zwischen dem Trennen des Knotens vom Netz. Disconnected_timeZwischenzeit, die vergeht, wenn die Knoten vom Netz getrennt sind

16 Company Logo 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

17 Company Logo 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.

18 Company Logo 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.

19 Company Logo 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.

20 Company Logo 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.

21 Company Logo 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.

22 Company Logo 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

23 Company Logo 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.

24 Company Logo 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.

25 Company Logo 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.

26 Company Logo 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)

27 Company Logo 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.

28 Company Logo 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

29 Company Logo 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

30 Company Logo 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

31 Company Logo 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.

32 Company Logo 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.

33 Company Logo 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.

34 Company Logo 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.

35 Company Logo 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.

36 Company Logo Danke für eure Aufmerksamkeit!


Herunterladen ppt "Www.themegallery.com Company Logo Prof. Dr. Lutz Wegner Stud. Sigita Andrulyte The Dangers of Replication and a Solution."

Ähnliche Präsentationen


Google-Anzeigen