Vortrag vom 19.01.2006

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
• Integrierten Shared-Nothing-MehrrechnerDatenbanksystemen,
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
OLTP
Applikationen
Decision
Support
Applikationen
Primary
OLTP
Datenbank
Replicate
Decision Support
Datenbank
Fortlaufende Weitergabe von Änderungen erzeugt eine ‘Echtzeit-Kopie‘
Beseitigt unvorhersehbare Einbrüche bei der OLTP Performance aufgrund
langlaufender Abfragen
Unternehmensweite Konsolidierung
Replicate
Site
NY
Primary
Sites
London
Netzwerk
Corporate
Tokyo
•
•
•
•
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
NY
London
Tokyo
Unternehmens-Datenverarbeitung
Central Datastore
Workgroup
Computing
Mobile
Computing
Embedded
Computing
Replikation in verteilten Datenbanken
Gliederung:
• Einführung
• Grundlagen und Verfahren
• Realisierte Technologien am Beispiel von Sybase
Verfahren zur Replikation
Konsistenzanforderung
Verfahren
Probleme,
Besonderheiten
Strenge
Konsistenz
erfordert
Synchrone
Replikation
Schwache
Konsistenz
ermöglicht
Asynchrone
Replikation
Verteilte
Transaktionen
mit 2-PC
Dump,
Reload
Table
Snapshot
Trigger- und
Regelbasierte
Replikation
Transaktionsbasierte
Replikation
Timestampbasierte
Replikation
Performance,
Verfügbarkeit
Geringe
Aktualität,
lokale
Autonomie
Konsistente
Transaktionen,
lokale
Autonomie
Administrativer
und
Performance
Overhead,
lokale
Autonomie
Eigentümer
prinzip oder
hierarchische
Topologie ?
ScriptEntwicklung
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 Datenbanken
Praktische 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
Wahl der Technologie ist abhängig von:
•
•
•
•
•
•
Konsistenz
Lokale Autonomie
Datenpartitionierung (-fragmentierung)
Transaktionssteuerung
Zugriffsmöglichkeiten (connection)
Topologie
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?
Konto
Konto
Kto.-Nr. Stand
Kto.-Nr. Stand
200
1000
Waterloo
200
1000
Paris
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.
Daten-Partitionierung
• 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
Transaktions-Steuerung
• Die gewählte Technologie sollte die ACIDBedingung 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
Topologie
Hierarchisch
Peer-to-peer
Consolidated
database
Remote
database/
Consolidated
database
Remote
database
database
Remote
database
database
database
database
database
Remote
database
Remote
database
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
Konsistenzanforderung
Verfahren
Probleme,
Besonderheiten
Strenge
Konsistenz
erfordert
Synchrone
Replikation
Schwache
Konsistenz
ermöglicht
Asynchrone
Replikation
Verteilte
Transaktionen
mit 2-PC
Dump,
Reload
Table
Snapshot
Trigger- und
Regelbasierte
Replikation
Transaktionsbasierte
Replikation
Timestampbasierte
Replikation
Performance,
Verfügbarkeit
Geringe
Aktualität,
lokale
Autonomie
Konsistente
Transaktionen,
lokale
Autonomie
Administrativer
und
Performance
Overhead,
lokale
Autonomie
Eigentümer
prinzip oder
hierarchische
Topologie ?
ScriptEntwicklung
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.
Konto
Konto
Kto.-Nr. Stand
Kto.-Nr. Stand
200
1000
200
1000
Bitte Warten, das
Konto wird
gerade geändert
Abhebung
$100
Waterloo
Paris
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.
Konto
Konto
Kto.-Nr. Stand
Kto.-Nr. Stand
200
1000
Leider ist das System nicht verfügbar
Abhebung
$100
Waterloo
X
200
1000
Paris
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
R1
R2
(Koordinator)
R3
Teil-TA-Ausführung
PREPARE
PREPARE
Logging
READY (FAILED)
Logging
COMMIT
COMMIT (ABORT)
Logging, Sperrfreigabe
ACK
Logging
Basisverfahren:
• 4 N Nachrichten (N = Anzahl der Teil-TA)
• 2 (N + 1) Log-Writes
ABORT-Nachrichten gehen nur an Teil-TA, die nicht mit FAILED gestimmt haben
Problem bei 2PC:
bei Koordinatorausfall lange Blockierung möglich
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
Dump und Reload
Topologie
database
database
database
database
database
database
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
Primärort
Replikatort 1
Replikatort 2
begin
Propagation queue
update T1
Trigger
Call uppdate T1(...)
delete T1
Trigger
Call delete T1(...)
insert T2
Trigger
Call insert T2(...)
update T3
Store and forward 2-PC
Trigger
Call update T3(...)
Transaktion
commit
.
.
.
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
Primärort
Replikatort 1
Replikatort 2
Begin
Replication
Server
Update T1
DBServer
delete T1
insert T2
Log Transfer
Manager
update T3
Replication
Server
Replication
Server
DBServer
Commit
Log
Stable
queue
Transaktion
Transaktion
Symmetrische Replikation versus Eigentümerprinzip
Symmetrische Replikation
Eigentümerprinzip
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
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
Transaktions-basierte Replikation:
Peer-to-peer/Eigentümerprinzip
Modulare Architektur mit Support für Heterogenität
Andere
Daten
Quellen
Replication
Agent
Network
Replication
Server
Andere
Daten
Ziele
DB- Replication
Agent
Server
Replication Driver for ODBC
• Replication Server verwaltet die Konfiguration und Verteilung von
Transaktionen
• Replication Agents protokollieren Update Transactions an den QuellDatenbanken
• Gateways und Replication Driver für ODBC liefern Änderungen für
DBMS verschiedener Hersteller
Transaktions-basierte Replikation:
Hierarchisch
Message
Agent
Message
Agent
DB
Network
LAN
Inbox
Remote
database
Log
Message
Agent
Consolidated
database
DB
Inbox
Log
DB
Inbox
Log
Remote
database
Transaktions-basierte Replikation
Product
sku_key qty_oh
1234
1X0
10
9
X
8
UPDATE Product SET qty_oh = 9
WHERE sku_key = 1234
UPDATE Product SET qty_oh = 8
WHERE sku_key = 1234
Product
sku_key qty_oh
1234
1X0
10
9
X
8
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 DBGrösse.
Timestampbasierte Replikation:
mit Synchronisations-Server
Consolidated Database Server
Consolidated
DB
ODBC
Remote Database Server
(ASA or UltraLite)
MobiLink Client
(ASA or UltraLite)
Remote DB
MobiLink
Server
TCP/IP
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
Product
sku_key qty_oh
1234
10
X
8
UPDATE Product SET qty_oh = 8
WHERE sku_key = 1234
Product
sku_key qty_oh
1234
1X0
10
9
X
8
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
Replicate Sites
Primary Sites
 Adaptive Server
Replication Replication
Agent
Server
 DirectCONNECT
(Native drivers)






Adaptive Server/Enterprise
Adaptive Server/Anywhere
Oracle
Informix
OS/390 DB2
Replication Toolkit for MVS
 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
Primärort
Replication
Agent
Replikatort
Replication
Server
Replication Server - Komponenten
Primä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
create replication definition Rep_DB1
with primary at DSDB1.DB1
with all tables named ‘table’…...
Fragment 1- primär
Fragment 2- repliziert
Fragment 3- repliziert
DB2
DB3
Fragment 1- repliziert
Fragment 1- repliziert
Fragment 2- repliziert
Fragment 2- primär
Fragment 3- primär
Fragment 3- repliziert
Replication Server - Fragmentdefinition
Replication definition:
Subscription definition:
create replication definition Rep_DB1
with primary at DSDB1.DB1
with all tables named ‘table’
(columnname…,
)
primary key (id,...)
searchable columns
(id,….)
create subscription Sub_DB2
for Rep_DB2
with replicate at DB1
where id = ‘…’
create subscription Sub_DB3
for Rep_DB3
with replicate at DB1
where id = ‘...’
Replication Server - Fragmentierungsmodelle
Konsolidierende Replikation
Fragment 1 - primär
Fragment 1- repliziert
Fragment 2 - primär
Fragment 2- repliziert
Fragment 3- repliziert
Fragment 3 - primär
SQL Remote
ASE
ASA
OR
MAPI
FTP
SMTP
FILE
ASA
VIM
MAPI
FTP
SMTP
FILE
ASA
VIM
SQL Remote
Hauptmerkmale
• Vollständige lokale Autonomie
• Partitionierung durch:
• Column values
• Subqueries
• Where clauses
• Nachrichtenbasiert (keine session)
• MAPI (Microsoft), VIM (Lotus), SMTP, FTP and File
SQL Remote
Hauptmerkmale
• 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
Consolidated Database
Server
Message Agent
Consolidated
Data Store
Message System
Remote Database
Server
Remote Data
Store
Message Agent
SQL Remote - Message Agent
Message
Agent
Message
Agent
Network
LAN
Consolidated
database
DB
Log
DB
Inbox
Inbox
Log
Remote
database
SQL Remote - Message Agent
Message
Agent
Message
Agent
Network
WAN
Consolidated
database
DB
Log
Inbox C
Inbox R
DB
Log
Remote
database
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 TransaktionsLog ü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 TransaktionsLog ü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
Publish
Subscribe
Subscribe
Publish
SQL Remote - Fragmentdefinition
Publication definition:
Subscription definition:
CREATE PUBLICATION publication-name
(TABLE table-name [(column-name,…)]
[WHERE search-condition]
[SUBSCRIBE BY expression],
…)
CREATE SUBSCRIPTION
TO publication-name [(subscription-value)]
FOR subscriber-id
MobiLink
ASA, ASE, Microsoft, Oracle, IBM
HTTP, TCPIP
Serial
HotSync, Wireless
ASA, PalmOS, CE, Pagers, Phones
MobiLink
Hauptmerkmale
• Vollständige lokale Autonomie
• Vollständige Kontrolle über DatenPartitionierung auf der konsolidierenden DB
durch die Verwendung von Scripts
• Scriptsprache der Konsolidierenden DB
• Keine Partitionierung in der remote DB
MobiLink
Hauptmerkmale
• Session basiert
• Bi-direktional
• Mittlere bis hohe Latenz
MobiLink
Hauptmerkmale
• 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
Consolidated Database Server
Consolidated
Data Store
ODBC
Remote Database Server
(ASA or UltraLite)
MobiLink Client
(ASA or UltraLite)
Remote Data
Store
MobiLink
Server
TCP/IP
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
MobiLink
Remote Synchronisations- Logik
• ASA und UltraLite verfolgen alle
Datenänderungen
• Eine Synchronisations-Komponente realisiert:
• Lesen aller Änderungen zum Aufbau eines
“upload stream”
• Empfangen des “download stream” und
verarbeiten der Änderungen in der remote DB