1 / 99

Replikation in verteilten Datenbanken

Replikation in verteilten Datenbanken. Gliederung: Einführung Grundlagen und Verfahren Realisierte Technologien am Beispiel von Sybase. Jürgen Bittner SQL GmbH Dresden juergen.bittner@sql-gmbh.de. Begriff Replikation. ist eine Funktionalität in

peregrine-palacios
Download Presentation

Replikation in verteilten Datenbanken

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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@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 • Fortlaufende Weitergabe von Änderungen erzeugt eine ‘Echtzeit-Kopie‘ • Beseitigt unvorhersehbare Einbrüche bei der OLTP Performance aufgrund langlaufender Abfragen OLTP Applikationen Decision Support Applikationen Replicate Decision Support Datenbank

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

  9. Central Datastore Workgroup Computing Mobile Computing EmbeddedComputing Unternehmens-Datenverarbeitung

  10. Replikation in verteilten Datenbanken • Gliederung: • Einführung • Grundlagen und Verfahren • Realisierte Technologien am Beispiel von Sybase

  11. Verfahren zur Replikation Strenge Konsistenz erfordert Synchrone Replikation Schwache Konsistenz ermöglicht Asynchrone Replikation 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 Autonomie Eigentümer prinzip oderhierarchischeTopologie ? Script-Entwicklung Probleme,Besonder-heiten

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

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

  14. Probleme der verteilten Datenhaltung Wahl der Technologie ist abhängig von: • Konsistenz • Lokale Autonomie • Datenpartitionierung (-fragmentierung) • Transaktionssteuerung • Zugriffsmöglichkeiten (connection) • Topologie

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

  16. Konto Konto Kto.-Nr. Kto.-Nr. Stand Stand 200 200 1000 1000 Strenge oder schwache Konsistenz • Welche Version der Daten wird benutzt? Waterloo Paris

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

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

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

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

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

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

  23. Topologie Hierarchisch Peer-to-peer database database database Consolidateddatabase Remote database/ Consolidateddatabase Remote database Remote database database database database Remote database Remote database

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

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

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

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

  28. Verfahren zur Replikation Strenge Konsistenz erfordert Synchrone Replikation Schwache Konsistenz ermöglicht Asynchrone Replikation 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 Autonomie Eigentümer prinzip oderhierarchischeTopologie ? Script-Entwicklung Probleme,Besonder-heiten

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

  30. Konto Konto Kto.-Nr. Kto.-Nr. Stand Stand 200 200 1000 1000 Streng konsistente Replikation • Änderungen werden “simultan” in allen Datenbanken ausgeführt. Bitte Warten, das Konto wird gerade geändert Abhebung $100 Waterloo Paris

  31. Streng konsistente Replikation :Konsistenz • Wenn absolute Konsistenz gefordert ist. • Die Transaktion wird in allen oder keiner der beteiligten Datenbanken realisiert.

  32. Konto Konto Kto.-Nr. Kto.-Nr. Stand Stand 200 200 1000 1000 Streng konsistente ReplikationLokale 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

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

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

  35. Verteiles 2-Phasen-Commit R1 R2 (Koordinator) R3 Teil-TA-Ausführung PREPARE PREPARE Logging READY (FAILED) Logging COMMIT COMMIT (ABORT) • 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 Logging, Sperrfreigabe ACK Logging

  36. Streng konsistente Replikation : Zugriffsmöglichkeiten • Zuverlässiges Netzwerk ist erforderlich. • Geschwindigkeit der Applikation ist stark abhängig von der Geschwindigkeit des Netzwerks.

  37. Streng konsistente Replikation :Topologie • Typisch für eine peer-to-peer Topologie. • Da alle Datenbanken “simultan” geändert werden, ist keine Masterkopie erforderlich.

  38. Streng konsistente ReplikationWeitere 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.

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

  40. Verfahren der schwach konsistenten Replikation • Dump und Reload • Table Snapshot Replikation • Trigger- und regelbasierte Replikation • Transaktions-basierte Replikation • Timestamp-basierte Replikation

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

  42. Dump und ReloadTopologie database database database database database database

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

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

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

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

  47. Transaktions-basierte Replikation Primärort Replikatort 1 Replikatort 2 Begin Update T1 delete T1 insert T2 update T3 Commit Replication Server DB- Server Transaktion Log Transfer Manager Replication Server Replication Server DB- Server Transaktion Log Stable queue

  48. 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 einerZeile Objekt der Prozedurreplikation ist “beliebige“ Prozedur Symmetrische Replikation versus Eigentümerprinzip

  49. Transaktions-basierte Replikation: Peer-to-peer/Eigentümerprinzip Modulare Architektur mit Support für Heterogenität Andere Daten Quellen • 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 ReplicationAgent Network Replication Server Andere Daten Ziele ReplicationAgent DB- Server Replication Driver for ODBC

  50. Transaktions-basierte Replikation:Hierarchisch MessageAgent MessageAgent Remote database DB Inbox Network LAN Log MessageAgent Consolidated database DB Inbox Log Remote database DB Inbox Log

More Related