Festplattenspeicherplatz ist heutzutage eine anspruchsvolle Ressource. Normalerweise möchten Sie Daten so lange wie möglich speichern, aber dies könnte ein Problem sein, wenn Sie nicht die erforderlichen Maßnahmen ergreifen, um ein potenzielles Problem mit „kein Speicherplatz“ zu vermeiden.
In diesem Blog werden wir sehen, wie wir dieses Problem für PostgreSQL erkennen, verhindern und, falls es zu spät ist, einige Optionen finden, die Ihnen wahrscheinlich helfen werden, es zu beheben.
So identifizieren Sie Probleme mit dem Speicherplatz von PostgreSQL
Wenn Sie sich leider in dieser Situation befinden, in der kein Speicherplatz vorhanden ist, können Sie einige Fehler in den PostgreSQL-Datenbankprotokollen sehen:
2020-02-20 19:18:18.131 UTC [4400] LOG: could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on deviceoder sogar in Ihrem Systemprotokoll:
Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]PostgreSQL kann eine Weile weiterarbeiten und schreibgeschützte Abfragen ausführen, aber schließlich wird es beim Versuch, auf die Festplatte zu schreiben, fehlschlagen, dann werden Sie in Ihrer Client-Sitzung so etwas sehen:
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.Wenn Sie sich dann den Speicherplatz ansehen, werden Sie diese unerwünschte Ausgabe haben ...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-vm--125--disk--0 30G 30G 0 100% /So verhindern Sie Probleme mit dem Speicherplatz von PostgreSQL
Der Hauptweg, um diese Art von Problemen zu verhindern, besteht darin, die Speicherplatznutzung und das Wachstum der Datenbank- oder Festplattennutzung zu überwachen. Aus diesem Grund sollte ein Diagramm eine benutzerfreundliche Möglichkeit sein, den Speicherplatzzuwachs zu überwachen:
Und dasselbe für das Datenbankwachstum:
Eine weitere wichtige Sache, die es zu überwachen gilt, ist der Replikationsstatus. Wenn Sie eine Replik haben und diese aus irgendeinem Grund nicht mehr funktioniert, kann es je nach Konfiguration möglich sein, dass PostgreSQL alle WAL-Dateien speichert, um die Replik wiederherzustellen, wenn sie zurückkommt.
Dieses ganze Überwachungssystem macht keinen Sinn, ohne dass ein Warnsystem davon Kenntnis hat wann Sie Maßnahmen ergreifen müssen:
So beheben Sie Probleme mit dem Speicherplatz von PostgreSQL
Nun, wenn Sie dieses Problem mit zu wenig Speicherplatz haben, selbst wenn das Überwachungs- und Warnsystem implementiert ist (oder nicht), gibt es viele Optionen, um zu versuchen, dieses Problem ohne Datenverlust (oder weniger) zu beheben wie möglich).
Was verbraucht Ihren Speicherplatz?
Der erste Schritt sollte darin bestehen, festzustellen, wo sich mein Speicherplatz befindet. Eine bewährte Methode ist es, separate Partitionen zu haben, mindestens eine separate Partition für Ihren Datenbankspeicher, damit Sie leicht feststellen können, ob Ihre Datenbank oder Ihr System übermäßig viel Speicherplatz belegt. Ein weiterer Vorteil besteht darin, den Schaden zu minimieren. Wenn Ihre Root-Partition voll ist, kann Ihre Datenbank immer noch ohne Probleme in ihre eigene Partition schreiben.
Datenbankplatznutzung
Sehen wir uns nun einige nützliche Befehle an, um die Speicherplatznutzung Ihrer Datenbank zu überprüfen.
Ein grundlegender Weg, um die Speicherplatzbelegung der Datenbank zu überprüfen, ist das Überprüfen des Datenverzeichnisses im Dateisystem:
$ du -sh /var/lib/pgsql/11/data/
819M /var/lib/pgsql/11/data/Oder wenn Sie eine separate Partition für Ihr Datenverzeichnis haben, können Sie direkt df -h verwenden.
Der PostgreSQL-Befehl „\l+“ listet die Datenbanken auf und fügt die Größeninformationen hinzu:
$ postgres=# \l+
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace
| Description
-----------+----------+-----------+---------+-------+-----------------------+---------+------------
+--------------------------------------------
postgres | postgres | SQL_ASCII | C | C | | 7965 kB | pg_default
| default administrative connection database
template0 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| unmodifiable empty database
| | | | | postgres=CTc/postgres | |
|
template1 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| default template for new databases
| | | | | postgres=CTc/postgres | |
|
world | postgres | SQL_ASCII | C | C | | 8629 kB | pg_default
|
(4 rows)Mit pg_database_size und dem Datenbanknamen können Sie die Datenbankgröße sehen:
postgres=# SELECT pg_database_size('world');
pg_database_size
------------------
8835743
(1 row)Und die Verwendung von pg_size_pretty, um diesen Wert in einer für Menschen lesbaren Weise anzuzeigen, könnte sogar noch besser sein:
postgres=# SELECT pg_size_pretty(pg_database_size('world'));
pg_size_pretty
----------------
8629 kB
(1 row)Wenn Sie wissen, wo Platz ist, können Sie die entsprechenden Maßnahmen ergreifen, um ihn zu reparieren. Denken Sie daran, dass das Löschen von Zeilen nicht ausreicht, um den Speicherplatz wiederherzustellen. Sie müssen ein VACUUM oder VACUUM FULL ausführen, um die Aufgabe abzuschließen.
Protokolldateien
Der einfachste Weg, Speicherplatz freizugeben, ist das Löschen von Protokolldateien. Sie können das PostgreSQL-Protokollverzeichnis oder sogar die Systemprotokolle überprüfen, um zu überprüfen, ob Sie dort etwas Speicherplatz gewinnen können. Wenn Sie so etwas haben:
$ du -sh /var/lib/pgsql/11/data/log/
18G /var/lib/pgsql/11/data/log/Sie sollten den Inhalt des Verzeichnisses überprüfen, um festzustellen, ob es ein Problem mit der Log-Rotation/Aufbewahrung gibt oder ob etwas in Ihrer Datenbank passiert und es in die Logs schreibt.
$ ls -lah /var/lib/pgsql/11/data/log/
total 18G
drwx------ 2 postgres postgres 4.0K Feb 21 00:00 .
drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..
-rw------- 1 postgres postgres 18G Feb 21 14:46 postgresql-Fri.log
-rw------- 1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log
-rw------- 1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.logBevor Sie die Protokolle löschen, wenn Sie ein großes haben, ist es eine gute Praxis, die letzten 100 Zeilen oder so zu behalten und sie dann zu löschen. So können Sie überprüfen, was nach dem Generieren von freiem Speicherplatz passiert.
$ tail -100 postgresql-Fri.log > /tmp/log_temp.logUnd dann:
$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.logWenn Sie es einfach mit „rm“ löschen und die Protokolldatei vom PostgreSQL-Server (oder einem anderen Dienst) verwendet wird, wird kein Speicherplatz freigegeben, also sollten Sie diese Datei mit diesem cat / stattdessen den Befehl dev/null.
Diese Aktion gilt nur für PostgreSQL- und Systemprotokolldateien. Löschen Sie nicht den pg_wal-Inhalt oder eine andere PostgreSQL-Datei, da dies Ihrer Datenbank kritischen Schaden zufügen könnte.
Aufblasen
Bei einem normalen PostgreSQL-Vorgang werden Tupel, die durch eine Aktualisierung gelöscht oder veraltet sind, nicht physisch aus der Tabelle entfernt; sie sind vorhanden, bis ein VAKUUM durchgeführt wird. Daher ist es notwendig, das VAKUUM regelmäßig durchzuführen (AUTOVAKUUM), insbesondere in häufig aktualisierten Tabellen.
Das Problem hierbei ist, dass Speicherplatz nicht einfach durch VACUUM an das Betriebssystem zurückgegeben wird, er steht nur zur Verwendung in derselben Tabelle zur Verfügung.
VACUUM FULL schreibt die Tabelle in eine neue Plattendatei um und gibt den ungenutzten Speicherplatz an das Betriebssystem zurück. Leider erfordert es eine exklusive Sperre für jede Tabelle, während es läuft.
Sie sollten die Tabellen überprüfen, um festzustellen, ob ein VACUUM (FULL)-Prozess erforderlich ist.
Replikationsslots
Wenn Sie Replikationsslots verwenden und diese aus irgendeinem Grund nicht aktiv sind:
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
slot1 | physical | f
(1 row)Es könnte ein Problem für Ihren Speicherplatz sein, weil es die WAL-Dateien speichert, bis sie von allen Standby-Knoten empfangen wurden.
Der Weg, es zu beheben, ist die Wiederherstellung des Replikats (falls möglich) oder das Löschen des Steckplatzes:
postgres=# SELECT pg_drop_replication_slot('slot1');
pg_drop_replication_slot
--------------------------
(1 row)Also wird der von den WAL-Dateien belegte Speicherplatz freigegeben.
Fazit
Wie bereits erwähnt, sind Überwachungs- und Warnsysteme der Schlüssel zur Vermeidung dieser Art von Problemen. Auf diese Weise kann ClusterControl Ihnen dabei helfen, Ihre Systeme zum Laufen zu bringen, Ihnen bei Bedarf Alarme zu senden oder sogar Wiederherstellungsmaßnahmen zu ergreifen, damit Ihr Datenbank-Cluster weiterhin funktioniert. Sie können auch verschiedene Datenbanktechnologien bereitstellen/importieren und bei Bedarf skalieren.
