Replikation in verteilten Datenbanken

1
Replikation in verteilten Datenbanken

• Gliederung
• Einführung
• Grundlagen und Verfahren
• Realisierte Technologien am Beispiel von Sybase

• Jürgen Bittner
• SQL GmbH Dresden
• juergen.bittner_at_sql-gmbh.de

2
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)

3
Begriff Replikation

• (konsistentes) Verwalten von Kopien von Daten in
  verschiedenen Orten einer verteilten Datenbank
• und zum Steuern von Geschäftsprozessen

4
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

5
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

6
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

7
Real-Time Decision Support
Primary OLTP Datenbank
OLTP Applikationen
Decision Support Applikationen
Replicate Decision Support Datenbank

• Fortlaufende Weitergabe von Änderungen erzeugt
  eine Echtzeit-Kopie
• Beseitigt unvorhersehbare Einbrüche bei der OLTP
  Performance aufgrund langlaufender Abfragen

8
Unternehmensweite Konsolidierung
NY
Replicate Site
Primary Sites
NY
Netzwerk
Corporate
London
London
Tokyo
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

9
Unternehmens-Datenverarbeitung
10
Replikation in verteilten Datenbanken

• Gliederung
• Einführung
• Grundlagen und Verfahren
• Überblick zum Stand bei einigen DBMS
• Realisierte Technologien am Beispiel von Sybase

11
Verfahren zur Replikation
Strenge Konsistenz erfordert Synchrone Replikation
Schwache Konsistenz ermöglicht Asynchrone Replikat
ion
Konsistenz- anforderung
Verteilte Transaktionen mit 2-PC
Dump, Reload
Table Snapshot
Trigger- und Regel- basierte Replikation
Transaktions- basierte Replikation
Timestamp- basierte Replikation
Verfahren
Performance, Verfügbarkeit
Geringe Aktualität lokale Autonomie
Konsistente Transaktionen lokale Autonomie
Administrativer und Performance Overhead lokale Au
tonomie
Eigentümer prinzip oderhierarchischeTopologie ?
Script-Entwicklung
Probleme,Besonder-heiten
12
Grundlegende Entscheidungskriterien

• Bei der Entscheidung über eine Replikationstechnol
  ogie ist zu betrachten
• Geschäftsanforderungen für die verteilte
  Datenbank
• Technologische Bedingungen und Grenzen der
  Anwendungsumgebung
• Verfügbare Resourcen für Entwicklung und
  Administration

13
Was ist ein Verteiltes System?

• C.J. Dates Arbeitsdefinition
• A distributed database system consists of a
  collection of sites, connected together via some
  sort of network, in which
• Each site is a database system in its own right
• Sites have agreed to work together (if
  necessary), so that a user at any site can access
  data anywhere in the network exactly as if the
  data were all stored at the users own site.

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

15
Probleme der verteilten Datenhaltung
Wahl der Technologie ist abhängig von

• Konsistenz
• Lokale Autonomie
• Datenpartitionierung (-fragmentierung)
• Transaktionssteuerung
• Zugriffsmöglichkeiten (connection)
• Topologie

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

17
Strenge oder schwache Konsistenz

• Welche Version der Daten wird benutzt?

Waterloo
Paris
18
Lokale Autonomie

• Jeder Ort sollte unabhängig von den anderen Orten
  operieren können.
• Daten
• Datenbank-Struktur
• Applikations-Software
• Zeit

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

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

21
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

22
Daten-PartitionierungGrundbegriffe
Forderung Fragmentierungstransparenz und
Replikationstransparenz immer
?
23
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.

24
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

25
Hierarchisch Peer-to-peer
Topologie
database
database
database
Consolidateddatabase
Remote database/ Consolidateddatabase
Remote database
Remote database
database
database
database
Remote database
Remote database
26
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.

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

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

29
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 ?

30
Verfahren zur Replikation
Strenge Konsistenz erfordert Synchrone Replikation
Schwache Konsistenz ermöglicht Asynchrone Replikat
ion
Konsistenz- anforderung
Verteilte Transaktionen mit 2-PC
Dump, Reload
Table Snapshot
Trigger- und Regel- basierte Replikation
Transaktions- basierte Replikation
Timestamp- basierte Replikation
Verfahren
Performance, Verfügbarkeit
Geringe Aktualität lokale Autonomie
Konsistente Transaktionen lokale Autonomie
Administrativer und Performance Overhead lokale Au
tonomie
Eigentümer prinzip oderhierarchischeTopologie ?
Script-Entwicklung
Probleme,Besonder-heiten
31
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

32
Streng konsistente Replikation

• Änderungen werden simultan in allen
  Datenbanken ausgeführt.

Bitte Warten, das Konto wird gerade geändert
Withdraw 100
Waterloo
Paris
33
Streng konsistente Replikation Konsistenz

• Wenn absolute Konsistenz gefordert ist.
• Die Transaktion wird in allen oder keiner der
  beteiligten Datenbanken realisiert.

34
Streng konsistente Replikation Lokale Autonomie

• Sehr niedriges Niveau der lokalen Autonomie.
• Falls ein Ort ausfällt, ist das gesamte System
  nicht mehr verfügbar.

X
Leider ist das System nicht verfügbar
Abhebung 100
Waterloo
Paris
35
Streng konsistente Replikation Daten-Partitionie
rung

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

36
Streng konsistente Replikation Transaktions-Steu
erung

• Ein Distributed Transaction Server (DTS) ist
  erforderlich.
• Datenbank-Server mit DTS-Funktionalität
• Spezieller DTS
• Application Server mit DTS-Funktionalität

37
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

38
Streng konsistente Replikation
Zugriffsmöglichkeiten

• Zuverlässiges Netzwerk ist erforderlich.
• Geschwindigkeit der Applikation ist stark
  abhängig von der Geschwindigkeit des Netzwerks.

39
Streng konsistente Replikation Topologie

• Typisch für eine peer-to-peer Topologie.
• Da alle Datenbanken simultan geändert werden,
  ist keine Masterkopie erforderlich.

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

41
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

42
Verfahren der schwach konsistenten Replikation

• Dump und Reload
• Table Snapshot Replikation
• Trigger- und regelbasierte Replikation
• Transaktions-basierte Replikation
• Timestamp-basierte Replikation

43
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

44
Dump und ReloadTopologie
database
database
database
database
database
database
45
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

46
Trigger-basierte Replikation
Primärort
Replikatort 1
Replikatort 2
begin
Propagation queue
update T1
Call uppdate T1(...)
Trigger
delete T1
Call delete T1(...)
Trigger
insert T2
Call insert T2(...)
Trigger
update T3
Call update T3(...)
Store and forward 2-PC
Trigger
Transaktion
. . .
commit
Transaktion
47
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

48
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

49
Transaktions-basierte Replikation
Primärort
Replikatort 1
Replikatort 2
Begin Update T1 delete T1 insert T2 update
T3 Commit
Replication Server
DB- Server
Transaktion
DB- Server
Replication Server
Log Transfer Manager
Replication Server
Transaktion
Log
Stable queue
50
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

51
Peer-to-peer/Eigentümerprinzip Modulare
Architektur mit Support für Heterogenität
Transaktions-basierte Replikation
Andere Daten Quellen
ReplicationAgent
Network
Replication Server
Andere Daten Ziele
DB- Server
ReplicationAgent
Replication Driver for ODBC

• 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

52
Transaktions-basierte ReplikationHierarchisch
MessageAgent
MessageAgent
Remote database
DB
Inbox
Network LAN
Log
MessageAgent
Consolidated database
DB
Inbox
Log
Remote database
DB
Inbox
Log
53
Transaktions-basierte Replikation
1234
10
UPDATE Product SET qty_oh 9WHERE sku_key 1234
UPDATE Product SET qty_oh 8WHERE sku_key 1234
1234
10
54
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.

55
Transaktions-basierte Replikation Lokale
Autonomie

• Hohe lokale Autonomie
• Datenbank benötigt nur Daten, die von der
  Applikation benötigt werden.

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

57
Transaktions-basierte Replikation
Transaktions-Steuerung

• Transaktions-Steuerung muss garantieren
• Senden und Verarbeiten in korrekter Reihenfolge.
• Keine Transaktion darf verlorengehen.

58
Transaktions-basierte Replikation
Zugriffsmöglichkeiten

• Ob eine direkte Verbindung erforderlich ist oder
  nicht ist abhängig von den Latenzanforderungen.

59
Transaktions-basierte Replikation Topologie

• Peer-to-peer und hierarchische Topologien können
  benutzt werden.
• Konfliktauflösung erfordert in der Regel ein
  hierarchisches Modell.

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

61
Timestampbasierte Replikationmit
Synchronisations-Server
Consolidated Database Server
Consolidated DB
MobiLink Client(ASA or UltraLite)
Remote Database Server (ASA or UltraLite)
MobiLinkServer
Remote DB
62
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.

63
Timestampbasierte Replikation
1234
10
UPDATE Product SET qty_oh 8WHERE sku_key 1234
1234
10
64
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.

65
Timestampbasierte Replikation Lokale Autonomie

• Hohe lokale Autonomie
• Datenbank benötigt nur Daten, die von der
  Applikation benötigt werden.

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

67
Timestampbasierte Replikation Transaktions-Steueru
ng

• 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

68
Timestampbasierte Replikation Zugriffsmöglichkeit
en

• Erfordert eine stabile Netzwerk-Verbindung
  während des Synchronisation-Prozesses.
• Geschwindigkeit der Verbindung beeinflusst den
  Umfang der Daten der synchronisiert werden kann.

69
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 ?

70
Timestampbasierte Replikation Weitere Aspekte

• Heterogene Umgebungen sind unterstützt.
• Jeder Ort kann unabhängig voneinander
  synchronisieren, deshalb können viele Orte
  unterstützt werden.

71
Replikation in verteilten Datenbanken

• Gliederung
• Einführung
• Grundlagen und Verfahren
• Überblick zum Stand bei einigen DBMS
• Realisierte Technologien am Beispiel von Sybase

72
Replication Server
Replicate Sites
Primary Sites

• Adaptive Server

Replication Agent
Replication Server

• DirectCONNECT
• (Native drivers)

• Adaptive Server/Enterprise
• Adaptive Server/Anywhere
• Oracle
• Informix
• OS/390 DB2
• Replication Toolkit for MVS

• DirectCONNECT/
• Anywhere (ODBC)

73
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

74
Replication Server
Replikatort
Primärort
Replication Agent
Replication Server
75
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

76
Replication Server - Komponenten Replication
Agent

• Liest das Transactions-Log des Primärortes
• Übergibt committed transactions in der
  Reihenfolge ihrer Verarbeitung an den
  Replication Server.

77
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

78
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

79
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

80
Replication Server - Fragmentierungsmodelle
Verteilte Primärfragmente
create replication definition Rep_DB1with
primary at DSDB1.DB1 with all tables named
table...
DB1
Fragment 1- primär
Fragment 2- repliziert
Fragment 3- repliziert
DB2
DB3
Fragment 1- repliziert
Fragment 1- repliziert
Fragment 2- primär
Fragment 2- repliziert
Fragment 3- primär
Fragment 3- repliziert
81
Replication Server - Fragmentdefinition
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 definition
Subscription definition
82
Replication Server - Fragmentierungsmodelle
Konsolidierende Replikation
Fragment 1 - primär
Fragment 2 - primär
Fragment 3 - primär
83
SQL Remote
ASE
ASA
OR
ASA
ASA
84
SQL RemoteHauptmerkmale

• Vollständige lokale Autonomie
• Partitionierung durch
• Column values
• Subqueries
• Where clauses
• Nachrichtenbasiert (keine session)
• MAPI (Microsoft), VIM (Lotus), SMTP, FTP and File

85
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

86
SQL Remote Komponenten
Consolidated DatabaseServer
Message Agent
Consolidated Data Store
Message System
Remote DatabaseServer
Message Agent
Remote Data Store
87
SQL Remote - Message Agent
MessageAgent
MessageAgent
Network LAN
Consolidated database
Remote database
DB
DB
Inbox
Inbox
Log
Log
88
SQL Remote - Message Agent
MessageAgent
MessageAgent
Network WAN
Consolidated database
Remote database
DB
Inbox R
Inbox C
DB
Log
Log
89
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

90
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

91
SQL Remote Komponenten Message System

• Sichert die store and forward-Technologie
• Benutzt
• MAPI
• SMTP
• VIM
• File
• FTP

92
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

93
SQL Remote Publisher und Subscriber

• Publication definiert die zu replizierenden
  Daten
• Subscription definiert das Replikationsziel
• Bi-direktionale Replikation

Subscribe
Publish
Subscribe
Publish
94
SQL Remote - Fragmentdefinition
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
Publication definition
Subscription definition
95
MobiLink
ASA, ASE, Microsoft, Oracle, IBM
Serial
HTTP, TCPIP
HotSync, Wireless
ASA, PalmOS, CE, Pagers, Phones
96
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

97
MobiLinkHauptmerkmale

• Session basiert
• Bi-direktional
• Mittlere bis hohe Latenz

98
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

99
MobiLink Komponenten
Consolidated Database Server
Consolidated Data Store
MobiLink Client(ASA or UltraLite)
Remote Database Server (ASA or UltraLite)
MobiLinkServer
Remote Data Store
100
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

101
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

102
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