9.5 Katastrophen-Recovery
9.5.1 Systemstruktur
Replizierte Datenbanken bieten hier natürlich eine Lösung, wenn die an einem Rechner (bzw. Rechenzentrum) vorliegenden Daten vollständig an anderen, geographisch verteilten Knoten repliziert sind. Dieser allgemeine Ansatz wird jedoch derzeit für OLTP-Anwendungen mit hohen Leistungs- und Verfügbarkeitsanforderungen nicht verfolgt, da die aufwendige Aktualisierung der Replikate signifikante Leistungseinbußen verursachen kann[39]. Stattdessen strebt man i.a. eine Lösung mit einer begrenzten Form von Replikation an, bei der eine vollständige Kopie der Datenbank an einem geographisch entfernten Backup-Rechenzentrum geführt wird, mit der im Katastrophenfall die Verarbeitung fortgesetzt werden kann. Ein solcher Ansatz wird bereits in kommerziellen Produkten wie Tandems RDF (Remote Data Facility) [Ly90], IBMs RSR (Remote Site Recovery) für IMS, Sybase (Replication Server) sowie Informix (Data Replication Server) unterstützt. Daneben befaßten sich mehrere konzeptionelle Arbeiten mit der Realisierung einer derartigen Katastrophen-Recovery [GPH90, BT90, KHGP91, MTO93, GR93].
Abb. 9-3: Systemkonfigurationen zur Katastrophen-Recovery [GR93]
Die in diesen Ansätzen unterstellte Systemkonfiguration ist stark vereinfacht in Abb. 9-3a dargestellt. Im Normalbetrieb findet dabei die gesamte DB-Verarbeitung im Primärsystem (Primary) statt, d.h. einem Rechenzentrum mit einem zentralisierten DBS bzw. lokal verteilten Mehrrechner-DBS. Das geographisch entfernte Backup-System ist passiv; es wird nur im Fehlerfall genutzt. Sämtliche Terminals sind mit beiden Rechenzentren verbunden. Neben einer Kopie der Datenbank werden im Backup-System auch Kontrollinformationen zu den offenen Benutzer-Dialogen oder Sessions geführt, damit im Fehlerfall ein schnelles Umschalten der Verbindungen möglich wird. Sämtliche Änderungen des Primärsystems werden unmittelbar an das Backup-System übertragen, so daß die DB-Kopie immer auf dem aktuellen Stand gehalten werden kann. Hierzu werden die Log-Daten vom Primärsystem zum Backup-System übertragen, wobei die Log-Daten im Backup-System nochmals gesichert und auf die DB-Kopie angewendet werden. Dieser Ansatz hat den Vorteil, daß im Primärsystem ein geringer Zusatzaufwand anfällt, da dort die Log-Daten ohnehin erstellt werden. Im Backup-System kann die Aktualisierung der Datenbank durch Anwendung von Log-Daten mit bekannten Recovery-Konzepten und mit vergleichsweise geringem CPU-Aufwand erfolgen.
Nach Ausfall des Primärsystems veranlaßt der Systemverwalter ein Umschalten auf das Backup-System, wo die Verarbeitung typischerweise nach wenigen Sekunden fortgeführt werden kann[40]. Die Verlagerung der DB-Verarbeitung ins Backup-System kann auch für geplante Unterbrechungen im Primärsystem genutzt werden, etwa zur Hardware-Aufrüstung oder Installation neuer Software-Versionen (z.B. für Betriebssystem oder DBS). Weiterhin können Dienstprogramme wie die Erzeugung einer Archivkopie im Backup-System ausgeführt werden und damit das Primärsystem entlasten. Schließlich können auch Lesetransaktionen (z.B. Ad-hoc-Anfragen), die keine aktuelle DB-Sicht benötigen, im Backup-System bearbeitet werden.
Abb. 9-3b zeigt eine erweiterte Systemkonfiguration, bei der beide Rechenzentren im Normalbetrieb genutzt werden können. Hierzu wird eine Partitionierung von Datenbank und Anwendungen in zwei Teilsysteme vorgenommen, wobei Transaktionen aus Leistungsgründen in jedem Teilsystem weitgehend lokal ausführbar sein sollten. Die beiden Primärsysteme laufen in verschiedenen Rechenzentren und werden durch ein eigenes Backup-System im jeweils anderen Rechenzentrum gegenüber Katastrophen gesichert. Eine solche Konfigurierung wird von einigen der genannten Implementierungen unterstützt, z.B. Tandems RDF.
[39] Daneben gibt es noch eine Reihe weiterer Gründe, die gegen ortsverteilte Mehrrechner-DBS sprechen (Kap. 3.1).
[40] Eine automatische Umschaltung zwischen Primär- und Backup-System ist i.a. nicht möglich/sinnvoll, da das System z.B. nicht zwischen einem tatsächlichen Ausfall des Primärsystems und einem Ausfall im Kommunikationssystem unterscheiden kann [Ly90, GR93].