Upload
peregrine-palacios
View
19
Download
0
Embed Size (px)
DESCRIPTION
Replikation in verteilten Datenbanken. Gliederung: Einführung Grundlagen und Verfahren Realisierte Technologien am Beispiel von Sybase. Jürgen Bittner SQL GmbH Dresden [email protected]. Begriff Replikation. ist eine Funktionalität in - PowerPoint PPT Presentation
Citation preview
Replikation in verteilten Datenbanken
Jürgen Bittner
SQL GmbH Dresden
Gliederung:
• Einführung• Grundlagen und Verfahren• Realisierte Technologien am Beispiel von Sybase
Begriff Replikation
ist eine Funktionalität in• Integrierten Shared-Nothing-Mehrrechner-
Datenbanksystemen,wie z.B. Workstation/Server-DBS und allen DBS mit multipler Allokation von Fragmenten
• Föderativen Mehrrechner-Datenbanksystemen (homogene und heterogene)
zum• Synchronisieren der Daten, d.h. zum (konsistenten)
Verwalten von Datenkopien • Verwalten abhängiger Aktionen, die an verschiedenen
Orten einer verteilten Datenbank stattfinden sollen (Steuern von Geschäftsprozessen)
Begriff Replikation
• (konsistentes) Verwalten von Kopien von Daten in verschiedenen Orten einer verteilten Datenbank
• und zum Steuern von Geschäftsprozessen
Ziele der Replikation
• Verbesserte Verfügbarkeit der Daten
• Erhöhte Performance
• Lokale Autonomie in Verbindung mit Integrationsprozessen
• Ziele verteilter Datenbanken weitgehend in Übereinstimmung mit Zielen der Replikation
Betriebliche Anforderungen
• Zuverlässige Bereitstellung von Up-to-Date
Informationen
• Unternehmensweite Konsolidierung von dezentralen
Einheiten
• Kombination von Decision Support mit OLTP
• Unterbrechungsfreier Betrieb trotz geplanter oder
ungeplanter Systemausfälle
Replikationsstrukturen (Beispiele)
• Zentral verfügbare Daten werden verteilt repliziert zur Unterstützung
lokaler Anfragen (Decision Support Replicates)
• Zusammenführung dezentral verfügbarer Daten in einem zentralen Ort
(Corporative Data Consolidation)
• dezentral verfügbare Daten werden zu den jeweils anderen Orten für
Anfragen repliziert, ohne daß Eigentümerprinzip gilt (Corporate Data
Integration)
• Daten eines Ortes werden vollständig zu einem anderen Ort repliziert
(Stand-by database)
In der Praxis mehr oder weniger gemischte Verwendung dieser Strukturen
Real-Time Decision Support
Fortlaufende Weitergabe von Änderungen erzeugt eine ‘Echtzeit-Kopie‘
Beseitigt unvorhersehbare Einbrüche bei der OLTP Performance aufgrund langlaufender Abfragen
OLTPApplikationen
DecisionSupportApplikationen
PrimaryOLTP
Datenbank
ReplicateDecision Support
Datenbank
Unternehmensweite Konsolidierung
• Lokale Autonomie - jeder Standort verwaltet seine eigene Primärkopie
• Einige oder alle Daten werden in die Zentrale repliziert
• DB-Schemata müssen nicht identisch sein
• Up-to-Date Informationen immer verfügbar
Primary Sites
NYNY
LondonLondon
TokyoTokyo
CorporateCorporate
Replicate Site
Netzwerk
TokyoTokyo
LondonNY
Central Datastore
Mobile Computing
EmbeddedComputing
Workgroup Computing
Unternehmens-Datenverarbeitung
Replikation in verteilten Datenbanken
Gliederung:
• Einführung
• Grundlagen und Verfahren
• Realisierte Technologien am Beispiel von Sybase
Verfahren zur Replikation
StrengeKonsistenz
erfordertSynchroneReplikation
Konsistenz-anforderung
VerteilteTransaktionen
mit 2-PC
Verfahren
Performance,Verfügbarkeit
Probleme,Besonder-heiten
SchwacheKonsistenzermöglicht
AsynchroneReplikation
Dump,Reload
TableSnapshot
Trigger- und Regel-
basierteReplikation
Transaktions-basierte
Replikation
GeringeAktualität,
lokaleAutonomie
KonsistenteTransaktionen,
lokaleAutonomie
Administrativerund
PerformanceOverhead,
lokaleAutonomie
Eigentümerprinzip oder
hierarchischeTopologie ?
Timestamp-basierte
Replikation
Script-Entwicklung
Grundlegende Entscheidungskriterien
Bei der Entscheidung über eine Replikationstechnologie ist zu betrachten:
• Geschäftsanforderungen für die verteilte Datenbank
• Technologische Bedingungen und Grenzen der Anwendungsumgebung
• Verfügbare Resourcen für Entwicklung und Administration
Verteilte DatenbankenPraktische Faktoren
• Nicht alle Systeme erfordern, dass alle Daten an
allen Orten verfügbar sind.
• Nicht alle Systeme erfordern, dass alle Daten an
allen Orten stets konsistent sind.
• Der Grad, in dem das System die Anforderungen der
Definition erfüllen soll, ist der wichtigste Faktor bei
der Auswahl der Replikationstechnologie.
Probleme der verteilten Datenhaltung
• Konsistenz • Lokale Autonomie• Datenpartitionierung (-fragmentierung)• Transaktionssteuerung• Zugriffsmöglichkeiten (connection)• Topologie
Wahl der Technologie ist abhängig von:
Konsistenz
• Strenge Konsistenz erfordert, dass sich alle Daten in
einem konsistenten Zustand befinden.
• Schwache Konsistenz erlaubt “nicht-aktuelle” Daten.
• Latenz ist das Maß, wie lange die Daten brauchen, um
konsistent zu werden.
• In manchen Fällen ist das System nie konsistent, weil es
immer Änderungen gibt, die noch nicht repliziert wurden.
Strenge oder schwache Konsistenz
Welche Version der Daten wird benutzt?
Waterloo
200 1000
Konto
Kto.-Nr. Stand
Paris
200 1000
Konto
Kto.-Nr. Stand
Lokale Autonomie
• Jeder Ort sollte unabhängig von den anderen
Orten operieren können.
• Daten
• Datenbank-Struktur
• Applikations-Software
• Zeit
Daten-Partitionierung
• Auch als Fragmentierung bezeichnet.
• Nur die Daten, die an einem Ort benötigt
werden, sollen dort gespeichert sein.
• Die Datenbank eines Ortes ist ein “complete”
subset der Daten.
• Ein Teil der Daten muß für verschiedene Orte
dupliziert werden.
Daten-Partitionierung Update Anywhere
• Primary keys müssen eindeutig sein in der gesamten Verteilten Datenbank.
• Falls mehrere Orte insert in die gleiche Tabelle ausführen.
• Erfordert einen Mechanismus zur Konflikterkennung und -auflösung.
• Falls mehrere Orte berechtigt sind, die gleichen Zeilen zu ändern.
• Bezugsobjekt der Fragmentierung ist Tabelle• Jedes Fragment ist eine Tabellen-Untermenge
• Vollständige Tabelle
• Teilmenge der Zeilen (row subset)
• Teilmenge der Spalten (column subset)
• Row und Column Subset
Daten-Partitionierung
Transaktions-Steuerung
• Die gewählte Technologie sollte die ACID-Bedingung erfüllen:• Atomicity, Consistency, Isolation, Durability
• Nur “committed data” sollten repliziert werden.• “committed data” müssen repliziert werden.• Fehler beim Replizieren von “committed data”
müssen erkennbar sein.• Änderungen müssen in allen Datenbanken in der
gleichen Reihenfolge verarbeitet werden.
Zugriffsmöglichkeiten
Welcher Netzwerk-Typ steht den Orten zur Verfügung?
• High-speed LAN/WAN
• Low-speed Dial-up (RAS)
• Wireless
• Indirect (email, ftp)
• Internet (HTTP)
• Sneaker-net
Hierarchisch Peer-to-peer
Remote database/
Consolidateddatabase
Remote database
Remote database
Consolidateddatabase
Remote database
Remote database
database database
database database
database
database
Topologie
Topologie
Welche Art von Beziehungen existiert zwischen den Orten?
Peer-to-peer (für update anywhere)• Jeder Ort kann Daten zu irgendeinem anderen
Ort transferieren.
• Keine zentralisierte Masterkopie existiert.
• Konfliktauflösung ist extrem schwierig.
• Es gibt keinen Ort zum Erkennen und Auflösen der Konflikte.
Topologie
Hierarchisch• Jeder Ort sendet und empfängt Daten auf- und
abwärts innerhalb der Hierarchie.
• Eine zentrale Masterkopie (konsolidierende Datenbank) existiert.
• Daten müssen stets über eine konsolidierende Datenbank zu anderen Orten repliziert werden.
• Erkennen und Auflösen der Konflikte sind in der konsolidierenden Datenbank implementiert.
Topologie
Peer-to-peer (für Eigentümerprinzip)
• Jeder Ort kann Daten zu irgendeinem anderen Ort transferieren.
• Keine zentralisierte Masterkopie existiert, aber jedes Fragment besitzt genau einen Eigentümer(ort) - Primärkopie.
• Konflikte werden vermieden. Konfliktauflösung ist nicht erforderlich.
Weitere Probleme
Anzahl der Orte• Bestimmte Technologien sind bei großer
Anzahl besser geeignet (mass deployment).
Hersteller• Sind die DBMS der verschiedenen Orte vom
gleichen Hersteller ?
Verfahren zur Replikation
StrengeKonsistenz
erfordertSynchroneReplikation
Konsistenz-anforderung
VerteilteTransaktionen
mit 2-PC
Verfahren
Performance,Verfügbarkeit
Probleme,Besonder-heiten
SchwacheKonsistenzermöglicht
AsynchroneReplikation
Dump,Reload
TableSnapshot
Trigger- und Regel-
basierteReplikation
Transaktions-basierte
Replikation
GeringeAktualität,
lokaleAutonomie
KonsistenteTransaktionen,
lokaleAutonomie
Administrativerund
PerformanceOverhead,
lokaleAutonomie
Eigentümerprinzip oder
hierarchischeTopologie ?
Timestamp-basierte
Replikation
Script-Entwicklung
Streng konsistente Replikation
• Replikation muß bei meisten DBMS programmiert
werden, nur ein Hersteller gestattet Definieren der
Replikation für Tabellen
• Benutzt das 2-Phase-Commit (automatisch oder
programmiert)
• alle Kopien sind identisch
• großer Protokoll-Overhead
• reduziert die Fehlertoleranz und Verfügbarkeit
Streng konsistente Replikation
Änderungen werden “simultan” in allen Datenbanken ausgeführt.
Waterloo
200 1000
Konto
Kto.-Nr. Stand
Paris
200 1000
Konto
Kto.-Nr. Stand
Abhebung $100
Bitte Warten, das Konto wird gerade geändert
Streng konsistente Replikation :Konsistenz
• Wenn absolute Konsistenz gefordert ist.
• Die Transaktion wird in allen oder keiner der
beteiligten Datenbanken realisiert.
Streng konsistente Replikation Lokale Autonomie
• Sehr niedriges Niveau der lokalen Autonomie.• Falls ein Ort ausfällt, ist das gesamte System nicht
mehr verfügbar.
Waterloo
200 1000
Konto
Kto.-Nr. Stand
Paris
200 1000
Konto
Kto.-Nr. Stand
Abhebung $100
Leider ist das System nicht verfügbar X
Streng konsistente Replikation :Daten-Partitionierung
• Daten können beliebig partitioniert werden.
• Die Applikation muß die notwendigen Änderungen überall ausführen.
• Da die Transaktion in den beteiligten Datenbanken simultan ausgeführt wird, gibt es keine Probleme mit primary keys oder Konflikten.
Streng konsistente Replikation :Transaktions-Steuerung
Ein Distributed Transaction Server (DTS) ist erforderlich.• Datenbank-Server mit DTS-Funktionalität
• Spezieller DTS
• Application Server mit DTS-Funktionalität
Verteiles 2-Phasen-Commit
Basisverfahren:
• 4 N Nachrichten (N = Anzahl der Teil-TA)
• 2 (N + 1) Log-WritesABORT-Nachrichten gehen nur an Teil-TA, die nicht mit FAILED gestimmt haben
Problem bei 2PC:
bei Koordinatorausfall lange Blockierung möglich
R1 R2(Koordinator)
R3
Teil-TA-Ausführung
Logging
Logging, Sperrfreigabe
PREPARE
READY (FAILED)
COMMIT (ABORT)
Logging
Logging
PREPARE
COMMIT
ACK
Streng konsistente Replikation : Zugriffsmöglichkeiten
• Zuverlässiges Netzwerk ist erforderlich.
• Geschwindigkeit der Applikation ist stark
abhängig von der Geschwindigkeit des
Netzwerks.
Streng konsistente Replikation :Topologie
Typisch für eine peer-to-peer Topologie.• Da alle Datenbanken “simultan” geändert
werden, ist keine Masterkopie erforderlich.
Streng konsistente Replikation Weitere Probleme
• “Leicht” zu verstehen• Sehr wenige Orte können unterstützt werden.• Verteilung der Daten schwer skalierbar, da
das Hinzufügen weiterer verteilter Komponenten die Performance senkt
• Heterogene Umgebungen “einfach” zu unterstützen.
Schwach Konsistente Replikation
• Primäre Kopie der Daten
• primäre und replizierte Daten sind nicht zu
jeder Zeit identisch
• Hohe Performance erreichbar
• hohe Verfügbarkeit der Daten und
Fehlertoleranz
Verfahren der schwach konsistenten Replikation
Dump und Reload
Table Snapshot Replikation
Trigger- und regelbasierte Replikation
Transaktions-basierte Replikation
Timestamp-basierte Replikation
Dump und Reload
• Datenbank Backups
• Datenbank Logs
• Versenden von Daten zu entfernten Orten
• Versenden von Transaktionen zum
Zentralort
• gewöhnlich lange Verzögerungszeit
• Schwierigkeiten mit großen Datenmengen
Table Snapshots Replikation
• Mehrere Hersteller unterstützen definierte Snapshots• Replikate sind Kopien von:
- Tabellen- Teilmengen von Tabellen- Views, Queries
• Ausführung automatisch (Trigger- oder zeitgesteuert) oder manuell
• meist read-only, aber auch eine updatable snapshot-Lösung existiert
• Problem: begrenzte Konsistenz muß von Anwendungen berücksichtigt werden
• spezielle Lösungen zum Erreichen akzeptabler Performance
Trigger-basierte Replikation
begin
Call uppdate T1(...)
Call delete T1(...)
Call insert T2(...)
Call update T3(...)
.
.
.
Primärort
Propagation queue
update T1
Trigger
Trigger
Trigger
Trigger
delete T1
insert T2
update T3
commit
Replikatort 1 Replikatort 2
Store and forward 2-PC
Transaktion
Transaktion
Trigger-basierte Replikation (1)
Trigger - ursprünglich Konzept zur Sicherung der Datenintegrität, hauptsächlich der Referenzintegrität
Belastung mit Replikationslogik führt zu großen Administrationsproblem
“The excessive use of triggers can create a complex web of mechanisms, which may be difficult to maintain in a large application“
Replikation bezüglich einer Tabelle erfordert i.a. mehrere Trigger
Performance Probleme:
• Triggerverfahren bewirkt Belastung der Transaktionen
• zeilenweises Auslösen, evtl. für jeweils mehrere Zielorte
• Daten- und Systemressourcen werden für längere Zeit gesperrt
Trigger-basierte Replikation (2)
Trigger in Verbindung mit “Update anywhere“ (symmetrische Replikation) erfordern synchronisierten Triggercode
weitere Belastung der Triggeradministration, z.B. bei 100 Tabellen die über 5 Server repliziert werden, sind bis zu 3 x 5 x 100 = 1500 Trigger notwendig;
falls ein Server hinzuzukommt, sind alle zu ändern
Transaktions-basierte Replikation
Begin
Update T1
delete T1
insert T2
update T3
Commit
Log Stablequeue Transaktion
TransaktionDB- Server
ReplicationServer
Log TransferManager
Primärort Replikatort 1 Replikatort 2
ReplicationServer
ReplicationServer
DB- Server
Symmetrische Replikation versus Eigentümerprinzip
Symmetrische Replikation
replizierte Daten dürfen an mehreren Orten geändert werden
Konfliktauflösung erforderlich
nur strukturgleiche Tabellen können repliziert werden
Objekt der Datenreplikation ist Tabelle
Objekt der Prozedurreplikation ist identische Prozedur
Eigentümerprinzip
jedes Datenelement besitzt einen Eigentümer (Primärort), der dieses Datenelement ändern darf; die Replikatorte dieser Datenelemente dürfen nur lesen
keine Konflikauflösung erforderlich
Replikate können strukturell von Primärdaten abweichen
kleinstes Objekt der Datenreplikation ist Spalte einer Zeile
Objekt der Prozedurreplikation ist “beliebige“ Prozedur
• Replication Server verwaltet die Konfiguration und Verteilung von Transaktionen
• Replication Agents protokollieren Update Transactions an den Quell-Datenbanken
• Gateways und Replication Driver für ODBC liefern Änderungen für DBMS verschiedener Hersteller
Peer-to-peer/Eigentümerprinzip Modulare Architektur mit Support für Heterogenität
DB-Server
Replication Server
NetworkNetwork
AndereAndereDatenDaten
QuellenQuellen
ReplicationAgent
ReplicationAgent
Replication Driver for ODBC
AndereAndereDatenDatenZieleZiele
AndereAndereDatenDatenZieleZiele
Transaktions-basierte Replikation:
NetworkNetworkLANLAN
MessageAgent
MessageAgent
Consolidated database
Remote database
Inbox
Inbox
Log
Log
DB
DB
Transaktions-basierte Replikation:Hierarchisch
MessageAgent
Remote databaseInbox
Log
DB
Transaktions-basierte Replikation
1234 10
Product
sku_key qty_oh
Product
sku_key qty_oh
109X1098
XX
UPDATE Product SET qty_oh = 8WHERE sku_key = 1234
UPDATE Product SET qty_oh = 9WHERE sku_key = 1234
1234 10109X1098
XX
Transaktions-basierte Replikation Konsistenz
• Niedriges bis hohes Konsistenz-Niveau ist möglich.
• Geschwindigkeit des “store and forward messaging
system” entscheidet wie konsistent die Datenbank ist.
• Irgendeine Latenz ist immer vorhanden.
Transaktions-basierte Replikation Lokale Autonomie
• Hohe lokale Autonomie
• Datenbank benötigt nur Daten, die von der
Applikation benötigt werden.
Transaktions-basierte Replikation Partitionierung
• Daten sind meist partitioniert.
• Jede DB hat gemeinsame Daten und spezifische Daten.
• Update anywhere erfordert:
• Unique primary keys.
• Konflikt-Erkennung und Auflösungsverfahren.
Transaktions-basierte Replikation Transaktions-Steuerung
Transaktions-Steuerung muss garantieren:• Senden und Verarbeiten in korrekter Reihenfolge.• Keine Transaktion darf verlorengehen.
Transaktions-basierte Replikation Zugriffsmöglichkeiten
• Ob eine direkte Verbindung erforderlich ist oder nicht ist abhängig von den Latenzanforderungen.
Transaktions-basierte Replikation Topologie
• Peer-to-peer und hierarchische Topologien können benutzt werden.
• Konfliktauflösung erfordert in der Regel ein hierarchisches Modell.
Transaktions-basierte Replikation Weitere Aspekte
Nur Transaktionen werden transportiert, deshalb:
• Ist es möglich viele DB zu unterstützen.• Der Durchsatz ist unabhängig von der DB-
Grösse.
Timestampbasierte Replikation:mit Synchronisations-Server
TCP/IP
ODBC
MobiLink Client(ASA or UltraLite)
Consolidated DB
Consolidated Database Server
Remote DB
Remote Database Server (ASA or UltraLite)
MobiLinkServer
TCP/IP
Timestampbasierte Replikation
• Gegenwärtiger Zustand der Daten wird zwischen den DB transportiert.
• Kann als “complete refresh” oder nur für geänderte Zeilen ausgeführt werden.
Timestampbasierte Replikation
1234 10
Product
sku_key qty_oh
1234 10
Product
sku_key qty_oh
109X1098
XX
108X
UPDATE Product SET qty_oh = 8WHERE sku_key = 1234
Timestampbasierte Replikation Konsistenz
• Niedriges bis hohes Konsistenz-Niveau ist
möglich.
• Daten sind nur unmittelbar nach der
Synchronization konsistent.
• Frequenz der Synchronisation beinflusst das
Niveau der Konsistenz aber in jedem Fall gibt
es irgendeine Latenz.
Timestampbasierte Replikation Lokale Autonomie
• Hohe lokale Autonomie
• Datenbank benötigt nur Daten, die von der
Applikation benötigt werden.
Timestampbasierte Replikation Partitionierung
• Daten sind meist partitioniert.
• Jede DB hat gemeinsame Daten und
spezifische Daten.
• Update anywhere erfordert:
• Unique primary keys.
• Konflikt-Erkennung und Auflösungsverfahren.
Timestampbasierte Replikation Transaktions-Steuerung
Transaktionsgrenzen werden nicht verwaltet.• Some operation sequences can not be
synchronized. (i.e. insert then delete of a row with the same primary key value)
Most synchronization technologies “batch” the operations.
• e.g. all deletes, then inserts, then updates
Timestampbasierte Replikation Zugriffsmöglichkeiten
• Erfordert eine stabile Netzwerk-Verbindung während des Synchronisation-Prozesses.
• Geschwindigkeit der Verbindung beeinflusst den Umfang der Daten der synchronisiert werden kann.
Timestampbasierte Replikation Topologie
• Peer-to-peer und hierarchische Topologien können benutzt
werden.
• Peer-to-peer ist schwierig, wenn update anywhere erlaubt
ist.
• Welche Kopie ist korrekt?
• Wer löst einen update-Konflikt auf ?
Timestampbasierte Replikation Weitere Aspekte
• Heterogene Umgebungen sind unterstützt.
• Jeder Ort kann unabhängig voneinander
synchronisieren, deshalb können viele Orte
unterstützt werden.
Replikation in verteilten Datenbanken
Gliederung:
• Einführung
• Grundlagen und Verfahren
• Realisierte Technologien am Beispiel von Sybase
Replication Server
Adaptive Server
Adaptive Server
Replication Agent
Replication Agent
Replication Server
Replication Server
DirectCONNECT(Native drivers)DirectCONNECT(Native drivers)
Adaptive Server/Enterprise Adaptive Server/Anywhere Oracle Informix OS/390 DB2 Replication Toolkit for MVS
Adaptive Server/Enterprise Adaptive Server/Anywhere Oracle Informix OS/390 DB2 Replication Toolkit for MVS
Replicate SitesReplicate SitesReplicate SitesReplicate SitesPrimary SitesPrimary SitesPrimary SitesPrimary Sites
DirectCONNECT/Anywhere (ODBC)DirectCONNECT/Anywhere (ODBC)
Replication Server Hauptmerkmale
• Transaktionen werden zu einem Replication Server
gesendet, der diese zwischenspeichert und zu den
Zielorten sendet
• Eine schnelle Verbindung wird vorausgesetzt
• Nahezu real time (niedrige Latenz)
• Große Datenmengen
• Begrenzte Anzahl von Orten
• Heterogene DBMS-Umgebung unterstützt
• Uni-direktional
Replication Server
Replication Agent
Replication Agent
Replication Server
Replication Server
ReplikatortReplikatortReplikatortReplikatortPrimärortPrimärortPrimärortPrimärort
Replication Server - KomponentenPrimärort
• Ursprung der Datenänderung
• Mehrere Hersteller von RDBMS unterstützt
• Hält Eintragungen für alle Transaktionen, normalerweise im Transaktions-Log, nicht bei allen RDBMS möglich
Replication Server - Komponenten Replication Agent
• Liest das Transactions-Log des Primärortes
• Übergibt “committed transactions” in der Reihenfolge ihrer Verarbeitung an den Replication Server.
Replication Server - Komponenten Replication Server
• Empfängt Transaktionen von Replication Agents
• Speichert die Transaktionen solange bis sie an allen
Replikatorten erfolgreich verarbeitet werden konnten
• Verwaltet die Verbindungen zu allen Replikatorten
• Automatisches Recovery und Restore
• Bestimmt welche Orte die Transaktion benötigen und
startet sie in der korrekten Reihenfolge
Replication Server - Komponenten Replication Server
• Verhindert “circular” transactions.
• Ermöglicht Nutzer-programmierte “function strings” zur Manipulation der Transaktion
• Daten-Konvertierung
• Konvertieren des SQL in heterogenen Umgebungen
• Erkennt SQL-Fehler
Replication Server - Komponenten Replikatort
• Verarbeitet SQL, das vom Replication Server
gesendet wurde
• Ein Replikatort kann auch als Primärort
definiert werden, wenn bi-direktionale
Replikation benötigt wird
Replication Server - Fragmentierungsmodelle
Verteilte Primärfragmente
DB1
DB2 DB3
Fragment 1- primär
Fragment 3- primär
Fragment 2- primär
Fragment 2- repliziert
Fragment 2- repliziert
Fragment 1- repliziertFragment 1- repliziert
Fragment 3- repliziert
Fragment 3- repliziert
create replication definition Rep_DB1with primary at DSDB1.DB1with all tables named ‘table’…...
Replication Server - Fragmentdefinition
create replication definition Rep_DB1with primary at DSDB1.DB1with all tables named ‘table’
(columnname…,)
primary key (id,...)searchable columns
(id,….)
create subscription Sub_DB2for Rep_DB2with replicate at DB1where id = ‘…’
create subscription Sub_DB3for Rep_DB3with replicate at DB1where id = ‘...’
Replication definition:
Subscription definition:
Replication Server - Fragmentierungsmodelle
Konsolidierende Replikation
Fragment 1- repliziert
Fragment 2- repliziert
Fragment 3- repliziert
Fragment 1 - primär
Fragment 2 - primär
Fragment 3 - primär
SQL RemoteHauptmerkmale
• Vollständige lokale Autonomie• Partitionierung durch:
• Column values
• Subqueries
• Where clauses
• Nachrichtenbasiert (keine session)• MAPI (Microsoft), VIM (Lotus), SMTP, FTP and File
SQL RemoteHauptmerkmale
• Hierarchisch
• Konsolidierende DB ist ASA oder ASE
• Remote DB sind ASA
• Homogen
• Viele Tausende Remote DB möglich
• Zentralisierte Administration
• Gestattet entfernte Administration einschließlich Schemaänderungen
• Für Endanwender völlig transparent
• Datensicherung mobiler Rechner
SQL Remote Komponenten
Message Agent
Remote Data Store
Remote DatabaseServer
Message System
Message Agent
Consolidated Data Store
Consolidated DatabaseServer
SQL Remote - Message Agent
NetworkNetworkLANLAN
MessageAgent
MessageAgent
Consolidated database
Remote databaseInbox Inbox
Log
Log
DB DB
SQL Remote - Message Agent
NetworkNetworkWANWAN
MessageAgent
MessageAgent
Consolidated database
Remote databaseInbox C Inbox R
LogLog
DBDB
SQL Remote Komponenten Konsolidierende DB
• Enthält eine Kopie aller Daten, die zu replizieren sind
• Realisiert Konflikterkennung und Auflösung
• Transaktionen werden im Transactions-Log aufgezeichnet
• Verwaltet zusätzliche Daten im Transaktions-Log über Transaktionen und Fragmente, die zu replizieren sind
SQL Remote Komponenten Message Agent
• Liest im Transactions-Log die Transaktionen, die repliziert werden sollen
• Bildet Nachrichten für jeden Ort, der Teilhaber der Transaktion ist
• Kooperiert mit dem Nachrichtensystem• Garantiert korrektes Versenden und
Verarbeiten der Transaktionen• Erkennt Konflikte
SQL Remote Komponenten Remote DB
• Enthält eine Teilmenge der Daten
• Transaktionen werden im Transactions-Log aufgezeichnet
• Verwaltet zusätzliche Daten im Transaktions-Log über Transaktionen und Fragmente, die zu replizieren sind
SQL Remote: Publisher und Subscriber
“Publication” definiert die zu replizierenden Daten
“Subscription” definiert das Replikationsziel
Bi-direktionale Replikation
Subscribe
Subscribe
Publish
Publish
SQL Remote - Fragmentdefinition
CREATE PUBLICATION publication-name(TABLE table-name [(column-name,…)]
[WHERE search-condition][SUBSCRIBE BY expression],…)
CREATE SUBSCRIPTIONTO publication-name [(subscription-value)]FOR subscriber-id
Publication definition:
Subscription definition:
MobiLink
ASA, ASE, Microsoft, Oracle, IBM
ASA, PalmOS, CE, Pagers, Phones
HTTP, TCPIP HotSync, WirelessSerial
MobiLinkHauptmerkmale
• Vollständige lokale Autonomie• Vollständige Kontrolle über Daten-
Partitionierung auf der konsolidierenden DB durch die Verwendung von Scripts• Scriptsprache der Konsolidierenden DB
• Keine Partitionierung in der remote DB
MobiLinkHauptmerkmale
• Hierarchische Topologie• Konsolidierende DB kann ODBC-DB sein
• Sybase, Microsoft, Oracle, IBM
• ASA und/oder UltraLite remote DB
• Optimiert für Tausende remote DB• Skalierbar durch konsolidierende DB
MobiLink Komponenten
TCP/IP
ODBC
MobiLink Client(ASA or UltraLite)
Consolidated Data Store
Consolidated Database Server
Remote Data Store
Remote Database Server (ASA or UltraLite)
MobiLinkServer
TCP/IP
MobiLink Synchronization Server
• Interface zwischen konsolidierender DB und remote server.
• Arbeitet mit ODBC-basierter KDB
• Verantwortlich für vollständige Sicherung des Synchronisationsprozesses
• Unterstützt mehrere Synchronisationsprozesse simultan
MobiLink Konsolidierende Synchronisations- Logik
• SQL statements werden in der konsolidierenden DB ausgeführt
• Geschrieben in der Sprache der KDB
• Steuert den Synchronisations-Server.
• Datenfluß in beiden Richtungen
• Behandelt Konflikte