Gérer l'espace disque plein dans postgresql

J'ai une application web Django avec backend postgresql 9.3.10 (assis dans un OS Linux). J'ai rencontré une erreur de disque plein, de sorte que même si j'essaie de tronquer une table, j'obtiens des erreurs de la sorte:

ERROR:  could not extend file "base/30137/33186048": No space left on device
HINT:  Check free disk space.

Je ne peux pas facilement ajouter plus d'espace disque au serveur, ni supprimer des éléments sur cette machine virtuelle. Cependant, il existe plusieurs tables qui sont candidates à la troncature, mais il semble que je ne puisse pas les tronquer maintenant non plus.

Quelqu'un peut-il me donner des conseils sur ce que je peux faire ici? Cela frappe durement mon serveur de production, et je suis un peu un DBA accidentel ici, donc totalement perplexe.

postgresql postgresql-9.3

— Hassan Baig
source

Vous pouvez récupérer de l'espace si vous pouvez (temporairement) supprimer un index ... tronquer des tables, puis le recréer

— joanolo

Étant donné que PostgreSQL doit écrire WAL avant d'apporter des modifications aux tables, il a besoin d'espace disque libre pour supprimer des éléments et libérer plus d'espace disque.

Si vous laissez le disque se remplir, vous ne pourrez pas récupérer depuis PostgreSQL. Même TRUNCATEdoit encore écrire à WAL.

Vous devez donc libérer de l'espace sur le volume ou augmenter le volume. Si vos fichiers journaux PostgreSQL se trouvent dans pg_logle répertoire de données, vous pouvez supprimer certains d'entre eux en toute sécurité et redémarrer Pg.

Ne supprimez paspg_xlog ou pg_clog. Ce ne sont pas des journaux d'erreurs du serveur, ce sont des parties critiques de la base de données, le journal des transactions et le journal de validation.

— Craig Ringer
source

Pourquoi faut TRUNCATE-il écrire à wal, et à quoi ressemble cette entrée dans WAL?

— Evan Carroll

"truncate n'enregistre pas les données complètes, seulement le fait qu'une troncature s'est produite. Afin de pouvoir la restaurer, le fichier sous-jacent est conservé jusqu'à ce que la transaction soit validée." [source] ( postgresql.org/message-id/... donc l' entrée de troncature dans le mur est super petit octets simples Si tel était l'ensemble de la charge de l' espace nécessaire, vous pourriez probablement obtenir par.. rm -rf /tmp/*ou la suppression de votre vimrc.

— Evan Carroll

@EvanCarroll rm -rf /tmp/*... qui peut également supprimer des éléments que vous pourriez souhaiter, tels que des sockets d'application, etc. Mieux vaut être plus sélectif. En ce qui concerne l'espace nécessaire, vous avez raison, c'est minime - une table vide de 8 Ko + quelques kb d'entrées WAL pour la troncature, l'allocation xid, l'enregistrement de validation, etc.

— Craig Ringer