Linden Consulting.
DevOps

RDS Storage Full: Warum Ihre Datenbank keinen Speicherplatz mehr hat

2026-04-22 · 8 Min. Lesezeit

Um 3 Uhr morgens an einem Dienstag beginnt Ihre Anwendung, 500-Fehler zurückzugeben. Die Datenbank akzeptiert keine Schreibvorgänge mehr. Sie prüfen Ihre RDS-Instance und sehen in der Konsole: Der Speicher ist zu 100% ausgelastet. Jedes INSERT, UPDATE und sogar einige SELECT-Abfragen schlagen fehl, weil die Datenbank-Engine keine temporären Dateien, Transaktionsprotokolle oder Datenseiten schreiben kann.

Eine RDS-Instance, der der Speicherplatz ausgeht, ist einer der schwerwiegendsten Ausfälle, die Sie erleben können, weil er sofort, total und überraschend schwer schnell zu beheben ist. Anders als bei CPU- oder Speicherdruck, wo die Datenbank allmählich langsamer wird, verursacht ein volles Storage-Volume harte Fehler ohne graceful Degradation.

So diagnostizieren Sie, was Ihren Speicher verbraucht hat, beheben es sofort und stellen sicher, dass es nie wieder passiert.

Die Fehlermeldungen, die Sie sehen werden

Je nach Datenbank-Engine unterscheiden sich die Fehlermeldungen:

PostgreSQL:

ERROR: could not extend file "base/16384/12345": No space left on device
HINT: Check free disk space.
PANIC: could not write to file "pg_wal/000000010000000000000042": No space left on device

MySQL:

ERROR 1114 (HY000): The table 'my_table' is full
ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/MY1234aB' (Errcode: 28 - No space left on device)

Schritt 1: Bestätigen, dass der Speicher voll ist

Beginnen Sie mit der Prüfung der aktuellen Speicherzuordnung und -nutzung:

# Instance-Speicherdetails abrufen
aws rds describe-db-instances \
  --db-instance-identifier my-database \
  --query 'DBInstances[0].{
    AllocatedStorage: AllocatedStorage,
    MaxAllocatedStorage: MaxAllocatedStorage,
    StorageType: StorageType,
    Engine: Engine,
    EngineVersion: EngineVersion,
    DBInstanceStatus: DBInstanceStatus
  }'

Prüfen Sie dann CloudWatch für die FreeStorageSpace-Metrik:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=my-database \
  --start-time 2026-04-20T00:00:00Z \
  --end-time 2026-04-22T12:00:00Z \
  --period 3600 \
  --statistics Minimum \
  --output table

Wenn FreeStorageSpace auf null oder nahe null gefallen ist, haben Sie das Problem bestätigt. Schauen Sie sich den Trend der letzten Tage an — ist er allmählich gesunken oder plötzlich gefallen? Ein allmählicher Rückgang deutet auf Datenwachstum oder Log-Akkumulation hin. Ein plötzlicher Abfall deutet auf eine außer Kontrolle geratene Abfrage, einen Massendatenimport oder Transaktionslog-Bloat durch eine lang laufende Transaktion hin.

Ursache 1: Storage Auto-Scaling nicht aktiviert

Dies ist der häufigste Grund, warum RDS-Instances keinen Speicherplatz mehr haben: Auto-Scaling wurde nie aktiviert. Wenn Sie eine RDS-Instance erstellen, ist Storage Auto-Scaling standardmäßig nicht aktiviert. Sie geben eine anfängliche Zuordnung an (z.B. 100GB), und das ist alles, was Sie bekommen, es sei denn, Sie erhöhen manuell oder aktivieren Auto-Scaling.

Prüfen, ob Auto-Scaling aktiviert ist:

aws rds describe-db-instances \
  --db-instance-identifier my-database \
  --query 'DBInstances[0].MaxAllocatedStorage'

Wenn dies null oder denselben Wert wie AllocatedStorage zurückgibt, ist Auto-Scaling nicht aktiviert.

Sofort aktivieren:

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --max-allocated-storage 500 \
  --apply-immediately

Dies teilt RDS mit, dass der Speicher automatisch bis zu 500GB wachsen kann. RDS skaliert den Speicher, wenn der freie Speicherplatz unter 10% des zugeteilten Speichers fällt und der Niedrigspeicher-Zustand mindestens 5 Minuten anhält.

Wichtig: Storage Auto-Scaling erhöht nur den Speicher. Er schrumpft nie. Sobald Ihre Instance auf 300GB wächst, bleibt sie bei 300GB, selbst wenn Sie die meisten Daten löschen.

Ursache 2: Transaktionslog-Bloat

Lang laufende Transaktionen sind ein stiller Speicherkiller. Während eine Transaktion offen ist, muss die Datenbank alle Log-Einträge aufbewahren, die für ein Rollback benötigt werden. Auf einer stark genutzten Datenbank kann eine einzige Transaktion, die stundenlang läuft, Gigabytes an Log-Akkumulation verursachen.

PostgreSQL WAL-Akkumulation

PostgreSQL verwendet Write-Ahead-Logging (WAL). WAL-Dateien akkumulieren, wenn:

  • Eine lang laufende Transaktion das WAL-Recycling verhindert
  • Replication Slots hinterherhinken (der Slot behält WAL, bis das Replica aufholt)
  • wal_keep_size zu hoch eingestellt ist

Auf lang laufende Transaktionen prüfen:

SELECT pid, now() - xact_start AS duration, query, state
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND state != 'idle'
ORDER BY duration DESC
LIMIT 10;

Replication-Slot-Lag prüfen:

SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS slot_lag
FROM pg_replication_slots;

Wenn ein Replication Slot Gigabytes an Lag zeigt, verhindert dieser Slot die WAL-Bereinigung. Entweder das Replica reparieren oder den Slot löschen, wenn das Replica nicht mehr benötigt wird:

SELECT pg_drop_replication_slot('my_old_slot');

MySQL Binary-Log-Aufbewahrung

MySQL-RDS-Instances behalten Binary Logs für Replikation und Point-in-Time-Recovery. Standardmäßig werden Binary Logs basierend auf der binlog retention hours-Einstellung aufbewahrt.

Aktuelle Aufbewahrung prüfen:

CALL mysql.rds_show_configuration;

Binary-Log-Festplattennutzung prüfen:

SHOW BINARY LOGS;

Wenn Binary Logs erheblichen Speicherplatz verbrauchen, reduzieren Sie die Aufbewahrungsdauer:

CALL mysql.rds_set_configuration('binlog retention hours', 24);

Die Reduzierung von dem Standard (der bei manchen Konfigurationen bis zu 168 Stunden betragen kann) auf 24 Stunden kann erheblichen Speicherplatz freigeben.

Ursache 3: Wachstum des temporären Tablespace

Sowohl PostgreSQL als auch MySQL verwenden temporären Speicher für Sortierungen, Hash-Joins und andere Operationen, die den Arbeitsspeicher überschreiten. Eine schlecht optimierte Abfrage, die Millionen von Zeilen verarbeitet, kann Gigabytes an temporären Dateien erzeugen.

PostgreSQL — temporäre Dateinutzung prüfen:

SELECT datname, temp_files, pg_size_pretty(temp_bytes) AS temp_size
FROM pg_stat_database
WHERE temp_bytes > 0
ORDER BY temp_bytes DESC;

MySQL — temporäre Tabellennutzung prüfen:

SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';

Wenn Created_tmp_disk_tables ein hoher Prozentsatz von Created_tmp_tables ist, schreiben Abfragen große temporäre Tabellen auf die Festplatte. Identifizieren Sie die problematischen Abfragen:

SELECT query, tmp_disk_tables, tmp_tables
FROM performance_schema.events_statements_summary_by_digest
WHERE tmp_disk_tables > 0
ORDER BY tmp_disk_tables DESC
LIMIT 10;

Ursache 4: Tabellen-Bloat und Dead Tuples (PostgreSQL)

Die MVCC-Implementierung von PostgreSQL erzeugt Dead Tuples, wenn Zeilen aktualisiert oder gelöscht werden. Der VACUUM-Prozess gibt diesen Speicherplatz frei, aber wenn VACUUM hinterherhinkt (oder durch lang laufende Transaktionen blockiert wird), kann Table Bloat erheblichen Speicherplatz verbrauchen.

Auf Table Bloat prüfen:

SELECT schemaname, relname,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
  n_dead_tup,
  n_live_tup,
  ROUND(n_dead_tup::numeric / NULLIF(n_live_tup, 0) * 100, 2) AS dead_pct,
  last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 20;

Wenn dead_pct für große Tabellen über 20% liegt, kommt VACUUM nicht hinterher. Sie können ein manuelles VACUUM auf den am stärksten aufgeblähten Tabellen auslösen:

VACUUM (VERBOSE) my_large_table;

Für extremen Bloat erwägen Sie VACUUM FULL, aber beachten Sie, dass dies die Tabelle sperrt und komplett neu schreibt — nicht geeignet für die Produktion während Spitzenzeiten.

Ursache 5: Verwechslung von Snapshot-Speicher

Ein häufiges Missverständnis: RDS-Snapshots verbrauchen nicht den zugeteilten Speicher Ihrer Instance. Snapshot-Speicher ist separat und wird anders abgerechnet. Es gibt jedoch einen verwandten Fallstrick: Wenn Sie aus einem Snapshot wiederherstellen, entspricht der zugeteilte Speicher der wiederhergestellten Instance dem Snapshot, nicht dem Auto-Scaling, das nach dem Snapshot stattfand.

Wenn Ihre ursprüngliche Instance von 100GB auf 300GB auto-skaliert wurde, aber Ihr Snapshot bei 100GB erstellt wurde, wird die wiederhergestellte Instance nur 100GB zugeteilten Speicher haben.

# Snapshot-Größe vor der Wiederherstellung prüfen
aws rds describe-db-snapshots \
  --db-snapshot-identifier my-snapshot \
  --query 'DBSnapshots[0].{AllocatedStorage: AllocatedStorage, SnapshotCreateTime: SnapshotCreateTime}'

Sofortige Wiederherstellung: Speicher erhöhen

Wenn Ihre Instance derzeit keinen Speicherplatz hat, ist die schnellste Lösung die Erhöhung des zugeteilten Speichers:

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --allocated-storage 200 \
  --apply-immediately

Wichtige Einschränkungen:

  • Die Speichermodifikation kann 10-30 Minuten dauern. Während dieser Zeit bleibt die Instance verfügbar, kann aber degradierte IOPS-Leistung haben.
  • Sie können den Speicher nur erhöhen, nie verringern.
  • Nach einer Speichermodifikation müssen Sie mindestens 6 Stunden warten, bevor Sie den Speicher erneut ändern können. Planen Sie Ihre Erhöhung großzügig.

Überwachen Sie den Modifikationsfortschritt:

aws rds describe-db-instances \
  --db-instance-identifier my-database \
  --query 'DBInstances[0].{
    Status: DBInstanceStatus,
    PendingStorage: PendingModifiedValues.AllocatedStorage,
    CurrentStorage: AllocatedStorage
  }'

IOPS-Auswirkungen bei vollem Speicher

Wenn ein RDS-Volume voll ist, gehen die Auswirkungen über Schreibfehler hinaus. Bei gp2-Volumes ist Ihre Baseline-IOPS direkt an die Speichergröße gekoppelt (3 IOPS pro GB). Ein 100GB gp2-Volume bietet nur 300 Baseline-IOPS. Wenn das Volume voll ist, werden diese 300 IOPS durch Wiederholungsversuche und interne Operationen verbraucht.

Bei gp3-Volumes sind IOPS unabhängig vom Speicher konfigurierbar, aber ein volles Volume verursacht trotzdem Schreibfehler.

# Aktuelle IOPS-Konfiguration prüfen
aws rds describe-db-instances \
  --db-instance-identifier my-database \
  --query 'DBInstances[0].{
    StorageType: StorageType,
    Iops: Iops,
    AllocatedStorage: AllocatedStorage
  }'

Wenn Sie gp2 mit einem kleinen Volume verwenden, gibt Ihnen die Migration auf gp3 3000 Baseline-IOPS unabhängig von der Volume-Größe.

Prävention: Monitoring und Alarme

Nach der Wiederherstellung von einem Storage-Full-Event implementieren Sie diese Sicherheitsmaßnahmen:

CloudWatch-Alarm für niedrigen Speicher

aws cloudwatch put-metric-alarm \
  --alarm-name "rds-my-database-low-storage" \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=my-database \
  --statistic Minimum \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 5368709120 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789:alerts \
  --alarm-description "Alarm wenn RDS freier Speicher unter 5GB faellt"

Mehrere Schwellenwerte setzen

Erstellen Sie Alarme bei 20%, 10% und 5% des zugeteilten Speichers. Der 20%-Alarm gibt Ihnen Zeit zur Untersuchung. Der 10%-Alarm bedeutet, dass Sie handeln müssen. Der 5%-Alarm bedeutet, dass ein Ausfall bevorsteht.

Enhanced Monitoring aktivieren

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --monitoring-interval 60 \
  --monitoring-role-arn arn:aws:iam::123456789:role/rds-monitoring-role \
  --apply-immediately

Enhanced Monitoring zeigt OS-Level-Metriken einschließlich Disk-I/O, was Ihnen hilft zu verstehen, ob der Speicherdruck von Datenwachstum, temporären Dateien oder Transaktionsprotokollen kommt.

Regelmäßige Wartung

  • Planen Sie wöchentliche Überprüfungen von Tabellengrößen und Bloat-Metriken
  • Richten Sie automatisierte Bereinigung alter Daten über Datenbank-Level-Partitionierung ein
  • Überwachen Sie den Replication-Slot-Lag, wenn Sie logische Replikation verwenden
  • Überprüfen Sie Binary-Log-Aufbewahrungseinstellungen vierteljährlich

Wenn Speicherprobleme tiefere Probleme signalisieren

Wiederholter Speicherdruck deutet oft auf architektonische Probleme hin: Tabellen, die ohne Begrenzung wachsen, weil es keine Datenlebenszyklusrichtlinie gibt, Abfragen, die übermäßig temporäre Dateien erzeugen, weil ihnen geeignete Indizes fehlen, oder Replikations-Setups, die still und leise zurückfallen.

Wir helfen Teams, Datenbankarchitekturen zu entwerfen, die vorhersehbar skalieren, korrektes Monitoring zu implementieren und Datenlebenszyklusrichtlinien aufzubauen, die das Speicherwachstum handhabbar halten. Kontaktieren Sie uns für eine kostenlose AWS-Beratung und lassen Sie uns Ihr Datenbank-Setup überprüfen, bevor der nächste Speichernotfall eintritt.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen