Warum habe ich in Amazon RDS for PostgreSQL die Fehlermeldung „Kein Speicherplatz mehr auf dem Gerät“ oder „DiskFull“ erhalten?

Lesedauer: 10 Minute
0

Ich habe eine kleine Amazon Relational Database Service (Amazon RDS) für PostgreSQL-Datenbank. Der freie Speicherplatz der Instanz nimmt ab, und ich erhalte den folgenden Fehler: "Fehlermeldung: PG: :Disk Full: FEHLER: Datei „base/16394/5139755" konnte nicht erweitert werden: Auf dem Gerät ist kein Speicherplatz mehr übrig. HINWEIS: Prüfen Sie den freien Speicherplatz.“ Ich möchte die DiskFull-Fehler beheben und Speicherprobleme vermeiden.

Kurzbeschreibung

Amazon RDS DB-Instance-Speicher wird von folgenden Personen verwendet:

  • Temporäre Tabellen oder Dateien, die durch PostgreSQL-Transaktionen erstellt werden
  • Datendateien
  • Vorausschauprotokolle schreiben (WAL-Logs)
  • Replikationssteckplätze
  • DB-Logs (Fehlerdateien), die zu lange aufbewahrt werden
  • Andere DB- oder Linux-Dateien, die den konsistenten Status der RDS-DB-Instance unterstützen

Auflösung

  1. Verwenden Sie Amazon CloudWatch, um Ihren DB-Speicherplatz mithilfe der ** FreeStorageSpace-Metrik zu überwachen. **. Wenn Sie einen CloudWatch-Alarm für freien Speicherplatz einrichten, erhalten Sie eine Benachrichtigung, wenn der Speicherplatz abnimmt. Wenn Sie einen Alarm erhalten, überprüfen Sie die zuvor genannten Ursachen für Speicherprobleme.

  2. Wenn Ihre DB-Instance immer noch mehr Speicherplatz verbraucht als erwartet, überprüfen Sie Folgendes:

  • Größe der DB-Logdateien
  • Vorhandensein temporärer Dateien
  • Ständiger Anstieg der Festplattennutzung von Transaktionsprotokollen
  • Replikationssteckplatz:
  • Physikalische Replikations-Slots werden von regionenübergreifenden Lese-Replikaten oder Lese-Replikaten derselben Region nur dann erstellt, wenn sie auf PostgreSQL 14.1 und höheren Versionen laufen
  • Logische Replikationsslots werden für ein Replikat oder einen Abonnenten erstellt
  • Aufblähung oder unsachgemäßes Entfernen von toten Reihen
  • Vorhandensein verwaister Dateien
  1. Wenn Ihr Workload vorhersehbar ist, aktivieren Sie die automatische Speicherskalierung für Ihre Instance. Wenn die automatische Speicherskalierung aktiviert ist, wird Ihr Speicher automatisch skaliert, wenn Amazon RDS feststellt, dass Ihnen der freie Datenbankspeicher ausgeht. Amazon RDS startet eine Speicheränderung für eine Autoscaling-fähige DB-Instance, wenn die folgenden Faktoren zutreffen:
  • Der frei verfügbare Speicherplatz macht weniger als 10 Prozent des zugewiesenen Speichers aus.
  • Der Zustand bei geringer Lagerung hält mindestens fünf Minuten an.
  • Seit der letzten Speicheränderung sind mindestens sechs Stunden vergangen, oder die Speicheroptimierung wurde auf der Instance abgeschlossen, je nachdem, welcher Zeitraum länger ist.

Sie können ein Limit für die automatische Skalierung Ihrer DB-Instance festlegen, indem Sie den maximalen Speicherschwellenwert festlegen. Weitere Informationen finden Sie unter Automatisches Verwalten von Kapazität mit Amazon RDS-Speicher-Autoscaling.

Überprüfen Sie die Größe der DB-Logdateien

Standardmäßig haben Amazon RDS for PostgreSQL-Fehlerprotokolldateien einen Aufbewahrungswert von 4.320 Minuten (drei Tagen). Große Protokolldateien können aufgrund höherer Arbeitslasten oder übermäßiger Protokollierung mehr Speicherplatz beanspruchen. Sie können den Aufbewahrungszeitraum für Systemprotokolle mithilfe des Parameters ** rds.log\ _retention\ _period in der ** DB-Parametergruppe ändern, die Ihrer DB-Instance zugeordnet ist. Wenn Sie den Wert beispielsweise auf 1440 festlegen, werden die Protokolle für einen Tag aufbewahrt. Weitere Informationen finden Sie unter PostgreSQL-Datenbank-Logdateien. .

Sie können auch die Parameter für Fehlerberichte und Protokollierung in der DB-Parametergruppe ändern, um eine übermäßige Protokollierung zu vermeiden. Dies wiederum reduziert die Größe der Protokolldatei. Weitere Informationen finden Sie unter Fehlerberichterstattung und Protokollierung.

Suchen Sie nach temporären Dateien

Temporäre Dateien sind Dateien, die pro Backend- oder Sitzungsverbindung gespeichert werden. Diese Dateien werden als Ressourcenpool verwendet. Überprüfen Sie die Statistiken zu temporären Dateien, indem Sie einen Befehl ausführen, der dem folgenden ähnelt:

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 view ** pg\ _stat\ _database sammeln Statistiken in aggregierter Form (**kumulativ). Dies ist beabsichtigt, da diese Zähler nur durch Wiederherstellung beim Serverstart zurückgesetzt werden. Das heißt, die Zähler werden nach einem sofortigen Herunterfahren, einem Serverabsturz oder einer Point-in-Time-Wiederherstellung (PITR) zurückgesetzt. Aus diesem Grund empfiehlt es sich, das Wachstum dieser Dateien in Bezug auf Anzahl und Größe zu überwachen, anstatt nur die Ausgabe zu überprüfen.

Temporäre Dateien werden für Sortierungen, Hashes oder temporäre Abfrageergebnisse erstellt. Um die Erstellung temporärer Tabellen oder Dateien zu verfolgen, legen Sie ** log\ _temp\ _files ** in einer benutzerdefinierten Parametergruppe fest. Dieser Parameter steuert die Protokollierung von temporären Dateinamen und -größen. Wenn Sie den ** Wert ** log\ _temp\ _files auf ** 0 setzen**, werden alle temporären Dateiinformationen protokolliert. Wenn Sie den Parameter auf einen positiven Wert setzen, werden nur Dateien protokolliert, die gleich oder größer als die angegebene Anzahl von Kilobyte sind. Die Standardeinstellung ist ** -1**, wodurch die Protokollierung temporärer Dateien deaktiviert wird.

Sie können Ihre Abfrage auch mit ** EXPLAIN ** ANALYZE überprüfen, um die Festplattensortierung zu überprüfen. Wenn Sie die Protokollausgabe überprüfen, können Sie die Größe der temporären Dateien sehen, die durch Ihre Abfrage erstellt wurden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zur Überwachung der Datenbankaktivität. .

Prüfen Sie, ob die Festplattenauslastung von Transaktionsprotokollen ständig zunimmt

Die CloudWatch-Metrik für ** TransactionLogsDiskUsage ** stellt den von Transaktions-WALs verwendeten Festplattenspeicher dar. Eine Erhöhung der Festplattennutzung im Transaktionsprotokoll kann folgende Ursachen haben:

  • Hohe DB-Auslastung (Schreibvorgänge und Aktualisierungen, die zusätzliche WALs generieren)
  • Streaming-Read-Replikat-Verzögerung (Replikate in derselben Region) oder Read Replica im vollen Speicherstatus
  • Replikationssteckplätze

Replikationsslots können als Teil der logischen Dekodierungsfunktion von AWS Database Migration Service (AWS DMS) erstellt werden. Für die logische Replikation ist der Slot-Parameter ** rds.logical\ _replication auf 1 ** gesetzt. ** **. Replikationssteckplätze behalten die WAL-Dateien, bis die Dateien extern von einem Verbraucher verwendet werden. Sie könnten beispielsweise von pg\ _recvlogical-, extract, transform, load (ETL) -Jobs oder AWS DMS genutzt werden.

Wenn Sie den Wert des ** rds.logical\ ** _replication-Parameters auf ** 1 setzen**, legt AWS RDS die Parameter ** wal\ _level**, ** max\ _wal\ _senders**, max\ _replication\ _slots und ** max\ _connections fest. ****** . Eine Änderung dieser Parameter kann die WAL-Generierung erhöhen. Es hat sich bewährt, den ** Parameter ** rds.logical\ _replication nur festzulegen, wenn Sie logische Steckplätze verwenden. Wenn dieser Parameter auf ** 1 gesetzt ist ** und logische Replikationssteckplätze vorhanden sind, es aber keinen Verbraucher für die vom Replikationssteckplatz gespeicherten WAL-Dateien gibt, kann die Festplattenauslastung der Transaktionsprotokolle steigen. Dies führt auch zu einer ständigen Verringerung des freien Speicherplatzes.

Führen Sie diese Abfrage aus, um das Vorhandensein und die Größe von Replikationssteckplätzen zu bestätigen:

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 weiter:

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

Nachdem Sie den Replikationsslot identifiziert haben, der nicht genutzt wird (mit einem aktiven Status, der ** False ist**), löschen Sie den Replikationsslot, indem Sie die folgende Abfrage ausführen:

psql=> SELECT pg_drop_replication_slot('Your_slotname_name');

Hinweis: Wenn es sich bei einer AWS DMS-Aufgabe um den Verbraucher handelt und diese nicht mehr benötigt wird, löschen Sie die Aufgabe und löschen Sie den Replikationsslot manuell.

Beispiel für eine Ausgabe:

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

In diesem Beispiel hat der Slot-Name ** xc36ujql35djp\ _00013322\ _907c1e0a\ _9f8b\ _4c13\ _89ea\ _ef0ea1cf143d den aktiven Status False. ** ** **. Dieser Steckplatz wird also nicht aktiv genutzt und der Steckplatz trägt zu 129 GB an Transaktionsdateien bei.

Löschen Sie die Abfrage, indem Sie den folgenden Befehl ausführen:

psql=> SELECT pg_drop_replication_slot('xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d');

Überprüfen Sie den Status von regionsübergreifenden Read Replicas

Wenn Sie die regionsübergreifende Lesereplikation verwenden, wird ein physischer Replikationsslot auf der primären Instance erstellt. Wenn das regionsübergreifende Read Replica ausfällt, kann dies Auswirkungen auf den Speicherplatz auf der primären DB-Instance haben. Dies liegt daran, dass die WAL-Dateien nicht auf das Read Replica repliziert werden. Sie können CloudWatch-Metriken, die Verzögerung beim ältesten Replikationsslot und die Festplattenauslastung der Transaktionsprotokolle verwenden, um festzustellen, wie weit das Replikat mit der größten Verzögerung zurückliegt. Sie können auch sehen, wie viel Speicherplatz für WAL-Daten verwendet wird.

Verwenden Sie die ** Abfrage pg\ _replication\ _slots, um den Status der regionsübergreifenden Read Replica zu überprüfen. . Weitere Informationen finden Sie in der PostgreSQL-Dokumentation für pg\ _replication\ _slots. . Wenn der aktive Status als ** falsch zurückgegeben wird, wird der Slot derzeit nicht für die Replikation verwendet.

psql=> SELECT * FROM pg_replication_slots;

Sie können auch view ** pg\ _stat\ _replication ** auf der Quellinstanz verwenden, um die Statistiken für die Replikation zu überprüfen. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation für pg\ _stat\ _replication. .

Prüfung auf Aufblähung oder unsachgemäße Entfernung von toten Zeilen (Tupeln)

Bei normalen PostgreSQL-Operationen werden Tupel, die durch ein ** UPDATE gelöscht oder veraltet werden, ** nicht aus ihrer Tabelle entfernt. Bei MVCC-Implementierungen (Multi-Version Concurrency Control) wird die Zeile nicht sofort aus der Datendatei entfernt, wenn ein ** ** DELETE-Vorgang ausgeführt wird. Stattdessen wird die Zeile als gelöscht markiert, indem das ** xmax-Feld ** in einer Kopfzeile festgelegt wird. Aktualisierungen markieren zuerst die zu löschenden Zeilen und führen dann einen Einfügevorgang durch. Dies ermöglicht Parallelität mit minimaler Sperrung zwischen den verschiedenen Transaktionen. Daher werden im Rahmen des MVCC-Prozesses verschiedene Zeilenversionen beibehalten.

Wenn tote Zeilen nicht bereinigt werden, können sie in den Datendateien verbleiben, bleiben aber für jede Transaktion unsichtbar, was sich auf den Speicherplatz auswirkt. Wenn eine Tabelle viele ** DELETE ** - und ** ** UPDATE-Operationen hat, verbrauchen die toten Tupel möglicherweise eine große Menge an Speicherplatz, was in PostgreSQL manchmal als „Bloat“ bezeichnet wird.

Die VACUUM-Operation kann den von toten Tupeln verwendeten Speicher freigeben, sodass er wiederverwendet werden kann, aber dadurch wird der freie Speicherplatz nicht für das Dateisystem freigegeben. Wenn VACUUM FULL ausgeführt wird, wird der Speicher für das Dateisystem freigegeben. Beachten Sie jedoch, dass während des VACUUM FULL-Laufs eine Zugriffssperre am Tisch angebracht ist. Diese Methode benötigt außerdem zusätzlichen Speicherplatz, da eine neue Kopie der Tabelle geschrieben wird und die alte Kopie erst freigegeben wird, wenn der Vorgang abgeschlossen ist. Es hat sich bewährt, diese Methode nur zu verwenden, wenn Sie in der Tabelle viel Speicherplatz zurückgewinnen müssen. Es ist auch eine bewährte Methode, regelmäßige Vakuum- oder Autovakuumvorgänge an Tabellen durchzuführen, die häufig aktualisiert werden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation für VACUUM. .

Um die geschätzte Anzahl der toten Tupel zu überprüfen, verwenden Sie die Ansicht ** pg\ _stat\ _all\ _tables. **. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation für die Ansicht pg\ _stat\ _all\ _tables. . In diesem Beispiel gibt es 1999952 tote Tupel (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     | 2018-08-16 04:49:52.399546+00
last_analyze        | 2018-08-09 09:44:56.208889+00
last_autoanalyze    | 2018-08-16 04:50:22.581935+00
vacuum_count        | 0
autovacuum_count    | 1
analyze_count       | 1
autoanalyze_count   | 1


psql => VACUUM TEST;

Suchen Sie nach verwaisten Dateien

Verwaiste Dateien können auftreten, wenn die Dateien im Datenbankverzeichnis vorhanden sind, es aber keine Objekte gibt, die auf diese Dateien verweisen. Dies kann passieren, wenn Ihrer Instance der Speicherplatz ausgeht oder die Engine während eines Vorgangs wie ** ALTER TABLE**, ** VACUUM FULL ** oder ** CLUSTER abstürzt**. Gehen Sie folgendermaßen vor, um nach verwaisten Dateien zu suchen:

  1. Melden Sie sich in jeder Datenbank bei PostgreSQL an.

  2. Führen Sie diese Abfragen aus, um die verwendeten und die tatsächlichen Größen zu ermitteln.

# Size of the database occupied by files
psql=> SELECT pg_size_pretty(pg_database_size('DATABASE_NAME'));

# Size of database retrieved by summing the objects (real size)
psql=> SELECT pg_size_pretty(SUM(pg_relation_size(oid))) FROM pg_class;
  1. Notieren Sie sich die Ergebnisse. 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