Datenbank Replikation

Eine Technik mit sehr vielen Möglichkeiten

Konsistenter Datenbestand
Immer mehr Unternehmen benötigen eine Datenhaltung, die es erlaubt, dieselben Daten gleichzeitig an verschiedenen Orten zur Verfügung zu stellen; und dennoch soll die Konsistenz eines einheitlichen Datenbestandes gewährleistet bleiben.
Für umfangreiche Daten- und Informationsbestände ist die Speicherung und Bereitstellung von Unternehmensinformationen in Datenbanksysteme meist unumgänglich. Datenbanken ermöglichen verschiedene Architekturen um einen einheitlichen Datenbestand zur Verfügung zu stellen: zentrale Datenbanken, verteilte Datenhaltung und Datenbankreplikation.

Inhalt
Konsistenter Datenbestand
zentrale Datenbanken
verteilte Datenhaltung
Datenreplikation

Auswirkungen auf die Unternehmensorganisation
Einsatzgebiete
Kennzeichend der Datenbankreplikation
Arten von Replikationen symetrische / asymetrische Konfiguration
synchrone / asychnchrone Konfiguration
Replikationskonflikt
Datenbank-Replikation mit dem Microsoft SQL-Server Verleger - Abonnent
Filtern von Daten
Snapshot-Replikation
Transaktionale Replikaton
Merge Replikation

Fallbeispiel für Merge-Replikation

Zentraler Datenbestand
Merkmal der zentralisierten Datenhaltung ist die Konzentration einer Datenbank an einem einzigen geografischen Standort. Der Vorteil dieses Konzeptes liegt in der relativ leicht zu gewährleisteten Konsistenzsicherheit. Nachteil ist die Abhängigkeit von einer WAN-Verbindung bei Zugriff von entfernten Standorten.

Verteilte Datenhaltung
Die verteilte Datenhaltung ist vereinfachend charakterisiert, durch die Speicherung unterschiedlicher Daten an unterschiedlichen Standorten. Beispielsweise könnten zwei Vertriebsniederlassungen Nord und Süd über eigene Datenbestände mit Kundenadressen verfügen. Dieses Konzept wird problematisch, wenn jede Niederlassung häufig auf die Daten der anderen zugreifen muss.

Datenreplikation
Bei der Replikation werden Kopien derselben Daten auf unterschiedliche Standorte abgelegt, wobei diese Datenbankkopien «voneinander Wissen». Diese Datenbestände werden dann in bestimmten Zeitabständen repliziert, d.h. ein Abgleich der Kopien miteinander vorgenommen. Die zugrunde liegende Idee ist, dass die Informationen, für die bei verteilter Datenhaltung bereichsübergreifende Zugriffe notwendig sind, für jeden Standort lokals vorgehalten werden. In der Replikationsarchitektur wird also bewusst und plannmässig mit Datenredudanzen umgegangen. Inkonsistenzen zwischen verschiedenen Repliken werden solange zugelassen, wie es aus betriegsorganisatoraischen Gründen vernünftig und akzeptabel ist.

Einsatzgebiete der Replikation
Die Replikationstechnik hat bedeutende Auswirkungen auf die Unternehmensorganisation genommen, wie folgende Beispiele zeigen:
So ist es möglich, dass z.B. jede Filiale einer Supermarktkette mit ihren eigenen lokalen Datenbestand. Die aktuellen Sonderangebotspreise werden aber von der Unternehmenszentrale an alle Filialen in der Nacht zuvor übermittelt. Zudem werden nach Geschäftsschluß die Verkaufszahlen zentral gesammelt, um sie für das Controlling und für die Unternehmensführung bereit zu stellen.
Oder es soll jeder Vertriebsmitarbeiter auf seinem Notebook den Datenbestand mit den aktuellen Vertragsarten und -konditionen vorfinden. Gleichzeitig sind die Daten seiner Vertragsabschlüsse oder -änderungen regelmäßig elektronisch an die Zentrale zu übermitteln.

Kennzeichen der Datenbankreplikation
Datenbankreplikation ist eine Technik, die es ermöglicht, mehrfache Kopien (Replikate) von einzelnen Datenbestände oder kompletter Teildatenbanken zu erzeugen. Der Einsatz dieser Technik erfolgt meist wegen Performanceproblemen aufgrund häufiger Zugriffe über langsame Verbindungen auf größere Datenbestände oder der Lastverteilung bei hoher Transaktionslast. Ein weiteres Einsatzgebiet sind so genannte autonome Datenbanken, deren Daten in unregelmäßigen Abständen abgeglichen werden. Hierbei steht die Unabhängigkeit von einem zentralen Datenbanksystem im Vordergrund.

Arten von Replikationen
symetrische / asymetrische Konfiguration
In Replikationsszenarien wird zwischen symmetrischen und asymmetrischen Konfigurationen unterschieden. Bei einer symetrische Konfiguration erfolgen Datenänderungen in allen Replikaten (Update Everywhere). Bei symetrische Konfiguration (oder auch Master / Slave bzw. Verleger / Abonnent genannt) erfolgen Änderungsoperationen an einem Knoten während an den anderen nur gelesen wir.

synchrone / asynchrone Konfiguration
Ein weiteres Unterscheidungsmerkmal ist der Zeitpunkt der Replikation. Hier spricht man von synchronen oder asynchronen Konstellationen. In einer synchronen Konfiguration werden alle Replikate gleichzeitig durch eine Änderungstransaktion aktualisiert. In der Praxis wird dies über ein Zweiphasen Synchronisationsprotokoll (2PC) realisiert. Bei einer asynchronen Aktualisierung werden die Änderungen verzögert aktualisiert. In einem solchen Szenario kommt es zeitweise zu Inkonsistenzen.
Beide Replikationsstrategien lassen sich zu folgenden Replikationsszenarien zusammenfassen:

Replikationskonflikt
Bei der symmetrischen, asynchronen Replikation kann es zwischen zwei Abgleiche (Synchronisationen) zu parallelen Änderungen am gleichen Datensatz in zwei oder mehreren Replikaten kommen. Dieser Fall wird Replikationskonflikt genannt, der durch eine festzulegende Logik (Resolver) aufgelöst werden muss.

Datenbankreplikation mit dem Microsoft SQL-Server
Der Microsoft SQL Server stellt Replikationsmechanismen bereit, die eine Abbildung der obigen Konfigurationen erlauben. Die Grundlegenden Techniken werden Snapshot-Replikation, Transaktionale-Replikation und Merge-Replikation genannt. Bezogen auf den SQL Server lässt sich obiges Diagramm wie folgt darstellen:

Verleger - Abonnent
Ein Verleger ist ein Server, der Datenbanken zur Replikation veröffentlicht. Jede einzelne Veröffentlichung wir Publikation genannt, die wiederum aus einzelnen Artikeln (Tabellen) bestehen kann. Grundsätzlich können Datenbanken und Tabellen mehrfach publiziert werden.
Ein Server, der eigene Datenbanken mit einer Publikation verbindet, wird Abonnent genannt.
Unabhängig von der Replikationsart kann die Synchronisation sowohl zentral den Replikaten aufgezwungen als auch dezentral angefordert werden. Die beiden Verfahren werden Push- und Pull-Prinzip genannt.

Filtern von Daten
Alle Replikationsarten unterstützten das Filtern der replizierten Daten. Dabei können sowohl ein Ausschluss von Tabellenfeldern (Spalten) als auch eine Filterung der Datensätze möglich. Die Filterung der Datensätze erfolgt in der Art einer SQL Where-Klausel und kann sowohl statisch (feste Bedingung) als auch dynamisch erfolgen. Bei der dynamischen Filterung kann auf Systemvariablen (z.B. Benutzer- oder Servername) als auch auf benutzerdefinierte Funktionen zurückgegriffen werden.

Snapshot-Replikation
Bei diesem einfachsten Fall der Replikation werden Schemaskripte für den publizierten Teil einer Datenbank nebst Bulk Dateien der Daten erzeugt und in ein spezielles Verzeichnis, dem sogenannten Snapshot Folder, gestellt. Der Abonnent greift auf dieses Verzeichnis zu und wendet zuerst die Schemaskripten auf die Datenbank an. Dabei ist eine Festlegung möglich, ob die vorhandenen Tabellen ersetzt oder beibehalten werden.
Anschließend werden die Daten eingespielt, wobei folgende Optionen möglich sind: löschen aller vorhandener Daten, nur einzuspielende Daten ersetzen oder bestehende Daten beibehalten.

Wichtigstes Einsatzgebiet für die Snapshot-Replikation ist die Erstsynchronisation von Replikaten.
Da eine Erstsynchronisation über langsame Verbindungen oftmals zu aufwändig ist, kann diese alternativ über FTP, alternative Snapshot Folder oder so genannte „Pack And Go"-Snapshots erfolgen. Im Fall des alternativen Snapshot Folders kann die Übertragung mittels Band oder CD erfolgen. Bei den „Pack and Go" Snapshots werden bereits vorhandene Abonnenten „geklont" (nur bei Pull-Konfigurationen!).

Transaktionale Replikation
Die Transaktionale Replikation beruht auf der Weitergabe der Datenänderungen abgeschlossener Transaktionen an die Abonnenten. Diese wenden dann dieses Protokoll auf die eigene Datenbank an und „rekonstruieren" dadurch die Transaktionen. Ist der Abonnent ein SQL Server System, so werden die After Images des Transaktionsprotokolls weitergeleitet. In heterogenen Szenarien werden SQL Anweisungen für das Zielsystem generiert.

Zwei wichtige Dienste bestimmen die Transaktionale Replikation: Log Reader und Distributor.
Am Verleger läuft der Log Reader Agent und liest das Transaktionsprotokoll. Daraus werden je nach Zielsystem die sogenannten Replications Commands erzeugt und in die Verteilerdatenbank geschrieben. Diese fungiert als Zwischenpuffer und speichert Änderungsanweisungen so lange, bis sie an alle Abonnenten weitergeleitet wurden. Die Verteilung der Änderungsanweisungen übernimmt der Distribution Agent. Die Hauptlast liegt dabei beim Verteiler, der zur Entlastung des Verlegerservers auch auf einem eigenständigen Server laufen kann.

Diensteinstellungen ermöglichen die Abstimmung der Sicherungen mit der Weitergabe der Datenänderungen. Dadurch können Verleger, Verteiler und Abonnenten im Störungsfall jederzeit ohne Unterbrechung der Replikation wiederhergestellt werden. Das jeweilige Zielsystem wir dann automatisch auf den aktuellen Stand gebracht, indem gegebenenfalls die Datenänderungen nochmals geliefert werden.
Ein besonderer Einsatzfall ist das Katastrophen-Recovery mit Hilfe des so genannten Log Shipping der Enterprise Edition. Dabei wird das Transaktionsprotokoll des Produktivservers kontinuierlich an die Standby Server übertragen, auf den im Störungsfall umgeschaltet wird. Diese befinden sich also in einem permanenten Wiederherstellungsprozess.
Zwar halten die Standby Server ein aktuelle Kopie des Produktivsystems, die auch für Lesezwecke verwendet werden können, aber im Störungsfall müssen die Clientanfragen umgeleitet werden, was aufgrund der eigenen Netzwerksidentifikation (Servername, IP-Adresse) der Standby System nicht ohne Umkonfiguration erfolgen kann. Für diesen Anwendungsfall ist das Failover Clustering der Enterprise Edition in den meisten Fällen die bessere Lösung.

Die Transaktionale Replikation arbeitet sehr robust mit hohem Durchsatz und ist relativ einfach zu konfigurieren. Bei gut verbundenen Servern liegt die Verzögerung im Sekundenbereich.

Die Transaktionen bleiben atomar, Konflikte werden dadurch vermieden, dass am Abonnenten nur gelesen wird. Insofern ist sie von Ihrer Art eher für asymmetrische Konfigurationen zur Verteilung der Leselast auf mehrere Server interessant.
Typische Einsatzgebiete sind etwa im Internet die Erhöhung von Zugriffsgeschwindigkeit und Verfügbarkeit beim Browsen des Warenkatalogs in E-Commerce-Systemen, Mirror Sites und Suchmaschinen oder die Datenbereitstellung in Data Warehousing Umgebungen. Letzterer Anwendungsfall wird durch die Möglichkeit der Datentransformation während des Replikationsvorgangs mit Hilfe des DTS Dienstes unterstützt.

Zwei Varianten der Transaktionalen Replikation erlauben auch eine Datenänderung in den Replikaten: Bidirektionale Replikation und aktualisierende Abonnenten.

Im ersten Fall treten sowohl die primäre Datenbank als auch das Replikat jeweils als Verleger und Abonnent auf. Eine so genannte Loopback Detection verhindert, dass eingespielte Datenänderungen zurück an den Originator geliefert werden. Allerdings ist diese Technik nur für partitionierte Datenbanken interessant, da der SQL Server für dieses Szenario keine Konflikterkennungsmechanismen bereitstellt.
Bei den aktualisierenden Abonnenten (Updating Subscribers) werden Änderungsanweisungen in den Replikaten abgefangen und auf die Verlegerdatenbank angewandt. Von dort aus werden die Änderungen dann sofort auf den Abonnenten repliziert. Dabei übernimmt der DTC Dienst (Distributed Transaction Koordinator) die Aufgabe der Befehlsweiterleitung über ein Zweiphasen Synchronisationsprotokoll. Allerdings erhalten die anderen Replikate die Änderung verzögert beim nächsten Replikationsvorgang, weshalb es sich hierbei nicht um eine vollständig symmetrisch synchrone Lösung handelt.

Ein interessanter Aspekt dieser Lösung ist die Beibehaltung der transaktionalen Konsistenz aufgrund der Tatsache, dass Änderungen nur in der zentralen Datenbank durchgeführt werden. Allerdings wird hierbei eine dauerhafte, performante Verbindung vorausgesetzt, da sonst die Transaktionen beim Abonnenten in Timeouts laufen. Um dies zu vermeiden, kann zwischen Verleger und Abonnenten eine Message Queue geschaltet werden, die Änderungsanweisungen asynchron überträgt. Allerdings kann es dabei zu Konflikten kommen.

Teil II Merge Replikation