Warum habe ich in Amazon RDS für PostgreSQL die Fehlermeldung „No space left on device“ oder „DiskFull“ erhalten?

Behebung

Hinweis: Wenn deine Workload vorhersehbar ist, aktiviere die automatische Speicherskalierung für deine Instance. Mit der automatischen Speicherskalierung skaliert Amazon RDS den Speicher automatisch, wenn der freie Datenbankspeicher knapp wird.

Um den Speicherplatz zu überwachen, überprüfe die Amazon CloudWatch-Metrik für FreeStorageSpace. Stelle einen CloudWatch-Alarm für freien Speicherplatz ein, um eine Benachrichtigung zu erhalten, wenn der Speicherplatz knapp wird. Wenn du einen Alarm erhältst, suche nach den folgenden Ressourcen, die Amazon RDS-DB-Instance-Speicher verwenden:

• Temporäre Tabellen oder Dateien, die durch PostgreSQL-Transaktionen erstellt werden
• Datendateien
• Write-Ahead-Protokolle (WAL)
• Replikationsslots
• DB-Protokolle wie Fehlerdateien, die zu lange aufbewahrt werden
• Andere DB- oder Linux-Dateien, die den konsistenten Status der RDS-DB-Instance unterstützen

Wenn die DB-Instance mehr als den erwarteten Speicherplatz verbraucht, ergreife die folgenden Maßnahmen zur Fehlerbehebung.

Überprüfung der Größe der DB-Protokolldateien

Standardmäßig haben Amazon RDS for PostgreSQL-Fehlerprotokolldateien einen Aufbewahrungswert von 4.320 Minuten (drei Tagen). Große Protokolldateien können aufgrund höherer Workloads oder übermäßiger Protokollierung mehr Speicherplatz beanspruchen. Um den Aufbewahrungszeitraum für Systemprotokolle zu ändern, verwende den Parameter rds.log_retention_period in der DB-Parametergruppe, die der DB-Instance zugeordnet ist. Wenn du den Wert beispielsweise auf 1440 festlegst, speichert Amazon RDS die Protokolle einen Tag lang. Weitere Informationen findest du unter RDS für PostgreSQL-Datenbankprotokolldateien.

Um die übermäßige Protokollierung zu reduzieren, ändere die Fehlerberichts- und Protokollierungsparameter in der DB-Parametergruppe. Diese Aktion führt zu einer verringerten Größe der Protokolldatei. Weitere Informationen findest du unter 19.8 Error reporting and logging (19.8 Fehlerberichte und -protokollierung) auf der PostgreSQL-Website.

Suche nach temporären Dateien

Temporäre Dateien sind Dateien, die Amazon RDS in jeder Backend- oder Sitzungsverbindung speichert. Amazon RDS verwendet diese Dateien als Ressourcenpool. Führe den folgenden Befehl aus, um die Statistiken für temporäre Dateien zu überprüfen:

psql=> SELECT datname, temp_files AS "Temporary files",temp_bytes AS "Size of temporary files" FROM pg_stat_database ;

Wichtig: Die Spalten temp_files und temp_bytes in der Ansicht pg_stat_database erfassen aggregierte Statistiken. Amazon RDS setzt diese Zähler erst nach einem sofortigen Herunterfahren, einem Serverabsturz oder einer zeitpunktbezogenen Wiederherstellung (PITR) zurück. Aus diesem Grund empfiehlt es sich, den Anstieg der Anzahl und Größe dieser Dateien zu überwachen und nicht nur die Ausgabe zu überprüfen.

Amazon RDS erstellt temporäre Dateien für Sortierungen, Hashes und temporäre Abfrage-Ergebnisse. Um die Erstellung temporärer Tabellen oder Dateien zu verfolgen, setze log_temp_files in einer benutzerdefinierten Parametergruppe auf 0, um alle temporären Datei-Informationen zu protokollieren. Standardmäßig ist log_temp_files auf -1 gesetzt, sodass Amazon RDS keine temporären Dateien protokolliert. Wenn du log_temp_files auf einen positiven Wert setzt, protokolliert Amazon RDS nur Dateien, die dieser Anzahl von Kilobyte entsprechen oder diese überschreiten.

Verwende EXPLAIN ANALYZE für deine Abfrage, um die Festplattensortierung zu überprüfen. Überprüfe in der Protokollausgabe die Größe der temporären Dateien, die deine Abfrage erstellt. Weitere Informationen findest du unter Optimieren von Sortieroperationen in PostgreSQL mit work_mem.

Überprüfung, ob die Festplattenauslastung von Transaktionsprotokollen ständig zunimmt

Überprüfe die TransactionLogsDiskUsage-Metrik, um den Speicherplatz anzuzeigen, den das Transaktions-WAL verwendet. Ein Anstieg der Festplattennutzung des Transaktionsprotokolls kann aus den folgenden Gründen auftreten:

• Hohe DB-Belastungen durch Schreibvorgänge und Aktualisierungen, die zusätzliche WALs generieren
• Verzögerung beim Streamen von Lesereplikaten in derselben AWS-Region oder Lesereplikaten im Speicherstatus „Voll“
• Replikationsslots

Der AWS Database Migration Service (AWS DMS) kann im Rahmen der logischen Decodierung Replikationsslots erstellen. Für die logische Replikation ist der Slot-Parameter rds.logical_replication auf 1 gesetzt. Replikationsslots speichern die WAL-Dateien, bis ein externer Verbraucher die Dateien verbraucht. Zu den Beispielnutzern gehören pg_recvlogical, Extract, Transform, Load (ETL)-Aufträge und das AWS DMS.

Wenn du rds.logical_replication auf 1 setzt, legt Amazon RDS die Parameter wal_level, max_wal_senders, max_replication_slots und max_connections fest. Diese Parameteränderungen können die WAL-Generierung erhöhen. Es hat sich bewährt, den Parameter rds.logical_replication nur festzulegen, wenn du logische Slots verwendest. Wenn es keinen Verbraucher für die aufbewahrten WAL-Dateien gibt, steigt die Festplattennutzung von Transaktionsprotokollen, und der freie Speicherplatz nimmt kontinuierlich ab.

Führe die folgenden Abfragen aus, um das Vorhandensein und die Größe von Replikationsslots zu überprüfen:

• PostgreSQL v9:

  psql=> SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

• PostgreSQL v10 und höher:

  psql=> SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

Beispielausgabe:

slot_name                                                      | replicationslotlag | active---------------------------------------------------------------+--------------------+--------
xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d    | 129 GB             | f
7pajuy7htthd7sqn_00013322_a27bcebf_7d0f_4124_b336_92d0fb9f5130 | 704 MB             | t
zp2tkfo4ejw3dtlw_00013322_03e77862_689d_41c5_99ba_021c8a3f851a | 624 MB             | t

Replikationsslots, deren aktiver Status auf f (falsch) gesetzt ist, werden nicht verbraucht. In diesem Beispiel hat der Slot xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d einen aktiven f-Zustand. Dieser Slot wird nicht aktiv genutzt, verwendet aber 129 GB an Transaktionsdateien.

Führe die folgende Abfrage aus, um ungenutzte Slots zu löschen:

psql=> SELECT pg_drop_replication_slot('YOUR_SLOTNAME');

Hinweis: Ersetze YOUR_SLOTNAME durch den Slot-Namen.

Beispielausgabe:

psql=> SELECT pg_drop_replication_slot('xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d');

Wenn eine AWS DMS-Aufgabe, die du nicht mehr benötigst, der Verbraucher ist, lösche die Aufgabe und lösche den Replikationsslot manuell.

Überprüfung des Status von regionsübergreifenden oder regionsgleichen Lesereplikaten

Hinweis: Du kannst die folgende Auflösung für Lesereplikate derselben Region nur verwenden, wenn sie auf PostgreSQL 14.1 oder höher ausgeführt werden.

Wenn du eine regionsübergreifende oder regionsgleiche Lesereplikation verwendest, erstellt Amazon RDS einen physischen Replikationsslot auf der primären Instance. Ein Lesereplikats-Fehler kann sich auf den Speicherplatz auf der primären DB-Instance auswirken. Diese Situation tritt auf, wenn die WAL-Dateien nicht im Lesereplikat repliziert werden. Überprüfe die Metriken OldestReplicationSlotLag und TransactionLogsDiskUsage, um zu ermitteln, wie weit das Replikat mit der größten Verzögerung zurückliegt. Du kannst auch sehen, wie viel Speicherplatz WAL-Daten verwenden.

Führe die folgende Abfrage aus, um den Status des Lesereplikats zu überprüfen:

psql=> SELECT * FROM pg_replication_slots;

Weitere Informationen zu pg_replication_slots findest du unter 52.19 pg_replication_slots auf der PostgreSQL-Website. Wenn für die Ausgabe der aktive Zustand auf f gesetzt ist, wird der Slot nicht für die Replikation verwendet.

Du kannst auch die Ansicht pg_stat_replication auf der Quell-Instance verwenden, um die Statistiken für die Replikation zu überprüfen. Weitere Informationen findest du in Table 27.14. pg_stat_replication view (Tabelle 27.14. pg_stat_replication-Ansicht) auf der PostgreSQL-Website.

Prüfung auf Bloats oder unsachgemäße Entfernung von toten Zeilen

In Standard-PostgreSQL-Operationen entfernt PostgreSQL keine toten Zeilen (Tupel), die Benutzer löschen oder die ein UPDATE aus ihrer Tabelle überflüssig macht. Bei Multi-Version Concurrency Control (MVCC)-Implementierungen wird die Zeile nicht sofort aus der Datendatei entfernt, wenn du eine DELETE-Operation ausführst. Stattdessen setzt PostgreSQL das xmax-Feld in einem Header, um die Zeile als gelöscht zu markieren. Aktualisierungen markieren zuerst die zu löschenden Zeilen und führen dann einen Einfüge-Operation durch. Dies ermöglicht Parallelität mit minimaler Sperrung zwischen den verschiedenen Transaktionen. Daher behält PostgreSQL im Rahmen des MVCC-Prozesses verschiedene Zeilenversionen bei.

Tote Zeilen, die nicht bereinigt werden, verbleiben in den Datendateien, bleiben aber für Transaktionen unsichtbar. Diese Zeilen können zu Speicherplatzproblemen führen. Wenn eine Tabelle viele DELETE- und UPDATE-Operationen hat, verbrauchen die toten Tupel möglicherweise viel Speicherplatz (Bloat).

Verwende die VACUUM-Operation, um den Speicherplatz frei zu machen, der von toten Tupeln belegt wird. Beachte, dass VACUUM den freien Speicherplatz nicht für das Dateisystem freigibt. Verwende VACUUM FULL, um den Speicher für das Dateisystem freizugeben. Beachte, dass PostgreSQL beim Ausführen von VACUUM FULL eine exklusive Zugriffssperre auf die Tabelle anwendet. Diese Methode benötigt zusätzlichen Speicherplatz, da VACUUM FULL eine neue Tabellenkopie schreibt und die vorhandene Kopie erst nach Abschluss der Operation freigibt. Es hat sich bewährt, VACUUM FULL nur zu verwenden, wenn du eine beträchtliche Menge an Speicherplatz in der Tabelle zurückgewinnen musst. Es empfiehlt sich auch, regelmäßige Vakuum- oder automatische Vakuumvorgänge an Tabellen durchzuführen, die du häufig aktualisierst. Weitere Informationen findest du unter EXPLAIN auf der PostgreSQL-Website.

Um die geschätzte Anzahl der toten Tupel zu überprüfen, verwende die Ansicht pg_stat_all_tables. Weitere Informationen findest du in Table 27.29. pg_stat_all_tables view (Tabelle 27.29. pg_stat_all_tables-Ansicht) auf der PostgreSQL-Website. In der folgenden Beispieltabelle gibt es 1 999 952 tote Tupel im Datensatz n_dead_tup:

psql => SELECT * FROM pg_stat_all_tables WHERE relname='test';
-[ RECORD 1 ]-------+------------------------------
relid               | 16395
schemaname          | public
relname             | test
seq_scan            | 3
seq_tup_read        | 5280041
idx_scan            |
idx_tup_fetch       |
n_tup_ins           | 2000000
n_tup_upd           | 0
n_tup_del           | 3639911
n_tup_hot_upd       | 0
n_live_tup          | 1635941
n_dead_tup          | 1999952
n_mod_since_analyze | 3999952
last_vacuum         |
last_autovacuum     | 2024-08-16 04:49:52.399546+00
last_analyze        | 2024-08-09 09:44:56.208889+00
last_autoanalyze    | 2024-08-16 04:50:22.581935+00
vacuum_count        | 0
autovacuum_count    | 1
analyze_count       | 1
autoanalyze_count   | 1


psql => VACUUM TEST;

Suche nach verwaisten Dateien

Verwaiste Dateien können auftreten, wenn keine Objekte auf eine Datei verweisen, die im Datenbankverzeichnis vorhanden ist. Dieses Szenario tritt auf, wenn der Instance der Speicherplatz ausgeht oder die Engine während einer Operation wie ALTER TABLE, VACUUM FULL oder CLUSTER abstürzt. Gehe wie folgt vor, um nach verwaisten Dateien zu suchen:

1. Melde dich in jeder Datenbank bei PostgreSQL an.

2. Führe die folgende Abfrage aus, um die verwendete Größe der Datenbank zu ermitteln:

   psql=> SELECT pg_size_pretty(pg_database_size('DATABASE_NAME'));

   Hinweis: Ersetze DATABASE_NAME durch deinen Datenbanknamen.

3. Führe die folgende Abfrage aus, um die tatsächliche Größe der Datenbank zu ermitteln:

   psql=> SELECT pg_size_pretty(SUM(pg_relation_size(oid))) FROM pg_class;

4. Vergleiche die verwendete und die tatsächliche Größe der Datenbank anhand der Ausgaben der vorherigen Befehle. Wenn der Unterschied signifikant ist, belegen verwaiste Dateien möglicherweise Speicherplatz.

Ähnliche Informationen

Arbeiten mit Read Replicas für Amazon RDS for PostgreSQL

Automatisierte Überwachungstools