Masterarbeit. Entwurf und Implementierung einer Offline-Replikation unter PostgreSQL. Eingereicht von. Benjamin Thurm. Seminargruppe: 11/063/71

Transkript

1 Hochschule für Technik und Wirtschaft Dresden Fakultät Geoinformation Masterstudiengang Geoinformation und Management Masterarbeit Entwurf und Implementierung einer Offline-Replikation unter PostgreSQL Eingereicht von Benjamin Thurm Seminargruppe: 11/063/71 Matrikelnummer: Gutachter: Prof. Dr.-Ing. F. Schwarzbach 2. Gutachter: MSc. A. Schulze (BTU Cottbus) Eingereicht am:

2 Inhaltsverzeichnis i Inhaltsverzeichnis Abbildungsverzeichnis iii 1 Einleitung 1 2 Open Information System for Research in Archaeology Datenhaltung OpenInfRA Mutter-Kind-Konzept Anforderungskatalog Fazit Analyse Grobkonzept Theoretische Grundlagen Verteilte Datenbanksysteme Referenzarchitektur verteilter Datenbanken Replikation Transaktionsverarbeitung Mobile verteilte Datenbanksysteme Architektur mobiler Datenbanksysteme Abgrenzung MDBMS und VDBMS Transaktionen in mobilen verteilten Systemen Eventually Concistency Synchronisation Pessimistische Synchronisationsverfahren Optimistische Synchronisationsverfahren Technik Native Replikation mit PostgreSQL Standby Server Hot-Standby-Replication Streaming-Replikation Synchrone Replikation Interpretation der WAL-Segmente PostgreSQL BDR Softwarelösungen und Erweiterungen Bucardo SymmetricDS ArcGIS Vorüberlegungen zur Replikationskomponente Anpassungen Datenbankschema Synchronisation Fragmentierung und Allokation der Projektdatenbank Synchronisation externer Dokumente Zusammenfassung Implementierung Installation Funktionsweise Konfiguration Engine

3 Inhaltsverzeichnis ii 6.4 Datenmodell Konfigurationstabellen Datentabellen Einrichten der Replikationshierachie eines Projekts Protokollieren von Verlaufsdaten Synchronisation externer Dokumente Mutterknoten einrichten Erstellen einer Kind-Instanz Synchronisation Offline-Synchronisation Konfliktlösung Purging Knoten entfernen Sichern des Kommunikationswegs Test der Konfiguration Notwendige Erweiterungen Fazit Zusammenfassung und Ausblick 86 Konfiguration SymmetricDS-Engine Standardkonfiguration Anlagenverzeichnis Monographien Publikationen Webseiten Erklärung über die eigenständige Erstellung der Arbeit v vii xiv xx xxii xxii xxiii xxvi

4 Abbildungsverzeichnis iii Abbildungsverzeichnis 1 OpenInfRA-Informationsmdel Anwendungsschema Projektdatenbank Komplexe Datentypen Instanziierung Kind-Instanz Exemplarische Mutter-Kind-Hierarchie Vergleich Client-Server - VDBMS Referenzarchitektur Verteilter Datenbanken Fragmentierung und Allokation einer Relation Darstellung Single- & Multi-Master-System Globale Transaktion Phase-Commit-Protokoll in einem verteilten Datenbanksystem Dimensionen verteilter Datenbanksysteme Architektur mobiler verteilter Datenbanksysteme Transaktionen MDBS CAP Pyramide Phasen optimistischer Synchronisation CDC Pattern Tier-Architektur ArcGIS Versionsbaum ArcGIS Replikationsschema Replikation externer Projektdaten SymmetricDS Systemtabellen SymmetricDS Verlaufstabellen Pull- und Push-Verfahren

5 Listings iv Listings 5.1 Installation uuid-ossp Abfrage aller Themeninstanzen eines Projekts Starten des SymmetricDS-Standalone-Service Minimalanwendung SymmetricDS Erstellen eines SymmetricDS-Nutzers Konfiguration der Knoten-Hierarchie Einrichten von Pull- und Push-Verbindungen Definition eines Datenkanals Einrichten der CDC-Trigger einer replizierten Relation Einrichten der CDC-Trigger via Wild Card Einrichten eines Router Zuordnung Router - Trigger Registrieren der Mutter-Instanz Registrierung symadmin Registrierung SQL Online-Initialisierung einer Kind-Instanz Hilfsfunktion Offline-Sync Manuelle Konfliktlösungsstrategie für Projektdaten Query zum Analysieren von Konflikten im empfangenen Batch Auffinden von Konflikten in ausgehenden Batches Einfache Hilfsfunktion zum Entfernen einer Kind-Instanz Hilfsfunktion Offline-Import SymmetricDS-Engine v 2 Standardkonfiguration Mutter-Kind-Konzept vii 3 Ordnerstruktur xx

6 1 Einleitung 1 1 Einleitung Fragt man jemanden, welche drei Dinge er auf eine einsame Insel mitnehmen würde, fällt mit hoher Wahrscheinlichkeit der Begriff des Internet. Aus dem heutigen Alltag kaum noch wegzudenken, hat sich ein ständiger Online-Zugang längst fest in das tägliche Leben vieler Menschen integriert. Was hierbei jedoch oft in Vergessenheit gerät ist, dass dies gar keine Selbstverständlichkeit darstellt. In weniger erschlossenen Gebieten ist eine stehende Internetverbindung ein kostbares Gut, das mitunter auch für Geld nicht zu haben ist. Besonders offensichtlich wird dieser Umstand für Fachgebiete wie der Archäologie. Während die Auswertung von Forschungsreisen mitunter komfortabel im Büro möglich ist, erfolgt die eigentliche Datenerhebung im Feld. Dies ist in der Praxis schnell Ursache für einen komplizierten Umgang mit den mühsam beschafften Daten. Unzureichende Mittel der Datensynchronisation zwischen offline gesammelten und online geänderten Daten stellen hier ein weit verbreitetes Problem dar. Im schlimmsten Fall kann dies bis hin zum Datenverlust führen, wenn der Aufwand den einstweiligen Nutzen der Datenintegration in den Grundbestand übersteigt - ein fürchterlicher Umstand, der der großen Mühe der Datenerhebung nicht würdig ist. Dennoch sind Mitarbeiter des Deutschen Archäologischen Instituts täglich mit diesem Problem bei ihrer Arbeit konfrontiert. Bei Projekten wie der Pergamon-Grabung in der Türkei, bei der Recherche in Museumsdepots und bei Forschungsreisen im Ausland sammeln sie neues Wissen und dokumentieren die Ergebnisse dabei in verschiedenster, zumeist digitaler Form. Grundlage dieser Arbeitsweise sollte ein Informationssystem sein, das für die vielen Facetten dieser Forschung geeignet ist. Dazu gehört insbesondere auch die Arbeit jenseits einer verlässlichen Netzwerkanbindung. In dieser Arbeit soll daher eine Replikations- und Sychronisationslösung als Bestandteil des digitalen Dokumentationssystems OpenInfRA Abhilfe für dieses Problem schaffen, indem das autonome Arbeiten von einem zentralen Datenbestand ermöglicht wird. Sie soll es dem Nutzer erlauben, online und offline mit der gleichen Anwendung zu arbeiten und den lokalen Datenbestand zu einem passenden Zeitpunkt mit den Änderungen auf der zentralen Auskunftsversion abzugleichen. Erfordern die Umstände eine weitere Offline-Version, für deren Einrichtung sich mit dem Internet nicht verbunden werden

7 1 Einleitung 2 kann, soll die Möglichkeit geschaffen werden, diese ausgehend vom lokalen Datenbestand zu erstellen. Einleitend wird daher zunächst das Informationssystem OpenInfRA vorgestellt, da es den Ausgangspunkt dieser Betrachtung darstellt. Eine Analyse des bestehenden Grobkonzeptes zu OpenInfRA wird darlegen, welche Anforderungen an eine Offline-Replikation gestellt werden. Hier soll auch das im Grobkonzept definierte sogenannte Mutter-Kind- Konzept betrachtet werden, welches das Bilden von Kind-Instanzen ausgehend vom zentralen Datenbestand beschreibt. Im Anschluss daran soll der aktuelle Wissensstand zu verteilten und mobilen verteilten Datenbanken dargelegt werden, sodass davon ausgehend die optimistische Replikation und Synchronisation betrachtet werden kann. Ein Überblick über bereits bestehende Lösungen für das Datenbanksystem PostgreSQL soll dann zeigen, welche davon für die Umsetzung des Mutter-Kind-Konzepts in Frage kommen. Die im fünften Abschnitt folgenden Vorüberlegungen zum Entwurf einer Replikation und Synchronisation sollen anschließend die konkrete Umsetzung einer geeigneten Lösung vorbereiten. Abschließend wird die Implementierung mit der vorher für geeignet befundenen Lösung SymmetricDS dokumentiert. Dabei soll auch geprüft werden, inwieweit die vorher gestellten Anforderungen erfüllt werden können.

8 2 Open Information System for Research in Archaeology 3 2 Open Information System for Research in Archaeology Das Open Information System for Research in Archaeology (OpenInfRA) stellt die Bemühungen des Deutschen Archäologischen Instituts Berlin (DAI) dar, ein digitales Dokumentationssystem für archäologische, bauforscherische und historische Fragestellungen [zu schaffen, das] unabhängig von konkreten Forschungsfragen (OpenInfRA 2013, S.6) eingesetzt werden kann. Ziel ist der Entwurf und die Implementierung des Systems sowohl für Projekte des DAI als auch für andere Institute wie Universitäten und ausländische Kooperationspartner. Ein großes Augenmerk liegt dabei darauf, das breite Spektrum von Arbeitsmethoden, Ergebnistypen und Fachobjekten zu berücksichtigen. (ebd., S. 27f.) OpenInfRA ist ein Kooperationsprojekt zwischen dem Lehrstuhl für Vermessungskunde der Brandenburgischen Technischen Universität Cottbus, dem dort ebenfalls ansässigen Lehrstuhl für Datenbank- und Informationssysteme, der Fakultät Geoinformation der Hochschule für Technik und Wirtschaft Dresden und dem Deutschen Archäologischen Institut (DAI). Die aktuelle Entwicklungsgrundlage für OpenInfRA stellt das Grobkonzept dar, welches im Ergebnis dieser Arbeit zum Thema Mutter-Kind-Konzept weiterentwickelt werden soll. Es beschreibt die Sicht auf ein neues Dokumentationssystem für archäologische Feldforschungsprojekte [...], das einen effizienten und nachhaltigen Umgang mit Forschungsdaten (ebd., S. 6) ermöglichen soll. Bisher ist es üblich, dass jedes Forschungsprojekt am DAI mitunter mehrere, individuell erstellte Dokumentationssyteme (ebd., S. 6) nutzt. Die Übernahme für andere, nachfolgende Projekte ist dabei oft - auch wenn die Datenerfassung zumeist digital erfolgt und sich Anwendungsgebiete überschneiden - nicht ohne erheblichen Aufwand, möglich. OpenInfRA soll dem Abhilfe schaffen und dabei auch durch eine Offline-Replikations- und Synchronisierungskomponente die Datenerfassung und digitale Projektpflege vor Ort erleichtern. Als Grundlage der weiteren Betrachtungen wurde das bestehende OpenInfRA-Grobkonzept mit Hinblick auf die für die Replikationskomponente relevanten Aspekte analysiert. In erster Linie interessiert hier natürlich die Datenhaltung. Die gewonnen Kenntnisse zur Speicherung in einer OpenInfRA-Projektdatenbank sind aus diesem Grund im Folgenden kurz charakterisiert. Anschließend wird das Mutter-Kind-Konzept erläutert, welches die

9 2 Open Information System for Research in Archaeology 4 grundlegenden Überlegungen zur Umsetzung der Replikation der Projektdatenbank darstellt. 2.1 Datenhaltung OpenInfRA Für OpenInfRA ist die Open Source Datenbank PostgreSQL vorgesehen. Für das RDBMS spricht, dass es für jedermann frei verfügbar ist, dabei plattformunabhängig implementiert ist und mit PostGIS eine mächtige GIS-Erweiterung bietet. Eine Replikationskomponente für das Informationssystem muss dementsprechend mit dieser Datenbank kompatibel sein und den gleichen Grundsätzen folgen. Um das erklärte Ziel zu erreichen, einem offenen Nutzerkreis die Bearbeitung von Projekten zu ermöglichen, wird das Datenbankschema von OpenInfRA aus einem konzeptuellen Anwendungsschema abgeleitet, deren Elemente auf einer höheren Abstraktionsebene modelliert werden ( Metamodell ). Zu erwarten ist, dass das generalisierte Datenbankschema dadurch stabil und insbesondere in hohem Maße robust gegenüber zukünftigen projektspezifischen Anforderungen [ist]. (OpenInfRA 2013, S. 57) Das projektspezifische Informationsmodell wird dabei wie in Abbildung 1 aus vorhandenem Domänenwissen des Metamodells durch Auswahl generiert. OpenInfRA Informationsmodell (Metamodell) Auswahl von Themen, Attributen und Wertelisten zur Projektinitialisierung Projektspezifisches Modell Abbildung 1: Ableitung des projektspezifischen Informationsmodells aus dem OpenInfRA-Informationsmodell (ebd., S. 56) Im Zusammenhang dieser Arbeit ist es wichtig in Bezug auf die grundlegende Datenhaltung in OpenInfRA-Systemdatenbank und der Projektdatenbank zu unterscheiden. Die Systemdatenbank stellt alle projektübergreifenden Informationen zur Verfügung und bildet so das OpenInfRA-Informationsmodell ab, aus dem die konkreten projektspezifischen

10 2 Open Information System for Research in Archaeology 5 Informationsmodelle abgeleitet werden können. Dies geschieht in Form der Initialisierung von Projektdatenbanken, welche ein aus der Systemdatenbank ausgewähltes initiales Themengerüst übertragen bekommen. Das Anwendungsschema der Projektdatenbank ist in Abbildung 2 und 3 in UML-Notation dargestellt. Abbildung 2: Anwendungsschema der Projektdatenbank (ebd.) Die Systemdatenbank unterscheidet sich von diesem Schema im Fehlen der Klassen, welche nur projektspezifisch relevant sind, d.h. insbesondere konkrete Themeninstanzen und deren Daten. Es wird klar, dass es sich auch bei diesem Vorgang der Initialisierung einer Projektdatenbank um eine Replikation von Daten handelt, da Informationen aus der Systemdatenbank übertragen werden. Dieser Vorgang geschieht dabei in der Regel unidirektional und nur einmal bei der Einrichtung der OpenInfRA Komponenten eines Projekts. Allgemeingültige Daten, wie triviale Wertelisten und Themengerüste werden dabei direkt für die Projektdatenbank übernommen. Es ist gut möglich, dass während der Lebenszeit eines Projekts beispielsweise neue nützliche Wertelisten ergänzt werden. Die automatisierte Übernahme all dieser Daten in die Systemdatenbank ist aber nicht vorgesehen. (OpenInfRA 2013, S. 75) Inwiefern in Zukunft auch beispielsweise allgemein nützliche Erweiterungen der Wertelisten in den Projektdatenbanken an die Systemdatenbank verteilt werden, ist nicht geklärt. Für diese Arbeit bedeutet dies, dass die Replikation und Synchronisation zwischen Instanzen der Projektdatenbank betrachtet werden muss, nicht aber die Kommunikation

11 2 Open Information System for Research in Archaeology 6 Abbildung 3: Komplexe Datentypen (ebd.) zwischen der System- und Projektdatenbank. Der Vorgang der Replikation und Synchronisierung zwischen verschiedenen Projektdatenbank-Instanzen ist im Grobkonzept als Mutter-Kind-Konzept beschrieben. 2.2 Mutter-Kind-Konzept Abgeleitet aus den Arbeitsmethodiken der durch OpenInfRA angezielten Fachgebiete der Archäologie und archäologischen Bauforschung ist die Anforderung gewachsen, berechtigten Administratoren die Möglichkeit zu geben, Kopien des Projektdatenbestands anzulegen. Dabei soll der Projektdatenbestand der zentralen Online-Version, hier treffend als Mutter-Instanz bezeichnet, auf die lokalen Computern oder auf einen lokalen Server der Forschungsniederlassung kopiert werden. Diese Kopien der Projektdatenbank, in dem Zusammenhang als Kind-Instanz bezeichnet, sollen dann in der Regel ohne eine Netzwerkverbindung zum zentralen Repository über eine lokal installierte Offline-Version der OpenInfRA-Anwendung nutzbar sein. Während auch Kind-Instanzen selbst neue Instanzen abbilden können, besitzt die Mutter-Instanz durch ihre Rolle als zentrales Portal bzw. Auskunftssystem auf den DAI-Servern einen gewissen Sonderstatus. So entsteht eine hierarchische Replikation von Projektdaten über mehrere Ebenen, was sprachlich unter Umständen schwer auszudrücken ist. Um die Mutter-Instanz bei der Beschreibung der Replikation der Projektdaten mit OpenInfRA sprachlich besser abzugrenzen wird daher vorgeschlagen, die rein konzeptuelle Bezeichnung der Eltern-Instanz einzuführen. Diese Eltern-Instanz bezeichnet immer die übergeordnete Instanz in der Replikationshier-

12 2 Open Information System for Research in Archaeology 7 Online-System Erstellen Mutter-Instanz Sync Kind-Instanz Importieren Offline-System Kind-Instanz Sync Offline-System Kind-Instanz Abbildung 4: Instanziierung und anschließende Synchronisation einer Kind-Instanz (ebd.) archie. So wird demzufolge eine Mutter-Instanz beim Einrichten einer Kind-Instanz zur Eltern-Instanz. Ebenso wird eine ursprüngliche Kind-Instanz, sobald aus ihr eine weitere Kind-Instanz abgebildet wird, eine Eltern-Instanz dieser neuen Kind-Version. Neben den eigentlichen Projektdaten müssen je nach zukünftiger Ausprägung auch Anwendungsdaten der OpenInfRA-Anwendung, welche für die lokale Ausführung als Offline-Instanz von Bewandtnis sind, mit repliziert werden. Da der Nutzen dieses sogenannten Mutter-Kind-Konzepts sein soll, Projektdaten in jeder Arbeitssituation für die Mitarbeiter zur Verfügung zu stellen, um insbesondere auch die Datenerfassung mit Hilfe einer Offline-Version der OpenInfRA-Anwendung zu gewährleisten, ist eine paarweise bidirektionale Synchronisation zwischen den jeweilig verwandten Eltern- und Kind-Instanzen vonnöten, welche sich bis zum Ursprung der Hierarchie der zentralen Mutter-Instanz paarweise fortsetzt. Das Erstellen von Kind-Instanzen und das anschließende Importieren dieser in eine Offline-Version der OpenInfRA-Anwendung ist in Abbildung 4 schematisch dargestellt. Aus dem Mutter-Kind-Konzept folgt eine hierarchische Baumstruktur bzw. Baum-Topologie unbestimmt vieler Ebenen von Datenbankinstanzen, die zueinander durch ihre Verwandt-

13 2 Open Information System for Research in Archaeology 8 schaftsverhältnisse verbunden sind. An der Spitze dieser Hierarchie steht immer die Mutter-Instanz (siehe auch Abbildung 5), deren Rolle nicht übertragbar ist und auf der durch Synchronisation entlang des sich ergebenden Graphen alle Änderungen zusammenlaufen. In der Praxis könnte die Nutzung folgendermaßen aussehen: Ein leistungsstarker, zentraler Server des DAI hostet die Online-Version der OpenInfRA- Anwendung, welche die Mutter-Instanz des Projektdatenbestands verfügt. Interessierte Besucher könnten diese nutzen, um öffentlich zugängliche Informationen zu recherchieren, während über das Internet verbundene Mitarbeiter sie für ihre Aufgaben nutzen. Die Forschungsniederlassung, die das Projekt betreibt, installiert eine Offline-Version der OpenInfRA-Anwendung auf einem oder mehreren Desktop-Rechnern und spielt eine Kind-Instanz auf dem zugehörigen Datenbankserver ein. Die Mitarbeiter profitieren nun von einer höheren Lokalität der Daten und können auch ohne Internetverbindung auf die Projektdaten zugreifen. Für den Außendienst wird aber ein Laptop benötigt, der ebenfalls mit einer OpenInfRA-Anwendung ausgestattet wird. Im Feld erhobene und im Büro recherchierte Daten können schließlich über eine lokale Netzwerkverbindung durch Synchronisation zwischen Laptop und Desktop abgeglichen werden. Die Synchronisation zwischen Mutter-Instanz und den lokalen Desktop-Rechnern könnte beispielsweise periodisch zum Ende des Arbeitstages geschehen. Dieses Szenario ist exemplarisch in Abbildung 5 dargestellt. Um Daten zwischen den Instanzen abzugleichen, sind zwei Verfahren vorgesehen: eine Online-Synchronisation per Netzwerkverbindung und eine komplementäre Offline-Synchronisation. Für die Synchronisation von Offline-Versionen der OpenInfRA-Anwendung kommt auch eine temporäre Netzwerkverbindung, wie sie über ein einfaches LAN-Kabel oder einen stationären WLAN-Router hergestellt werden kann, in Frage. Für Synchronisationspartner mit einer relativ stabilen Netzwerkverbindung zueinander sollte zusätzlich auch eine periodische Synchronisation möglich sein, die das Abweichen der Datenbestände auf den Synchronisationspartner so gering wie möglich voneinander hält. Die Offline-Synchronisation soll durch den Austausch von Synchronisationsnachrichten erfolgen, die durch berechtigte Nutzer erstellt werden können. Die konkreten Erwartungen, die mit dem Mutter-Kind-Konzept verbunden werden, sind im Anforderungskatalog des Grobkonzepts näher beschrieben.

14 2 Open Information System for Research in Archaeology 9 1. Hierarchieebene Online-System Mutter-Instanz DAI-Server 2. Ebene Desktop- Rechner Offline-System Kind-Instanz Offline-System Kind-Instanz 3. Ebene Laptop für Außendienst Offline-System Kind-Instanz Periodische Sync. On-Demand Sync. Abbildung 5: Die Hierarchie unter den Datenbankinstanzen folgt aus der Instanziierungsreihenfolge, deren Ausgangspunkt immer die zentrale Mutter-Instanz ist. Das Beispiel zeigt eine mögliche Konstellation, in der OpenInfRA im Rahmen eines Projekts genutzt werden könnte. 2.3 Anforderungskatalog Für die Ableitung funktionaler und nicht-funktionaler Anforderungen werden die im Grobkonzept definierten Anwendungsfälle genutzt. Das Mutter-Kind-Konzept und damit die Replikation bzw. Synchronisation betreffend ist der Anwendungsfall Administration Projekt Instanz, welcher die Abläufe bei der Verwaltung einer Projektinstanz beschreibt. Der Vorgang fällt unter die Kategorie der Projekt-Administration, als Akteur ist der Administrator bestimmt. Vorbedingung ist also, dass der Administrator angemeldet ist, die benötigten Rechte für die Administration der Projekt-Instanz hat und ein entsprechendes Projekt angelegt wurde. Zum möglichen Ablauf der Administration sind derzeit sechs Fälle definiert: Das Erstellen einer Kind-Instanz eines Projektes. Die entsprechende Anforderung AC_0280 spezifiziert dies als das Erstellen einer (Offline-)Version in unterschiedlichen Ausprägungen an einem ausgewähltem Speicherort mit den Wahlmöglichkeiten, nur den Datenbestand des Projekts zu exportieren und eventuelle Systemdateien und/oder Projektkonfigurationen mit einzubeziehen.

15 2 Open Information System for Research in Archaeology 10 Die Möglichkeit eine Online- (AC_0300) oder Offline-Synchronisation (AC_0310) zwischen Kind-Instanz und Mutter-Instanz durchzuführen. Eine Kind-Instanz auf einer Offline-Version der OpenInfRA-Anwendung importieren bzw. installieren (AC_0320, AC_0330). Die für die Offline-Synchronisation vorgesehen Synchronisationsdateien (AC_0311, AC_0312) exportieren (AC_0313). Darüber hinaus bestehen konkrete Anforderungen im Bereich der Sicherheit, die nicht direkt aus dem Anwendungsfall entnommen werden können. Sie betreffen die Protokollierung aller Synchronisationsvorgänge durch Zeitstempel, Benutzername, der beteiligten Instanz, dem Status der Synchronisation und einer entsprechenden Fehlermeldung bei Misserfolg (SEC_0260). Darüber hinaus ist eine gesicherte Übertragung (SEC_0410) bei der Synchronisation gefordert (SEC_0420), die nur ein Administrator starten darf (SEC_0400). Des Weiteren werden im Grobkonzept konzeptuelle Anforderungen formuliert. So beschreibt KT_1000 genau eine Mutter-Version des Datenbestands eines Projekts, die als Grundlage der Erzeugung von Kind-Versionen und welche immer das Auskunftssystem des Systems darstellt (KT_1050). Ein oder mehrere Kind-Instanzen (KT_1010) bilden die Mutter-Instanz nach Datenbestand und projektspezifischen Eigenschaften ab. Darüber hinaus ist formuliert, dass die Transaktionierung zwischen Mutter und Kind-Instanz dem optimistischen Transaktionsansatz folgen soll (KT_1031) und für die Synchronisation lange Transaktionen unterstützt (KT_1032). Die grafische Benutzeroberfläche (GUI) soll letztendlich auf Online- und Offline-Instanzen gleich aussehen (KT_1040). Neben den konkret für die Replikations/Synchronisationskomponente formulierten Anforderungen gelten für sie die gleichen Grundsätze wie für alle Bestandteile von OpenInfRA. Dazu zählt insbesondere, dass die Implementierung betriebssystemunabhängig für die Systeme Microsoft Windows (XP), Mac OS X und Linux erfolgen muss (SW_0130), die grundlegende Administration per Admin-Client vorgenommen werden kann und die genutzten Komponenten als Open Source-Software zur Verfügung stehen (SW_0140, 0160). Der Aufbau der Komponente soll modular zum Gesamtsystem OpenInfRA erfolgen, sodass es möglich ist zu entscheiden, ob die Komponente Replikation für einige Projekte gar nicht von Bewandtnis sein soll (SW_4000). Bei auftretenden Fehlern soll der Nutzer außerdem per Statusnachricht darüber informiert werden (SW_0041). Nötige Einstellungen, die für die Komponente vonnöten sind, können neben der Nutzung des Admin-Client per Konfigurationsdateien (SW_0230) und/oder über administrative Einstellungen im Datenbanksystem (SW_0240) vorgenommen werden. Die bestehenden Anforderungen des Grobkonzepts sind im Folgenden zusammen mit

16 2 Open Information System for Research in Archaeology 11 ihrer ID und der Priorisierung in gekürzter Form aufgelistet: Tabelle 2.1: Anforderungsfälle Mutter-Kind-Konzept ID Art Anforderung Prior. AC_0280 FA Erstellen einer Instanz eines Projektes 1 AC_0300 FA Online-Synchronisation 1 AC_0310 FA Offline-Synchronisation 1 AC_0311 FA Erstellung SQL-Dump 2 AC_0312 FA Parametrierung SQL-Dump 2 AC_0313 FA Import SQL-Dump 2 AC_0320 FA Import einer Kind-Version 1 AC_0330 FA Installation einer (Offline-)Instanz 1 SEC_0260 NFA Protokollierung Synchronisation 1 SEC_0410 NFA Datensicherheit 3 SEC_0420 FA Datenübertragung 2 KT_1000 NFA Mutter-Version 1 KT_1010 NFA Kind-Version 1 KT_1031 NFA Optimistischer Transaktionsansatz 1 KT_1032 NFA Lange Transaktionen 1 KT_1040 NFA Einheitliche GUI für Online / Offline Nutzung 1 KT_1050 NFA Mutter-Instanz als Auskunftssystem 1 SW_0130 FA Betriebssystem 1 SW_0140 FA Client-Komponenten des Systems KO SW_0041 FA Fehlermeldungen KO SW_0230 FA Systemanpassungen über Konfigurationsdateien KO SW_0240 FA Systemanpassungen über Datenbankmanagementsystem KO SW_4000 NFA Modularer Aufbau KO 2.4 Fazit Analyse Grobkonzept Bei einer ersten Analyse des Grobkonzepts wurde der Unterschied zwischen Datenbankinstanzen und der Online- und Offline-Anwendung OpenInfRA durch die stringente Bezeichnungen Mutter/Kind-Instanz und Online/Offline-Version besser voneinander differenziert. Außerdem ist für den Fall der Offline-Synchronisation nun nicht mehr der SQL-Dump als Format vorgesehen, um über die entsprechenden Anforderungen die Implementierungsmöglichkeiten nicht einzuschränken. Stattdessen wird die allgemeinere Formulierung Synchronisationsdateien genutzt. Um die Replikationshierarchie zwischen Mutter- und Kind-Instanzen und Kind- und Kind-Instanzen leichter zu beschreiben, wurde die konzeptuelle Bezeichnung der Eltern-Instanz eingeführt, welche eine Instanz beschreibt, die zuvor eine Kind-Instanz gebildet hat und als dessen Synchronisationspartner auftritt. Dies dient außerdem zur besseren Abgrenzung der Sonderstellung der Mutter-Instanz bzw. der zentralen Online-Version als Auskunftssystem.

17 2 Open Information System for Research in Archaeology 12 Die Anforderung einer stetigen Online-Synchronisation in frei definierbaren Intervallen wurde mit einer mittleren Priorität aufgenommen. Grund dafür ist, dass sie für Niederlassungen mit einer stabilen Netzwerkverbindung zur Mutter-Instanz oder bei der Synchronisation von niederen Ebenen der Hierarchie in lokalen Netzwerken als sehr nützlich angesehen wird. Es kann so besser auf Bedürfnisse verschiedenster Projekte eingegangen werden. In Abschnitt 2.2 wurde der anvisierte Nutzen des Mutter-Kind-Konzepts beschrieben, die Projektdaten autonom vom zentralen Datenbestand auf den Servern des DAI bei den lokalen Kompetenzzentren zur Verfügung zu stellen. Dabei ist allgemein formuliert, dass jede Kind-Instanz als Eltern-Instanz eintreten kann. In der Praxis wird die Tiefe dieser Vererbungshierarchie eine praktikable Obergrenze haben, was für die Implementierung einer Softwarelösung unter Umständen berücksichtigt werden darf. Schon vor einer tiefgreifenderen Betrachtung ist klar, dass bei der Nutzung eines optimistische Transaktionsansatzes und autonomen Schreiboperationen auf den Kind-Instanzen Konflikte beim Synchronisieren möglich sind. Für OpenInfRA kann angenommen werden, dass solche Konflikte relativ selten sind, immerhin handelt es sich um eine Anwendung, die in erster Linie für das Sammeln von Informationen genutzt werden soll. Diese Annahme wird durch das in Abschnitt 2.1 beschriebene Anwendungsschema gestützt, in dem Attribute konkreter Instanzen durch Assoziationsbeziehungen referenziert sind. Praktisch bedeutet dies, dass die Wahrscheinlichkeit, dass zwei parallele Transaktionen die gleiche Tabellenzeile bearbeiten, sehr gering ist. Dementsprechend stellt die manuelle Auflösung von Konflikten bei der Synchronisation ein adäquates Mittel dar, das den Nutzern die beste Kontrolle über die Daten bietet. Entsprechend ist im Grobkonzept die manuelle Konfliktlösung durch Administratoren bei Synchronisationskonflikten aufgeführt. Für die Synchronisation zwischen Datenbankinstanzen ist zu beachten, dass die Qualität der Netzwerkverbindung stark variieren kann. Es sind deshalb Verfahren zu bevorzugen, die lediglich diejenigen Datensätze übermitteln, die von Änderungen betroffen sind. Dies gilt auch für die Offline-Synchronisation. Das Mutter-Kind-Konzept beschreibt die Replikation und Synchronisation der Projektdaten. Gemeint sind dabei auch externe Dokumente wie Texte, Bilder und Pläne, welche durch die OpenInfRA-Anwendung im Dateisystem abgelegt werden oder die zur Konfiguration der OpenInfRA-Komponenten benötigt werden. Deshalb muss beim Installieren der Offline-Version der Anwendung bzw. beim Import der initialen Daten eine Möglichkeit gegeben sein, externe Daten zu selektieren, die für die Projekt-Instanz bei der autonomen Arbeit relevant sind. Die Anwendungsschicht muss dabei auf Datensätze, welche Verknüpfungen auf externe Dateien darstellen die auf der Offline-Version nicht zur Ver-

18 2 Open Information System for Research in Archaeology 13 fügung stehen, ohne einen Systemfehler bzw. mit einem passenden Hinweise reagieren können. Es ist anzunehmen, dass die Replikation und Synchronisation von externen Daten nicht über eine Datenbankverbindung organisiert werden kann, sondern dass hierfür externe Prozesse benötigt werden. Bei der Online-Synchronisation ist bei Dateien insbesondere wichtig, dass diese komprimiert übertragen werden. Die Implementierung einer Replikationskomponente für das OpenInfRA-Projekt erfordert eine Auseinandersetzung mit der zugrundeliegenden Thematik der Replikation und Synchronisation in relationalen Datenbanken. Im anschließenden Kapitel wird deshalb eine theoretische Einführung hierzu geboten und auf mögliche Lösungsstrategien und eventuelle Fehlersituationen eingegangen. Im darauffolgenden Kapitel werden schließlich bestehende Replikationslösungen für PostgreSQL und verwandte Systeme beschrieben, die als Ausgangspunkt oder Vorlage der Implementierung dienen könnten.

19 3 Theoretische Grundlagen 14 3 Theoretische Grundlagen Das in Kapitel 2.2 beschriebene Mutter-Kind-Konzept stellt die Kommunikation zwischen den im System befindlichen Computern dar. Als Übertragungsmedium kommt eine Ethernetverbindung (LAN), eine Internetverbindung (WAN) aber sogar die Übertagung als Datei in Betracht. Um die Funktion eines Computers als Kommunikationspartner in einem solchen System besser abzugrenzen, werden sie häufig als Stationen oder Knoten bezeichnet. Um die Projektdaten verwalten zu können und so die Anforderungen des Mutter-Kind-Konzepts zu erfüllen, muss jede der Stationen über einen lokalen Datenbankserver verfügen. Neben diesem Datenbankserver werden unter Umständen weitere Services ausgeführt die für die OpenInfRA-Anwendung, sei es online oder offline, von Belang sind. Während die einzelnen Stationen mit Hilfe der auf ihnen gespeicherten Daten autonom voneinander arbeiten können, ist für die Konsolidierung von Änderungen am Datenbestand Kommunikation vonnöten. Es handelt sich deshalb um ein Verteiltes System, genauer ein verteiltes Datenbanksystem. Der Begriff soll im Folgenden kurz erläutert werden. 3.1 Verteilte Datenbanksysteme Unter einem verteilten System versteht man in der Informatik vernetzte Computer und Komponenten, die sich per Nachrichten über ihre Aktionen austauschen und koordinieren. Die Client/Server-Architektur des World Wide Web kann beispielsweise als verteiltes System angeführt werden, bei dem die Komponenten nebenläufig agieren, auf keine globale Uhr zurückgreifen und unter Umständen unabhängig voneinander ausfallen können. (Coulouris, Dollimore und Kindberg 2002, S. 17f.) In diesem Sinne beschreiben Ceri und Pelagatti (1984, S. 6f.) verteilte Datenbanken grob als eine Sammlung von Informationseinheiten, die einen logischen Zusammenhang bilden, aber räumlich getrennt auf mehreren durch ein Kommunikationsmedium verbundenen Computern verwaltet werden. Jeder dieser Computer, in diesem Zusammenhang als Knoten bezeichnet, nimmt dabei an mindestens einer globalen Aufgabe teil. Die Gesamtheit der Knoten bildet das verteilte Datenbanksystem. (Mutschler und Specht 2004, S. 65f.) Abbildung 6 stellt einer verteilten Datenbank die klassische Client-Server- Architektur gegenüber. Im Vergleich handelt es sich [beim Client-Server-System] also

20 3 Theoretische Grundlagen 15 sozusagen um ein degeneriertes VDBMS [=verteiltes Datenbankmanagementsystem], da nur der Server Daten abspeichert. (Kemper und Eickler 2009, S. 462) Deshalb wird bei einer Client-Server-Architektur auch von einer verteilten Anwendung gesprochen. Client Station 1 Client Kommunikationsnetz Server Kommunikationsnetz Station 1 Station 1 (a) Client-Server-Architektur (b) Verteiltes Datenbanksystem Abbildung 6: Vergleich Client-Server-Architektur - verteilte Datenbank (ebd., S. 462) Verteilte Datenbanken können im wesentlichen nach drei Kriterien bzw. Dimensionen klassifiziert werden: Heterogenität beschreibt die grundsätzliche Verschiedenheit von Konzepten im Bereich der Hardware, Kommunikation oder des Betriebssystems. Für Datenbanksysteme gilt dies insbesondere auch für unterschiedliche Modellierung, unterschiedliche Datenbanksysteme und unterschiedlicher Datenmodelle. (Mutschler und Specht 2004, S. 65) Verteilung beschreibt, ob das Datenbanksystem auf einem Computer zentral vorhanden ist, oder es sich über mehrere Computer hinweg erstreckt. (ebd., S. 65) Die Autonomie umfasst die Konzepte der Kommunikationsautonomie (Communication Autonomy), also inwiefern eine Komponente mit einer anderen kommunizieren kann, der Entwurfsautonomie (Design Autonomy), welche beschreibt in welchem Umfang das eigene Design bestimmt werden kann und der Ausführungsautonomie (Execution Autonomy), die aussagt, ob externe Prozesse die Ausführung lokaler Operationen beschränkt. (ebd., S. 65) Im folgenden Abschnitt wird die Referenzarchitektur für verteilte Datenbanksysteme vorgestellt und anschließend die mit verteilten Datenbank oft einhergehende Replikation erläutert. In Abschnitt 3.4 werden schließlich die zur Konsistenzerhaltung eingesetzten Verfahren charakterisiert.

21 3 Theoretische Grundlagen Referenzarchitektur verteilter Datenbanken Ceri und Pelagatti (1984, S. 37ff.) definieren eine Referenzarchitektur verteilter Datenbanken, welche von einem globalen Schema über das Fragmentierungsschema und dem Zuordnungs- bzw. Allokationsschema hin zur lokalen Datenbank reicht. Die Architektur ist in Abbildung 7 dargestellt. globales Schema Stationsunabhängige Schema Fragmentierungsschema Zuordnungsschema lokales Schema lokales Schema lokales DBMS lokales DBMS lokale DB lokale DB Abbildung 7: Referenzarchitektur Verteilter Datenbanken nach Ceri und Pelagatti (ebd., S. 38) Das globale Schema ist der Ausgangspunkt des Entwurfs und entspricht dem Implementierungsschema des zentralisierten Datenbankentwurfs. Für das Fragmentierungsschema, der logischen Ebene der Struktur des verteilten Datenbanksystems (Mutschler und Specht 2004, S. 68), werden sich daraus ergebende logisch zusammenhängende Informationsmengen - hier Relationen - in (weitgehend) disjunkte Fragmente (Untereinheiten) zerlegt. (Kemper und Eickler 2009, S. 463) Die Zerlegung kann dabei in horizontaler (Zerlegung in Tupelmengen) als auch vertikaler Richtung (Projektion in Attributbereiche) erfolgen und muss sich nach dem zu erwartenden Zugriffsverhalten richten. Es gelten im wesentlichen drei Bedingungen für eine korrekte Fragmentierung: Vollständigkeit: Alle Daten der globalen Relation müssen auf Fragmente aufgeteilt werden und dürfen bei der Fragmentierung nicht verloren gehen.

22 3 Theoretische Grundlagen 17 Rekonstruierbarkeit: Globale Relationen müssen aus ihren Fragmenten wiederherstellbar sein. Disjunktheit: Fragmente müssen disjunkt zueinander sein, das heißt ein Datum ist nicht mehreren Fragmenten zugeordnet, um Überlappungen durch das Allokationsschema explizit zu bestimmen. (Ceri und Pelagatti 1984, S. 42; Kemper und Eickler 2009, S. 465) Die Verteilung der Fragmente auf die einzelnen Stationen wird abschließend durch das Allokationsschema, der physischen Ebene der Struktur einer verteilten Datenbank (Mutschler und Specht 2004, S. 65), beschrieben. Für die Zuteilung der Fragmente sind zwei Möglichkeiten gegeben. Bei der redundanzfreien Allokation werden die Fragmente jeweils exakt einer Station zugewiesen. Die Zuordnung erfolgt in diesem Fall möglichst nah an der Station, die diese Daten am ehesten nutzt. Die zweite Möglichkeit besteht darin Fragmente mehr als einer Station zuzuweisen. Man spricht nun von Allokation mit Replikation. (Ceri und Pelagatti 1984, S. 39; Coulouris, Dollimore und Kindberg 2002, S. 644) Abbildung 8 stellt die beschriebene Fragmentierung und Allokation einer Relation noch einmal schematisch dar. Fragmentierung Allokation Station 1 Relation Station 2 Global Relation Fragmente Physisches Abbild Abbildung 8: Fragmentierung und Allokation einer Relation nach Ceri und Pelagatti (1984, S. 40) Die Allokation mit Replikation stellt ein häufig genutztes Konzept dar, welches Grundlage dafür ist, Informationen ohne eine Verbindung zum zentralen Server auf Knoten zur Verfügung zu stellen. Entsprechend soll es im Folgenden näher betrachtet werden.

23 3 Theoretische Grundlagen Replikation Replikate sind Kopien von Datenobjekten, also Tabellen, Tabellenpartitionen, Datensätze oder Dateien, in verschiedenen Systemen, die konsistent zueinander gehalten werden sollen. Geläufig ist für sie auch die Bezeichnung Snapshot oder materialisierte Sicht. Für die Repliken verwaltenden Stationen ist der Begriff Repliken-Manager geläufig. (Coulouris, Dollimore und Kindberg 2002, S.644; Saito 2005, S. 1) Durch die beschriebene Allokation mit Replikation kann eine hohe Verfügbarkeit von Daten erreicht werden. Insbesondere die Lokalität von Daten kann durch Repliken an den entsprechenden Knoten erhöht und so die Zugriffszeit verkürzt werden, was insbesondere auch für die Verfügbarkeit von Daten auf entkoppelten Knoten gilt die zeitweise autonom vom verteilten Datenbanksystem agieren sollen. Caching und Hoarding sind dabei verwandte Techniken bei denen Daten vervielfältigt werden. Caching beschreibt dabei das dynamische Zwischenspeichern von angefragten Daten zur Beschleunigung von Abfragen und der Verbindungsentlastung beim Online-Betrieb, Hoarding die Erweiterung dieses Verfahrens durch vorsorgliches Anfordern von Daten von denen vermutet wird, dass diese zukünftig benötigt werden. Während Caching- und Hoarding-Techniken nur geringen Einfluss auf die Wahl der lokal bzw. offline zur Verfügung stehenden Informationen zulassen, erlaubt Replikation durch die in Abschnitt 3.2 beschriebene Fragmentierung und Allokation eine sehr genaue Auswahl der Daten. (Höpfner, Türker und König-Ries 2005, S. 181ff.) So ist die grundsätzliche Möglichkeit der unverbundenen Arbeit, etwa bei archäologischen Außenarbeiten anhand der Repliken gegeben. Werden auf mehreren Repliken-Managern Änderungen akzeptiert, also nicht nur auf einem zentralen Server, und sollen diese zu einem späteren Zeitpunkt konsolidiert werden, spricht man von der sogenannten Multi-Master-Replikation. Das komplementäre Gegenstück hierzu wird als Master-Slave-Replikation bezeichnet, in der ein designierter Server über die verbleibenden Knoten wie über Sklaven herrscht. Lokale Änderungen sind in diesem Fall gar nicht möglich, oder werden im Zweifelsfall überschrieben. (Saito 2005, S. 3; Petersen, M. J. Spreitzer u. a. 1997, S. 288) Abbildung 9 stellt die beiden Formen exemplarisch gegenüber. Vergleicht man die beiden Konfigurationen, ist intuitiv klar, dass ein Single-Master-Systeme einfacher umzusetzen ist. Da Schreibzugriffe nur auf einem Knoten vorkommen können, werden eventuelle Konflikte sofort erkannt und können dem Benutzer transparent mitgeteilt werden. Updates müssen dann lediglich in eine Richtung transportiert werden. Nachteilig ist jedoch die Gefahr die von einem Single Point of Failure im Master-Knoten ausgeht. Im Gegensatz dazu kann die Multi-Master-Konfiguration diesen Nachteil durch

24 3 Theoretische Grundlagen 19 Slave 1 Master Slave 2 Master 1 Master 2 Master 3 (a) Single-Master-System (b) Multi-Master-System Abbildung 9: Exemplarische Darstellung eines Single-Master & Multi-Master-Systems in Anlehnung an Böszörmenyi und Schönig (2013, Pos. 496). Pfeile geben die Transportrichtung von Datensätzen an. hohe Verfügbarkeit mehrerer Knoten ausgleichen. Ähnlich wie bei der parallelen Nutzung durch viele Clients in einer zentralisierten Datenbank, kann es aber hier zu einem konkurrierenden Schreibzugriffen zwischen den Knoten kommen. (Saito 2005, S. 3) Diesem Umstand muss durch eine Transaktionsverarbeitung und Serialisierung der Schreibvorgänge begegnet werden. 3.4 Transaktionsverarbeitung Kemper und Eickler (2009) definieren den Begriff Transaktion in einem Datenbanksystem wie folgt: Eine Transaktion stellt eine Folge von Datenverabeitungsbefehlen (lesen, verändern, einfügen, löschen) dar, die die Datenbasis von einem konsistenten Zustand in einen anderen - nicht notwendigerweise unterschiedlichen - konsistenten Zustand überführt. (ebd., S. 279) In diesem Zusammenhang kommt das Akronym ACID zum tragen welches die geforderten Eigenschaften einer Transaktion beschreibt und Kernprinzipien der Architektur von relationalen Datenbanksystemen (Edlich u. a. 2011, S. 30) darstellt: Atomarität (Atomicity): Eine Transaktion wird als kleinste, nicht mehr zerlegbare Einheit betrachtet und wird ausschließlich im Gesamten festgeschrieben. [Sie] muss alles oder nichts erledigen. (Coulouris, Dollimore und Kindberg 2002, S. 546) Werden alle Änderungen einer Transaktion zurückgesetzt, weil sie nicht komplett ausgeführt werden kann, so spricht man vom Zurücksetzen einer Transaktion. (Dadam 1996, S. 185) Konsistenz (Consistency): Beim Abschluss einer Transaktion muss ein konsistenter Datenbestand zurückbleiben, der den Bedingungen des definierten Daten-

25 3 Theoretische Grundlagen 20 bankschemas genügt, dessen Integrität also nicht verletzt wird. (Dadam 1996, S. 185) Isolation: Parallel ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen. Damit einher geht die Forderung nach der Serialisierbarkeit der parallel ausgeführten Operationen bei der das Ergebnis der Operationen mindestens durch eine serielle (also nicht-überlappte) Ausführungsreihenfolge dieser Transaktionen erzeugbar sein muss. (ebd., S. 185) Dauerhaftigkeit (Durability): Eine abgeschlossene Transaktion bleibt dauerhaft erhalten und ihre Wirkung kann nur durch eine kompensierende Transaktion aufgehoben werden. (Kemper und Eickler 2009, S. 283) Die Struktur einer Transaktion besteht auch im verteilten DBS aus einer Folge von Leseund Schreibanweisungen, welche in Begin of Transaction und End of Transaction, bzw. Rollback geklammert sind. In einem verteilten Datenbanksystem können dabei mehrere Knoten beteiligt sein. Der Rechner an dem eine Transaktion gestartet wird ist dabei der Heimatknoten und übernimmt in der Regel die Koordination der Transaktion. Finden alle Operationen der Transaktion am Heimatknoten statt, spricht man von einer lokalen, andernfalls von einer globalen Transaktion. Abbildung 10 stellt eine globale Transaktion über drei Knoten exemplarisch dar. Bei einer globalen Transaktion muss dabei sichergestellt werden, dass alle beteiligten Knoten getreu dem ACID-Paradigma am Ende der Transaktion zum selben Ergebnis kommen und die Änderungen entweder alle festschreiben oder alle zurücknehmen. (Rahm 1994, S. 114) T1 Knoten A Starte ST Starte ST T11 Knoten B T12 Knoten C Abbildung 10: Beispiel einer globalen Transaktion koordiniert durch Knoten A, welcher Subtransaktionen an Knoten B und C startet. (Darstellung nach Dadam (1996, S. 186)) Für die Koordination von verteilten Transaktionen wurden verschiedene Verfahren entwickelt. Abbildung 11 stellt das 2-Phasen-Commit-Protokoll (2PC-Protokoll) das, das ausgehend von einer Koordinator-Station eine Transaktion im System in zwei Phasen kommuniziert. Durch sie wird sichergestellt, dass eine Transaktion immer auf allen beteiligten

26 3 Theoretische Grundlagen 21 Agenten-Stationen akzeptiert oder abgelehnt wird, sie also auch im verteilten System atomar erscheint. In allen Phasen des 2PC-Protokolls besteht dabei jedoch die Möglichkeit, dass die Transaktion nicht nur auf Grund einer Integrationsverletzung des Datenbankschemas, sondern wegen einer fehlerhaften Kommunikation abgebrochen werden muss. (Kemper und Eickler 2009, S. 485f.) A1 A1 K A2 K A2 K A3 A3 PREPARE FAILED/READY COMMIT/ABORT ACK Abbildung 11: Nachrichtenaustausch zwischen Koordinator K und beteiligten Agenten beim 2-Phase-Commit-Protokoll. (ebd., S. 486) In Kapitel 2 wurde festgestellt, dass der Zweck des Mutter-Kind-Konzepts die Arbeit autonom von einer ständigen Netzwerkverbindung sein soll. Dementsprechend sind restriktive Verfahren wie das 2PC-Protokoll für diese Belange ungeeignet. Dementsprechend müssen die Gedanken zum verteilten Datenbanksystem um die Komponente der Mobilität ergänzt werden. Hierfür wird im Folgenden das mobile verteilte Datenbanksystem vorgestellt. 3.5 Mobile verteilte Datenbanksysteme Mobile Geräte, wie sie häufig bei archäologischen Arbeiten verwendet werden, insbesondere Mobile Standardcomputer wie Laptops, Notebooks, Subnotebooks und TabletP- Cs können ebenfalls Bestandteil eines verteilten Datenbanksystems sein. Sie werden treffend als mobile Knoten bezeichnet und sind zumeist über eine temporäre, drahtlose Netzwerkverbindung in das System integriert. Sie erweitern so die Definition des verteilten Datenbanksystems hin zu einem mobilen verteilten Datenbanksystem. (Höpfner, Türker und König-Ries 2005, S. 9ff.) Durch ihre schwache Anbindung sind sie häufig vom Gesamtsystem getrennt und verursachen so Netzwerkpartitionierungen. Während diese Fehlersituation auch bei normalen Knoten eintreten kann, ist dies bei mobilen Knoten wesentlich häufiger der Fall. (Mutschler und Specht 2004, S. 65) Die Klassifikation von verteilten Datenbanksystemen lässt sich für mobile verteilte Datenbanksysteme in der Dimension der Verteilung um den Faktor Mobilität erweitern. Abbildung 12 deutet an,

27 3 Theoretische Grundlagen 22 wie die Architektur des verteilten Datenbanksystems durch die oben definierten Kriterien beeinflusst wird. Verteilung Mobile Homogene DBMS Mobilität Mobile Multidatenbanksysteme Mobile Heterogene DBMS Mobile Heterogene Multidatenbanksysteme Autonomität verteilte Datenbanksysteme Zentralisierte Datenbanksysteme Heterogenität Abbildung 12: Dimensionen (mobiler) verteilter Datenbanksysteme Die konkrete Umsetzung eines Datenbanksystems fällt dabei natürlich immer als ein Kompromiss zwischen den Spannungsfeldern aus. Aus Abschnitt 2 ist bekannt, dass in erster Linie die Mobilität der Nutzer und damit einhergehend ihrer Geräte interessant ist. Darüber hinaus ist ein hoher Grad an Autonomie der Knoten gefragt, der es ihnen erlaubt auch ohne Kontakt zum globalen System im Sinne der in Abschnitt 3.1 vorgestellten Kommunikations- und Ausführungsautonomie Änderungen am Datenbestand vorzunehmen (s. auch Multi-Master-System Abschnitt 3.3). Während in Sachen Hard- und Software potentiell ein hoher Grad an Heterogenität der Knoten durch OpenInfRA unterstützt wird, kommt mit PostgreSQL lediglich ein Datenbanksystem zum Einsatz, auf dem das Projektdatenbankschema installiert ist. Das spricht in diesem Punkt sowohl für eine gewisse Homogenität als auch für eine geringe Design Autonomie. Allgemein lässt sich das System als ein mobiles Datenbanksystem einordnen für das im weiteren die möglichen Architekturen betrachtet werden sollen. 3.6 Architektur mobiler Datenbanksysteme Für mobile Datenbanksysteme bestehen zwei grundlegende Architekturen, welche als erweiterte Client-Server-Architektur und als Middleware-Architektur mit Replikati-