4 VERTEILTE DATENBANKS YSTEME
4.2 D ATENBANKREPLIKATION
4.2.1 Replikationsstrategien
4.2.1.11 Schwächere Formen der Datenreplikation
Bevor auf die schwächeren Formen der Datenreplikation eingegangen wird, möchten wir an dieser Stelle noch einmal die Schwerpunkte der bisherigen Replikationsformen erläutern. Eine sehr wichtige Rolle spielte hierbei die Replikationstransparenz, d.h. dem Anwendungsprogramm oder Benutzer soll der Eindruck erweckt werden, es handle sich um einen zu verwaltenden Datenbestand, sowie die Konsistenz (jede Kopie ist immer auf dem aktuellen Stand).
Um diese Hauptkriterien zu gewährleisten ergeben sich gravierende Probleme, die hohe Änderungskosten, da jede Änderung synchron propagiert wird, zur Folge haben. Weiterhin können Verfügbarkeitsprobleme auftreten, vor allem bei geographischer Verteilung. Bei Replikationen, die in mobilen Anwendungen Verwendung finden, lassen sich die oben erläuterten Update Strategien nicht anwenden, da diese Daten meistens „offline“ verfügbar sind.
Eine Lösung sind demnach schwächere Konsistenzformen durch asynchrone Aktualisierung der Kopien. Hinweis: Da die Bedingung eines „Lazy“- Replikationsmodells immer die Konsistenzerhaltung (siehe Glossar) beinhaltet, zählt es nicht zu den schwächeren Replikationsformen. Dazu gehören unter anderem die Schnappschuß-Replikation und die Möglichkeit „fast“ aktueller Kopien die einen schnellen Katastrophen-Recovery (siehe Glossar) unterstützen. Eine weitere Form der schwächeren Datenreplikation ist das „Update Anywhere“ bei mehreren Änderungsknoten pro Objekt.
Diese erfordert einen asynchronen „Refresh“, welcher unter Umständen zu Konsistenzproblemen führen kann. Auch ist eine anwendungsspezifische Konflikt-Behebung erforderlich (siehe Merge-Replikation). In den folgenden Abschnitten werden mögliche Replikationsalternativen und die schwächeren Replikationsformen im Detail erörtert.
4.2.1.11.1 Alternativen eines „Refreshs“
Queues:
Eine Alternative wäre das Konzept von persistenten Warteschlangen. Diese sind dafür verantwortlich die weiterzuleitender Änderungen am Datenbestand zwischen zu speichern und nach bestimmten Kriterien abzuarbeiten.
Verzögerungsdauer: Aktualität vs. Overhead:
Bei diesem Kriterium muss man sich überlegen ob die Daten möglichst aktuell gehalten werden sollen („As Soon As Possible“) oder ob es keine große Rolle spielt die Transaktionen zu einem späteren Zeitpunkt durchführen zu lassen. Letzteres erlaubt das Ausführen in festen Zeitabständen und die Möglichkeit gemeinsam übertragbarer Änderungen. Die Aktualität hat üblicherweise eine sehr hohen Last auf dem DBS zur Folge.
Push- vs. Pull-Replikation:
Dieses Kriterium versteht sich als Master/ Slave bzw. Publisher/ Subscriber Konzept.
Dabei ist der Master/ Publisher in der Position eine Notifikation von Änderungen bei den einzelnen Replikaten zu erzwingen. Dieser Vorgang wird auch als „Push“ bezeichnet.
Der Slave/ Subscriber hingegen überprüft beim „Pull“ Vorgang, ob Transaktionen vorhanden sind und führt diese gegebenenfalls aus. Als Beispiel sei hierfür ein mobiles Endgerät zu nennen, welches nur zeitweise Verbindung zum gemeinsamen Netz hat.
Einfache Replikate vs. abgeleitete Replikation:
Unter einfachen Replikaten versteht man identische Kopien eines Urbilds, wohingegen sich abgeleitete Replikationen als Ergebnisse einer SQL-Operation verstehen.
Vollständige vs. inkrementelle Aktualisierung von Replikaten:
Es kann eine vollständige Aktualisierung der Replikate in einer Transaktion durchgeführt werden, d.h. sie beinhaltet „updates“ auf allen Replikaten. Durch die Verwendung von Triggern können „updates“ inkrementell weiter propagiert werden. Dies kann eine Art Kettenreaktion auslösen.
Sequentielle vs. parallele Aktualisierung:
Es können sowohl Änderungen als einzelne Transaktion durchgeführt werden, als auch in mehreren Transaktionen.
4.2.1.11.2 Schnappschuß-Replikation
Das Hauptmerkmal der Schnappschuß-Replikation ist die Erzeugung einer materialisierten Sicht (=View). Im Allgemeinen, wie auch bei Sichten, ergeben sich folgende Probleme:
Diese Replikation befindet sich nicht immer auf dem neuesten Stand und ist u.a. für den Benutzer nicht transparent. Auch besteht auf einem solchen Replikat nur lesender Zugriff.
Um die Daten konsistent zu halten, werden die Replikate periodisch, d.h. in bestimmten Zeitintervallen (täglich, monatlich, etc.) oder explizit auf Anforderung, durch den Aufruf REFRESH SNAPSHOT relationen_name synchronisiert.
Die Vorteile einer Schnappschuß- Replikation sind, dass keine Synchronisationskonflikte auf der Kopie bzw. dem Replikat entstehen und sich daraus ein relativ geringer Änderungsaufwand ergibt.
Ein Beispiel könnte folgendermaßen aussehen:
create snapshot ds_gehalt (abt, geh) as select anr, avg(gehalt)
from pers group by anr refreshed every month;
4.2.1.11.3 Katastrophen-Recovery
Diese Form der Replikation bezieht sich auf den möglichen Fall des Datenverlustes.
Trotzdem wird sie aber noch den schwächeren Replikationsformen zugeordnet.
Im Ursprünglichen wird hierbei auf eine Archivkopie zurückgegriffen um mit deren Hilfe die verloren gegangenen Daten wiederherzustellen. Meist ist dies ein sehr Zeitaufwendiges Verfahren, da große Datenmengen aus den untersten Ebenen der Speicherhierarchie (z.B. Streamer) zurückgespielt werden müssen. Dieses wiederum bedeutet den Verlust vieler Transaktionen. Allerdings möchten wir an dieser Stelle nicht zu sehr ins Detail gehe n, da dies Inhalt des Vortrages 11 (Backup, Tertiärspeicher) ist. Aus Gründen der Vollständigkeit werden im Folgenden noch Untermodelle des Recoverys genannt.
Dazu gehört u.a. das Remote Logging. Dies ist eine Übertragung von Log-Daten einer Datenbank und deren Archivkopien an ein entferntes Rechenzentrum. Nach diesem Modell, lässt sich ein Schema von zwei gleichberechtigten (aktiven) Rechenzentren ableiten. In jedem Rechenzentrum laufen Server, die per gegenseitiges Remote Logging ihre Daten sichern. Zur Synchronisation wird das Primary Copy Verfahren verwendet. Ein weiterer Vorteil ist die daraus resultierende Lastverteilung, was zusammenfassend zur Daten- Integrität und Verfügbarkeit beiträgt.
Das passive Stand-By-System, oder auch Hot-Stand- By (Abbildung 23) genannt, wird dem Katastrophen Recovery zugeordnet. Das zugrundeliegende Prinzip lässt sich folgendermaßen erklären. Während des Betriebes werden permanent sogenannte Redo-Log- Daten, ähnlich wie beim Remote Logging, zum Backup-System übertragen. Diese aufgezeichneten Änderungsdaten setzen sich aus After-Images (siehe Glossar) zusammen und dienen zur Wiederherstellung. Im Katastrophenfall gehen somit bei asynchroner Übertragung höchstens einige wenige Änderungen verloren. Bei "wichtigen"
Datenbankoperationen erfolgt hingegen eine synchrone Übertragung der Log- Daten. Dies wird durch eine Commit- Verzögerung, bis die entfernte Datenbank aktualisiert ist, gewährleistet.
Konfigurationsvariante (graphisch dargestellt):
Primary 1 Primary 1
Primary 2 Primary 2 Backup 1 Backup 1 Backup 2
Backup 2
Log Log
System System
Primary 1 Primary 1
Primary 2 Primary 2 Backup 1 Backup 1 Backup 2
Backup 2
Log Log
System System
Abbildung 22: Remote Logging PrimaryPrimary BackupBackup Benutzer
Session
Primary Log
Primary BackupBackup Benutzer
Session
Log BackupBackup Benutzer
Session
Log
Abbildung 23: Hot Stand-B y
4.2.1.11.4 Merge-Replikation
Die Merge-Replikation ist definiert als eine nicht synchronisierte Änderung eines replizierten Objekts an mehreren Knoten mit einer asynchronen Propagierung der Änderungen. Damit ergeben sich Performanz- und Verfügbarkeitsvorteile gegenüber der synchronen Aktualisierung.
Aus der eben erläuterten Definition findet dieses Modell Einsatz in der mobilen Datenbank-Nutzung, an welcher häufig Änderungsbedarf besteht. Um sich dies besser verständlich zu machen, kann man sich mehrere Außendienstmitarbeiter einer Firma vorstellen die Datenbestände aktualisieren, verändern oder hinzufügen. Die Daten die sich auf diesen Client Rechnern befinden sind demnach inkonsistent. Es muss also, wenn sie
sich wieder in das Firmennetzwerk einloggen, ein Datenabgleich erfolgen. Somit spricht man von einer Mischung (=Merge) paralleler Änderungen. Konflikte die bei diesem Vorgang entstanden sind müssen nun nachträglich erkannt und aufgehoben werden.
Konflikt-Erkennung und Behebung:
Eine Möglichkeit ist es den Objektänderungen einen Zeitstempel der Vorgängerversion sowie den neuen Wert, zuzuweisen. Man spricht nun von einem Konflikt, falls der lokale Zeitstempel einer zu aktualisierenden Objektversion vom Zeitstempel der Vorgängerversion abweicht. Die Konfliktwahrscheinlichkeit wächst mit der Anzahl der änderbaren Replikate und mit Aktualisierungsverzögerungen.
Eine weitere Möglichkeit ist die anwendungsspezifische Konflikt- Behandlung (=Reconciliation). Hierbei müssen vordefinierte Strategien in einem Datenbanksystem eingehalten werden. Beispiele solcher Strategien sind:
• "last timestamp wins": Die aktuellste Änderung wird propagiert.
• "site priority": Es werden Prioritäten für Benutzer und/ oder Systeme vergeben.
Die mit der höchsten Priorität werden bevorzugt.
• "average": Mehrheitlich semantisch äquivalente Änderungen werden angewendet.
Es können weiterhin benutzerdefinierte Konfliktauflösungsroutinen angestoßen, oder eine Konfliktbehebung manuell ausgelöst werden. Nicht zu vernachlässigen ist die Gefahr von
"lost updates" (siehe Glossar) und anderen Anomalien.