Robotron*Standby - Desaster Recovery, aber schnell
Einleitung
Wenn wir von Datenbankbetrieb sprechen, gehört eine den Anforderungen entsprechende Backupstrategie natürlich als wesentlicher Bestandteil dazu. Maßgeblich für diese Strategie ist die RPO, Recovery Point Objective, also der Zeitpunkt, zu dem die Datenbank wiederhergestellt werden können soll. Daraus ergibt sich, wie lange Backups aufgehoben werden müssen. Allerdings ist der häufigste RPO der aktuelle Zeitpunkt. Wenn ein Datenbanksystem ausfällt und ein Restore benötigt wird, um es wieder zur Verfügung zu stellen, dann will man narmalerweise auch einen möglichst aktuellen Stand wiederherstellen. Hier kommt die RTO, Recovery Time Objective, die Zeit zum Wiederherstellen, ins Spiel. Je größer die Datenbank war, um so länger wird das Restore benötigen. Diese Zeit hat man oftmals nicht.
Die Lösung für dieses Problem sind Standby-Systeme. Es gibt also ein unabhängiges Zweitsystem bestehend aus eigenem Server und eigenem Storage, das eine Kopie des Primärsystems darstellt und laufend die Aktivitäten auf dem Primärsystem nachspielt. Im Desasterfall kann dieses Standbysystem dann einfach in Betrieb genommen werden. Die RTO liegt also im Minutenbereich.
In der Enterprise Edition der Oracle Datenbank gibt es dafür Dataguard. Dabei wird eine Standbydatenbank durch ein permanent laufendes Recovery mit den Redo-Informationen der Primärdatenbank auf dem aktuellen Stand gehalten.
Was ist mit der Standard Edition 2
Für die Standard Edition 2 (SE2) gibt es eine solche Lösung leider nicht. Der Bedarf dafür ist natürlich trotzdem vorhanden. Daher haben wir mit robotron*Standby eine Möglichkeit geschaffen, auch mit der SE2 Standbydatenbanken realisieren zu können. Dabei werden in regelmäßigen Abständen die Transaktionslogs zur Standbydatenbank transportiert und dort eingespielt. Das bedeutet, dass im Desasterfall nur ein minimaler Datenverlust auftritt, der vom Aktualisierungsintervall abhängt.
robotron*Standby automatisiert den kompletten Prozess analog zu Dataguard, organisiert den Transport der Transaktionslog, führt das Recovery der Standbydatenbank durch und handhabt geplante und ungeplante Rollenwechsel.
Minimierung geplanter Downtimes
Nicht nur für ungeplante Ausfälle bietet robotron*Standby eine schnelle Wiederinbetriebnahme der Datenbanken. Auch und gerade geplante Downtimes wie z.B. zum Patchen eines Servers können damit extrem verkürzt werden. Denn es ist genau wie bei Dataguard auch möglich, die Rollen der Datenbanken zu tauschen, ganz ohne Datenverlust. Das bedeutet, die Standbydatenbank wird zur Primärdatenbank und umgekehrt. Die Umschaltzeit liegt dabei im einstelligen Minutenbereich. Der Server, auf dem gerade nur Standbydatenbanken laufen, kann dann ganz ohne Einfluss auf die Verfügbarkeit mit den aktuellsten Patches versorgt werden. Ein nicht zu unterschätzender Vorteil für die Verfügbarkeit und eine einfache Lösung, die Systeme auf dem aktuellen Sicherheitsstand zu halten.
Funktionsumfang
Im Folgenden eine Liste der Funktionalitäten von robotron*Standby:
- Unterstützung von Linux und Windows
- vollautomatische Aktualisierung der Standbydatenbanken
- geplante Umschaltung ohne Datenverlust (graceful switchover)
- ungeplante Umschaltung als Desaster Recovery (failover)
- Recovery der Standbydatenbank über Lücken in den Archivelogs hinweg
- volle Unterstützung der Multitenant Architektur
- mehrere Standbydatenbanken pro Primärdatenbank möglich
- verschlüsselte und optional komprimierte Übertragung der Transaktionslogs
- Neuerstellung einer Standbydatenbank (reinstate)
- Bash-completion unter Linux
- Browserbasiertes Frontend
Beispielkonfiguration
Die folgenden beiden Videos zeigen kurz die Erstellung einer Konfiguration sowie das Erstellen und erstmalige Aktualisieren einer Standbydatenbank.
Kommentare
Keine Kommentare