Powerpoint-Beispiel2

4. Replikation und Synchronisation
4-1
4. Replikation und Synchronisation
Gliederung
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Motivation
Replikation
Synchronisation
Klassische Verfahren
Neue mobile Verfahren
SyncML (Synchronization Markup Language)
Zusammenfassung
4-2
4.1 Motivation
• Was ist Replikation?
– Ziel: Daten sollen in Offline-Phasen unabhängig auf einem Client
bearbeitet werden können
– Replikation bezeichnet das Anlegen einer Kopie
und damit die Einführung von Datenredundanz
– Daten werden dadurch auf mobilen Clients verfügbar
oft auch nur Teile (Selektion, Projektion) der urspüngl. Relation
(-> Nachforderungen, schwieriger Wiederabgleich)
Projektion
Relation
Selektion
4-3
Motivation
• Was ist Synchronisation?
– Auf den Clients geänderte Daten sollen wieder auf den Server
rückübertragen werden
– Probleme entstehen, wenn auch dort die Daten zwischenzeitlich geändert
wurden
– Ziel: Datenkonsistenz innerhalb einer Replikationsumgebung, da
Inkonsistenzen zu schwerwiegenden Fehlern führen können
– Bei der Synchronisation werden die geänderten Daten nach bestimmten
Verfahren (meistens konventionell, zeitstempelbasiert oder semantisch)
abgeglichen
 Replikation und Synchronisation sind wichtige Grundlagen für Offline-Szenarien
4-4
4.2 Replikation
4.2.1 Ursprung
• Ursprung der Replikation:
– Ursprung in den verteilten Systemen und in den verteilten
Datenbanksystemen
– Verteilte, nichtreplizierende (DB-)Systeme sind wesentlich
anfälliger für Ausfälle im Gegensatz zu zentralistisch ausgelegten
Systemen
– Um Ausfall von einem Knoten zu kompensieren, werden wichtige
Daten redundant auf mehreren Knoten abgespeichert
– Auch Daten mit hohen Zugriffsraten werden auf mehrere Knoten
verteilt
– Alle Knoten die replizierte Daten enthalten bilden zusammen die
Replikationsumgebung
4-5
4.2.2 Vorteile von Replikation
• Vorteile:
–
–
–
–
–
Höhere Verfügbarkeit durch Verteilung der Daten auf mehrere Knoten
Niedrigere Kommunikationskosten
Bessere Performanz durch lokalen Zugriff
Ermöglicht Lastverteilung (Zugriff auf Knoten mit geringster Last)
Vorbeugung gegenüber Datenverlust
– Replikation ist Grundlage für das Arbeiten mit Clients, die sich im
Disconnected Mode befinden
 Suche nach intelligenten Verfahren zur Auswahl der zu
replizierenden Daten
4-6
4.2.3 Was ist ein Replikat?
• Definition
– Ein Replikat ist eine Kopie, also eine redundante Speicherung
eines bereits existierenden Datenelements
– Datenelement kann ein Tupel, eine Relation, Teile einer Relation
oder eine ganze Datenpartition sein
– Per se gibt es kein Originalelement, dieses kann aber bei Bedarf
festgelegt werden
– Es können beliebig viele Kopien existieren
4-7
4.2.4 Zentrale Strategien beim Einsatz
der Replikation
Übersicht:
• Kopie-Update-Strategien
• Fehlerbehandlungs-Strategien
• Synchronisations-Strategien konkurrierender Zugriffe
• Konsistenz-Strategien bei Lesetransaktionen
4-8
Zentrale Strategien beim Einsatz
der Replikation
• Kopie-Update-Strategien:
– Datenoperationen werden auf einem einzelnen Replikat ausgeführt
– Die daraus resultierenden Änderungen werden auf 2 verschiedene
Arten an die anderen Kopien weitergegeben
• Wenn alle Replikate gleichzeitig aktualisiert werden, spricht
man von Eager Replication
• Wenn die Änderung asynchron an die anderen Replikate
weitergegeben wird, spricht man von Lazy Replication
– Die Erlaubnis zur Änderung ist oft an spezifische Bedingungen
geknüpft und hängt oft von den anderen Kopien des Replikats ab
(z.B. Quorum-Verfahren)
4-9
Zentrale Strategien beim Einsatz
der Replikation
• Fehlerbehandlungsstrategien:
– Enthält Methoden, mit denen auf Fehlersituationen während der
Replikation reagiert wird
– Repräsentiert den Ausnahmefall gegenüber den durch die KopieUpdate-Strategien abgedeckten Normalfall
– Häufigste Fehlersituation sind typische Netzpartitionierungen,
wenn also Clients dauerhaft vom Gesamtsystem getrennt werden
– In mobilen Umgebungen aber Netzpartitionierungen Normalfall,
deshalb hat die „Fehlerbehandlung“ eine wichtige Rolle
(Begriff „Fehlerbehandlung“ in diesem Zusammenhang fraglich)
4-10
Zentrale Strategien beim Einsatz
der Replikation
• Synchronisation konkurrierender Zugriffe
– Wichtig sind Methoden zur Konsistenzsicherung innerhalb einer
Replikationsumgebung
– Aufgabe: Eine geeignete Serialisierbarkeitsreihenfolge (Schedule)
finden, damit bei allen Replikaten während allen Transaktionen
keine Konsistenzkonflikte entstehen
– 3 Synchronisationsverfahren:
• konventionell (mit Einsatz von Sperren),
• optimistisch (zeitstempelbasiert, read-set, write-set)
• semantisch (Einbeziehung von speziellem Anwendungswissen)
4-11
Zentrale Strategien beim Einsatz
der Replikation
• Konsistenzstrategien:
3 verschiedene Konsistenzgrade bei Lese-TAs:
Replikate sind
• aktuell und konsistent
negativ für Gesamtdurchsatz, kein disconnected Mode
• Konsistent, aber dürfen etwas veraltet sein. Durch Versionskonzept
können Lese- und Änderungstransaktionen parallel ablaufen
• innerhalb bestimmter Toleranzgrenzen inkonsistent. Die Toleranzgrenze
bestimmt die maximal erlaubte Abweichung vom aktuellen,
konsistenten Datenbankzustand
4-12
4.2.5 Replikationsdefinition
• Wichtigste Aufgabe der Replikation ist die Replikationsdefinition.
Sie wird in 2 Subaufgaben gegliedert:
– Replikationsschemadefinition:
• Definiert den Ausschnitt des Datenbankschemas auf der
Replikationsquelle, der für die Datenreplikation genutzt wird, und
• die Operationen, die auf den replizierten Daten ausgeführt werden
dürfen,
• sowie zusätzliche Integritätsbedingungen
– Replikatdefinition:
• Wählt die zu replizierenden Daten aus (Selektionsbedingungen)
• Ausgewählt werden können alle Daten, die dem Replikationsschema
genügen
• Neben Daten werden auch Integritätsbedingungen auf die Senke
übertragen
4-13
4.2.6 Forderungen
• Weitere Forderungen in der Replikationsumgebung:
– Replikationstransparenz: Der Benutzer merkt von unterschiedlichen Kopien nichts
– 1-Kopie-Serialisierbarkeit: Es gibt mind. einen Schedule, welcher
mit seriellen Transaktionen auf einer Datenbank ohne Replikate
den gleichen Endzustand erzeugt
– Replikationskorrektheit: Änderungen auf einer Kopie sind auf
allen anderen Kopien nachziehbar: alle redundanten Kopien sind
konsistent. Entweder streng korrekt (Identität) oder innerhalb
bestimmter Grenzen ( Konsistenzgrade)
4-14
4.2.7 Zielkonflikt der Replikation
• 3 verschiedene Forderungen an die Replikation
1. Erhöhung der Verfügbarkeit
2. Konsistenz aller Kopien
3. Niedrige Kosten der Replikation
• Konflikt:
Verfügbarkeit
Zielkonflikt der
Replikation
Konsistenz
Kosten
– Replikation wird oft eingesetzt um die Verfügbarkeit zu erhöhen
– Je mehr Senken, desto mehr Daten müssen konsistent gehalten
werden
– Dadurch steigen mit der Zahl der Senken die Kosten
• Konsequenz:
– Alle 3 Forderung sind nie zu erreichen
– Je näher man 2 Forderungen kommt, desto mehr entfernt man sich
von der 3.
4-15
4.3 Synchronisation
•
Ziel: konsistenter Zustand aller Kopien innerhalb einer
Replikationsumgebung
•
Bei Synchronisation müssen Änderungen von der Replikationssenke
auf die Quelle und umgekehrt übertragen werden
- Reintegration: Abgleich der geänderten Daten von Senke auf
Quelle
- Rückübertragung: Quelle überträgt aktuellen + konsistenten
Datenzustand auf die Senke
- Beide Phasen: Bidirektionale Synchronisation
- Eine Phase: unidirektionale Synchronisation
4-16
4.4 Klassische Replikations- und
Synchronisationsverfahren
•
Die wichtigsten Replikations- und
Synchronisationsverfahren:
1. Konsistenzerhaltende Verfahren
•
•
Pessimistische Verfahren (ROWA, Primary-Copy-Verfahren, Quorum, ...)
Optimistische Verfahren (Log-Transformation, Data-Patch-Verfahren)
2. Verfügbarkeitserhaltende Verfahren
•
•
Epsilon-Serialisierbarkeit
Quasi-Copy-Verfahren
3. Data Caching (Replikation innerhalb der Speicherhierarchie)
4. Data Hoarding (gezieltes Nachladen vom Server)
4-17
4.4.1 Konsistenzerhaltende Verfahren
• Eigenschaften der konsistenzerhaltenden Verfahren
– Hauptziel: Strikte Durchsetzung der Konsistenz
(oft auf Kosten der Verfügbarkeit)
– Unterteilt in pessimistische und optimistische Verfahren
– Pessimistische Verfahren:
• verwenden Sperren um von vorneherein alle möglichen Inkonsistenzen
zu verhindern
• Änderungen können gleichzeitig (2-Phasen-Commit-Protokoll) (eager
Repl.) oder asynchron (lazy Repl.) mit gesonderten Update-Aktionen
durchgeführt werden
• Vorteil bei asynchronen Updates: keine systemübergreifende Sperren
– Optimistische Verfahren:
• Gehen von seltenen Inkonsistenzen aus und verwenden deshalb keine
Sperren
• Nach jeder Transaktion findet Validierung statt, ob ein inkonsistenter
Zustand vorliegt
4-18
Pessimistische Verfahren
- ROWA • ROWA (Read One Write All):
– Innerhalb einer Änderungstransaktion alle Kopien updaten
(verwendet 2-Phasen-Commit-Protokoll)
– Alle Kopien eines Replikats sind deshalb stets konsistent
– Lesetransaktionen bekommen so auch keine veralteten Daten
– Erreichbarkeit aller Kopien muss gegeben sein
• deshalb in mobiler Umgebung so nicht einsetzbar, da viele mobile
Clients sich im Disconnected Mode befinden
• Es exisiteren Varianten des ROWA-Verfahrens, die aber keine sinnvolle
Lösungen für den Einsatz in mobilen Umgebungen sind,
z.b. Write-All-Available oder Missing-Update
4-19
Pessimistische Verfahren
- Primary-Copy Verfahren • Primary-Copy-Verfahren:
– Änderungstransaktion wird erst auf einer Masterkopie durchgeführt
– Für die asynchrone Aktualisierung ist nun nicht mehr die
Änderungstransaktion selbst, sondern die Masterkopie zuständig
– Stark zentralistisches Verfahren (Gleichheit aller Knoten wird aufgegeben)
– Vorteil:
• In mobiler Umgebung möglich, dann darf sich aber die Masterkopie nicht auf
einem Client befinden, sondern auf stationärem Knoten
– Nachteil:
• Bei Änderungstransaktionen muss eine Netzwerkverbindung bestehen
• Bei Transaktionen mit vielen Updates kann der Knoten der Masterkopie zu einem
Hot-Spot werden
• Die Wahrscheinlichkeit, dass keine Netzwerkverbindung für eine
Änderungstransaktion besteht, steigt mit jedem Knoten
 Abhilfe: Virtual-Primary-Copy-Verfahren (siehe später)
4-20
Pessimistische Verfahren
- Quorum Verfahren • Quorum-Verfahren:
– Abstimmung entscheiden ob Aktualisierung durchgeführt wird
– Jede Kopie besitzt eine Anzahl von Stimmen (meistens 1)
– Um Aktualisierung durchzuführen muss die Transaktion die
Mehrheit der Stimmen gewinnen (Majority Consensus)
– Transaktion gewinnt eine Stimme wenn eine Kopie durch diese
Transaktion gesperrt werden kann
– Konkurrierendes Schreiben wird verhindert wenn
Schreibquorum > n/2 (Anzahl der Stimmen)
– Konkurrierendes Lesen und Schreiben wird verhindert, wenn
Lese- + Schreibquorum > n
– Randfall: Schreibquorum=n und Lesequ=1 dann ROWA-Verfahren
4-21
Pessimistische Verfahren
- Quorum Verfahren • Quorum-Verfahren Teil II:
– Variante: Einführung von Stimmgewichten
– Variante: Einführung von Zeugen (Stellvertreter-Knoten)
– Wenn Mehrheiten fest vergeben, dann spricht man von
statischem Quorum-Verfahren
– Wenn zur Laufzeit vergeben, spricht man von dynamischen QuorumVerfahren (z.B. zum Zeitpunkt verfügbarer Stimmen)
– (nur bedingt) in der mobilen Umgebung einsetzbar:
• Für Änderungstransaktion muss Verbindung zur Basisstation verfügbar
sein. Diese muss dann das Quorum der anderen Kopien einholen
• Nur mindestens |Qw| Knoten müssen während Abstimmung online sein.
• Für Commit eigentlich alle, Nachziehen auf offline Knoten? Sperren
halten? (Unwahrscheinlich, dass kein Client im Disconnected Mode)
4-22
Optimistische Verfahren
• Eigenschaften:
– Keine Sperren, dafür wird am Ende jeder Transaktion validiert, ob
konsistenter Zustand vorliegt (mittels Zeitstempel)
– Propagation durchgeführter Änderungen erfolgt dann asynchron
– Späteres Wiedereinbringen von Daten kann zu Konflikte führen
(z.B. Änderungen auf einen bereits alten Datensatz)
– Häufig werden diese Konflikte durch semantisches Wissen
aufgelöst (z.B. summierende Verfahren, „neueste Info zählt“…)
– Die 2 wichtigsten Verfahren sind
• Log-Transformation und das
• Data-Patch-Verfahren
4-23
Optimistische Verfahren
- Log-Transformation • Log-Transformation:
– Änderungen einer (mobilen) Kopie werden
zuerst auf der zentralen Datenbank nachgezogen,
dann an die anderen Kopien asynchron weitergegeben
– Alle Transaktionen werden in Logbuch-Einträgen protokolliert
– Bei Konflikten wird die konfliktauslösende Transaktion
zurückgesetzt
– Einfaches Auflösen von Konflikten, aber umfangreiches oder
kaskadierendes Zurücksetzten kompletter Transaktionen möglich
4-24
Optimistische Verfahren
- Data Patch • Data-Patch Verfahren
– Es gibt kein Zurücksetzen von TAs
denn bereits beim Datenbankentwurf werden
anwendungsbezogene Regeln festgelegt
– Diese Regeln legen fest, wie aus 2 verschiedenen Versionen ein
neuer konsistenter Zustand wird
(z.B. neueste Info zählt, Aufaddieren, Chef hat immer recht, ...)
– Data-Patch-Verfahren kann gut in mobilen Umgebungen eingesetzt
werden
– Dieses Verfahren kann sowohl den konsistenz- als auch den
verfügbarkeitserhaltenden Verfahren zugeordnet werden
4-25
4.4.2 Verfügbarkeitserhaltende Verfahren
• Eigenschaften verfügbarkeitserhaltender Verfahren
– Im Gegensatz zu den konsistenzerhaltenden Verfahren steht hier
die höhere (Lese-) Verfügbarkeit von Daten im Mittelpunkt
– Dies wird dadurch erreicht, dass in bestimmten Situationen
inkonsistente Daten geduldet werden
– Konflikte werden oft durch semantisches Wissen aufgelöst
(z.B. summierende Verfahren, Prioritätsverfahren oder
„neueste-Info-zählt“-Verfahren)
– Werden keine Abweichungen toleriert, kann wieder von
konsistenzerhaltenden Verfahren gesprochen werden
4-26
Verfügbarkeitserhaltende Verfahren
• Beispiele für verfügbarkeitserhaltende Verfahren:
– Epsilon-Serialisierbarkeit:
• globaler Faktor Epsilon bestimmt tolerierbare Abweichung gegenüber
bestimmten Konsistenzzustand
• Jedes Replikat hält selbst sein aktuelles Epsilon fest
• Lesezugriff auch auf epsilon-inkonsistente Replikate möglich
 höhere Verfügbarkeit
– Quasi-Copy-Verfahren:
• Ähnlich zur Epsilon-Serialisierbarkeit aber jetzt
– Anzahl Änderungen auf lokaler Kopie
– oder Zeitspanne ausschlaggebend,
nicht eine bestimmte Abweichung
4-27
Was bisher war
• Definition der Begriffe Replikation und Synchronisation
– Ursprung und die Vorteile der Replikation
– 4 Zentralen Strategien beim Einsatz der Replikation
– Zielkonflikt der Replikation
• Beispiele für konstistenzerhaltende Verfahren
– 3 pessimistische Verfahren
– 2 optimistische Verfahren
• 2 Beispiele für verfügbarkeitserhaltende Verfahren
4-28
Was kommt
• Data Caching und Data Hoarding Verfahren
• Verzicht auf Replikation
• Beispiele für neue mobile Verfahren
• Synchronization Markup Language (SyncML)
4-29
4.4.3 Data Caching
• Data Caching: (Replikation innerhalb der Speicherhierarchie)
– Zugriff auf Daten wird stark beschleunigt, wenn die Daten schon im
Cache sind. Deshalb bevorzugte Speicherung im Cache
– Intelligente und vorrausschauende Verfahren gesucht, damit Daten
mit hohen Zugriffsraten im Cache sind oder/und bleiben
– Da bei mobilen Clients der Cache bisher recht klein ist, sind solche
intelligenten Verfahren sehr wichtig
– Eine Variante ist das semantische Cachen. Es werden zusätzlich
Beschreibungen der Daten gespeichert, damit intelligente
Einlagerungsstrategien implementiert werden können
(Nachteil: Speicherplatzbedarf steigt)
4-30
Data Caching
– Cachen heißt zusätzliche Redundanzebene:
– Bei Synchronisation: Cache-Kohärenz sicherstellen!
Damit nicht mit alten Cache-Werten weitergearbeitet wird.
– Mobile Endgeräte:
Vorab-Cache-Einlagerungen (Prefetching)
• Nicht nur zugriffs- und zeitabhängig
• auch ortsabhängig (bei Standortwechsel des Nutzers)
4-31
4.4.4 Data Hoarding
•
Data Hoarding: (gezieltes, vorausschauendes Nachladen
vom Server)
– Besondere Variante des Prefetchings bei Caches, speziell für die
mobile Umgebung
– Datenaustausch zwischen Server und Client nur an speziellen
Infostationen
– Die Infostationen sind mit WLANs ausgestattete Terminals, die
untereinander mit Hochgeschwindigkeitsnetzwerk verbunden sind
– Gerade dort eingesetzt, wo Benutzer keine eigenen Clients,
sondern nur anwendungsspezifische Clients haben (z.B. Museum)
4-32
Data Hoarding
– Spezieller Proxy-Server koordiniert sämtliche Hoarding-Prozesse:
• Schritt 1: Drahtloser Download der wahrscheinlich benötigten
Informationen
• Schritt 2: Trennung der Verbindung zur Infostation
• Schritt 3: Gelegentliche Übertragung des protokollierten
Nutzerverhaltens an erreichbare Infostationen
bei Bedarf: Nachladen
4-33
4.4.5 Verzicht auf Replikation
• Verzicht auf Replikation:
– Nur möglich, wenn eine zuverlässige und hochverfügbare
Infrastruktur drahtloser Netzwerktechnologien vorhanden ist
(z.B. firmeninternes WLAN)
– Zentrale Datenhaltung und eine Schnittstelle für drahtlosen OnlineZugriff anzubieten kann einfacher sein als Offline-Szenarien mit
komplizierter Replikation und Synchronisation
4-34
4.5 Neue mobile Verfahren
• Eigenschaften:
– Pessimistische Verfahren sind schlecht einsetzbar, da sie auf dem
Einsatz von Sperren basieren.
Sperren können aber sehr kritisch sein, falls ein Client eine Sperre
setzt und in den Disconnected Mode wechselt und dort lange bleibt
– Grundlage sind die optimistischen Verfahren
– Trotzdem wurden auch pessimistische Verfahren entwickelt,
Beispiel dafür ist das Virtual-Primary-Copy-Verfahren
4-35
Neue mobile Verfahren
1. Virtual-Primary-Copy
• Virtual Primary Copy:
– Virtual-Primary-Copy ist eine Variante des Primary-Copy Verfahren
– Basiert auf den konsistenzerhaltenden, pessimistischen Verfahren
– Masterkopie jetzt immer auf dem mobilen Client (!), zusätzlich noch
eine virtuelle Masterkopie (Position frei wählbar, meist im Festnetz)
– Falls nun Masterkopie für andere Clients nicht erreichbar ist,
können die anderen Clients ihre Änderungstransaktion auf der
virtuellen Masterkopie durchführen
– Sobald wieder online muss ein Abgleich beider Kopien erfolgen,
damit ein konsistenter Zustand vorliegt
4-36
Neue mobile Verfahren
2. Snapshot-Verfahren
• Snapshot-Verfahren:
– Sehr gut einsetzbar in mobilen Umgebungen
– Snapshots sind materialisierte Sichten nichtlokaler Datenbestände
– Snapshots basiert auf einer Originaltabelle, auch Mastertabelle
genannt
– Snapshots können einzelnen Tupel bis hin zu kompletten
Relationen sein
– Replikationsserver werden als Master-Sites, mobile Clients als
Snapshot-Sites bezeichnet
– Kommunikation kann synchron (verbindungsorientiert)
oder asynchron (dateibasiert) erfolgen
– Synchronisation kann als Abgleich von Snapshots aufgefasst
werden
4-37
Neue mobile Verfahren
- Snapshot-Verfahren • Publish & Subscribe-Modell:
Der Server bietet Publikationen an,
der Client subscribiert sie
– Publikationen = { Publikationsartikel* }
– Publikationsartikel = Snapshot beliebiger Granularität,
z.b. durch SQL-Anweisung definiert
– Zuordnung von Publikationen (Snapshots) zu mobilen Clients
erfolgt anhand von Subskriptionen (auch parametrisierbar)
 Subskription = Zuordnung Replikationsquelle zu Senke
4-38
Neue mobile Verfahren
- Snapshot-Verfahren • Einfache vs. Komplexe Snapshots
(vgl. View-Update Problem)
– Einfache Snapshots basieren auf einer einzelnen Tabelle. Zwischen
Originaltabelle und Snapshot muss eine bijektive Abbildung existieren
– Komplexe Snapshots beziehen sich auf mehrere Tabellen oder enthalten
GROUP BY oder Aggregatfkt oder weitere Snapshots
– Bei komplexen Snapshots ist keine Reintegration möglich,
deshalb nur lesender Zugriff auf den mobilen Clients
• Zusammenfassung
– Snapshots unterstützen den Disconnected Mode mobiler Clients
– In Offline-Phasen können beliebig viele Update-Operationen ausgeführt
werden
– Abgleich der Daten danach durch Synchronisation und gegebenenfalls
durch Konfliktauflösungsroutinen
4-39
Neue mobile Verfahren
3. Replikationsserver-Verfahren
• Motivation:
– Beobachtung: Replikation und Synchronisation erzeugt erhebl. Last
auf stationärem DBS, besonders bei sehr vielen mobilen Clients
– Idee: Um den Datenbankserver von der Koordination der
Replikation und Synchronisation zu entlasten, kann man die
klassische Client/Server-Architektur erweitern um einen
Replikationsserver (Replication Proxy Server)
– Dann auch anwendungsgesteuerte, dynamische Auswahl der
Replikate
– SQL-ähnliche Schnittstelle, um eine solche dynamische Auswahl
treffen zu können
4-40
Neue mobile Verfahren
- Replikationsserver-Verfahren • 3-stufige Architektur:
– Replikationsanforderungen des mobilen Clients werden dann über
den Replikationsserver an den Datenbankserver übertragen
– Replikationsserver hat eine Kopie der Daten vom Datenbankserver
– Aufgabe des Replikationsserver:
• Pflege von Daten- und Schemaelementen
• Bestimmung der zu replizierenden Daten unter der Berücksichtigung
der bereits replizierten Daten
– Der Datenaustausch zwischen mobilen Client und Datenbankserver
ist nur noch indirekt möglich
– Replikationsserver auf eigenem Rechner, z.B. auf Basisstation
4-41
Neue mobile Verfahren
- Replikationsserver-Verfahren • Architektur:
Mobiler Client
Anwendung
Replikationsserver
Quellserver
Daten und
Updates
DBMS
Dienstaufrufe
DBMS
DBMS
Kommunikation
zu anderen RPS
– Vorteil: Skalierbarkeit bei sehr vielen mobilen Clients
(sync erzeugt erhebl. Last auf stationärem DBS)
– Ebenso können Lastspitzen vom Datenbankserver weg verteilt
werden
4-42
Neue mobile Verfahren
- Replikationsserver-Verfahren • Anforderungen und Ablauf nutzerdefinierter Replikation:
– Heute meist traditioneller Szenarien:
z.B. Zugriff auf einen gemeinsamen Informationspool
– Zukünftig: Location Based Services
– Dabei: Benutzer soll dann Daten nicht nur verwenden, sondern
auch aktualisieren oder ergänzen
– Def.: nutzerdefinierte Replikation:
Dienst, der dynamisch die zu replizierenden Daten abhängig von
Position und Zeit bestimmt, damit diese Daten dann im
Disconnected Mode weiterverarbeitet werden können
4-43
Neue mobile Verfahren
- Nutzerdefinierte Replikation • 5 Anforderungen an die Implementierung nutzerdefinierter Replikation:
– Replikation: Anwendung soll nach den Vorgaben des Nutzer die Daten
aus einer zentralen Datenbank lokal replizieren
– Replikationseffizienz: Nur Daten replizieren, die noch nicht lokal
vorhanden sind
– Speicherplatzbeschränkung: Wenn für neue Daten kein Speicherplatz
auf Client ist, müssen alte, nicht mehr
benötigte Daten gelöscht werden
– Zugriff: jeder Nutzer soll über die notwendigen Änderungs- und
Einfügerechte verfügen
– Konsistenz: Um Konsistenz der Daten zu garantieren, müssen
Routinen für Konflikterkennung und –behandlung
implementiert werden
4-44
Neue mobile Verfahren
- Nutzerdefinierte Replikation • Anforderungen und Ablauf:
– Weitere Punkte:
• Schnittstelle muss implementiert werden für Anwendungen, die
dynamische Replikation von Daten anfordern,
• Replikate müssen mit Zusicherungen ergänzt werden
(z.B. einem garantierten Einfügerecht)
– Der Abgleich der Daten zwischen Replikations- und Quellserver
erfolgt asynchron
– Primärziel der Einführung eines Replikationsservers ist die
Entkopplung der mobilen Nutzer vom Quellserver
4-45
4.6 Synchronization Markup Language
(SyncML)
• SyncML:
– Definiert eine herstellerunabhängige Technologie für die
Synchronisation von Daten in einem mobilen Client/Server-Szenario
(Open Mobile Alliance: Nokia, IBM, Panasonic, Ericson, Motorola, ...)
– Als plattenformunabhängiges Datenformat der zu übertragenden
Synchronisationsnachrichten wurde XML bestimmt
– Um die Abhängigkeit von bestimmten Netzwerkprotokollen zu
umgehen, wurde der physikalische Transport aus SyncML
ausgeklammert
– Welches Transportprotokoll benutzt wird, hängt von der jeweiligen
Implementierung ab
– Ziel: alle anfallenden Synchronisationsvorgänge sollen über einen
einzelnen Mechanismus abgewickelt werden
– Beispiel: Nokia Communicator 9210
4-46
Synchronization Markup Language
• 7 Synchronisationsszenarien:
– Zwei-Wege-Synchronisation (bidirektionale Synchronisation):
• Client und Server teilen sich nacheinander gegenseitig alle
angefallenen Änderungen mit
– Langsame Synchronisation:
• Client übermittelt seine Änderungen an den Server, dort werden die
empfangenen Änderungen feldweise mit dem Datenbestand verglichen
– Einweg-Synchronisation (Client):
• Client übermittelt seine Änderungen an den Server. Eventuelle
zwischenzeitl. Änderungen auf dem Server werden ohne Nachfrage
überschrieben
– Einweg-Synchronisation (Server):
• Wie beim Client, nur Übertragung von Server auf Client
4-47
Synchronization Markup Language
• 7 Synchronisationsszenarien:
– Erneuerungs-Synchronisation (Client):
• Der Client überträgt seinen kompletten Datenbestand an den Server.
Auf dem Server werden alle entsprechenden Daten überschrieben
– Erneuerungs-Synchronisation (Server):
• Wie beim Client, nur Übertragung von Server auf Client.
D.h. Server überschreibt alle Client-Daten komplett
– Serverinitiierte Synchronisation:
• Server stellt die Forderung an den Client, einen Synchronisationsvorgang, der einer der ersten sechs Typen sein muss, zu
initialisieren
4-48
Synchronization Markup Language
• Anforderungen für die Synchronisation:
– Datensätze müssen separierbar sein
– Jeder Datensatz muss eindeutig identifizierbar sein
– Identifikatoren werden serverseitig als Global Unique Identifier
(GUID), clientseitig als Local Unique Identifier (LUID) bezeichnet
– Wenn auf Server und Client verschiedene Identifikatoren verwendet
werden, muss der Server eine korrekte Zuordnung vornehmen
können (Mapping-Tabelle)
– Datenveränderungen werden immer in Log-Dateien protokolliert
(dienen als Grundlage für spätere Sync-Vorgänge)
4-49
Synchronization Markup Language
SyncEngine
Anwendung
SyncServer
Agent
SyncClient
Agent
SyncMLAdapter
SyncML
XML-Objekte
SyncMLAdapter
SyncMLInterface
– Um Daten synchronisieren zu können,
müssen alle beteiligten Anwendungen
das SyncML Sync Protokoll implementieren
– SyncEngine auf Clientseite nicht abgebildet,
da diese nur eingeschränkte Funktionen hat
– SyncML-Interface + -Adapter transformieren
Originaldaten ins XML-Format
– Kommunikation aller beteiligten Instanzen
erfolgt nur über diese Adapter
– Für das globale Management aller
Synchronisationsprozesse wird ein
Synchronisationsserver eingesetzt
Anwendung
SyncMLInterface
• SyncML-Framework:
Transport (z.B. HTTP)
4-50
Synchronization Markup Language
• Synchronisationskonflikte:
– Können natürlich auch hier auftreten
– Konfliktlösung ist Aufgabe des Servers bzw. der SyncEngine
– Wenn SyncEngine Konflikt feststellt, wird dies an den konfliktauslösenden
Client mitgeteilt
– SyncML legt aber nicht fest, welche Konfliktauflösungsroutinen in welchem
Konfliktfall konkret angewandt werden sollen
4-51
Synchronization Markup Language
• Synchronisationskonflikte
– Beispiele für Konfliktauflösungsmethoden:
• Kapitulation: Synchronisation wird nicht durchgeführt.
• Duplikat: Von dem Datensatz, der einen Konflikt ausgelöst hat, wird ein
Duplikat angelegt. Beide Änderungen werden dann
unabhängig voneinander auf jeweils einem der verfügbaren
Datensätze ausgeführt.
• Priorität: Im Konfliktfall kann eine höhere priorisierte Operation
bevorzugt werden.
• Gewinner: Dabei gewinnt immer eine der beiden Konfliktparteien. So
kann z.B. immer der Client gewinnen.
4-52
4.7 Zusammenfassung
•
•
•
•
•
Definition der Begriffe Replikation und Synchronisation
Ursprung und die Vorteile der Replikation
4 Zentralen Strategien beim Einsatz der Replikation
Zielkonflikt der Replikation
Beispiele für konsistenz- und verfügbarkeitserhaltende
Verfahren
• Data-Caching und Data-Hoarding-Verfahren
• Beispiele für neue mobile Verfahren
• Synchronization Markup Language (SyncML)
4-53