Hochverfügbarkeit für die DB: Active/Standby oder Cluster?
Geschäftskritische Applikationen müssen eine hohe Verfügbarkeit aufweisen. Bei vielen Anwendungen spielen Datenbanken eine zentrale Rolle. In diesem Blog-Beitrag erfahren Sie, welche Möglichkeiten es gibt, Datenbanken hochverfügbar zu machen und welche wann Sinn macht.
Der DB-Cluster
Im Clusterbetrieb teilen sich die Datenbankserver einen gemeinsamen Speicher. Selbstverständlich muss dieser Speicher redundant ausgelegt werden. In der Regel wird ein geeignetes und produktespezifisches RAID verwendet. Durch den gemeinsamen Speicher kann die DB sozusagen ohne Unterbruch und automatisiert beim Ausfall eines Servers von einem anderen Server übernommen werden. Die Last der Abfragen kann im Normalbetrieb verteilt werden. Dummerweise sind aber die Daten bei einem Benutzer- oder Applikationsfehler auf allen beteiligten Servern betroffen. Was nützt einem demzufolge ein hochverfügbarer Cluster, wenn durch einen Applikations- oder Bedienungsfehler sämtliche Daten gelöscht werden können? In einem solchen Fall müssen die Daten meistens von einem Backup zurückgespielt werden, was je nach Datenmenge Stunden bis Tage dauern kann. In dieser Zeit steht der Cluster zumindest für die betroffenen Daten nicht zur Verfügung.
Der Aktiv-/Standbybetrieb
Im Aktiv-/Standbybetrieb hat jeder Server seinen eigenen Datenspeicher. In der Regel wird dieser durch eine geeignete RAID Konfiguration ebenfalls redundant ausgelegt. Die Server in diesem Verbund synchronisieren sich über die Transaktions-Logfiles. Das wichtigste an dieser Konfiguration ist das Übertragen dieser Logfiles vom aktiven Server auf den passiven Server. Im Falle einer asynchronen Übertragung muss definiert werden in welchem Zeitabstand eine Übermittlung stattfinden soll, wodurch wiederum der Zeitraum für den maximalen Datenverlust definiert wird. Werden die Transaktions-Informationen synchron übertragen können je nach Distanz zwischen dem aktiven und dem Standby-Server verlängerte Wartezeiten bei Transaktionen entstehen. Um den Aufwand bei einem Benutzer- oder Applikationsfehler möglichst gering zu halten kann die Nachlaufzeit auf dem Standby-Server entsprechend konfiguriert werden. Das heisst, dass sich die Transaktions-Informationen wohl auf dem Standby-Server befinden diese aber noch nicht eingelesen wurden. Sollten nun aus Versehen auf dem aktiven System Daten gelöscht worden sein, kann der Service auf das Standby-System gewechselt werden, wobei dort die Transaktionen nur bis unmittelbar vor dem aufgetretenen Fehler angewendet werden. Das Wechseln des Services auf das andere System erfolgt manuell.
Warum der Aktiv-/Standbybetrieb besser ist
In den meisten Fällen empfehlen wir den Betrieb von hochverfügbaren Datenbanken als Aktiv-/Standby Konfiguration. Die Komplexität hält sich gegenüber dem Clusterbetrieb in Grenzen und erfahrungsgemäss ist die Auftretenswahrscheinlichkeit von Benutzer- und Applikationsfehlern höher als von Hardwaredefekten.
Eine Fortsetzung zum Thema folgt. Wir müssen uns noch mit der virtuellen IP befassen und damit, wie sich eine Applikation verhalten muss, wenn „plötzlich“ ein anderer DB Server antwortet.