Datenbank-Replikation 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:

Synchron
Transaktionale Replikation Transaktionale Replikation
Log Shipping --------------- Aktualisierende Abonnenten
Asymmetrisch -------------- Symmetrisch

Asynchron
Transaktionale Replikation Merge Replikation
Asymmetrisch -------------- Symmetrisch

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.