RDS operiert hinsichtlich der Management-Ebene deutlich näher an normalen EC2-Instanzen, als dies etwa der voll verwaltete Datenbank-Service DynamoDB tut. Daher erfor­dern Datenbank-Instanzen so wie jede physische Instal­lation eine regel­mäßige Wartung. Dazu zählen Updates für das Betriebs­system und die Daten­bank selbst.

Der wesentliche Unter­schied zu selbst installierten Datenbanken auf Basis von EC2-Instanzen ist, dass AWS bei RDS die Patches automatisch für die Kunden einspielt. Dies erfordert jedoch eine Downtime der Instanz. Solche Ausfallszeiten lassen sich jedoch durch die Verwen­dung von Deployments minimieren, die sich über mehrere Availability Zones erstrecken. Ferner kümmert sich AWS um automatische Backups.

DB-Instanz für OS-Updates offline

AWS führt in regel­mäßigen Abständen Wartungs­arbeiten an RDS-Ressourcen durch. Die Wartung umfasst in der Regel die Aktualisierung des zugrunde­liegenden Betriebs­systems (OS) der DB-Instance oder der Datenbank-Engine.

OS-Updates werden von den Herstellern meist wegen Sicherheits­problemen heraus­gegeben. Daher sollten sie stets so schnell wie möglich installiert werden. Wartungs­elemente erfordern jedoch, dass Amazon RDS die DB-Instance für kurze Zeit in den Offline-Betrieb versetzt.

Diese Wartungs­aufgaben erfolgen in unregel­mäßigen Abständen, meist einmal alle paar Monate und sollten selten mehr als einen Bruchteil Ihres Aktualisierungs­fensters in Anspruch nehmen.

Prüfung des Wartungsstatus

Man kann sich übrigens jederzeit anzeigen lassen, ob ein Wartungs-Update für eine ausgewählte DB-Instance verfügbar ist, indem man in der RDS-Konsole den Status in der Spalte Maintenance (nicht Status) prüft.

Hier steht entweder Available oder Required. Ist eine Wartung erforderlich, kann der Nutzer die Wartungs­elemente sofort anwenden, verschieben, ins nächste Wartungs­fenster legen oder die Wartung ignorieren.

Bei einer manuellen Wartung ist zu beachten, dass DB-Instanzen bei der Installation von Betriebs­system-Updates nicht automatisch gesichert werden. Daher sollten man bei außerplan­mäßigen Wartungen seine DB-Instances vorher sichern.

Wartungsfenster konfigurieren

Im Rahmen des definierten Wartungs­fensters hingegen erfolgt das Einspielen von Updates automatisch, sofern verfügbar. Die Funktion Maintenance Windowerlaubt wahlweise beim Erstellen der VM oder im Nachhinein, das gewünschte Wartungs­fenster in der RDS-Konsole zu konfigurieren.

Dazu markiert man die Instanz in der DB-Instanz­liste des RDS-Dashboards und klickt im Tab Details auf Modify. Hier scrollt man dann ganz ans Ende des Dialoges zum Abschnitt Maintenance.

Hier legt man den Wochentag und die Uhrzeit fest, wann Wartungs­aufgaben an der DB-Instanz durchgeführt werden sollen. Nutzer haben an dieser Stelle zusätzlich die Möglichkeit, das Einspielen von Minor-Updates der gewählten DB-Engine zu aktivieren.

Gründe für Downtime

Im Allgemeinen sind bei RDS mehrere Szenarien vorstellbar, die entweder eine Wartung (und damit verbunden eine mögliche kurze oder längere Offline-Phase der Datenbank) oder gar eine Downtime der kompletten DB-Instanz nach sich ziehen können.

Die folgenden Ausführungen gelten allgemein. Im Detail hängt es zudem vom Typ der DB-Engine (MySQL, SQL-Server) ab, welche Maßnahmen den Operational-Status Available  (Spalte Status) ändern. Die mögliche Stati finden sich in der RDS-Dokumentation.

Diese Tabelle zeigt nebenbei auch an, ob AWS dem Nutzer in Abhängigkeit des Status DB-Instanz und Speicher, nur Speicher oder weder DB-Instance noch Speicher in Rechnung stellt. Allerdings wird für jeden DB-Instance-Status stets die Sicherungs­nutzung berechnet.

Diese 7 Szenarien ändern den Betriebsstatus der DB-Instanz:

1. Wartung (Einspielen von OS-Patches, Einspielen von DB-Patches)
2. Sicherung / Backup
3. Upgrade der Datenbank-Version
4. Änderung der DB-Instanzklasse (vCPUs, Speicher)
5. Upgrade der DB-Instanz-Klasse (vertikales Skalieren)
6. Vergrößern des DB-Instanz-Storage (vertikales Skalieren des Storage)
7. Ändern des DB-Instanz-Storage-Typs (Performance / Durchsatz)

Backups erfolgen unabhängig vom Wartungsfenster

Sowohl Wartungs­aufgaben als auch Sicherungen können manuell oder automatisch erfolgen. Ein Wartungs­fenster hat allerdings nichts mit dem Backup-Intervall zu tun. Während die Datenbank für Wartungs­arbeiten in den Offline-Betrieb wechselt, passiert dies bei Backups nicht. Backups verlangsamen nur mitunter die Datenbank.

Übrigens besteht technisch gesehen kein Unterschied zwischen einer automatisierte Sicherung der DB-Instance und einem manuell erstellten Snapshot. Beim Backup erstellt RDS ebenfalls einen Snapshot für das Speicher­volume der DB-Instance, sodass die gesamte DB-Instance gesichert wird und nicht nur einzelne Datenbanken.

Sowohl Backups, als auch Snapshots werden in einer speziellen, dafür vorgesehenen „Partition“ in AWS S3 erstellt (Sicherungs­speicher). Der Nutzer muss dazu also nicht explizit ein Bucket anlegen. Die Sicherungen sind auch nicht über die S3-Konsole zugänglich. Lediglich die manuell erstellte RDS-Snapshots sind über die RDS-Konsole im Menü Snapshots sichtbar.

So ist es dem Nutzer jederzeit möglich, seine DB-Instanz von hier aus zu restaurieren und, falls gewünscht, bei der Gelegenheit eine andere Instanz­klasse oder einen anderen Speichertyp zu wählen bzw. das Speicher-Volume zu vergrößern.

Upgrades der Datenbank-Engine

Sobald Amazon RDS eine neue Version der Datenbank-Engine unterstützt, können Nutzer Ihre DB-Instanzen auf die neue Version aktualisieren, wobei AWS zwei Arten von Upgrades unterscheidet:

• Upgrades von Hauptversionen
• Upgrades von Nebenversionen (Minor version upgrade)

Wechsel der Instanzklasse

Zu Punkt 4 ist zu erwähnen, dass die DB-Instance-Klasse die Compute- und (Arbeitsspeicher)-Kapazität einer Instanz bestimmt. Amazon RDS unterstützt drei Arten von Instance-Klassen:

• Standard (M-Typen)
• Memory Optimized (R-Typen)
• Burstable Performance (T-Typen).

Beim Wechsel auf eine andere Instanze-Klasse der gleichen Familie z. B. mit mehr CPU-Kernen oder Threads pro Kern kommt es zu einem kurzen Ausfall der DB-Instance. Hierzu klickt man in der RDS-Konsole wieder auf Modify und wählt die gewünschte Instanz-Klasse. Der Status wechselt anschließend auf Modifying.

Man kann aber auch, wie in Punkt 5 angedeutet, auf eine komplett andere (größeren oder kleineren) Instanz-Klassen-Famile (M-, R-, T-Typ) wechseln. Das Vorgehen ist prinzipiell das Gleiche, allerdings weist der Modify-Dialog in der RDS-Konsole dann darauf hin, dass mit einer möglichen Downtime zu rechnen ist.

Alternativ kann man die vorhandene Instanz zuvor auf einen Snapshot sichern und dann einen Instance-Restore auf einen neuen Typ vornehmen. Dies führt in jedem Fall zu einer Downtime der DB-Instanz.

Skalierung des Instanz-Storage

Schließlich ist es noch möglich, auch das Instance-Storage zu vergrößern, falls die Speicher­kapazität der Instanz an ihre Grenzen stößt (6.), bzw. auf einen perfor­manteren Typ zu migrieren (7.). In der Regel verursacht die Storage-Skalierung keine Ausfallzeiten. Auch die Leistung des Servers verringert sich nicht.

Beim Ändern der Storage-Größe einer DB-Instance wechselt allerdings der Status der DB-Instance statt auf Modifying vorrüber­gehend  auf Storage-optimization. Dabei bleibt die DB-Instance voll funktionsfähig. Allerdings kann der Nutzer entweder sechs Stunden lang, bzw. während der DB-Instance-Status auf storage-optimization lautet, keine weiteren Speicher­modifi­kationen vornehmen, je nachdem, was länger dauert.

Stellt der Nutzer hingegen das Storage auf einen anderen (performanteren) Typ um, lässt sich die DB-Instance während der Migration zwar verwenden, es kommt aber während der Migration der Daten auf das neue Volume zu Leistungs­einschrän­kungen.

Die Dauer des Migrations­vorgangs hängt von mehreren Faktoren, wie der Auslastung der Datenbank, der Speichergröße, dem Speichertyp und der Menge an zur Verfügung gestellten IOPS (wenn vorhanden), ab. In der Regel dauert er einige Minuten, lediglich bei einer Migration zum oder vom Magnet­speicher kann es in manchen Fällen mehrere Tage dauern.