9.5 Katastrophen-Recovery

9.5.2 Commit-Behandlung

Eine wesentliche Entwurfsentscheidung bei der Realisierung eines solchen Ansatzes betrifft die Festlegung, ob die Änderungen einer Transaktion sowohl im Primär- als im Backup-System zu protokollieren sind, bevor ein Commit möglich ist. Diese Festlegung führt zur Unterscheidung von 1-sicheren (1-safe) und 2-sicheren (2-safe) Transaktionen [MTO93]. Für 2-sichere Transaktionen ist durch ein verteiltes Commit-Protokoll zwischen Primär- und Backup-System zu gewährleisten, daß die Änderungen einer Transaktion an beiden Systemen gesichert sind, bevor die Commit-Entscheidung getroffen wird[41]. Für 1-sichere Transaktionen erfolgt dagegen das Commit bereits nach Sicherung der Änderungen im Primärsystem; die Übertragung der Log-Daten an das Backup-System geschieht asynchron. Der Vorteil 2-sicherer Transaktionen liegt darin, daß auch im Katastrophenfall keine Änderungen verlorengehen und die DB-Kopie auf den aktuellsten Zustand gebracht werden kann. Andererseits ergeben sich signifikante Leistungseinbußen, da die Antwortzeit sich um die Übertragungszeit für die Log-Daten sowie die Schreibverzögerung im Backup-System erhöht. Weiterhin ist der Ansatz von der ständigen Verfügbarkeit des Backup-Systems abhängig, so daß sich ohne weitere Vorkehrungen die Verfügbarkeit sogar reduzieren kann. Zur Vermeidung dieser Nachteile unterstützen existierende Systeme eine asynchrone Aktualisierung der Bakkup-Kopie. Der Verlust einiger weniger Transaktionen im Katastrophenfall wird dabei in Kauf genommen.

Wünschenswert wäre ein hybrider Ansatz zur Unterstützung von 1- und 2-sicheren Transaktionen. Damit könnte für die Mehrzahl der Transaktionen eine effiziente asynchrone Übertragung der Log-Daten vorgenommen werden. "Wichtige" Transaktionen, z.B. Banktransaktionen mit hohem Geldumsatz, könnten dagegen als 2-sicher eingestuft werden, um ihren Verlust zu vermeiden. Bei der Realisierung eines solchen gemischten Ansatzes ist zu beachten, daß im Primärsystem Abhängigkeiten von 2-sicheren Transaktionen zu zuvor beendeten 1-sicheren Transaktionen bestehen können. Diese Abhängigkeiten müssen auch im Backup-System beachtet werden, um die Rekonstruktion eines konsistenten DB-Zustands zu ermöglichen.

Beispiel 9-6

Im Primärsystem habe Transaktion T2 von Transaktion T1 geänderte Objekte gelesen und für eigene Änderungen verwendet, so daß die Serialisierungsreihenfolge T1 < T2 besteht. Wenn T1 1-sicher, T2 dagegen 2-sicher ist, ist es aufgrund der verzögerten Übertragung der Log-Daten für 1-sichere Transaktionen möglich, daß die Log-Daten von T1 erst nach denen von T2 im Backup-System eintreffen. Probleme gibt es, falls das Primärsystem ausfällt, nachdem die Log-Daten von T2 im Backup-System gesichert sind, jedoch bevor die Log-Daten von T1 abgeschickt wurden. In diesem Fall würde die alleinige Anwendung der Änderungen von T2 im Backup-System einen inkonsistenten DB-Zustand erzeugen.

Die Lösung dieses Problems erfordert, daß die Log-Daten von 1-sicheren Transaktionen, die im Primärsystem vor einer 2-sicheren Transaktion beendet wurden, im Backup-System gesichert sind, bevor das Commit der 2-sicheren Transaktion erfolgt [MTO93]. Dies ist einfach realisierbar, wenn alle Log-Daten innerhalb eines "Log-Stroms" übertragen werden[42]. In diesem Fall sind die Log-Daten im Backup-System lediglich in der gleichen Reihenfolge anzuwenden, wie sie im Primärsystem generiert wurden.

Liegt am Primärsystem ein Mehrrechner-DBS vor, dann verlangt die Verwendung eines einzigen Log-Stroms jedoch das Mischen der Log-Daten vor der Übertragung, was einen hohen Zusatzaufwand einführen kann (der im Falle von Tandems RDF in Kauf genommen wird[43]). Für Shared-Nothing besteht die Alternative, daß jeder Rechner die Log-Daten seiner DB-Partition in einem eigenen Log-Strom an das Backup-System sendet, wobei dort dann ebenfalls mehrere Log-Dateien geführt werden. Der Vorteil dieses Ansatzes ist zum einen, daß das Mischen der Log-Daten und damit ein potentieller Engpaß entfällt. Zudem kann eine höhere Übertragungsbandbreite zwischen Primär- und Backup-System genutzt werden. Ein Problem bei Verwendung mehrerer Log-Ströme ist jedoch, daß es im Backup-System aufgrund der asynchronen Log-Übertragung nicht ohne weiteres möglich ist, einen konsistenten DB-Zustand zu erzeugen, da die Log-Informationen zu den einzelnen DB-Partitionen i.a. einen unterschiedlichen Änderungsstand reflektieren. Die Lösung dieses Problems erfordert zusätzliche Synchronisierungsmaßnahmen im Backup-System; Algorithmen dazu werden in [GPH90] vorgestellt.

[41] Hierzu ist kein vollständiges Zwei-Phasen-Commit-Protokoll erforderlich. Es genügt die synchrone Übertragung der Log-Daten in der ersten Commit-Phase [GR93], so daß lediglich zwei zusätzliche Nachrichten (sowie eine Log-E/A) anfallen.
[42] Hierzu können die Log-Daten im Primärsystem in einem Puffer gesammelt werden, der dann übertragen wird, wenn er gefüllt ist oder das Commit einer 2-sicheren Transaktion ansteht. Damit werden i.a. Log-Daten mehrerer Transaktionen gebündelt übertragen.
[43] Im Falle eines Mehrrechner-DBS vom Typ "Shared Disk" (DB-Sharing) ist ein solches Mischen lokaler Log-Daten ohnehin erforderlich (s. Kap. 13.3.4).