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

www.themegallery.com Company Logo

Prof. Dr. Lutz WegnerStud. Sigita Andrulyte

The Dangers of Replication and a Solution


Non-Transactional Replication

Lazy Replication

Eager Replication

Replication Modelle

Einführung

Two-Tier Replication

Zusammenfassung


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


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.


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.


Ziele der Replikation: Erhöhte Verfügbarkeit

Grundidee bei der Erhöhung der Verfügbarkeit und der Zuverlässigkeit ist dasEinfü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


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


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.


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


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“.


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.


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.


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.


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.


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_Disconnects

Mittlere Zeit zwischen dem Trennen des Knotens vom Netz.

Disconnected_time Zwischenzeit, die vergeht, wenn die Knoten vom Netz getrennt sind


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


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.


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.


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.


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.


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.


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



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.



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.



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.


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)


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.


Two-Tier Replikation: Arbeitsweise

Online: Erweitertes Primary-Copy VerfahrenOffline: Mobiler Knoten erzeugt vorläufige Transaktionen auf der von ihm

replizierten DatenbankBeim 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 oderFehlschlag jeder vorläufigen Transaktion - Löschen vorläufiger Objektversionen, da sie vom Master erneuert werden


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


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


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.


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.


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.


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.


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.


Danke für eure Aufmerksamkeit!

Documents

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