Schijfruimte is tegenwoordig een veeleisende bron. Meestal wilt u gegevens zo lang mogelijk bewaren, maar dit kan een probleem zijn als u niet de nodige acties onderneemt om een mogelijk probleem met onvoldoende schijfruimte te voorkomen.
In deze blog zullen we zien hoe we dit probleem voor PostgreSQL kunnen detecteren, voorkomen, en als het te laat is, enkele opties die u waarschijnlijk zullen helpen het probleem op te lossen.
Problemen met PostgreSQL-schijfruimte identificeren
Als u zich helaas in deze situatie met onvoldoende schijfruimte bevindt, kunt u enkele fouten in de PostgreSQL-databaselogboeken zien:
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 deviceof zelfs in uw systeemlogboek:
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 kan een tijdje blijven werken met alleen-lezen query's, maar uiteindelijk zal het niet proberen om naar schijf te schrijven, dan zul je zoiets als dit zien in je clientsessie:
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.Als je dan naar de schijfruimte kijkt, krijg je deze ongewenste uitvoer...
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-vm--125--disk--0 30G 30G 0 100% /Problemen met PostgreSQL-schijfruimte voorkomen
De belangrijkste manier om dit soort problemen te voorkomen, is door het schijfruimtegebruik en de groei van het database- of schijfgebruik te controleren. Hiervoor moet een grafiek een vriendelijke manier zijn om de toename van de schijfruimte te controleren:
En hetzelfde voor de databasegroei:
Een ander belangrijk ding om te controleren is de replicatiestatus. Als je een replica hebt en deze werkt om de een of andere reden niet meer, afhankelijk van de configuratie, kan het zijn dat PostgreSQL alle WAL-bestanden opslaat om de replica te herstellen wanneer deze terugkomt.
Dit bewakingssysteem heeft geen zin zonder een waarschuwingssysteem om te weten wanneer u actie moet ondernemen:
Problemen met PostgreSQL-schijfruimte oplossen
Nou, als je te maken krijgt met dit probleem met onvoldoende schijfruimte, zelfs met het monitoring- en waarschuwingssysteem geïmplementeerd (of niet), zijn er veel opties om te proberen dit probleem op te lossen zonder gegevensverlies (of minder mogelijk).
Wat verbruikt uw schijfruimte?
De eerste stap zou moeten zijn om te bepalen waar mijn schijfruimte is. Een best practice is om aparte partities te hebben, ten minste één aparte partitie voor uw databaseopslag, zodat u gemakkelijk kunt controleren of uw database of uw systeem overmatige schijfruimte gebruikt. Een ander voordeel hiervan is dat de schade tot een minimum wordt beperkt. Als je rootpartitie vol is, kan je database nog steeds zonder problemen in zijn eigen partitie schrijven.
Gebruik van databaseruimte
Laten we eens kijken naar enkele nuttige commando's om het gebruik van uw databaseschijfruimte te controleren.
Een eenvoudige manier om het gebruik van de databaseruimte te controleren, is door de gegevensmap in het bestandssysteem te controleren:
$ du -sh /var/lib/pgsql/11/data/
819M /var/lib/pgsql/11/data/Of als u een aparte partitie voor uw gegevensmap heeft, kunt u df -h rechtstreeks gebruiken.
Het PostgreSQL-commando "\l+" geeft een lijst van de databases die de grootte-informatie toevoegen:
$ 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)Met pg_database_size en de databasenaam kunt u de databasegrootte zien:
postgres=# SELECT pg_database_size('world');
pg_database_size
------------------
8835743
(1 row)En het zou nog beter kunnen zijn om de pg_size_pretty te gebruiken om deze waarde op een voor mensen leesbare manier te zien:
postgres=# SELECT pg_size_pretty(pg_database_size('world'));
pg_size_pretty
----------------
8629 kB
(1 row)Als je weet waar ruimte is, kun je de bijbehorende actie ondernemen om het te repareren. Houd er rekening mee dat alleen het verwijderen van rijen niet voldoende is om schijfruimte vrij te maken, u moet een VACUUM of VACUUM FULL uitvoeren om de taak te voltooien.
Logbestanden
De gemakkelijkste manier om schijfruimte vrij te maken is door logbestanden te verwijderen. U kunt de PostgreSQL-logboekmap of zelfs de systeemlogboeken controleren om te controleren of u daar wat ruimte kunt winnen. Als je zoiets hebt:
$ du -sh /var/lib/pgsql/11/data/log/
18G /var/lib/pgsql/11/data/log/U moet de inhoud van de directory controleren om te zien of er een probleem is met de rotatie/retentie van logboeken of dat er iets gebeurt in uw database en dit naar de logboeken schrijft.
$ 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.logVoordat u de logboeken verwijdert, is het een goede gewoonte om de laatste 100 regels of zo te bewaren en deze vervolgens te verwijderen als u een grote heeft. U kunt dus controleren wat er gebeurt nadat u vrije ruimte heeft gegenereerd.
$ tail -100 postgresql-Fri.log > /tmp/log_temp.logEn dan:
$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.logAls je het gewoon verwijdert met "rm" en het logbestand wordt gebruikt door de PostgreSQL-server (of een andere service), wordt ruimte niet vrijgegeven, dus je moet dit bestand afkappen met deze cat / dev/null-opdracht in plaats daarvan.
Deze actie is alleen voor PostgreSQL- en systeemlogbestanden. Verwijder de pg_wal-inhoud of een ander PostgreSQL-bestand niet, omdat dit kritieke schade aan uw database kan veroorzaken.
Bloat
In een normale PostgreSQL-bewerking worden tuples die door een update zijn verwijderd of verouderd, niet fysiek uit de tabel verwijderd; ze zijn aanwezig totdat een VACUM wordt uitgevoerd. Het is dus noodzakelijk om het VACUM periodiek uit te voeren (AUTOVACUUM), vooral in regelmatig bijgewerkte tabellen.
Het probleem hier is dat de ruimte niet wordt teruggegeven aan het besturingssysteem met alleen VACUM, het is alleen beschikbaar voor gebruik in dezelfde tabel.
VACUUM FULL herschrijft de tabel naar een nieuw schijfbestand en geeft de ongebruikte ruimte terug aan het besturingssysteem. Helaas vereist het een exclusief slot op elke tafel terwijl het actief is.
Controleer de tabellen om te zien of een VACUM (VOL) proces vereist is.
Replicatieslots
Als u replicatieslots gebruikt en deze om de een of andere reden niet actief is:
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
slot1 | physical | f
(1 row)Het kan een probleem zijn voor uw schijfruimte omdat het de WAL-bestanden zal opslaan totdat ze zijn ontvangen door alle standby-knooppunten.
De manier om dit op te lossen is het herstellen van de replica (indien mogelijk) of het verwijderen van het slot:
postgres=# SELECT pg_drop_replication_slot('slot1');
pg_drop_replication_slot
--------------------------
(1 row)De ruimte die door de WAL-bestanden wordt gebruikt, wordt dus vrijgegeven.
Conclusie
Zoals we al zeiden, zijn monitoring- en waarschuwingssystemen de sleutels om dit soort problemen te voorkomen. Op deze manier kan ClusterControl u helpen om uw systemen up-and-running te hebben, u alarmen te sturen wanneer dat nodig is of zelfs herstelacties te ondernemen om uw databasecluster werkend te houden. U kunt ook verschillende databasetechnologieën implementeren/importeren en indien nodig uitschalen.