Weniger Daten, dieselbe Speicherrechnung: RDS behält die große Zuteilung

Zusammenfassung

• Bei einer RDS-Datenbankinstanz lässt sich bereits zugeteilter Speicher nicht am selben Objekt verkleinern. Sinkende Belegung lässt den Preis dieser bereitgestellten Kapazität deshalb bestehen.
• Eine unterstützte Blue/Green-Bereitstellung kann eine kleinere Produktionsumgebung schaffen. Replikation, Umschaltung und die Aufbewahrung der bisherigen Datenbank machen daraus ein eigenes Sparprojekt.

Der aufgeräumte Schrank bleibt gemietet

Ein leerer Datenbankspeicher hat einen bemerkenswerten Charakterzug: Er kann betrieblich beruhigend und finanziell lästig zugleich sein. Nach einer Bereinigung zeigt die Überwachung wieder reichlich freien Platz. Die Rechnung für den bereitgestellten Platz hat davon noch nichts erfahren.

Für RDS for MySQL beschreibt AWS den Speicherpreis als Entgelt für die bereitgestellte Kapazität. Änderungen dieser Kapazität innerhalb eines Monats werden anteilig berücksichtigt. Eine kleinere Datenmenge ändert aber zunächst nur die Belegung. Selbst wenn die Bereinigung tatsächlich Dateisystemplatz freigibt, bleibt die Zuteilung bestehen. Wer eine Wohnung ausmistet, hat damit den Mietvertrag nicht verkleinert.

Die Autoscaling-Dokumentation erklärt die Richtung eindeutig: Die Funktion erweitert den Speicher einer DB-Instanz; sie reduziert ihn nicht. Auch eine manuelle Änderung derselben Instanz bietet keinen Rückweg zu einer kleineren Zuteilung. Das Abschalten der Automatik beendet künftige automatische Erweiterungen, beseitigt aber keine bereits vorhandene Kapazität.

Die Automatik erfüllt dabei einen vernünftigen Zweck. Eine volle Datenbank kann den Betrieb beeinträchtigen. Rechtzeitig zusätzlichen Platz bereitzustellen, erspart dem Team einen Eingriff unter Zeitdruck. Der wirtschaftliche Haken entsteht später: Der Mechanismus, der den Engpass beseitigt, erledigt nicht automatisch die anschließende Kostenkorrektur. Eine nützliche Rettungsmaßnahme wird zur neuen Normalgröße.

Die kleinere Datenbank steht neben der großen

AWS bietet einen Weg nach unten an. Für geeignete Datenbank-Engines lässt sich eine Blue/Green-Bereitstellung mit weniger Speicher in der grünen Umgebung anlegen. Diese zweite Umgebung übernimmt später die Produktion. Die bestehende Instanz schrumpft dabei nicht; eine andere tritt an ihre Stelle. Alternativ beschreibt AWS eine neue, kleinere Instanz mit manueller Datenmigration und Wechsel der Endpunkte.

Die Anleitung zur Erstellung verlangt bei einer Speicherreduktion mindestens 20 Prozent Platz über der gegenwärtigen Nutzung. Ein reines Rechenbeispiel macht den Unterschied sichtbar: 500 GiB zugeteilt, zur Hälfte genutzt, ergeben 250 GiB Nutzung und rechnerisch 300 GiB Mindestziel. Das ist die Größenrechnung vor der Prüfung der konkreten Konfiguration. Weiteres Wachstum während des Umzugs braucht zusätzlichen Spielraum.

Mit einem so berechneten Ziel ist die Arbeit noch nicht fertig. Die Speicherreduktion löst eine Änderung der Speicherkonfiguration aus. Diese Arbeit beansprucht Ein- und Ausgabe und kann die Erstellung verlängern. Der Kunde bestellt folglich keinen Rabattknopf, sondern eine zweite Umgebung, deren Daten und Verhalten vor dem Wechsel stimmen müssen.

Für Blue/Green gelten Engine- und Versionsgrenzen. Hier geht es um eine geeignete RDS-for-MySQL-Instanz. Die Methode steht auch für bestimmte MariaDB- und PostgreSQL-Versionen zur Verfügung; Db2, SQL Server und Oracle gehören nicht zu dieser Unterstützung. Aus einer möglichen MySQL-Verkleinerung wird damit kein allgemeines Versprechen für jede RDS-Datenbank.

Der alte Name zieht um, die alte Geschichte nicht

Der kontrollierte Wechsel prüft unter anderem den Zustand der Replikation und ihren Rückstand. RDS hält neue Schreibvorgänge an, trennt Verbindungen, wartet auf den Datenabgleich und benennt Instanzen und Endpunkte um. Anschließend übernimmt die grüne Umgebung die Produktionsarbeit. Ein bloßer manueller Promote-Klick auf die grüne Instanz wäre ein anderer Vorgang und würde die Blue/Green-Replikation unterbrechen.

Die vertraute Adresse kann danach auf die neue Produktion zeigen. Hinter ihr bleibt jedoch die Identität der neuen Ressource bestehen. Besonders teuer kann es werden, diese Unterscheidung in der Wiederherstellungsplanung zu übersehen. Laut den RDS-Beschränkungen übernimmt die neue Produktionsinstanz nicht die Historie für zeitpunktgenaue Wiederherstellungen der alten. Ihre eigene Historie beginnt mit der Erstellung der grünen Umgebung. Die alte blaue Instanz bewahrt ihre bisherige Historie und automatischen Sicherungen bis zu ihrer Löschung.

Wer diese ältere Wiederherstellungsmöglichkeit noch braucht, muss sie in den Umzug einkalkulieren. AWS weist ausdrücklich auf die weiterlaufenden Rechen- und Speicherkosten einer behaltenen blauen Instanz hin. Die neue kleinere Produktion kann also bereits funktionieren, während die Gesamtkosten wegen der Übergangsphase noch höher liegen.

Auch das Löschen der Blue/Green-Bereitstellung räumt die blaue Umgebung nicht automatisch ab. Verwaltungseintrag und bezahlte Datenbank sind verschiedene Dinge. Und wer eine MySQL-Instanz lediglich stoppt, bezahlt laut Preisübersicht weiterhin den Speicher.

Der Vergleich braucht deshalb zwei Zeithorizonte: die kleinere dauerhafte Kapazität und den Aufwand, sie sicher zu erreichen. Ohne tatsächliche Preise, Laufzeiten und Wiederherstellungsbedarf lässt sich kein seriöser Netto-Sparbetrag nennen. Der Entscheidungsfehler ist auch ohne diesen Betrag sichtbar: Eine gesunkene Belegung als erledigte Kostensenkung zu verbuchen, überspringt den gesamten Umzug.