Synchronisation von verteilten Datenbeständen Wissen alle Bescheid? In einer Anwendung hat die Datenbank vor allem die Aufgabe, für einen konsistenten Datenbestand zu sorgen, der jederzeit nach Bedarf abgerufen werden kann. Das setzt voraus, daß Anwendung und Datenbank online miteinander verbunden sind. In früheren Systemumgebungen konnte man dies als Selbstverständlichkeit annehmen. Doch mit Mobile Computing und dem Einsatz des Internet in vielfältiger Weise verändern sich die Systemlandschaften deutlich. Das einfache Modell einer zentralen Datenbank mit Online-Clients weicht zunehmend dem Konzept der Replikation. Doch darin verbergen sich einige Fußangeln. Autor: Torsten Schlabach Es gibt ja nach Anwendungssituation sehr unterschiedliche Motive für die Replikation von Datenbanken, angefangen von der Lastverteilung zahlreicher Anwender auf mehrere Server über Sicherheitskonzepte, bei denen man sicherstellen will, daß bei einem Systemausfall das Replika sofort in aktuellem und konsistentem Zustand zur Verfügung steht. Weitere Gründe sind die Reduzierung von Netzlast auf einem WAN, indem man Datenbestände näher an die Anwender repliziert, oder die Unterstützung von Offline-Clients, die ihre Daten nur in Intervallen mit dem zentralen Datenbestand abgleichen. Es läßt sich eine einfache Einteilung in die eher pflegeleichte Online-Replikation und die eher problematische Offline-Replikation vornehmen. Das Offline-Dilemma Bei einer Online-Replikation werden alle beteiligten Datenbanken quasi in Echtzeit repliziert, was eine ständige Verbindung voraussetzt. Bei einem unausgeglichenen Verhältnis von Schreib- und Lesezugriffen in einem verteilten Netzwerk läßt sich so Netzlast reduzieren. In einem Filialunternehmen wird beispielsweise der Artikelstamm mit den Preisen höchstens ein- oder zweimal am Tag aktualisiert, jedoch tausende Male gelesen. In einem solchen Fall repliziert man die Master-Datenbank in der Zentrale mit den Filialen, die dann auf eine lokale Kopie zugreifen können, um den Verkehr auf dem Netzwerk zu reduzieren. Bei einer Online-Replikation vermeidet man die Notwendigkeit, an verschiedenen Orten zunächst auseinandergelaufene Datenbestände beim späteren Replikationslauf synchronisieren zu müssen. Nehmen wir an, anstelle eines Filialunternehmens handelt es sich um eine Firma, die ihre Außendienstmitarbeiter mit Notebooks ausstattet, auf denen in der lokalen Datenbank jeweils eine Kopie des Artikelstamms sowie der Bestellungen des betreffenden Außendienstlers gespeichert sind. Während des Tages nimmt der Mitarbeiter Bestellungen entgegen. Dabei prüft die Software, ob ein ausreichender Lagerbestand vorhanden ist, um die Bestellung ausführen zu können. Nach erfolgreicher Prüfung wird die bestellte Menge der Waren vom Lagerbestand abgezogen; jedoch zunächst nur auf der lokalen Datenbank auf dem Notebook. Erst im Zuge der Replikation wird der Lagerbestand in der Zentrale verringert und die bestellte Menge erhöht. Dabei kann es vorkommen, daß von einem begehrten Artikel beispielsweise 500 Stück am Lager sind. Ein Außendienstmitarbeiter verkauft einem Kunden 280 Stück, ein anderer Außendienstmitarbeiter verkauft einem anderen Kunden am selben Tag 270 Stück. Der tatsächliche Bestand reicht nicht aus, was aber erst zu spät bemerkt wird. Konfliktlösung Eine solche Problemsituation ist nur durch eine geeignete Anwendungslogik zu handhaben, was bedeutet, daß die Anwendung für den Betrieb in der replizierten Umgebung angepaßt werden muß. In diesem Fall würde man in der Anwendung beispielsweise eine Bestellung erst dann als bestätigt darstellen, wenn die Replikation mit der Master-Datenbank erfolgreich durchgeführt worden ist. Dabei können weitere Probleme auftreten. Wenn sich beispielsweise die Preise in der Master-Datenbank inzwischen geändert haben, muß eine Neuberechnung der Preise erfolgen. Noch komplizierter wird es, wenn man beispielsweise die Regel einführt, daß nicht dem Außendienstmitarbeiter die Ware zugewiesen wird, der zuerst seinen Datenbestand repliziert, sondern jede Bestellung mit einem Zeitstempel versehen wird, der maßgeblich ist. In einem solchen Fall wäre eine Bestellung selbst nach erfolgter Replikation nicht definitiv bestätigt, denn jemand könnte nachträglich ältere Rechte auf die Ware geltend machen. Replikationsmethoden Viele Ansätze, die die Datenbank-Hersteller bisher verfolgt haben, wurden vor allem für die Online-Replikation entwickelt, die für die Anwendung transparent sein sollte. Dazu gehören beispielsweise die folgenden Methoden: Server-Server-Abgleich auf Tabellenebene als die klassische Form der Datenbankreplikation. Sybase ist der Vorreiter auf diesem Gebiet und bietet solche Lösungen seit langem an. Anwender können auf Daten auf anderen Servern direkt durchgreifen und so die Konsistenz von Daten auf unterschiedlichen Servern sicherstellen. Publish-Subscribe-Mechanismen, wie sie beispielsweise beim Centura Ranger vorkommen. Auf jeder der beteiligten Datenbanken wird ein Agent installiert. Diese Agenten kommunizieren im Netzwerk miteinander. Die Replikation wird eingerichtet, indem jeweils ein Agent mitgeteilt bekommt, daß er die anderen Agenten benachrichtigen soll, wenn in der Datenbank bestimmte Transaktionen, wie beispielsweise ein Update auf eine ganz bestimmte Tabelle, vorgenommen werden. Die Agenten, die eine solche Benachrichtigung erhalten, führen dieselbe Transaktion auf der entsprechenden Kopie der Datenbank durch. Grundsätzlich geeignet für die Offline-Replikation sind alle Methoden, die entweder unidirektional sind oder bei einer bidirektionalen Replikation darauf basieren, daß Delta-Informationen zuerst gesammelt, dann übertragen und verarbeitet werden. Beispiele hierfür sind Zeitgesteuerter Server-Server-Abgleich. Mit dieser Technik arbeitet der Microsoft SQL Server. Sie wurde ursprünglich von Sybase entwickelt. Der Datenbankadministrator hat die Möglichkeit, die Inhalte bestimmter Tabellen zu replizieren. Der Abgleich erfolgt zu festgelegten Zeitpunkten via Netzwerk oder per E-Mail. Peer-to-Peer-Mehrpunkt-Replikation ist eine Abwandlung dieser Technik, die von Sybase bei deren Produkt SQLAnywhere verwendet wird. Damit können Anwender dieser Datenbank Daten von jeder Stelle im Netzwerk an jede andere Stelle replizieren, ohne sich dabei um die Wahrung der referenziellen Integrität kümmern zu müssen. Automatische Datenpumpen wie beispielsweise InfoPump von Platinum. Diese Werkzeuge werden vor allem im Großrechnerumfeld eingesetzt und sind mit Zehntausenden von Dollar pro Installation meist recht teuer. Ein Batch-Prozeß läuft in bestimmten Abständen, um Daten zwischen unterschiedlichen Datenbanken abzugleichen. Dazu wird die Abgleichlogik in einer proprietären Scriptsprache programmiert. In sämtlichen dieser Fälle - mit Ausnahme der automatischen Datenpumpen - wird jedoch ein möglicher Konflikt bei der Replikation als Ausnahmefall angesehen, dessen Auftreten im fehlerfreien Ablauf nicht eingeplant ist. Doch diese Annahme ist zumindest für die meisten heutigen Anwendungen wenig realistisch, wie am oben erwähnten Beispiel der doppelt verkauften Waren deutlich wird. Es gibt einige Methoden, die nicht direkt zur Replikation im engeren Sinne gehören, insbesondere da sie nicht für den fortlaufenden Betrieb gedacht sind. Dazu gehören vor allem Datenkonvertierungswerkzeuge, wie sie unter anderem von Data Junction oder Platinum mit Info Refiner angeboten werden. Sie sind dazu gedacht, einen Datenbestand einmalig zwischen verschiedenen Schemata zu transformieren, beispielsweise aus einem abzulösenden Altsystem in das neue System oder aus einem operativen System in ein Data Warehouse. Programmbasierte Replikation Wenn man Konflikte bei der Replikation von vornherein berücksichtigt und durch entsprechende Anwendungslogik abdecken will, sollte man diese Logik auch in der Anwendung ansiedeln. Replikationswerkzeuge, die losgelöst von der Anwendung agieren, stellen Probleme entweder in einem Logfile ab, das von einem Systemadministrator bearbeitet werden muß oder verlangen vom Anwender, mit einem separaten Werkzeug zu arbeiten, das nicht seiner Arbeits- und Begriffswelt entspricht. Fehlermeldungen über die Verletzung der referentiellen Integrität helfen einem Außendienstmitarbeiter ebensowenig wie eine Lösung, die die Replikation und dabei Auslieferung aller Aufträge verweigert, wenn eventuell nur ein Auftrag einen Replikationskonflikt auslöst. Der Entwickler der Anwendung kann den vollständigen Datenabgleich selbst programmieren, indem er eine Routine schreibt, die sich mit beiden Datenbanken verbindet, Daten aus der einen Datenquelle in die andere überträgt und Konflikte, wenn möglich, selbständig handhabt oder in verständlicher Form dem Anwender mitteilt. ("Die Preise wurden geändert, Auftrag 1234 wurde neu kalkuliert.") Solche Routinen werden jedoch schon bei vergleichsweise einfachen Abstimmungsproblemen recht komplex. Es kommt hinzu, daß man oft dazu neigt, bestimmte Fakten über die Ablaufumgebung wie beispielsweise die Typen der beteiligten Datenbanken oder die Konfiguration (Master-Slave oder n-Tier) fest in das Programm zu codieren, so daß solche Programme einen hohen Pflegeaufwand verursachen. Die notwendige Abstraktion von vornherein aufzubauen, würde Erfahrungen voraussetzen, die die mit der Aufgabe betrauten internen Entwickler in den wenigsten Fällen besitzen. Programmierbare Replication Engine Einen sinnvollen Kompromiß bietet der recht neue Ansatz, den Centura mit seinem Produkt SQL Base Exchange geht. Dabei handelt es sich um eine programmierbare Replication Engine. Diese Replication Engine ist unabhängig von der Datenbank. Sie wurde mit dem Ziel konzipiert, dem Entwickler eines Replikationsprozesses so wenig Programmierarbeit wie möglich zu bereiten und dennoch der Anwendung die Steuerung des Prozesses einschließlich der Konfliktlösung zu ermöglichen. Erreicht wird dies durch den Einsatz eines interaktiven Werkzeugs (Replication Studio), mit dessen Hilfe ein DBA Datenbestände definieren kann, die repliziert werden sollen. Er legt dazu auf Tabellenebene Kriterien für den Extrakt fest, definiert Master- und abhängige Tabellen sowie, falls erforderlich, Konvertierungsregeln für den Fall, daß die beiden Datenbanken, zwischen denen repliziert werden soll, nicht mit dem identischen Schema arbeiten. Dieses sogenannte Replication Set wird als Datei in die Produktionsumgebung kopiert. Ist also eine Reihe von Rechnern beteiligt, braucht das Replication Set nicht erneut definiert zu werden. Die Replication Engine selbst führt die Replikation nicht vollautomatisch aus, sobald sie über das Replication Set verfügt. Sie hat ein ActiveX-Interface, über das sie von jeder entsprechenden Programmiersprache in Windows einschließlich VisualBasic oder sogar aus Office-Anwendungen und Webseiten heraus angesprochen werden kann. In obigem Beispiel der Offline-Bestellannahme auf dem Notebook wird in die Anwendung ein Menüpunkt "Replikation" eingebaut, der den notwendigen Aufruf an das ActiveX-Control vornimmt, das Replication Set "Bestellungen" zu starten. Die Replication Engine stellt anhand des Replication Set die Verbindungen zu den beteiligten Datenbanken her und beginnt den Replikationsprozeß. Wird ein Konflikt entdeckt, verzweigt die Replication Engine zurück in die Bestellannahme-Anwendung, die entweder über einen eigenen Algorithmus den Konflikt löst oder eine entsprechende Mitteilung an den Anwender gibt. Haben sich beispielsweise die Preise geringfügig geändert, kann die Anwendung den Auftrag stillschweigend neu kalkulieren und die Replikation fortsetzen. Entsteht jedoch das weiter oben beschriebene Problem, daß der Außendienstmitarbeiter Ware verkauft hat, die inzwischen nicht mehr am Lager ist, bekommt er eine Meldung und muß entscheiden, ob der Auftrag trotzdem - mit entsprechender Lieferzeit - ausgeführt oder storniert werden soll. Flexibilität und Abstraktion Der Vorteil einer solchen Architektur liegt darin, daß keine Informationen über die Ablaufumgebung an sich (also die Namen der Server, die Namen von Datenbankobjekten auf dem Server usw.) in die Logik zur Handhabung der Replikation integriert zu werden brauchen. Centura SQLBase Exchange kann beispielsweise mit einer Reihe von unterschiedlichen Datenbanken arbeiten und verlangt nur, daß sich an einem Ende des Replikationspfades eine Centura-Datenbank befindet. Am anderen Ende kann ebenso eine Centura oder eine Oracle-, Sybase- oder Informix-Datenbank eingesetzt werden. Wird also beispielsweise die Informix-Datenbank in der Zentrale durch eine Oracle-Datenbank ersetzt und im gleichen Schritt das Schema verändert, reicht es aus, mit dem Replication Studio ein neues Replication Set zu erstellen und zu verteilen. Die Replication Engine kann damit arbeiten, ohne daß sich das API und folglich die Logik in der Anwendung ändert. Anwendungsentwickler haben auf diese Weise die Möglichkeit, sich auf die Business-Logik der Replikation zu konzentrieren und können die gesamte technische Abwicklung zwischen den beteiligten Datenbanken an die Replication Engine delegieren, was dem Prinzip der Schichtentrennung in einer Anwendung entspricht. Der zukünftige Wartungsaufwand für die Anwendung wird deutlich reduziert, da Änderungen in der Ausführungsumgebung keine Programmierarbeit erfordern. Die Endanwender profitieren von einer klaren Benutzerführung, in der sie eventuelle Probleme oder aber den erfolgreichen, fehlerfreien Datenabgleich im Klartext bestätigt bekommen. Der Autor, Torsten Schlabach, ist freier Journalist in München.