85
Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden [email protected] Gliederung: Einführung Grundlagen und Verfahren Realisierte Technologien am Beispiel von Sybase

Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden [email protected] Gliederung: Einführung Grundlagen und Verfahren Realisierte

Embed Size (px)

Citation preview

Page 1: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Replikation in verteilten Datenbanken

Jürgen Bittner

SQL GmbH Dresden

[email protected]

Gliederung:

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

Page 2: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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)

Page 3: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Begriff Replikation

• (konsistentes) Verwalten von Kopien von Daten in verschiedenen Orten einer verteilten Datenbank

• und zum Steuern von Geschäftsprozessen

Page 4: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 5: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 6: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 7: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 8: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 9: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Central Datastore

Mobile Computing

EmbeddedComputing

Workgroup Computing

Unternehmens-Datenverarbeitung

Page 10: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Replikation in verteilten Datenbanken

Gliederung:

• Einführung

• Grundlagen und Verfahren

• Überblick zum Stand bei einigen DBMS

• Realisierte Technologien am Beispiel von Sybase

Page 11: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 12: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 13: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 14: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Probleme der verteilten Datenhaltung

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

Wahl der Technologie ist abhängig von:

Page 15: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 16: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Strenge oder schwache Konsistenz

Welche Version der Daten wird benutzt?

Waterloo

200 1000

Konto

Kto.-Nr. Stand

Paris

200 1000

Konto

Kto.-Nr. Stand

Page 17: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Lokale Autonomie

• Jeder Ort sollte unabhängig von den anderen

Orten operieren können.

• Daten

• Datenbank-Struktur

• Applikations-Software

• Zeit

Page 18: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 19: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 20: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

• 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

Page 21: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 22: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 23: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Hierarchisch Peer-to-peer

Remote database/

Consolidateddatabase

Remote database

Remote database

Consolidateddatabase

Remote database

Remote database

database database

database database

database

database

Topologie

Page 24: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 25: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 26: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 27: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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 ?

Page 28: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 29: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 30: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Verfahren der schwach konsistenten Replikation

Dump und Reload

Table Snapshot Replikation

Trigger- und regelbasierte Replikation

Transaktions-basierte Replikation

Timestamp-basierte Replikation

Page 31: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 32: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 33: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 34: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 35: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 36: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 37: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

NetworkNetworkLANLAN

MessageAgent

MessageAgent

Consolidated database

Remote database

Inbox

Inbox

Log

Log

DB

DB

Transaktions-basierte Replikation:Hierarchisch

MessageAgent

Remote databaseInbox

Log

DB

Page 38: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 39: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 40: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Transaktions-basierte Replikation Lokale Autonomie

• Hohe lokale Autonomie

• Datenbank benötigt nur Daten, die von der

Applikation benötigt werden.

Page 41: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 42: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Transaktions-basierte Replikation Transaktions-Steuerung

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

Page 43: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Transaktions-basierte Replikation Zugriffsmöglichkeiten

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

Page 44: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Transaktions-basierte Replikation Topologie

• Peer-to-peer und hierarchische Topologien können benutzt werden.

• Konfliktauflösung erfordert in der Regel ein hierarchisches Modell.

Page 45: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 46: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 47: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 48: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 49: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 50: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Timestampbasierte Replikation Lokale Autonomie

• Hohe lokale Autonomie

• Datenbank benötigt nur Daten, die von der

Applikation benötigt werden.

Page 51: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 52: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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.

Page 53: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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 ?

Page 54: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Timestampbasierte Replikation Weitere Aspekte

• Heterogene Umgebungen sind unterstützt.

• Jeder Ort kann unabhängig voneinander

synchronisieren, deshalb können viele Orte

unterstützt werden.

Page 55: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Replikation in verteilten Datenbanken

Gliederung:

• Einführung

• Grundlagen und Verfahren

• Überblick zum Stand bei einigen DBMS

• Realisierte Technologien am Beispiel von Sybase

Page 56: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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)

Page 57: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 58: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Replication Server

Replication Agent

Replication Agent

Replication Server

Replication Server

ReplikatortReplikatortReplikatortReplikatortPrimärortPrimärortPrimärortPrimärort

Page 59: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 60: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

Replication Server - Komponenten Replication Agent

• Liest das Transactions-Log des Primärortes

• Übergibt “committed transactions” in der Reihenfolge ihrer Verarbeitung an den Replication Server.

Page 61: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 62: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 63: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 64: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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’…...

Page 65: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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:

Page 66: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 67: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL Remote

ASE

MAPI VIM

FILE

FTP SMTP

ASA

ASA

MAPI VIM

FILE

FTP SMTP

ASA

OR

Page 68: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL RemoteHauptmerkmale

• Vollständige lokale Autonomie• Partitionierung durch:

• Column values

• Subqueries

• Where clauses

• Nachrichtenbasiert (keine session)• MAPI (Microsoft), VIM (Lotus), SMTP, FTP and File

Page 69: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 70: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL Remote Komponenten

Message Agent

Remote Data Store

Remote DatabaseServer

Message System

Message Agent

Consolidated Data Store

Consolidated DatabaseServer

Page 71: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL Remote - Message Agent

NetworkNetworkLANLAN

MessageAgent

MessageAgent

Consolidated database

Remote databaseInbox Inbox

Log

Log

DB DB

Page 72: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL Remote - Message Agent

NetworkNetworkWANWAN

MessageAgent

MessageAgent

Consolidated database

Remote databaseInbox C Inbox R

LogLog

DBDB

Page 73: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 74: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 75: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 76: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

SQL Remote: Publisher und Subscriber

“Publication” definiert die zu replizierenden Daten

“Subscription” definiert das Replikationsziel

Bi-direktionale Replikation

Subscribe

Subscribe

Publish

Publish

Page 77: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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:

Page 78: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

MobiLink

ASA, ASE, Microsoft, Oracle, IBM

ASA, PalmOS, CE, Pagers, Phones

HTTP, TCPIP HotSync, WirelessSerial

Page 79: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 80: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

MobiLinkHauptmerkmale

• Session basiert

• Bi-direktional

• Mittlere bis hohe Latenz

Page 81: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 82: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 83: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 84: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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

Page 85: Replikation in verteilten Datenbanken Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de Gliederung: Einführung Grundlagen und Verfahren Realisierte

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